Electronic health information export

Who can export

• The patient downloads their own record from the patient portal: account menu, Download my health information.
• Practice staff export any patient they can see from the patient's chart: Exports, then Export health information.
• Software authorized by the practice requests an export through the API described below.

The export is free. Every export is recorded in the practice's audit trail.

What you receive

One zip file holding:

• manifest.json, the export's status manifest (below);
• one file per record type, numbered in manifest order, such as 001-Patient.ndjson or 012-Observation.ndjson;
• files named NNN-error-OperationOutcome.ndjson, when some record types could not be exported, saying which and why;
• README.txt.

Each .ndjson file is newline-delimited JSON (application/fhir+ndjson, UTF-8): every line is one complete FHIR R4 resource. Resources follow the US Core 8.0.1 profiles where one applies. A record exported through the API arrives as the same NDJSON files, one per manifest entry, without the zip.

The record is exported exactly as it stood at the moment the export started, named by the manifest's transactionTime.

Which records are included

Every resource in the patient's FHIR Patient compartment (the HL7 FHIR R4B Patient CompartmentDefinition): demographics, visits, visit notes, conditions, allergies, medications and prescriptions, orders, results and reports, immunizations, procedures, documents, care plans, coverage and claims, and messages.

• An export run by the practice is the practice's copy of the whole record. It also includes the practice's own work about the patient: staff messages, call-back requests and tasks (Task, which R4B's Patient compartment omits, is included by patient, owner and requester).
• An export run by the patient includes what the patient can see in the portal: messages the patient sent or received, and requests and tasks the patient filed, but not staff-to-staff work about them.

Messages are exported as Communication resources: each conversation is a Communication, followed by one Communication per message whose partOf names the conversation.

Documents and images

Documents, report files and photos are inside the records that hold them (DocumentReference.content.attachment, DiagnosticReport.presentedForm, Patient.photo and others):

• each attachment carries its file as base64 data, with contentType and size in bytes;
• a file larger than 32 MiB is not inlined. A DocumentReference attachment then carries url, an absolute address that returns the file to the same credentials that ran the export;
• hash holds Breeze's storage key for the file (the hex SHA-1 of its content), not the base64 SHA-1 that the FHIR specification describes.

Not included

• The chart access log (who viewed the record and when).
• Eligibility checks and claim transactions exchanged with payers that are held outside the clinical record.
• Prescribing history held by the third-party e-prescribing service.

Ask the practice for any of these.

Requesting an export through the API

The export follows the HL7 FHIR Bulk Data Access implementation guide (STU2). All addresses are relative to the practice's FHIR base, https://<host>/realm/<practice>/fhir.

Start the export for one patient:

POST [base]/Patient/$export
Accept: application/fhir+json
Prefer: respond-async
Content-Type: application/fhir+json

{"resourceType": "Parameters",
 "parameter": [{"name": "patient",
                "valueReference": {"reference": "Patient/<id>"}}]}

GET [base]/Patient/$export?patient=Patient/<id> is accepted too. Optional parameters:

Parameter	Meaning
patient	Patient/<id>; repeat it for several patients
_type	Comma-separated resource types to export
_since	A FHIR instant; only resources changed at or after it
_typeFilter	Type?param=value, equality on top-level elements
_outputFormat	application/fhir+ndjson (the default; application/ndjson and ndjson are accepted)

Authorization:

• a patient's SMART token (patient/*.read scopes) may export only its own launch patient;
• a practice user's token may export the patients the user can read;
• a backend-services client granted access to the whole practice may omit patient to export every patient (the population export).

The export covers only the resource types the token's scopes may read; a _type naming any other is refused (403).

The request answers 202 Accepted with a Content-Location status address. Poll it: it answers 202 with Retry-After while the export runs, then 200 with the manifest:

{"transactionTime": "2026-10-20T21:00:00Z",
 "request": "https://<host>/realm/<practice>/fhir/Patient/$export",
 "requiresAccessToken": true,
 "output": [{"type": "Patient", "count": 1, "url": "https://<host>/.../$export-file/<job>/<file>"}],
 "error": []}

Download each output and error address with the same token. count is the exact number of lines in that file, and a type with no records is left out. DELETE on the status address cancels the export. An export can be polled, downloaded or cancelled only by whoever started it; to anyone else its addresses answer 404. An export expires one hour after it starts.

Population export

A practice's whole patient population is exported in the same format. Breeze runs it on the practice's request, with the practice's written authorization, and delivers it through a secure channel the practice chooses.

Versions

This format is versioned. A change to its structure (a record type added or removed, a changed representation, a changed manifest field) is a new version, recorded here.

• Version 1 (October 2026): first publication.

Contact

Questions about this format: ttallman@breezeehr.com.