FHIR XML serialization is a legacy format that shows up in specific integration contexts even in 2026. Understanding when it matters prevents unnecessary XML support.
Where FHIR XML still matters
1. HL7v2-to-FHIR converters that emit XML. Some legacy converters produce FHIR XML rather than JSON. 2. Enterprise integration platforms. Some enterprise middleware handles XML natively. 3. Existing XSD-based validation. Systems that validate against XSD schemas. 4. HL7 CDA integration. CDA is XML; FHIR XML fits into CDA-adjacent workflows.
Where FHIR XML doesn't matter
1. Modern REST clients. JSON is default and expected. 2. Bulk data operations. NDJSON, never XML. 3. Web/mobile apps. JSON exclusively. 4. New greenfield integrations. JSON always.
Format negotiation
HTTP Accept header determines format:
- application/fhir+json — JSON. - application/fhir+xml — XML. - application/fhir+ndjson — NDJSON (bulk only).
Servers should support both JSON and XML on standard REST endpoints; NDJSON exclusive to bulk.
XML-specific considerations
1. Namespaces required — http://hl7.org/fhir for FHIR elements. 2. UTF-8 mandatory. 3. id attribute on resource element (not <id> element). 4. xsi:type attribute for polymorphic elements (value[x] types).
Vendor XML support (mid-2026)
| Server | XML support |
|---|---|
| HAPI FHIR | Full |
| Aidbox | Full |
| Medplum | External |
| Microsoft FHIR Server | Full |
When to enable XML
1. Existing integration partners send FHIR XML → keep it. 2. New integrations → default JSON. 3. Reduce over time → deprecate XML where partners can move to JSON.
FHIR XML is legacy tech in 2026. Support it where required; migrate to JSON where possible.
