Publisert - 03.06.2026

Integration with Norsk helsenetts Storage Solution as a Document Source

Note ℹ️
For any questions related to document sharing, or integrating as a document source, feel free to contact us in our slack-channel #ext-nhn-pasientens-journaldokumenter

Below are the common integration steps for becoming a document source using XcaDocumentSource, developed by Norsk helsenett. Usual integration follow a "gradual transition" from storing everything in their existing Storage Solution, to uploading both in the Storage Solution, but also uploading an increasingly larger amount of the documents to XcaDocumentSource, allowing for a smooth transition.

XcaDocumentSource is a IHE XDS/XCA-compliant XCA responding gateway with integrated registry and repository developed by Norsk helsenett. It can be used as a standalone storage system or used in conjunction with an existing storage system, like in Example 2
XcaDocumentSource - github.com

Steps when integrating with Norsk helsenetts Storage Solution

As an integrator, you will mainly interact with two services: PHR-API and XcaDocumentSource.

PHR-API is the entrance-portal to storing documents, and contain endpoints for uploading a FHIR-bundle
XcaDocumentSource is the solution name of the Storage Solution used in Norsk helsenett. There are several instances of XcaDocumentSource running in our environments, and one will be delegated to you upon initial integration.

In your existing Storage System, you need to create a propagation mechanism that functions as follows:

The document and metadata must be transformed to a FHIR-bundle, complying with the ITI-65 transaction of the MHD Profile.
Before uploading the FHIR bundle - any custom codes and coding systems must be mapped according to the norwegian IHE XDS-metadata specification and the coding systems used in healthcare in Norway.
- Norwegian profile for XDS metadata
When a document is uploaded to your Storage Solution, the document and metadata is also sent to the NHN PHR API, which will forward it to your assigned instance of XcaDocumentSource.
The response will contain a FHIR OperationOutcome, signaling whether the operation completed with any errors. This should be handled either by the integration engine or the front-end, depending on the mechanism for forwarding documents.

Integration documentation for ITI-65

Slack-channel for integration questions

When integrating with Norsk helsenetts Storage Solution, you need to be assigned an instance of XcaDocumentSource.
You will get an Object Identifier identifying your instance of XcaDocumentSource. When uploading documents, this identifier must be included in the relevant properties of the FHIR-bundle.
To get an instance of XcaDocumentSource, and for any questions regarding integrations, feel free to contact us in our Slack-channel:
#ext-nhn-pasientens-journaldokumenter

Examples

Example 1: Existing Storage Solution (0% of documents stored in NHN infrastructure)

This might represent the current architecture of a EPR-system who wants to connect to XcaDocumentSource, and their documents are stored in the systems local Storage Solution.

See Existing Storage Solution for more info.

flowchart LR

act[Healthcare <br>personell]

subgraph "EPR system"
    eepr[EPR system]
    epdb[(Storage Solution)]
end

act--Uploads documents-->eepr

eepr --Uploads to<br>internal storage--> epdb

Example 2: Parallel-Storage Solution using XcaDocumentSource (25-75% of documents stored in NHN infrastructure)

This is usually what a transition phase looks like, where you store documents in both registry/repositories at once, allowing XcaDocumentSource to be queried by Norsk helsenetts XCA Initiating Gateway, exposing the shared documents through XcaDocumentSource as a Target Community. Some migration might need to be done to sync all of the documents between the existing system and XcaDocumentSource.

This is a simple approach which allows fetching of documents from the existing storage as normal, while also making them available to the broader XCA community.

For some actors, this parallel/hybrid is a sufficient Storage Solution. Storing all the documents in both the existing Storage Solution aswell as XcaDocumentSource There may be limitations in the vendors system or organization which prevents a more thorough integration. Thus this is a low-cost-low-risk solution.

This solution applies to:

actors who are vendor-locked in to existing storage infrastructure who want to share documents, but are unable to get vendors to support interoperability or integration
actors who wants to pilot an interoperable storage solution
actors who are planning development of FHIR/XDS-compliant interfaces for direct communication with Norsk helsenett
actors who want to share only certain document types (ie. only share documents under Kjernejournalforskriften or with citizens of Norway)

flowchart LR

act[Healthcare <br>personell]

subgraph "Norsk helsenett"
  xcads[(XcaDocumentSource)]
  phr[[PJD REST API]]
  xcagw[NHN<br>XCA Gateway]
end

subgraph "EPR system"
    eepr[EPR system]
    epdb[(Storage Solution)]
    intngn[[FHIR Integration<br>layer]]
    fwd((&nbsp;))
end

act --Uploads documents--> eepr

eepr --Forwards to both<br>internal storage<br>and NHN--> fwd

fwd --> intngn
fwd --> epdb

intngn --ITI-65 HL7 FHIR ProvideBundle-request--> phr 
phr --Forwards to<br>correct<br>XcaDS--> xcads

xcads <--Queries for<br>documents--> xcagw

Example 3: NHN-governed Storage Solution using XcaDocumentSource (100% of documents stored in NHN infrastructure)

This is applicable if you are migrating from a parallel Storage Solution, or if you do not have a Storage Solution in the first place.