Fact of Death Exchange FHIR Implementation Guide
0.2.0 - CI Build
Fact of Death Exchange FHIR Implementation Guide
0.2.0 - CI Build
Fact of Death Exchange FHIR Implementation Guide, published by HL7 International - Public Health Work Group. This guide is not an authorized publication; it is the continuous build for version 0.2.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/shpringman/fhir-fod/ and changes regularly. See the Directory of published versions
| Page standards status: Trial-use | Maturity Level: 3 |
This page defines what implementers are expected to do. It is a shell: the structure and the artifact inventory are in place, and the sections marked To be written still need content from the work group.
| Actor | Role |
|---|---|
| Death Record Source | Holds registered death records and originates notifications. Typically a jurisdictional Vital Records Office. |
| Notification Intermediary | Optionally relays notifications from a source to one or more receivers. Routes on the message header alone. |
| Notification Receiver | Accepts notifications and attempts to match each one to a patient record. Typically an EHR. |
A notification is a FHIR message. MessageHeader.event carries one of three codes, which is all an
intermediary needs in order to route without inspecting decedent content.
| Event code | Message | Meaning |
|---|---|---|
fact-of-death-notification |
Notification | An initial assertion that a registered death occurred. |
fact-of-death-correction |
Correction | Revises content previously sent for the same death record. |
fact-of-death-void |
Void | Retracts a notification previously sent. |
The Fact of Death Notification Bundle is a
Bundle of type message. Its content slices deliberately mirror the VRDR Mortality Roster Bundle,
so a jurisdiction already producing roster content can reuse the same resource instances.
| Entry | Profile | Cardinality |
|---|---|---|
| MessageHeader | FOD Message Header | 1..1, first entry |
| Decedent | FOD Decedent | 1..1 |
| DeathDate | FOD Death Date | 1..1 |
| SourceOrganization | FOD Source Organization | 1..1 |
| Provenance | FOD Provenance | 1..1 |
| DeathLocation | FOD Death Location | 0..1 |
| Certifier | VRDR Certifier | 0..1 |
Two points that are easy to get wrong:
Patient.deceasedBoolean is fixed to true and exists only so that a receiver can see the fact of
death without dereferencing. Where the two ever disagree, the observation wins.placeOfDeath component on the
observation is always present; the Death Location resource is optional and may carry a generalized
address. A sender that cannot disclose a street address still conveys the kind of place.Matching is the receiver's responsibility. This guide does not specify an algorithm, and the source or assurance level of the sender's identity information is out of scope.
What the guide does constrain is the breadth of demographics a notification must carry, so that
safe matching is possible at all. The fod-decedent-matchable invariant requires either a Social
Security Number, or a birth date together with an address or a telecom.
To be written: rationale for the invariant's threshold, guidance on what a receiver should do with a low-confidence match, and whether the weighted element scheme from the Identity Matching IG should be adopted in place of the current invariant.
To be written. Needs to cover: that a correction carries complete current content rather than a
delta; that Provenance.recorded establishes ordering; that a void sets the Death Date observation's
status to entered-in-error; and what a receiver is expected to do when a void arrives for a
notification it never matched.
Receiver support for acknowledgement is optional, but without it a jurisdiction has no way to learn whether its notifications are reaching a patient record. The Acknowledgement Bundle reports a Match Outcome and deliberately carries no decedent content back to the sender.
To be written: whether acknowledgement should be promoted from optional to required, and how a receiver reports an outcome that changes after human review.
Notifications are delivered by invoking $process-message at the receiver's server root.
To be written: authentication and authorization expectations, whether asynchronous delivery is permitted, and how endpoints are discovered and trusted.
A notification carries the fact of death, when and where it happened, and enough demographics to match. It does not carry cause of death, manner of death, autopsy findings, pregnancy status, or tobacco contribution, all of which VRDR defines and none of which a receiver needs in order to coordinate care or stop outreach.
To be written: the reasoning behind this boundary in the terms the work group wants on record, and guidance for jurisdictions whose statutes constrain what may be disclosed.
Expectations by actor are stated in the Sender and Receiver capability statements.
As normative statements are written into the sections above, they should also be recorded in the Narrative Conformance Statements resource for traceability. That resource currently has no statements in it.