On this page we describe in overview some of the prevailing standards and profiles related to document based sharing of healthcare information.
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).
A number of the open source software components under 4S governance handle different aspects of document sharing and the standards related to this:
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:
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).
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 http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_MHD.pdf.
“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)