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

History

History

Published versions of the Huli FHIR Core Implementation Guide (R4 package, huli.fhir.core.r4). A separate IG package will track the R5 surface; each FHIR version has its own version history.

Version	Date	Status	FHIR Version	Notes
0.2.0	2026-07-13	current	4.0.1	R4 conformance & validation changes (see below). Includes stricter write validation that rejects some previously-accepted requests.
0.1.0	2026-05-29	superseded	4.0.1	Initial release — Patient, Appointment, Encounter, Observation profiles; Practitioner, Organization read-only; 8 Huli extensions; HuliSecondLastname for multi-surname naming.

0.2.0 — R4 conformance & validation changes

Shipped alongside the R5 surface. These touch the R4 wire contract; an integration built against 0.1.0 may need changes where flagged. Most are fail-closed corrections that reject previously-accepted malformed or inconsistent input rather than silently discarding it.

Read-shape changes

• Appointment.cancelationReason renders as a full CodeableConcept (SNOMED CT + Huli codings), with .text carrying the reason display name and the cancellation notes as a fallback. Previously it was { "text": <notes> }; a client reading only .text still receives text.
• Observation.effectiveDateTime is omitted for a zero / pre-epoch (BC) stored date instead of emitting 0001-01-01T00:00:00Z.
• Patient/$everything now also aggregates the patient's Appointment resources (additive — when the token carries an Appointment instance read scope; without it the type is withheld like any other unscoped type).
• A structurally invalid Patient create/update returns a single OperationOutcome document. Previously the 400 body could contain TWO concatenated OperationOutcome JSON documents, which strict JSON parsers reject.
• A 404 OperationOutcome now carries the HPB-00102 code in issue.details.coding, matching every other error class.
• issue.details.coding is sanitized: internal HP- codes outside the curated, documented set are replaced by the generic public code for the HTTP status (e.g. HPB-00101 on a 400) instead of leaking verbatim.

Status-code corrections (⚠ if you matched on the exact status)

• The multi-specialty booking guards HPB-00115 (specialty required) and HPB-00116 (specialty not offered) return their documented 422 — previously the wire returned 400 while the error catalog declared 422.

Stricter write validation (⚠ may reject a request that 0.1.0 accepted)

• Creating/updating an Appointment with a huli-confirmation-status extension whose value differs from the server's current confirmation status is rejected 422 (previously the supplied value was ignored). Echo the value you read, or omit the extension. This is the item most likely to affect a client that PUTs a resource fetched before a status change.
• A field-edit PUT on an Appointment in a terminal state is rejected 422 (previously it silently rescheduled with 200).
• Creating an Encounter whose diagnosis references a contained Condition that is not present is rejected 400 (previously the dangling diagnosis was silently skipped).
• Creating an Observation carrying referenceRange is rejected 422 — the surface does not persist reference ranges (previously the field was silently dropped).

Versioning policy

This IG follows semantic versioning:

• Major — wire-breaking changes (a partner integration that worked against the previous major must be updated)
• Minor — additive profiles, extensions, terminology, or search parameters (existing integrations continue to work unchanged)
• Patch — documentation, narrative, or example fixes with no impact on conformance

The GET /fhir/R4/metadata CapabilityStatement on the Huli Public FHIR R4 API is kept in lockstep with the published IG version. Partners should compare the API's software.version against the version listed here when validating against profiles.