Publisert - 02.06.2026

JFT WriteAPI overview

The WriteAPI provides endpoints for submitting events and event status updates. As per FHIR conventions, the resource type is part of every endpoint address. The resource types currently supported are:

Bundle: For a single event represented by multiple resources.
Composition: For clinical notes and documents.
MedicationDispense: For successful medication dispensing events.

Example requests are available here.

Available environments

Environment	FQDN
Test	api.write.jft.test.nhn.no
Prod	api.write.jft.nhn.no

Submitting events

Events are submitted by making POST requests to the resource type endpoints.

Endpoint format: POST /v1/<ResourceType>

For example: POST /v1/Composition submits an event represented by a FHIR Composition resource.

A successful submission returns 202 Accepted. The response includes a Location header with the URL that can be used to check the event's status.

Note

There is a request size limit of approximately 1 MB for WriteAPI endpoints.

Journaling acknowledgement

When an event has been successfully journaled in an EHR system, the EHR client can acknowledge this to JFT.

Endpoint format: POST /v1/<ResourceType>/{ResourceId}/$journaling-acknowledged

For example: POST /v1/MedicationDispense/123/$journaling-acknowledged registers a journaling acknowledgement for an event submitted as a FHIR MedicationDispense resource with resource ID 123 (resource IDs are GUIDs in practice).

The endpoint responds with 202 Accepted and includes a Location header pointing to the event's status URL.

Validation

To ensure data quality and prevent mixing of test and production data, the following checks are performed on every submission.

Format check

The API deserializes the received JSON to verify that the content conforms to the FHIR R4 standard. Requests with invalid JSON structures or missing mandatory FHIR elements are rejected with 400 Bad Request.

Handling of national identification numbers (NINs)

Production: Only real Norwegian NINs are accepted.
Test: Only synthetic identity numbers are accepted.

We recommend using SyntPop to generate valid synthetic test data for use in our test environments. More information can be found at NHN Developer Portal - SyntPop.

Handling of organization numbers

Production: Only real Norwegian organization numbers are accepted.
Test: Only synthetic organization numbers are accepted.

Note

Currently there is an exception for organization numbers in the claim orgnr_supplier. Until further notice, real organization numbers in this claim are also accepted in Test.

Required claim

The orgnr_parent claim is required in the access token for all endpoints. Its value must be the organization number of the municipality's main entity.

Optional header: nhn-source-system

Vendors are encouraged to include the nhn-source-system header when submitting events. If present, the header value is stored and returned as metadata when the event is later retrieved via the ReadAPI. This makes it easier for EHR systems to identify the originating system for an event.

When this header is provided, the value appears in the event metadata under the https://fhir.jft.nhn.no/source-system-name tag. See EventLifecycle for an end-to-end example.

{
  "meta": {
    "lastUpdated": "2026-05-26T10:06:17.01493+00:00",
    "tag": [
      {
        "system": "https://fhir.jft.nhn.no/source-system-name",
        "code": "Bruno V0.1.2"
      }
    ]
  }
}

See the ReadAPI for the full list of metadata included in event responses.

Søket er fullført!