Standard data access pattern (Legacy Approach)
Deprecated
This page describes the legacy approach for consuming funeral data. For the recommended approach using structured data, please see Consuming funerals (Structured API).
Note
Funeral homes will be using the dgm/api/funeral-home
endpoints, while graveyard authorities will be using the
dgm/api/graveyard-authority
endpoints. The following sequence diagram uses the graveyard authority as an example.
Both funeral homes and graveyard authorities can consume funeral events by subscribing to the no.dgm.v1.funeral.updated
.
Data Access Pattern
1. Subscribing to events
2. Evaluating if the event is relevant
The payload of the event contains some values that can be used for filtering out irrelevant events. For the graveyard
authority specialist systems, locationIds
list may be useful to filter out events that are not relevant for the
given graveyard authority.
For funeral homes, funeralHomeId
can be used to filter out events that are not relevant for the given funeral home.
3. Getting the responsibility statement
Use the responsibility statement id from the event to get the responsibility statement from DGM.
4. Getting the v0916B attachment
Use the responsibility statement id from the event to get the v0916B attachment from DGM. If it returns 404 Not Found, the attachment has not been uploaded yet.
5. Getting other attachments
Use the party id from the event to get a list of metadata for attachments associated with the given party. Then use the fileId from the metadata to get the actual attachment.