One of the ‘sweet spots’ for FHIR is establishing RESTful interfaces to an IHE XDS (Cross Enterprise Document Sharing) implementation. IHE had already started down this path when it created the ‘Mobile Access to Health Documents’ – MHD – profile as a way of making it easier for mobile devices to access XDS installations, but with the emergence of FHIR, the two efforts have been merged and the intention is that the MHD version 2 profile will be FHIR based. This is not to say that FHIR can replace XDS – there are circumstances where the native XDS interfaces can be required – especially in larger deployments, but the ease of use of FHIR makes an attractive façade in many situations.
It should also be mentioned that it is quite feasible to implement an ‘XDS-like’ system that follows the overall pattern of XDS, but doesn’t have an XDS ‘back-end’ if it meets the use cases.
This will be the first in a series of posts that talks about implementing the FHIR as a front end to XDS, and will be an overview to XDS and how FHIR resources match the profile.
For those who are not familiar with XDS, its purpose is to enable the sharing of documents between healthcare enterprises. The image below is the standard representation of XDS:
It shows 5 principal actors:
- The Document Registry that is the ‘index’ to available documents. Within a single implementation there is only a single registry, though there are profiles (like XCA) that support ‘inter-registry’ queries where there are multiple co-operating deployments
- One or more Document Repositories that actually hold the documents
- Multiple Document Sources that actually create the document, and submit them to a repository
- Multiple Document Consumers that query the registry for documents, and then retrieve the documents from the indicated repository
- A single Identity Source, that manages patient identity
There are a number of transactions defined, and the ones that are of interest to us are as follows:
- Register and provide document set (ITI-41), where a document source assembles a package containing 1 or more documents, with associated metadata (which we’ll talk about shortly) and sends that to a repository for storage.
- Register document set (ITI-42) where the repository forwards the metadata to the registry.
- Registry stored query (ITI-18) which is the consumer making a query of the registry to retrieve specific documents based on some search criteria.
- Retrieve document set (ITI-43) defines how a consumer retrieves a specific document. Generally, this will be after they have queried the registry.
- Patient Identity Feed (ITI-8, ITI-44) shows the identity source updating the registry with demographic information about patients – especially ‘merges’ where a single patient is known by more than one identifier.
Refer to the XDS profile for more details.
Applying FHIR resources to this picture, gives us the following:
We can see that there is a good match (not unsurprisingly) between the XDS transactions & the FHIR resource end points.
- A document source can submit the document and metadata to the repository via a transaction (like the medication update)
- The repository updates the registry by posting a resource to the registries DocumentReference endpoint
- A Consumer searches for documents via a query against the registries DocumentReference endpoint, and retrieves the document via a GET against the repositories /binary endpoint.
- A SecurityEvent resource that records accesses of significance.
Note that for the purpose of this discussion (to keep things simple), we are ignoring the DocumentManifest resource, and only using the DocumentReference resource – which means that we will only be submitting and retrieving a single document at a time. The DocumentReference resource describes the metadata (and supplies the base data for searching) for a single document. The DocumentManifest resource ‘groups’ multiple documents (for example a document and an attachment) into a single package. We’ll come back to this in a later part of this series.
It’s also possible for the document source to update the registry directly. They may do this if the document is being stored outside of the XDS infrastructure (e.g. to support a repository that is not otherwise functioning as an XDS repository). We’ll also touch in this later on.
We’ve talked about a ‘document’ quite a lot – but what is a document? Well, in regards to this discussion it’s pretty much anything you need it to be – the spec states:
A document is some sequence of bytes that is identifiable, establishes it’s own context (e.g. what subject, author etc), can be displayed to the user, and has defined update management
It could be a CDA, a PDF, a text file, a FHIR document or even a Microsoft Word document. It’s the DocumentReference that has the metadata about the document – which includes the format of the document (as the mime type)
The last thing that we’ll touch on in this introduction is the concept of the Affinity Domain. IHE defines the affinity domain as “a group of healthcare enterprises that have agreed to work together using a common set of policies and share a common infrastructure”
In practice this includes things like:
- The security & privacy policy that members will adhere to
- Confidentiality codes & their meanings
- What are the document ‘types’ and ‘sub-types’ – e.g. LOINC codes for things like ‘Patient Summary’, ’Discharge Summary’, ‘Clinic Note’ etc.
- The supported document formats – eg the mimeType or more detailed descriptions
- What are the possible statuses that a document can be in
- The types of facility that are recognised (Primary Care, Hospital, Rest Home)
- Clinical service (Orthopaedic, Paediatric, ED…)
There are other characteristics that can be applied to a document, but these are the most important that the affinity domain needs to agree on.
In the next post, we’ll dig into how the client sends a document to the server.