Integration guide for Norwegian use of IHE XDS & XCA for document sources

Introduction

Patient Health Records (PHR) facilitates Cross enterprise document sharing between health professionals and between health professionals and citizens in Norway.The main objectives of PHR are:

• Give health professionals necessary access to referrals, discharge summaries and other types of reports(documents) stored in other healthcare enterprises to achieve more effective health care decisions and reduce errors.
• Reduce the administrative burden and costs of today's collection and delivery of health information.
• Increase the overview of available health information across enterprises.
• Enable access to patients to their medical records throughout Norway.

To facilitate the sharing of health records in the Norwegian health care, interoperability between each actor is mandatory. The goal of this document is to achieve a common understanding of how profiles and standards must be implemented to achieve this. The target audience of this document is technical professionals wanting to implement a solution for making healthcare information available cross-enterprise.

References

• IT Infrastructure (ITI) Technical Framework Volume 1
• IT Infrastructure (ITI) Technical Framework Volume 2
• Metadata used in Document Sharing profiles (ITI TF Vol. 3)
• Norwegian profiling of IHE XDS metadata
• NDH | Målarkitektur for nasjonal dokumentdeling
• SAML-specification | NHN Utviklerportal
• Begrepsliste | NHN Utviklerportal

About this document

This document will describe the Norwegian usage and profilings of the IHE integration profiles based on XDS, XCA and XUA provided in Volumes 1 through 3 of the IHE IT Infrastructure Technical Framework in a national context.

Profilings are the extensions and restrictions to actors and transactions in the profiles. The national extensions and restrictions are included to effectively support document sharing in healthcare in Norway.

IHE and IHE profiles

Integrating the Healthcare Enterprise (IHE) is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. (IHE)-profiles describe the interactions between different systems, but does not describe what should be integrated in those systems.The word profile is used in the context of "shape", as in a profile has a certain shape, but what makes up that shape (ie. the details) are not specified. This gives the implementer the freedom to "fill up" the shape with what they desire, as long as the end result of the shape stays the same. In practical terms, this gives the implementer enough freedom to ensure compliancy with their systems, but the profiles are also sufficiently described as to ensure interoperability with other systems.

Aspects of profiles that IHE does not cover include:

• Roles and responsibilities
• Privacy concerns
• Authorization
• When the publication of a document occurs, and what is published
• Administrative roles
• Configurations
• Service-Level Agreements (SLA)

To begin integration as a document source for Patent Health Records, it is important for the reader to familiarize themselves with the concept of an Affinity Domain, aswell as the profiles XDS, XCA, XUA and their respective transactions (ITI-messages).

IHE profiles for storing documents

IHE has described profiles for various interactions between healthcare systems. The Provide and Register Document Set-b ITI-41 profile is relevant for saving/storing documents.
It is up to the document source themselves to establish a mechanism for storing documents. This may be based on the ITI-41 profile, but other approaches are valid as long as the formats and metadata-elements follow specifications.

National adaptions of IHE profiles

Below is a description of the national considerations taken when PHR (formerly "document sharing") was being established as a national service. These considerations were done in relation to the national amenities in place, such as a National Patient Identifier(NPI/NIN).
When identifying a patient, the XDS profile specifies the actor Patient Identity Source, as specified in ITI-TF Volume 1 chapter 10.1. In the norwegian use of IHE XDS, the Patient Identity Source has been omitted in favor of the NPI for identification of a given patient.

As the need for identifying patients based on local identifiers are not required, another decision was to utilize a central, national XCA-gateway (maintained by Norsk helsenett) for centralized querying and retrieval of documents. This means that all queries to PHR goes through the national XCA, and the national XCA acts as a forwarder to the document sources. Norsk helsenett administrates the service on a national level.

Optimized queries

Note: As of writing, this is not in use. It is described here for informational purposes.

Use of IHE XCA requires an Initiating Gateway to always send document queries to every existing responding gateway. South-Eastern Norway Regional Health Authority covers about half the population in Norway. It is probably not effective to send all queries to all communities. And since our document sharing architecture is not including a national master patient index register, holding information on where to find patients' documents, other measures to optimize queries must be evaluated. A possible solution is to use the IHE standard Cross-Community Patient Discovery (IHE XCPD). IHE XCPD supports the means to locate communities that hold patient relevant health data across communities. The Cross Gateway Patient Discovery transaction ITI-56 supports the ability for Initiating Gateways to request a list of communities which may have healthcare data about the identified patient.

Description of usage of IHE XCPD

When an Initiating Gateway receives a document query (ITI-18) for a given patient, it requests all Responding Gateways with an ITI-56 Patient Location Query. Each Responding Gateway must work out whether they have any health data about the requested patient and send a negative or positive response back to the Initiating Gateway. The Initiating Gateway will make a list of communities responding positively, and then send an ITI-38 to these communities. When acquiring/implementing a Responding Gateway, communities should ensure that the solution supports processing an ITI-56 Patient Location Query.

Actors and components

The XDS-architecture consists of the following actors/components:

Document source

A document source is typically an EHR-system which has produced a document which will be shared using the XDS-solution.

Document consumer

A document consumer is typically a EHR-system or (citizen portal) which queries for documents on a given patient.

Patient identity source

This component ensures every patient is given an unambigous identificator, for example a local, regional or nationwide population register. In Norway, a personal identificator is in use (person number), so a dedicated service for handling patient identifications is not required.

Document repository

A document repository is the service responsible for storing or making the document accessible. an XDS-solution can consist of one or more document repositories.

Document registry

The document registry contains information (metadata) about all archived documents in the XDS area served by this document repository. An XDS site is always served by only one document repository, but a document repository can cover multiple XDS areas. In addition to metadata about existing documents, the document register contains pointers to the document archive where the document is stored.

Affinity Domain

The concept of an affinity domain is, literally and figuratively, central in the realm of sharing health documents. The XDS-profile describes how documents are shared across enterprise boundaries within an affinity domain, as well as the rules that make sharing possible. An affinity domain has its own unique identifier, known as a homeCommunityID. This ID is used when querying the domain.
The boundaries of an Affinity Domain is not specified, but a logical separation within a country is natural. In Norway, this separation is on a RHF (Regionalt helseforetak)-level. This level of separation makes it possible for the affinity domains to profilings catered towards the needs of both the domain, aswell as the RHF.

Transactions in XDS

A set of transactions that can be performed in an XDS solution has been The technical format of the transactions is defined according to the ebXML RegRep 3.0 specification. The various transactions are briefly described below:

Send (Provide and Register Document Set - ITI-41)

This transaction is used to send relevant documents from a document source to a document archive aswell as the document metadata.

Register (Register Document Set - ITI-42)

This transaction is used to send information about new documents in a document archive from this document archive to a document register covering the relevant area. Similar to send, but here only the metadata is sent, and not the actual document.

Search Registry (Registry Stored Query - ITI-18)

This transaction is used in a dialogue between the document user and the document register to ask for documents with specific properties and to get answers to which documents exist and where the individual document is located. A request with specific search parameters is sent from a document user to the document register, which sends back a list of documents that satisfy the search parameters.

Get (Retrieve Document Set - ITI-43)

This transaction is used by a document user to transfer one or more documents from a document repository. A request with specific document identifiers is sent from a document user to a document repository that is tasked with retaining the requested documents. The document archive sends the requested documents back to the document user.

Update patient identity feed information (ITI-8)

This transaction is used in a dialogue between the document register and the patient identity source to exchange information about the used patient identifier.

Document consuming process

Below is a diagram showing the process of retrieving the document-list and the document. Each affinity domain has its own XCA, which again has its own registry and repositories.
When querying for a document-list, the registry is utilized, as it holds the metadata and references to the documents in the repository. When retrieving a document, the repository is used with the ID from the registry.

Diagram 1: Simplified example on a query of document, each XCA is its own affinity domain, and the response for each domain may be different (ie. some domains reject requests from certain GP-roles)

Object Identifiers (OID)

Note: For OIDs to effectively work, there must be some level of governance when creating and managing OIDs. Norsk helsenett(NHN) should have a comprehensive overview of the OIDs related to PHR. NHN shall be informed of the OID of a new document source.

Object Identifiers are unique identifiers for objects or things. Anything can have an OID. In PHR, OIDs are used to unambiguously identify a system or facility. The OIDs might get translated by the systems into the actual URL, which means the URL can change, but the OID stays the same. OIDs are also used in logging. OIDs have a "tree/path"-like structure, and can be represented by its numerical or text variant.More about OIDs on NHN's Developer portal (In Norwegian).

Governing Object Identifiers

The Norwegian profile of IHE XDS metadata defines the use of OIDs for identifying communities. Norsk helsenett (NHN) governs an OID-base and can issue an OID to a community. Each Norwegian health region also governs their own OIDbase and can choose to issue their own homecommunity ID. The OID-base which NDE governs has the following OID structure for document sharing:

• 2.16.578.1.12.4.1.7 – Document sharing root
  • 2.16.578.1.12.4.1.7.1 – Community base OIDs governed by NHN
    • 2.16.578.1.12.4.1.7.1.1 – National community

Historically, this OID-base has belonged to The Norwegian Directorate of eHealth (NDE/e-Helse) for PHR (formely known as Dokumentdeling)

Section 3: Integration

This section aims to give the actor (hereunder document source/ techical personell/integrator) sufficient information to be able to integrate and test their integration with Patients Health Records.While the previous section has covered the basics of the standards, interactions and processes involved in creating and managing documents, this section will focus on the practical steps to integrating with PHR as a document source.

Environments

It is recommended that the actor follows the integration process linearly, beginning with Dev-environment, then Test, followed by QA and then Production.
Integrations may begin in the test-environment if the actor does not have development environment.

Integration and workflow

For sharing/publishing documents, the Provide and Register Document Set-b (ITI-41) transaction is used. Implementors of this transaction shall comply with all requirements described in: ITI TF-2: Appendix V : Web Services for IHE Transactions.
Document sources need a mechanism for making a document-list available to the requestor. This mechanism should follow the IHE-profiles and specifications. Each community/document source must be compliant to the Norwegian profile of IHE XDS.b metadata With reference to chapter 3.38 Cross Gateway Query in IHE ITI-2b, the following restriction applies for Norwegian use of XDS:

National document sharing does not require support of Associations, folders and submission sets . A responding gateway can respond with zero entries when receiving queries which specifies associations, folders or submission sets

Establish an XCA gateway

In practical terms, and XCA-gateway is a SOAP-endpoint capable of recieving and processing SOAP-requests. The requests a document source will recieve is ITI38 and ITI39 - messages, and they shall respond with a corresponding message of the same type.

• For ITI-38-messages, the Content-Type shall be application/soap+xml
• For ITI-39-messages, the Content-Type shall be multipart/related

Actors who already use DIPS (Classic or Arena) can aquire DIPS IHE XDS. This also requires the DIPS Service Broker-platform. To handle SAML-tokens for DIPS-based integrations, DIPS Federation Service (authentication), DIPS Authorization Service (authorication) og DIPS Audit Service (logging) must also be in place.

Diagram 2: Transactions between national and regional XCA-gateways

SOAP message restrictions

ITI-43 Retrieve Document Set and XCA ITI-39 Cross Community Retrieve transactions require SOAP 1.2 with MTOM/XOP. When using SOAP 1.2 MTOM/XOP the following applies:

• Usage of a MTOM/XOP wrapper
• Metadata goes in the root part which is identified by the start parameter of the content-type header
• Documents are included by the Document element (as defined by the profile)
• For national usage only un-optimized format is supported. The document contents must be included as base64 encoded value of the Document element. ITI-18 and ITI-38 transactions require use of Simple SOAP message.

XDS Document Source Options

Section 3.41.4.1.2.1 of the ITI-41 transaction describes 4 options for document sources. None of these options are in use in document sharing today.

XCA Options supported

Table 18.2-1 in IHE ITI Vol 1 shows a list of possible options for XCA actors. In Norway only one option must be supported for each XCA community: XDS Affinity Domain Option (see chapter 18.2.1 in IHE ITI Vol 1 for more details). The other options are not supported. In addition, grouping rules described in chapter 18.2.3 in IHE ITI VOL 1 must be supported.

Ensure correct validation of user claims

When recieving a request, the document source must correctly process the SAML-ticket from HelseID. In other environments, there must be unanimous logic in place to ensure that only authorized healthcare providers are allowed to retrieve information. Non-standard access control should be documented. A common approach is to utilize a PEP/PAP/PDP service for this.

Ensure sufficient logging

Transaction-id

The IHE XDS and XCA profiles only specify logging details based on transactions between two IHE defined actors. Using XDS over XCA, many actors and transactions are involved in a query or retrieval request. IHE does not specify how to link each transaction belonging to the same query or retrieval request/response. This will depend on each software architecture and is therefore out of scope for IHE to specify.Still, it is essential to link each transaction involved in the same request/response. The underlying standards used in IHE XDS/XCA/XUA has no mechanism to include an identifier which can be added in each transaction a query or retrieval request/response consists of.

Persistence of Transaction-IDs

The XCA-gateway will take the <MessageID>-xml element in the SOAP-message and use it as a session-ID. Example:
<MessageID xmlns="http://www.w3.org/2005/08/addressing">urn:uuid:02d9e81f-f6ee-42df-b264-f70cdae5c706</MessageID>.
The XCA-gateway will also create session-IDs which will be used by the responding gateways and as their "local" session ids.

Diagram 3: Delegation of session IDs

This all happens in the same session-ID initially delegated by the consumer, which makes tracing events across gateways possible.

Document formats

A document can have different formats: xml, pdf, tiff etc. To show a document to the user a Document Consumer must recognize the format to select a viewer able to understand the format. Combinations of the metadata attributes MimeType and FormatCode shall give enough information for Document Consumers to choose a correct viewer. Examples of valid combinations is shown in the following section.

It is recommended to use XML based document formats since these documents are machine readable.

XML-based document formats

Several XML-based message standards are mandatory to use in Norway. Documents based on these standards should be shared in xml-formats, and stylesheets for displaying these XML formats are published on Sarepta.ehelse.no.

⚠️⚠️ Legg ut stylesheets på utviklerportalen ⚠️⚠️

Example on usage:

• Filetype: XML
• MimeType: application/xml
• FormatCode: urn:no:ehelse:xmlstds:henvisning:2017-11-30

CDA based document formats

CDA is a HL7 standard for static clinical documents. CDA is not used on a national level in Norway today and usage of CDA documents must therefore be avoided. In the future, national usage of CDA based clinical documents will probably need to be supported.

CDA wrapper for non-XML documents

The CDA standard includes a technique to wrap an XML envelope around non-xml documents to add XML metadata to the document. Such a CDA document consists of a CDA header where metadata is placed and a CDA body where the non-XML document is included.
Wrapping non-XML documents like images, PDFs and RTFs in a CDA wrapper is allowed. When a CDA wrapper is used for non-XML documents, MimeType shall include the Mime type of the non-XML document and FormatCode shall specify usage of a CDA wrapper with version.

Example 1:

• Filetype: GIF
• MimeType: image/gif
• FormatCode: urn:hl7-org:sdwg:ccda-nonXMLBody:2.1

Example 2:

• Filetype: PDF
• MimeType: application/pdf
• FormatCode: urn:hl7-org:sdwg:ccda-nonXMLBody:2.1

Metadata in the CDA header is currently not profiled for use in Norway and it is up to each document repository to decide which metadata to include.
When displaying non-XML documents, it is common to show some of the document's metadata in the same display. Although metadata is included in the CDA header, we recommend using metadata from the ITI-18 response as these are standardized.

Diagram 4: Layer-view of the metadata in a ITI39/ITI43 response

Which document types can be shared

Theses are the basis for the document types which can be shared, and is excpected from other actors.

Section X: Transactions and search parameters

This section will provide a brief description of the IHE transactions used in national document sharing, aswell as the search parameters for each transaction.

ITI-18 Registry Stored Query

ITI-18 Registry Stored Query transaction is a query done by either Document Consumer or XCA gateway against Document Registry to find documents with defined criteria.
Example:

<ns4:AdhocQueryRequest xmlns:ns4="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
    <ns4:ResponseOption returnType="LeafClass"/>
    <AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
        <Slot name="$XDSDocumentEntryPatientId">
            <ValueList>
                <Value>'12119000465^^^&2.16.578.1.12.4.1.4.1&ISO'</Value>
            </ValueList>
        </Slot>
        <Slot name="$XDSDocumentEntryStatus">
            <ValueList>
                <Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
            </ValueList>
        </Slot>
        <Slot name="$XDSDocumentEntryCreationTimeFrom">
            <ValueList>
                <Value>20230513000000</Value>
            </ValueList>
        </Slot>
        <Slot name="$XDSDocumentEntryCreationTimeTo">
            <ValueList>
                <Value>20240513235959</Value>
            </ValueList>
        </Slot>
    </AdhocQuery>
</ns4:AdhocQueryRequest>

ITI-18 specifies many different types of stored queries. For national use of ITI-18 only two stored queries are required to support for Document Consumers and XCA gateways:

• FindDocuments: Find documents in a document registry for a given patientID with a matching availabilityStatus attribute
• GetDocuments: Retrieve metadata on (a collection of) documents given unique Ids on the documents. Other stored queries defined in 3.18.4.1.2.3.7 in ITI TF-2a is optional and XCA communities not supporting these stored queries shall return a zero successful result.

Search parameters for stored query FindDocuments

ITI TF-2a specifies the query parameters for a stored query “FindDocuments” (see ITI TF-2a 3.18.4.1.2.3.7.1). The stored query “FindDocuments” MUST be used using the parameters described in Table 8.
In column 2 the cardinality of each parameter is described:

• [1..1] indicates that the parameter is required for the document consumer and only one value is allowed.
• [0..1] or [0..*] indicates that the parameter is optional for a document consumer, but when using the parameter one [0..1] or multiple [0..*] values are allowed.
• [0..0] indicates "not in use".

<rim:Slot name="$XDSDocumentEntryPatientId">
    <rim:ValueList>
        <rim:Value>
            12345612345^^^&2.16.578.1.12.4.1.4.1&ISO
        </rim:Value>
    </rim:ValueList>
</rim:Slot>

<rim:Slot name="$XDSDocumentEntryClassCode">
    <rim:ValueList>
        <rim:Value>
            'A00-1^^2.16.578.1.12.4.1.1.9602'
        </rim:Value>
    </rim:ValueList>
</rim:Slot>

<rim:Slot name="$XDSDocumentEntryClassCode">
    <rim:ValueList>
        <rim:Value>
            'A03-2^^2.16.578.1.12.4.1.1.9602'
        </rim:Value>
    </rim:ValueList>
</rim:Slot>

<rim:Slot name="$XDSDocumentEntryCreationTimeFrom">
<rim:ValueList>
    <rim:Value>200412252300
    </rim:Value>
</rim:ValueList>
</rim:Slot>

<rim:Slot name="$XDSDocumentEntryAuthorPerson"> 
 <rim:ValueList>
   <rim:Value>
        9144889^Koman^Magnar^^^^^^& 2.16.578.1.12.4.1.4.4&ISO  
   </rim:Value> 
  </rim:ValueList> 
</rim:Slot>

<rim:Slot name="$XDSDocumentEntry FormatCode "> 
    <rim:ValueList> 
        <rim:Value>
            urn:no:kith:xmlstds:epikrise:2006-09-23
        </rim:Value> 
    </rim:ValueList> 
</rim:Slot>

Response

In FindDocuments stored queries, a Document Consumer can choose between two response types:

1. ObjectRef: Returns only the documents' unique identificators (UUID and homeCommunityID)
2. LeafClass: Returns all metadata the system can return.

When the response type "LeafClass" is used in an ITI-18 FindDocument or GetDocuments stored query, the Document Register shall always return at least all required metadata as described in the Norwegian IHE XDS metadata profile. An example response is included in chapter 5.

Section X: Administration of XDS-infrastructure for document sources

The administration include the management of the service after it is in production.

Routines for administration

It is important that any actor in PHR follows the administration routines. This is to ensure that incidents and processes are followed in the same manner. See Deling av pasientens journaldokumenter, section Spesielle bruksvilkår for Pasientens journaldokumenter* og forvaltningsrutiner (NB: In norwegian)

Administration of the document registry

The metadata in the document registry must be maintained to ensure the information is accessible. This can be done by a document administrator. They must be capable of searching the metadata, aswell as updating the information in the registry. This will require its own interface and accesses.

Administration of document ownership

There are multiple scenarios in which the document source has to make changes to their organization or system that affects the access to their stored documents. Some of these cases are:

1. A general practitioner who shares documents concludes their practice or switches EHR (Electronic Health Record) providers.
2. When an organization intends to replace or merge its document repository solution or transfer its responsibilities to another organization.
3. If an organization upgrades or changes its entire system platform, such as transitioning from an older version to a newer one, it can impact document links in terms of accessibility and compatibility.
4. In the event of business mergers or divestitures, there may be a need to review and update document links to reflect the new organizational structures and responsibilities.

Architectural principles

This section will cover business, informational and security-realted principles for document sources.

Business-principles

Information principles

Security principles