Page History

...

The OpenMRS SHR interface module will actaully consists of two major modules. One module that will act as an XDS.b repository and the other acting as an XDS.b registry. We will attempt to will leverage the other open source projects in order to provide XDS.b functionality in the modules. Documents will be stored in OpenMRS and processed discretely as far as possible. See the rest of the design here for more details about thisThis module provides an XBS.b interface into OpenMRS. It is expected to receive any type of document payloads over the XDS.b interface and pass those on to the content handler with the content type of the payload.

XDS.b Behaviour

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

...

XDS.b repository module (Document Repository):

• ITI-41 Provide and Register Document Set.b
• ITI-42 Register 43 Retrieve Document Set.b.
• ITI-43 Retrieve 42 Register Document Set.b

XDS.

...

b registry module (Document Registry):

• ITI-18 Registry Stored Query
• ITI-42 Register Document Set.b

...

• ITI-8 Patient identity feed.

Image Added

(Edit this image)

The SHR

...

Image Removed

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 repository (or repositoryregistry) for an external 3rd party repository registry (or registry)repository).

The development effort will focus on building the repository capabilities into the OpenMRS SHR, during this time a 3rd party XDS.b registry can be used to enable the XDS.b transactions to take place. The OpenMRS registry module will only be build at such a time when there is a particular need for it to exist along side the repository in OpenMRS and in cases where the 3rd party registry is not able to fulfil this role any more.

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.

...

The SHR can act as a Document Repository for Provide and Register Document Set.b transactions. The transaction must be sent to the IOLIL; which will act as a Patient Feed Consumer for resolving will resolve the patient id as well as act as a Document Repository for sending an ITI-42 Register Document Set.b transaction. The . 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

...

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 OpenMRS XDS.b registry and repository modules will implement the required ANTA audit logging. The IL will provide secure interfaces for communication with external systems (Node Authentication) and provide audit logging for the Document Source and Document Consumer actors..

Module Design

OpenXDS

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. Further investigation/prototyping is required.

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.

Content Handling

Implementation

The XDS.b transactions will be build directly into the OpenMRS modules. An attempt will be made to reuse existing open source code to speed up this work. In particular the following projects will be examined to identify reusable components:

HIEOS 1.x

This is a registry / repository that has been previous used in other XDS.b implementations, it was found to be easier to wield than the 2.x release. Good setup guide was on the Kenai wiki https://kenai.com/projects/hieos/pages/SetupGuide. One of the problems is it relies on having glassfish 2.1 running (it won’t run on 3, or 4 or even other 2.x releases of glassfish).

DCM4CHE

This is technically an XDS-I implementation for a RIS however works as an XDS repository/registry system as well. The specific project is https://github.com/dcm4che/dcm4chee-xds.

OpenXDS

An open source XDS.b registry and repository implementation.

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