Site Tools


Document Sharing

On this page we describe in overview some of the prevailing standards and profiles related to document based sharing of healthcare information.

National Reference Architectures and Document Sharing

The Danish National eHealth Authority have published a "Reference architecture for sharing documents and images". This reference architecture adopts (parts of) the IHE/XDS architecture. Furthermore, the "Reference architecture for collecting health data from citizens", also published by the Danish eHealth Authority, recommends that data collected from citizens are made available to healthcare providers on XDS-based infrastructure and with regards to content formats recommends that health data collection should be based on the HL7 CDA format Personal Healthcare Monitoring Report (PHMR).

4S Software Components and Document Sharing

A number of the open source software components under 4S governance handle different aspects of document sharing and the standards related to this:

  1. Net4Care XDS Connector: A standalone component for interfacing Cross Enterprise Document Sharing (XDS) sources, which follows the Danish profiling of XDS metadata.
  2. Net4Care MHD Server: A standalone component implementing the IHE Mobile access to Health Documents (MHD) profile. This service implements af RESTful interface that can act as light weight frontend towards an XDS infrastructure. Makes use of the XDS Connector.
  3. Net4Care PHMR Builder: A standalone component for producing Personal Health Monitoring Reports, which follows the Danish profiling of PHMR.
  4. Net4Care PHMR Viewer: A standalone component for searching and viewing PHMR (or any other type of CDA) documents. Makes use of the MHD Server.
  5. KIH Database: National Danish system that collects, stores and makes telemedical measurements and monitoring data available across systems and sectors. Exposes XDS Document Repository services Provide and Register Document Set - b (ITI-41) and Retrieve Document Set (ITI-43). Uses PHMR Builder to produce PHMR documents.
  6. OpenTele as XDS Document Source: XDS Connector and PHMR Builder integrated in OpenTele, so that the OpenTele server can act as a standalone XDS Document Source.


IHE XDS1) - or Cross-Enterprise Document Sharing - is a specification that focuses on sharing document based information about patients between different actors within healthcare. With XDS patient information can be indexed and retrieved across organisation, department and professional boundaries. At the core it consists of a number of Document Repositories and a Document Registry. The repositories are responsible for storing documents while the registry is responsible for storing metadata about these documents. Metadata is information like author, creation time, document format and patient ID. XDS is content neutral and thus documents can be anything spanning from plain text, over PDF and images, to fully structured HL7 CDA documents.

The administrative concept of an XDS Affinity Domain is there to ensure interoperability between document sources and consumers by agreeing on and specifying such things as allowed document formats, coding schemes and patient identification policy. Notice that the Affinity Domain is not a technical entity but an organisational construct realised through a community of stakeholders that agree on a list of policies establishing the basic rules of engagement for a particular XDS. An Affinity Domain contains a single XDS Registry but can contain any number of Repositories, Sources and Consumers.

XDS in a library analogy:

With a simple analogy XDS can be compared to a library. In this particular analogy the main library contains no books but only a catalogue index with index cards. The catalogue index corresponds to the Document Registry. Each of the index cards contains information about things like book title, author, edition, publication date, publishing house etc. The index card also contains information about the book repository - i.e. the physical location - where the book can be picked up. The index cards correspond to the document metadata contained in the Document Registry and the book repositories, of which there can be many, of course correspond to the Document Repositories containing the documents themselves.

The actors involved in XDS are typically depicted as follows:

  • A Document Source submits packages of documents and their metadata to the Registry (IHE ITI transaction: Provide & Register Document Set - b [ITI-41])
  • The Repository registers the contained metadata and a pointer to the document with the Registry. This happens when the Repository receives a document package from a document source. (IHE ITI transaction: Register Document Set - b [ITI-42])
  • A Document Consumer searches the Registry for documents with specific information (metadata). (IHE ITI transaction: Registry Stored Query [ITI-18])
  • A Document Consumer retrieves selected documents from one or more Repositories. (IHE ITI transaction: Retrieve Document Set [ITI-43])
  • The Patient Identity Source provides a unique identifier for each patient. It facilitates validation of patient identifiers by the Registry Actor. (IHE ITI transactions: Patient Identity Feed [ITI-8], [ITI-44])

The actors are merely roles that can be assumed by configurations of components in a real world implementation of XDS. That is, one actor could map to one component, but it could also be mapped to several interacting components. Similarly actors may be grouped, so that for instance a Document Source can be grouped with a Document Repository and potentially implemented by one and the same component.

Notice that XDS is just a part of a larger number of IHE Infrastructure profiles and that an IHE profile can depend on others. XDS, for instance, depends directly on the Audit Trail and Node Authentication (ATNA) profile which in turn depends on the Consistent Time profile. You can find an overview of the infrastructure profiles and their dependencies in "IHE IT Infrastructure, Technical Framework, Volume 1" (ITI TF-1).

Furthermore, a number of the IHE technical infrastructure profiles are closely related to the XDS profile. These include: Cross-Community Access (XCA), Cross-Enterprise User Assertion (XUA) and Cross-Enterprise Reliable Interchange (XDR). All of these are described in overview in (ITI TF-1).

Learn more about XDS


MHD stands for “Mobile access to Health Documents” and is an IHE profile defining a light weight RESTful service interface to document sharing environments like XDS (MHD on IHE wiki). The profile was started simultaneously with HL7's work on the new FHIR standard framework and there has been a lot of interaction between the two. The first version of MHD did not, however, base itself on FHIR, but defined its own document resource concepts. The second version was based on FHIR DSTU1 (the first trial version of FHIR) and the latest version (June 2016) has aligned the MHD profile with the DSTU2 version of FHIR - the official technical description of this version of the MHD profile can be found at

Learn more about MDH


“The HL7 Version 3 Clinical Document Architecture (CDA®) is a document markup standard that specifies the structure and semantics of “clinical documents” for the purpose of exchange between healthcare providers and patients. It defines a clinical document as having the following six characteristics: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness and 6) Human readability.

A CDA can contain any type of clinical content – typical CDA documents would be a Discharge Summary, Imaging Report, Admission & Physical, Pathology Report and more. The most popular use is for inter-enterprise information exchange, such as is envisioned for a US Health Information Exchange (HIE).” (HL7 Standards Product Brief - CDA® Release 2)

Learn more about CDA


HL7 FHIR Documents


The current version of XDS is called XDS.b. This is used because in prior versions of the Technical Framework there was an XDS.a. XDS.a was deprecated with version 7 of the Technical Framework. This is also the reason why some of the transactions end in a “-b”.
standards/documentsharing.txt · Last modified: 2018/12/12 13:27 (external edit)