Fact Of Death Direct Enquiry Response Implementation Guide
0.1.0 - ci-build
Fact Of Death Direct Enquiry Response Implementation Guide
0.1.0 - ci-build
Fact Of Death Direct Enquiry Response Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
This page provides a list of the FHIR artifacts defined as part of this implementation guide.
These define constraints on FHIR resources for systems conforming to this implementation guide.
| FODDER Death Record Document Reference |
A DocumentReference profile for optionally including a death record PDF document alongside a matched DeceasedPatient resource in a $match response Bundle. The document is included as a Bundle entry with search.mode = 'include' and is linked to the matched Patient via the subject reference. |
| FODDER Deceased Patient Profile |
A patient profile for confirmed deceased individuals returned from the Veritas Fact of Death API. This profile constrains the USCorePatientProfile to require a deceasedDateTime value and prohibit the use of deceasedBoolean, ensuring that all deceased patients have a specific date and time of death rather than just a boolean indicator. Match quality is conveyed using the standard FHIR match-grade extension (http://hl7.org/fhir/StructureDefinition/match-grade) on Bundle.entry with values: certain, probable, possible, or certainly-not. |
| FODDER Deceased Patient Subscription |
A Subscription profile (R5 backport on R4) by which a client registers interest in mortality notifications for one or more known patient identifiers. The Subscription SHALL reference the FODDER Deceased Patient Identified SubscriptionTopic in Subscription.criteria, SHALL declare at least one filterCriteria on Subscription.criteria, SHALL use channel type rest-hook, and SHALL request payload content id-only. Upon receiving a notification, the subscriber retrieves the matched Patient via GET Patient/{id} from the FODDER server. |
These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.
| Death Record Document Reference Example |
An example DocumentReference containing a death record PDF document, included alongside a matched DeceasedPatient in a $match response Bundle. |
||||
| Deceased Patient Example |
An example of a deceased patient returned from the Veritas Fact of Death API query, demonstrating the required deceasedDateTime. Match quality is expressed using the standard FHIR match-grade extension on the Bundle entry, not on the Patient resource itself. |
||||
| Deceased Patient Notification Bundle Example (id-only) |
An example FODDER subscription notification Bundle delivered to the subscriber's rest-hook endpoint when the service identifies a deceased Patient matching one of the registered identifiers. Payload type is id-only: the Patient resource itself is not included; the subscriber retrieves it via GET Patient/{id}. |
||||
| Deceased Patient Subscription Example |
Example FODDER subscription registering interest in mortality notifications for two SSN-identified patients. Each filterCriteria targets a single Patient.identifier. When a deceased Patient is identified for any of the registered identifiers, the FODDER server delivers an id-only notification Bundle to the subscriber's rest-hook endpoint. |
||||
| Patient $match Response Bundle Example |
|
||||
| deceased-472132936 |
These are resources that are used within this implementation guide that do not fit into one of the other categories.
| Deceased Patient Identified Topic |
Defines the FODDER notification trigger that fires when the service identifies a deceased Patient matching one or more identifiers registered in a Subscription's filterBy criteria. Subscribers register interest by patient identifier and receive an id-only notification when a mortality is recorded for any registered identifier; the subscriber then retrieves the matched Patient by GET Patient/{id}. |