Implementing XDS on a FHIR Server

Jan 7, 2013

This is a follow up to an earlier post, Implementing ATNA on a FHIR server, and a preparative post for the XDS-focused FHIR Connectathon to be held this weekend. For the connectathon, I am providing an XDS.b interface to a FHIR Resource Repository. The server accepts and XDS.b “ProvideAndRegisterDocumentSet” operation, and converts it a set of FHIR resources, and then submits them to the FHIR Repository. It would be possible to support other XDS.b operations, but I don’t have time for this prior to the connectathon.

There’s some conceptual differences between a XDS.b approach, and the FHIR RESTful approach to XDS:

  • The XDS.b interface is very transactional - a focus on “submission sets”, things that are submitted together. On the other hand, the FHIR definitions for XDS are very focused on stable resources - documents, folders, authors, patients. The notion of a submission set is absent in FHIR (though you can submit groups of these resources as a “batch” to a FHIR Repository
  • Security: the FHIR definitions that support XDS functionality do not get involved with security - it is assumed that this comes from elsewhere, using standard functionality such as OAuth.
  • The classic XDS architecture has a document source submitting to a document repository, which notifies a patient registry of the existence of the document, so that document consumers can find it. FHIR handles this differently: registries, which are aggregators of content, subscribe to multiple repositories by using their atom feeds.

To explain the third point further, an XDS eco-system consists of a series of clients and servers that use the following resource types:

  • Patient/Person - patient demographics
  • Agent/Organization - author & provider information etc
  • XdsEntry - the actual index entry for a document
  • XdsFolder - when the document is allocated to a folder
  • SecurityEvent - equivalent of an ATNA record (seeImplementing ATNA on a FHIR server)
  • Binary - the resource that actually stores the document itself

In FHIR, the difference between a registry and a Repository is that the repository supports the binary resource, and references from the XdsEntry to the Binary refer to local references on the server, whereas a registry has XdsEntry resources that refer to the content found elsewhere - either Binary Resources on another server, or some other kind of server that serves resources. A registry subscribes to XdsEntry updates, and converts (if necessary) relative references to Binary resources to absolute references. It would also subscribe to the other resource types (Patient, Person, Agent, Organization, XdsFolder)

This means that a server that provides “ProvideAndRegisterDocumentSet” has to take the submission, convert it to a set of resources, and store those resources in a FHIR repository. Documents submitted through the XDS.b interface become visible by watching the XdsEntry atom feed, or by searching the XdsEntry resources on the server. Done carefully, a ProvideAndRegisterDocumentSet can be converted to a FHIR batch in a single operation, which can then be submitted to a FHIR repository as a separate operation - this is called an “XDS 2 FHIR Bridge”.

A test implementation of an XDS 2 FHIR bridge can be found at http://hl7connect.healthintersections.com.au:3098/svc/xds. This accepts XDS ProvideAndRegisterDocumentSet operations. Submitted documents can be seen at http://hl7connect.healthintersections.com.au/svc/fhir/xdsentry. This is based on an IHE certified XDR implementation, though this version hasn’t been IHE certified. (No security, btw, since the outputs are public anyway, so don’t submit real clinical documents!) (And note that due to a technical limitation in the XDS side of the implementation, this interface only accepts CDA documents, not any other kind of document).

Note that this test implementation also builds an XdsEntry2 as well as an XdsEntry - the FHIR project team is evaluating two different granularity approaches to XDS, to see which provides the best balance of usability and re-useability.

Note also that this implementation makes extensive use of inline resources, as discussed previously, as a way of evaluating their use.

**Implementation Details **

The implementation of the bridge is done in javascript. The script is commented extensively to explain that is happening. As an overview, the script has to build the following kinds of resources:

  • XdsEntry (no XdsFolder support - I haven’t seen real world usage of that yet)
  • Patient/Person
  • XdsEntry2 / Agent

In addition to building their raw contents by extracting information from the XDS ExtrinsicObject, the script also has to figure out how the resources are identified, and link them up correctly in in the batch so that server will identify them properly. Much of the hard work is involved in this step (see previous post on this subject).

The script is called and provided with a handle to 3 parameters of interest: the ExtrinsicObject element in the submission set, the associated binary content as base64, and an empty batch to be filled out form the information provided in the ExtrinsicObject. The script makes use of some fairly obvious utility functions, and a FHIR factory object that is used to construct the objects that build out the batch.

I keep the current version of the script at http://www.healthintersections.com.au/xds2fhir.js - read the script for further information.