...
| Info | ||
|---|---|---|
| ||
Please note that this page is under active developmentnot finalised and may change significantly |
The OpenMRS SHR will leverage the HIEOS project in order to provide consists of two major modules. One module that will act as an XDS.b repository and the other acting as an 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 registryregistry. 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 this.
XDS.b Behaviour
The OpenMRS/HIEOS SHR will perform 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.
The SHR
...
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 (or registry)registry (or 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
Both HIEOS and the Interoperability Layer will handle the sending of ATNA audit messages (Audit Trail). The IOL The 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..
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:
...
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
...
.