XDS.b Interface Design

The OpenMRS SHR will leverage the HIEOS project in order to provide XDS.b functionality. An instance of HIEOS will run in front of OpenMRS in order to receive and process XDS.b requests, acting as an XDS.b registry. Documents will be stored in OpenMRS and processed discretely as far as possible.

XDS.b Behaviour

The OpenMRS/HIEOS SHR will perform as Document Registry and Document Repository actors in the following transactions:

• ITI-18 Registry Stored Query
• ITI-41 Provide and Register Document Set.b
• ITI-42 Register Document Set.b
• ITI-43 Retrieve Document Set.b.

Note that the SHR will NOT participate in the Patient Identity Feed transactions (ITI-8, ITI-44) when performing transactions in the Document Registry role. In the wider OpenHIE architecture, the Interoperability Layer performs the task of resolving patient identifiers from the Client Registry (acting as Patient Identity Source) before sending transactions to the Shared Health Record. In addition, the SHR will also not provide the ITI-42 Register Document Set.b transaction functionality, which will be provided by the IOL whenever a Provide and Register Document Set.b transaction is received. It is therefore the combination of the SHR (both OpenMRS and HIEOS) and the IOL that provides a complete implementation of an XDS Registry and Repository.

The SHR (with the IOL) plays a dual role of both Document Registry and Document Repository. As a registry the SHR can store metadata about documents, while as a repository, the SHR can provide the storage for these documents. The SHR must switch between roles depending on the transaction, and should, if required, be able to perform just the role of registry (or repository) for an external 3rd party repository (or registry).

Transactions

See this page: http://wiki.ihe.net/index.php?title=Cross_Enterprise_Document_Sharing as well as the technical framework documentation at http://www.ihe.net/Technical_Frameworks/#IT for technical details about the XDS.b transactions.

ITI-18 Registry Stored Query

The SHR can act as a Document Registry for Registry Stored Query requests.

ITI-41 Provide and Register Document Set.b

The SHR can act as a Document Repository for Provide and Register Document Set.b transactions. The transaction must be sent to the IOL; which will act as a Patient Feed Consumer for resolving the patient id as well as act as a Document Repository for sending an ITI-42 Register Document Set.b transaction. The SHR will act as a Document Registry for receiving the Register Document Set.b transaction, but if required, another external registry can be used. In this case the SHR will not act as Registry for the particular Provide and Register Document Set.b transaction. After patient id validation/enrichment and sending the Register Document Set.b transaction, the IOL will forward the Provide and Register Document Set.b transaction to the SHR (acting as Document Repository) for handling.

ITI-42 Register Document Set.b

As described, the SHR can act as a Document Registry for receiving Register Document Set.b transactions. This transaction will allow Document Repositories to store metadata about the documents that they need to store.

ITI-43 Retrieve Document Set.b

The SHR can act as a Document Repository for receiving Retrieve Document Set.b requests. The transaction allows Document Consumers to retrieve specific documents from the repository.

ATNA

Both HIEOS and the Interoperability Layer will handle the sending of ATNA audit messages (Audit Trail). The IOL will provide secure interfaces for communication with external systems (Node Authentication).

Implementation

HIEOS has a flexible storage backend and by default provides a MySQL storage implementation for storing documents. We plan however to store all documents in OpenMRS, and therefore will implement a custom HIEOS storage class that will forward/retrieve all documents to/from OpenMRS. The HIEOS storage class will use REST services using the SHR REST Interface module in order to communicate with OpenMRS.

Document Unique ID and OpenMRS encounter UUID

Documents are identified in HIEOS using an uniqueId field. It will be necessary to map this field to an encounter UUID in OpenMRS, especially since the encounter UUID will be transparent at an XDS level. Two possible options are:

1. Add the association in HIEOS and query documents from OpenMRS using the encounter UUID
2. Integrate the uniqueId into OpenMRS and expose a REST endpoint for retrieving documents using the uniqueId.