Consuming Funerals (Structured API)

This page describes the recommended workflow for consuming funeral data using the structured petition endpoints.

Overview of the Data Access Pattern

Both funeral homes and graveyard authorities can consume funeral events by subscribing to the no.dgm.v1.funeral.updated event and accessing structured data through the petition endpoints.

1. Subscribe to Events

See Subscribing to events.

2. Evaluate if the Event is Relevant

The payload of the event contains values that can be used for filtering out irrelevant events:

• For 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. Retrieve Type Definitions

To correctly interpret the structured data, you should first retrieve type definitions:

• GET /dgm/api/v1/definitions/grave-types - Returns grave type definitions with their attributes
• GET /dgm/api/v1/definitions/rite-types - Returns rite type definitions

These definitions provide metadata about the data structures used in the funeral petition, helping you interpret codes and expected attributes correctly.

4. Get the Responsibility Statement

Use the responsibility statement id from the event to get the responsibility statement from DGM:

• GET dgm/api/graveyard-authority/responsibility-statements/{id}

5. Get Structured Funeral Petition Data

Instead of parsing unstructured attachments, you can retrieve structured funeral petition data using:

• GET /dgm/api/v1/funeral-petitions/{partyId} - Returns structured data about the funeral petition

This endpoint provides a structured representation of the funeral data, including: - Responsibility statement information - Cremation or coffin burial details - Grave information - Rite details

Using this structured data offers several advantages: - No need to parse unstructured PDF or form data - Direct access to validated, structured data - More efficient data processing

5.1 Understanding Component Status and Processing Workflows

Responsibility Statement Data: - Requires user confirmation/signature in Altinn - Data submitted through the petition endpoint will only be considered official after being signed by the user - When consuming this data, check if it has been fully signed and approved - The data returned may represent a pending state rather than fully approved data

Grave Data: - Also requires approval through a separate workflow - When consuming this data, understand that it may be in a pending state - Additional status checks may be needed to determine if the grave data has been officially approved

Rites Data: - Processed immediately without additional approvals - When consuming this data, you can consider it as the current official state - No additional status checks are necessary for rites data

5.2 Handling Different Component States in Integration

When consuming funeral petition data for your integration:

1. Check the Event Type: The specific event type can indicate which component has been updated
2. Component-specific Logic: Implement different processing logic based on which component of the petition has changed
3. Status Tracking: For responsibility statements and grave data, maintain state information to track the approval process
4. Versioning: Be aware that you might receive updated petition data as components move through their workflows

Example response from GET /dgm/api/v1/funeral-petitions/{partyId}:

{
  "partyId": "00000000-0000-0000-0000-000000000000",
  "data": {
    "responsibilityStatement": {
      "funeralHomeId": "12345",
      "allowFuneralHomeToContactNextOfKin": true,
      "placeOfDeathLocationId": "0301",
      "hasNotifiedNextOfKin": true,
      "cremation": {
        "ashHandling": "BURIAL",
        "urnBurialLocationId": "0301",
        "crematoriumId": "12345",
        "urnProvider": "FUNERAL_HOME",
        "hasAshSpreadingPermit": false
      }
    },
    "grave": {
      "type": "STANDARD_GRAVE",
      "attributes": {
        "depth": 2,
        "graveSize": "single"
      }
    },
    "rites": [
      {
        "type": "MEMORIAL_SERVICE",
        "location": "Oslo Cathedral",
        "dateTime": "2025-06-01T14:00:00Z"
      }
    ]
  }
}

6. Get Additional Attachments

Use the party id from the event to get a list of metadata for attachments associated with the given party:

• GET dgm/api/graveyard-authority/attachments?Id=..&associatedEntityType=party

Then use the fileId from the metadata to get the actual attachment:

• GET dgm/api/graveyard-authority/attachments/{fileId}

7. Process the Data

Once you have retrieved all necessary information, process the data according to your system's requirements.