FHIR R4 & Bulk Data

FHIR R4 (4.0.1). Resources are shaped to US Core: a profile is put in meta.profile only when the resource carries what that profile requires, and the exporter was last checked with the HL7 validator against US Core 6.1.0. Resource types: Patient, Observation, Condition, MedicationStatement, QuestionnaireResponse, Immunization, CarePlan, DocumentReference and Coverage (base R4).

One patient: the record

• GET/v1/patients/{member_ref}/recordOne patient's record as a FHIR R4 Bundle
• GET/v1/patients/{member_ref}/brief/documentThe pre-visit brief as a FHIR R4 DocumentReference, ready to file in your chart

GET /v1/patients/{member_ref}/record returns an application/fhir+json collection Bundle, filtered by types and since. What the patient's sharing choices leave out is listed in an OperationOutcome entry. It needs a BAA on file (409 record_baa_required) and is capped (by default 2,000 resources or 5 MB); a larger record answers 413 record_too_large_use_population_export. The pre-visit brief is also available as a DocumentReference (LOINC 34133-9, docStatus preliminary) to file in the chart.

Many patients: Bulk Data export

An asynchronous export modelled on the FHIR Bulk Data pattern, under /v1 with your partner token. It is not a $export operation: there is no Prefer: respond-async and no Content-Location header.

1. Kick off. POST /v1/population/exports with an optional JSON body: types, since and deidentify (none or safe_harbor). The answer is 202 with export_id and status_url. One export per client at a time (409 export_in_progress); an identified export needs a BAA (409 population_export_baa_required). Safe Harbor exports drop DocumentReference and use ids that are random per export.
2. Poll GET /v1/population/exports/{export_id}, or subscribe to population.export_completed. It answers 200 with status and progress; when complete it includes a Bulk Data style manifest (transactionTime, request, requiresAccessToken: true, output[] with type, url and count, error[]).
3. Download each output[].url (/v1/population/exports/{export_id}/files/{Type}.ndjson, application/fhir+ndjson) with the same bearer token. Every download is audited, and refused with 503 if the audit log is unavailable.
4. Expiry. Files are kept for 24 hours, then 410 export_expired. DELETE removes an export early (204, safe to repeat).

• POST/v1/population/exportsStart an asynchronous FHIR Bulk Data export of your panel
• GET/v1/population/exports/{export_id}Status and manifest of one export
• GET/v1/population/exports/{export_id}/files/{name}Download one NDJSON file of a completed export
• DELETE/v1/population/exports/{export_id}Cancel or delete an export

Health centres also have GET /v1/population/uds-plus: UDS+ shaped FHIR NDJSON in a zip. In a sandbox every exported resource carries the HL7 HTEST security label and a synthetic tag.

FHIR in

POST /v1/panel/imports accepts Bulk Data NDJSON files, a zip of them or a FHIR Bundle, staged as a dry run you then commit or discard. Oncology treatment summaries are imported the same staged way.

• POST/v1/panel/importsStage a panel import and get its dry run

Other FHIR documents

• Medical travel returns an HL7 International Patient Summary document Bundle (GET /v1/travel/journeys/{journey_ref}/ips).
• Electronic case reports are FHIR eICR (hl7.fhir.us.ecr 2.1.2); see Public-health reporting.