Search loading...

API Hub

Explore and Make use of Nationally Defined Messaging APIs

 

PDS Death Notification

The FHIR profiles used for the PDS Death Notification event message bundle

PDS Death Notification event messages are generated by the Spine and published to the NEMS when a patients death notification status is changed within PDS. The death notification status of the patient is carried within the event message as specified in the guidance on this page.

FHIR Profiles

The PDS Death Notification event message bundle is expected to include a combination of the following resources to support the event header and data item requirements:

PDS Death Notification Event Message Bundle
EMS-Bundle-1
EMS-MessageHeader-1
EMS-Communication-1
EMS-HealthcareService-1
CareConnect-EMS-Patient-1

Onward Delivery

The delivery of the PDS Death Notification event messages to subscribers via MESH will use the following WorkflowID within the MESH control file. This WorkflowID will need to be added to the receiving MESH mailbox configuration before event messages can be received.

MESH WorkflowID CHILDHEALTH_DEATHNOTIFICATION_UPDATE

Bundle structure

PDS Death Notification Bundle (open in new TAB)

The extension(deathNotificationStatus) and deceasedDateTime elements within the patient resource are the main indicators of the patients death status.

PDS Death Notification Event Message Types

The PDS Death Notification event message will be sent by the NEMS, following an update to the patient death information on PDS. This information includes the death notification status which may be updated should the patient’s death notification status change. The event message behaviour following each update to the patient’s death notification status is demonstrated in the table below:

If a subscriber receives multiple PDS Death Notification event messages for the same patient, the latest event message as indicated by the systemEffectiveDate extension within the Patient resource should be considered the source of truth for the deathNotificationStatus. This is the specific dateTime on which the deathNotificationStatus was updated on PDS.

The below table is included to highlight the different types of Death Notification event message you may receive and the key elements within resource which help identify the type of Death Notification event message you have received. Additional guidance around the content of the FHIR resources is outlined in the Resource population requirements and guidance section below.

  PDS Death Notification (Informal) PDS Death Notification (Formal) PDS Death Notification (Death Notification Status removed)
  Death notice received via an update from a local NHS Organisation such as GP or Trust Death notice received from Registrar of Deaths A revoke of a patient death event as the death was entered in error, the patient is NOT DEAD.
EMS-MessageHeader-1 Resource      
extension(eventMessageType) Fixed value: new Fixed value: new Fixed value: new
event Fixed value: PDS004 (PDS Person Death) Fixed value: PDS004 (PDS Person Death) Fixed value: PDS004 (PDS Person Death)
EMS-Communication-1 Resource      
status Fixed value: completed Fixed value: completed Fixed value: completed
CareConnect-EMS-Patient-1      
extension(deathNotificationStatus) Fixed value: 1 (Informal) Fixed value: 2 (Formal) Fixed value: U (Removed)
deceasedDateTime element populated with dateTime of death element populated with dateTime of death element not included in resource

Resource population requirements and guidance

The following requirements and resource population guidance should be followed in addition to the requirements and guidance outlined in the Events Management Service specification.

EMS-MessageHeader-1

The MessageHeader resource included as part of the event message SHALL conform to the EMS-MessageHeader-1 constrained FHIR profile and the additional population guidance as per the table bellow:

Element Cardinality Additional Guidance
extension(eventMessageType) 1..1 Will be populated as per the event life cycle table above.
event 1..1 Fixed Value: PDS004 (PDS Person Death)
focus 1..1 This will reference the “EMS-Communication-1” resource which contains information relating to the event message.

EMS-Communication-1

The Communication resource included in the event message SHALL conform to the EMS-Communication-1 constrained FHIR profile and the additional population guidance as per the table below:

Element Cardinality Additional Guidance
status 1..1 Will be populated as per the event life cycle table above.
payload 1..1 This will reference the patient resource representing the patient who is the focus of this event.

EMS-HealthcareService-1

The HealthcareService resource included in the event message SHALL conform to the EMS-HealthcareService-1 constrained FHIR profile and the additional population guidance as per the table below:

Element Cardinality Additional Guidance
providedBy 1..1 This will reference the source organization of the event message. For PDS events this will be a reference to an organization resource which can be retrieved using the ODS Lookup API
type 1..1 This will represent the type of service responsible for the event message. This will have a fixed value: PDS (Personal Demographics Service)

CareConnect-EMS-Patient-1

The patient resource included in the event message SHALL conform to the CareConnect-EMS-Patient-1 constrained FHIR profile and the additional population guidance as per the table below:

Element Cardinality Additional Guidance
meta.versionId 1..1 This element will contain the serial change number (SCN) of the patient record within Spine at the time this event was published.
extension(deathNotificationStatus) 1..1 This will be populated as per the event life cycle table above.
extension(systemEffectiveDate) 1..1 Element populated with dateTime when Death Notification Status was updated on the Spine.
deceasedDateTime 0..1 This will be populated as per the event life cycle table above.

CareConnect-Organization-1

References to Organization resources within this event message will use absolute URL reference which can be retrieved as described in the FHIR ODS Lookup API Implementation guide rather than including the organization resource within the event message bundle.

Tags: fhir

All content is available under the Open Government Licence v3.0, except where otherwise stated