Authorization

On behalf of a funeral home

Read the authentication section to learn how to authenticate. It covers which endpoints are relevant for funeral homes, as well as how to authenticate using JWT bearer or a dedicated access code.

As for authorization, the endpoints prefixed with dgm/api/funeral-home requires the header x-synchronization-id. The x-synchronization-id header is a string that represents the dgm identifier number of the funeral home you're operating on behalf of, or the identifier of a funeral home department you're operating on behalf of.

x-synchronization-id: "123456789"

The organization ID is important as it is used in the access rules of individual funerals. This means that you can only access funerals that are associated with the organization ID you're operating on behalf of.

Access rules

The access rules for funeral homes are as follows:

  • A funeral home can access funerals that does not have any responsible party yet.
  • A funeral home can access funerals where the responsible party has chosen a funeral home given the organization ID from the x-synchronization-id header.
  • A funeral home can access funerals where the responsible party has chosen a funeral home department given the department identifier from the x-synchronization-id header.

Examples

For the coming examples, consider the next of kin, Alice, and the following funeral home:

{
    "organizationId": "123456789",
    "name": "Eternal Grace Funeral Services"
}

Example 1 - Accessing a funeral without a responsible party

Let's say that Alice chooses Eternal Grace Funeral Services (EGFS) as the funeral home for the funeral. Alice reaches out to EGFS to help her out with arranging the funeral. Because Alice and the other next of kin have not yet done anything in regard to the funeral, EGFS can access the funeral without any issues. Via your system, EGFS can retrieve the funerals that Alice is "eligible" to take responsibility for using:

POST /dgm/api/funeral-home/lookup HTTP/1.1
Authorization: Bearer <JWT>
x-synchronization-id: "123456789"

...

{
    "ssn": "12345678901" // Alice's SSN
}

Example 2 - Accessing a funeral with a responsible party

Let's say that Alice has chosen Eternal Grace Funeral Services (EGFS) as the funeral home for the funeral using the form in Altinn. Alice is now the responsible party for the funeral. When the funeral is updated with Alice as the responsible party, your system receives an event that the funeral was updated along with the data needed to retrieve the funeral:

{
    "funeralId": "B5A95229-629F-4DC7-A183-6D5AF47B3B08",
    "responsibilityStatementId": "C8436BA4-B1B3-49A5-863A-6A4CBBB9B55E",
    "partyId": "A4E661CA-3CC1-4C7B-8820-5B6023B40C14",
    "locationIds": ["0301"],
    "crematoriumId": null,
    "funeralHomeId": "123456789" // We know the event is relevant for EGFS because of this ID
}

With the data from the event, your system can now retrieve the responsibility statement on behalf of EGFS:

GET /dgm/api/funeral-home/responsibility-statements/C8436BA4-B1B3-49A5-863A-6A4CBBB9B55E HTTP/1
Authorization: Bearer <JWT>
x-synchronization-id: "123456789"

If attempting to access a funeral where another funeral home is chosen, the system will return a 403 Forbidden error.

On behalf of a graveyard authority or crematorium

Read the authentication section to learn how to authenticate. It covers which endpoints are relevant for graveyard authorities, as well as how to authenticate using JWT bearer or a dedicated access code.

As for authorization, the endpoints prefixed with dgm/api/graveyard-authority requires the header x-synchronization-id or x-location-id depending on what type of organization you're operating on behalf of.

The x-synchronization-id header is a string that represents the organization number of the crematorium you're operating on behalf of. The x-location-id header is a string that represents the municipality number of the graveyard authority you're operating on behalf of.

x-synchronization-id: "123456789"

x-location-id: "0301"

The organization ID is important as it is used in the access rules of individual funerals. This means that you can only access funerals that are associated with the crematorium organization ID or graveyard authority location ID for the crematorium or graveyard authority you're operating on behalf of.

Both x-synchronization-id and x-location-id are provided in the event data when a funeral is updated. Use this data to retrieve the funeral on behalf of the crematorium or graveyard authority.

Access rules - Graveyard authorities

When cremation is chosen, the x-location-id must be one of the following locations:

  • When urn burial is chosen, the graveyard authority in the burial municipality has access
  • When urn burial municipality is not chosen, the graveyard authority in the deceased's municipality of residence has access

When coffin burial is chosen, the x-location-id must be one of the following locations:

  • When the burial municipality is chosen, the graveyard authority in the burial municipality has access
  • When the coffin is to be taken out of the country, the graveyard authority in the deceased's municipality of residence has access

Access rules - Crematoriums

When cremation is chosen, the x-synchronization-id must be the organization ID of the crematorium used.

Example - Crematorium

Let's say that Alice has become the responsible party for a funeral and has chosen cremation, and the crematorium Vestfold Crematorium (VC) is chosen:

{
    "organizationId": "123456789",
    "name": "Vestfold Crematorium"
}

At the moment that Alice becomes the responsible party, your system receives an event that the funeral was updated along with the data needed to retrieve the funeral:

{
    "funeralId": "B5A95229-629F-4DC7-A183-6D5AF47B3B08",
    "responsibilityStatementId": "C8436BA4-B1B3-49A5-863A-6A4CBBB9B55E",
    "partyId": "A4E661CA-3CC1-4C7B-8820-5B6023B40C14",
    "locationIds": ["0301"],
    "crematoriumId": "123456789",
    "funeralHomeId": null
}

Your system can use the crematoriumId to filter out the events that are not relevant for VC and retrieve the responsibility statement on behalf of VC:

GET /dgm/api/graveyard-authority/responsibility-statements/C8436BA4-B1B3-49A5-863A-6A4CBBB9B55E HTTP/1
Authorization Bearer <JWT>
x-synchronization-id: "123456789"

If attempting to access a funeral where another crematorium is chosen, the system will return a 403 Forbidden error.

Example - Graveyard authority

Let's say that Alice has become the responsible party for a funeral and has chosen coffin burial, and the graveyard authority Oslo Graveyard Authority (OGA) is chosen:

{
    "locationId": "0301",
    "name": "Oslo Graveyard Authority"
}

At the moment that Alice becomes the responsible party, your system receives an event that the funeral was updated along with the data needed to retrieve the funeral:

{
    "funeralId": "B5A95229-629F-4DC7-A183-6D5AF47B3B08",
    "responsibilityStatementId": "C8436BA4-B1B3-49A5-863A-6A4CBBB9B55E",
    "partyId": "A4E661CA-3CC1-4C7B-8820-5B6023B40C14",
    "locationIds": ["0301"],
    "crematoriumId": null,
    "funeralHomeId": null
}

Your system can use the locationIds to filter out the events that are not relevant for OGA and retrieve the responsibility statement on behalf of OGA:

GET /dgm/api/graveyard-authority/responsibility-statements/C8436BA4-B1B3-49A5-863A-6A4CBBB9B55E HTTP
Authorization Bearer <JWT>
x-location-id: "0301"

If attempting to access a funeral where another graveyard authority is chosen, the system will return a 403 Forbidden.