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.