Integrasjon

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.