Atrius India Core FHIR Implementation Guide
0.1.0 - ci-build

Atrius India Core FHIR Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Er Chest Pain Frontend Contract

ER chest pain pathway — minimal frontend contract

Minimal integration contract for an ED frontend (physician UI) working with the Atrius ER chest pain pathway: show the classification questionnaire, persist QuestionnaireResponse, then receive branch-specific CDS recommendations.

Related: ER chest pain pathway, CDS clinical reasoning.

1. Roles

Component Port (local) Frontend uses it for
Clinical HFS 8082 Read/write chart (Patient, Encounter, QuestionnaireResponse, …)
KR HFS 8079 Read Questionnaire, PlanDefinition, Library (after IG publish)
cds-server 8095 CDS Hooks discovery + $apply → pathway cards / RequestGroup
cr-fhir-bridge 8081 Optional read proxy (CDS engine uses this; frontend usually talks to 8082 directly for writes)

Profile: All clinical writes use AtriusInQuestionnaireResponse
(https://atrius.in/fhir/r4/atrius-in/StructureDefinition/atrius-in-questionnaireresponse).

2. Sequence (happy path)

Physician starts ED encounter (chest pain)
        │
        ▼
① POST cds-server /cds-services/er-chest-pain-pathway  (hook: encounter-start)
        │  → cards: "Initial assessment", "Complete classification", maybe branch hints
        ▼
② Physician completes history / exam (outside this contract — native ED UI)
        │
        ▼
③ GET Questionnaire/er-chest-pain-classification  (form definition)
        │
        ▼
④ Render single-choice form (linkId: primary-classification)
        │
        ▼
⑤ POST QuestionnaireResponse → Clinical HFS  (status: completed)
        │
        ▼
⑥ POST cds-server again (same hook + prefetch including new QR)
        │  → cards / RequestGroup for branch (e.g. ACS: ECG, troponin, aspirin, consult)
        ▼
⑦ Physician accepts / places orders (native order entry — future ActivityDefinition wiring)

3. When to invoke CDS

Event Call CDS?
ED encounter started / opened, chief complaint includes chest pain Yes — encounter-start
After classification QR saved Yes — same service, re-invoke with same hook
Patient viewed elsewhere without active ED chest pain encounter No

Service id: er-chest-pain-pathway
Hook: encounter-start
PlanDefinition: https://atrius.in/fhir/r4/atrius-in/PlanDefinition/er-chest-pain-pathway|0.1.0

Pathway applicability (In Scope) is evaluated server-side from prefetched chart data — including an active EMER encounter with chest pain chief complaint. encounterId is required in hook context.

4. CDS Hooks — invoke

Discovery

GET http://127.0.0.1:8095/cds-services

Find service with "id": "er-chest-pain-pathway".

Invoke (minimal body)

POST http://127.0.0.1:8095/cds-services/er-chest-pain-pathway
Content-Type: application/json

{
  "hook": "encounter-start",
  "hookInstance": "<uuid — new per invocation>",
  "context": {
    "patientId": "<patient-id>",
    "encounterId": "<encounter-id>",
    "userId": "Practitioner/<practitioner-id>"
  },
  "prefetch": {
    "patient": { "resourceType": "Patient", "id": "<patient-id>", "...": "..." },
    "encounter": { "resourceType": "Encounter", "id": "<encounter-id>", "...": "..." },
    "conditions": [],
    "observations": [],
    "questionnaireResponses": []
  }
}

Prefetch notes

  • Keys must match what the cds-server manifest / PlanDefinition expects (align with your manifest generator output).
  • Include questionnaireResponses on the second call (after step ⑤), filtered to the current encounter if possible.
  • encounter should be emergency class (EMER) with chest pain reasonCode (SNOMED 29857009) for In Scope to pass.
  • Omitted prefetch may still work if cds-server resolves from FHIR server — confirm in your manifest; explicit prefetch is safer for v0.1.

Response (conceptual): CDS Hooks card array with embedded RequestGroup in card extension
https://atrius.dev/cds-clinical-reasoning-request-group → requestGroup.
Branch actions such as branch-acs appear nested under chest-pain-classification → action[], not at the RequestGroup root (UI must search recursively).

5. Load the questionnaire (form definition)

Canonical

https://atrius.in/fhir/r4/atrius-in/Questionnaire/er-chest-pain-classification|0.2.0

Fetch options (pick one for v0.1)

Source Request
KR (after IG publish) GET http://127.0.0.1:8079/Questionnaire/er-chest-pain-classification
IG build artifact Ship output/Questionnaire-er-chest-pain-classification.json with the frontend release

Form shape (fixed for v0.2)

Field Value
item[0].linkId primary-classification
item[0].type choice
item[0].required true
item[0].repeats false
item[0].text Working classification of chest pain etiology (after initial assessment)
Allowed answers ValueSet atrius-in-er-chest-pain-classification-vs (7 codes below)

You may expand the ValueSet client-side or $expand via HTS (9091) in production.

6. Answer codes (must match exactly)

Use these valueCoding entries in the submitted QuestionnaireResponse. CQL matches on CodeSystem + code.

UI label system code Pathway branch
Acute coronary syndrome https://atrius.in/fhir/r4/atrius-in/CodeSystem/atrius-in-er-chest-pain-classification-cs acs ACS order set
Aortic dissection ↑ aortic-dissection Other cardiac
Pericarditis ↑ pericarditis Other cardiac
Pneumothorax ↑ pneumothorax Non-cardiac pulmonary
Pleurisy or pneumonia ↑ pleurisy-pneumonia Non-cardiac pulmonary
Musculoskeletal chest pain ↑ musculoskeletal Other
Heartburn or GERD ↑ heartburn Other

7. Save QuestionnaireResponse (clinical write)

Request

POST http://127.0.0.1:8082/QuestionnaireResponse
Content-Type: application/fhir+json

(or PUT with client-assigned id)

Minimal resource body

{
  "resourceType": "QuestionnaireResponse",
  "meta": {
    "profile": [
      "https://atrius.in/fhir/r4/atrius-in/StructureDefinition/atrius-in-questionnaireresponse"
    ]
  },
  "questionnaire": "https://atrius.in/fhir/r4/atrius-in/Questionnaire/er-chest-pain-classification|0.2.0",
  "status": "completed",
  "subject": { "reference": "Patient/<patient-id>" },
  "encounter": { "reference": "Encounter/<encounter-id>" },
  "authored": "2026-06-11T08:35:00+05:30",
  "author": { "reference": "Practitioner/<practitioner-id>" },
  "item": [
    {
      "linkId": "primary-classification",
      "text": "Working classification of chest pain etiology (after initial assessment)",
      "answer": [
        {
          "valueCoding": {
            "system": "https://atrius.in/fhir/r4/atrius-in/CodeSystem/atrius-in-er-chest-pain-classification-cs",
            "code": "acs",
            "display": "Acute coronary syndrome"
          }
        }
      ]
    }
  ]
}

Required fields (AtriusIn profile)

  • status, questionnaire, subject, authored, item, item.linkId, item.answer, item.answer.value[x]
  • encounter — strongly recommended; CQL ties classification to the active ED encounter
  • status — must be completed for pathway branching (in-progress → show form; completed → evaluate branch)

Idempotency

  • One completed classification per encounter is assumed (Latest Classification Response in CQL).
  • If the physician changes their mind, update the same QR or POST a new one with a later authored; CQL uses the latest by authored descending.

8. UI states (minimal)

State Condition UI
Pathway not applicable First CDS call returns no cards / not in scope Hide pathway panel
Assessment In scope, no completed QR Show assessment checklist (informational); show classification form when ready
Classification pending No QR or QR status = in-progress Show 7-way choice form
Branch active Completed QR exists Re-invoke CDS; show branch cards (ACS orders, etc.)
Fallback No QR but diagnosis coded Server may branch from Condition (dev only — prefer QR in production)

9. TypeScript sketch (optional)

const CLASSIFICATION_CS =
  "https://atrius.in/fhir/r4/atrius-in/CodeSystem/atrius-in-er-chest-pain-classification-cs";
const QUESTIONNAIRE_CANONICAL =
  "https://atrius.in/fhir/r4/atrius-in/Questionnaire/er-chest-pain-classification|0.2.0";
const QR_PROFILE =
  "https://atrius.in/fhir/r4/atrius-in/StructureDefinition/atrius-in-questionnaireresponse";

type ClassificationCode =
  | "acs"
  | "aortic-dissection"
  | "pericarditis"
  | "pneumothorax"
  | "pleurisy-pneumonia"
  | "musculoskeletal"
  | "heartburn";

function buildQuestionnaireResponse(params: {
  patientId: string;
  encounterId: string;
  practitionerId: string;
  classification: ClassificationCode;
  authored: string;
}): fhir4.QuestionnaireResponse {
  const labels: Record<ClassificationCode, string> = {
    acs: "Acute coronary syndrome",
    "aortic-dissection": "Aortic dissection",
    pericarditis: "Pericarditis",
    pneumothorax: "Pneumothorax",
    "pleurisy-pneumonia": "Pleurisy or pneumonia",
    musculoskeletal: "Musculoskeletal chest pain",
    heartburn: "Heartburn or GERD",
  };
  return {
    resourceType: "QuestionnaireResponse",
    meta: { profile: [QR_PROFILE] },
    questionnaire: QUESTIONNAIRE_CANONICAL,
    status: "completed",
    subject: { reference: `Patient/${params.patientId}` },
    encounter: { reference: `Encounter/${params.encounterId}` },
    author: { reference: `Practitioner/${params.practitionerId}` },
    authored: params.authored,
    item: [
      {
        linkId: "primary-classification",
        text: "Working classification of chest pain etiology (after initial assessment)",
        answer: [
          {
            valueCoding: {
              system: CLASSIFICATION_CS,
              code: params.classification,
              display: labels[params.classification],
            },
          },
        ],
      },
    ],
  };
}

10. Preconditions checklist (integrator)

  • PlanDefinition/er-chest-pain-pathway and Library/AtriusERChestPainPathway v0.2.0 on KR (8079)
  • cds-server manifest includes er-chest-pain-pathway with planDefinitionId
  • Questionnaire/er-chest-pain-classification available (KR or bundled JSON)
  • Active ED Encounter with chest pain reason on Clinical HFS
  • cds-server /ready pins library + PlanDefinition

11. Out of scope for this contract (later)

  • Rendering / submitting initial assessment as structured data (today: native ED workflow + informational ActivityDefinition)
  • One-click order placement from ACS ActivityDefinitions (RequestGroup → CPOE)
  • in-progress autosave / partial QR
  • Auth / SMART on FHIR launch context

12. Smoke test script

With the local stack running:

./scripts/cds-er-chest-pain-smoke.sh
./scripts/cds-er-chest-pain-smoke.sh --classification aortic-dissection
./scripts/cds-er-chest-pain-smoke.sh --seed-only          # chart data only
./scripts/cds-er-chest-pain-smoke.sh --no-seed --patient-id my-patient --encounter-id my-enc

See also: docs/smart-clinical-ui-stack.md in the repository for the browser-based E2E harness (atrius-bff + atrius-clinical-ui).

Pre-requisites: translate-cql.sh, import-atrius-kr-libraries.py --clinical-reasoning, then in atrius-hfs:

python3 scripts/generate-cds-hooks-manifest.py --from-plandefinition \
  --kr-base-url http://127.0.0.1:8079 \
  --output manifests/cds-services-kr-ecqm.json
# restart cds-server so it reloads the manifest

Use --from-plandefinition (not Library-only mode). Authored pathways register as er-chest-pain-pathway from PlanDefinition.identifier, not from CQL define names.

13. Example reference instance

IG example (for test data seeding):
QuestionnaireResponse/atrius-in-qr-er-chest-pain-acs-example — see input/fsh/clinical-reasoning/pathways/er-chest-pain/examples.fsh.