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

The Interoperability Layer will handle the sending of all ATNA audit messages (Audit Trail), as well as provide secure interfaces for communication with external systems (Node Authentication).

Module Design

Interface

The module will expose a single HTTP(S) endpoint and will support the aforementioned XDS.b transactions via SOAP web services. Documents will be included in SOAP messages using MTOM.

Registry

The module will provide new tables and functionality for storing and retrieving document metadata.

All documents submitted to the system will get a database entry added to the document table. For repository actor transactions, such as Provide and Register Document Set.b, an entry will also be added to the document table, so as to allow for quick identification of documents. However full metadata for a document won't be added for these repository-type transactions, only the minimum required in order to identify a document. The data-model for the document registry is therefore designed to be flexible. Only a core set of fields will be required to identify a document: a document's unique id, it's content type (MIME) and the patient id. Further document metadata will be added to the document_metadata table, with the types identified via the document_metadata_type table.

The patient_id column on the document table is a foreign key to the existing OpenMRS patient table.

A submission set is used to identify documents that have been submitted together in a single transaction. Documents can therefore have a link to the submissionset table. Submission sets can also have metadata associated with them, provided by the submissionset_metadata and submissionset_metadata_type tables. This metadata describes the set as a whole rather than individual documents.

Content Handling

For saving and querying documents, the module will make use of the functionality provided by the Content Handler module.

Folders

An XDS.b submission may contain folder object types. The module will treat folders as a document with a specific content type and will generate and process it's own document contents for use with folder types. The content is simply a JSON blob with a list of identifiers of the documents that are associated with the folder.

Tools and Resources

OpenXDS provides an open-source XDS.b implementation and is fully IHE certified. It may be possible to reuse elements of this project (perhaps as a library) for helping to implement the OpenMRS module, especially for features such as metadata validation. Another option is IHEOS. Further investigation is required to determine the extent that these tools can be reused.