XDS.b Interface Module Design
Work In Progress
Please note that this page not finalised and may change significantly
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 this.
XDS.b Behaviour
The 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-43 Retrieve Document Set.b.
- ITI-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 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 be able to perform just the role of repository (or registry) for an external 3rd party 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.
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 IL; which will resolve the patient id. 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.
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 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
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.
6 Comments
Justin Fyfe
I was wondering what the inteface between HIEOS or OpenMRS would look like? Were you thinking of integrating HIEOS code within an OpenMRS module or writing this capability in HIEOS (i.e. HIEOS code that hosts OpenMRS), or using RPC or REST interface for integration between the two?
Hannes Venter
Hi Justin,
So the idea here was to make changes to HIEOS and make use of their repository storage abstract classes (http://sourceforge.net/p/hieos/code/HEAD/tree/trunk/src/xds/src/com/vangent/hieos/services/xds/repository/storage/). In this approach a new storage handler would just be added, replacing the use of the MySQL handler. This handler could then talk to the SHR REST module to communicate documents to/from OpenMRS. HIEOS would therefore handle all the XDS.b transactions, both registry and repository, but the OpenMRS SHR would handle the actual storage, including parsing the document into its discrete data model. The HIEOS - OMRS interface would then just use custom REST.
At some stage though some reservations came up about using HIEOS. The big concern was over the fact that the repository hasn't really been actively maintained, and so creating code changes may be a bit of a risk due to the lack of support. It also introduces another codebase which needs to be maintained as part of the SHR. An alternative idea was to develop a XDS.b Repository module natively in OpenMRS, enabling support for the Repository transactions, and then simply using a 3rd party registry (i.e. HIEOS or OpenXDS). At some later stage one could even develop a registry module for OpenMRS (in fact that we even had an earlier design for that https://wiki.ohie.org/pages/viewpage.action?pageId=14680366)
PS Good to hear your voice (virtually) btw!
Justin Fyfe
Hi Ryan/Hannes/et al.,
Was just wondering if you had any thoughts about routing the ITI-8 and ITI-42 transactions through the IL? What I'm thinking is that registry is already expecting to receive ITI-8 (which will be important especially for merges) and ITI-42 which HIEOS/SHR would produce. I think the IL in this type of architecture would act like a true bus for messages. For example:
HIEOS (ITI-42) <publish>=> IL <subscribe>=> XDS Registry (ITI-42)
PIX MGR (ITI-8) <publish>=> IL <subscribe>=> XDS Registry (ITI-8)
Something like subscribe the registry to ITI-42, ITI-8 and ITI-18, and subscribe the HIEOS/SHR to ITI-41 and ITI-43.
Looks good by the way.
Ryan Crichton
Hey Justin,
Yes, that is what we would want to do. So basically the registry and the repository will be kept separate and use the IL to communicate. We could setup channels in the IL do this.
I will update this documentation page to better reflect this and the new design of the SHR in the next day or 2.
To implement an XDS.b repository in the other project you have worked on, what part of HIEOS 1.x did you use? Was the classes for the XML bindings, the code to expose the actual interfaces, the auditing code, or some combination of these? Do this work well for the project or would you have done it differently if given the option? I'm just wondering how we should go about this while trying to learn from your experiences. I'd be keen to hear any insight you may have.
Thanks!
Justin Fyfe
Hi Ryan,
You might want to take a look at the xdr folder as both XDS and XDR are ITI-41 transaction profiles. That would contains auditing client stuff as well. The only bits you'd need to steal from an XDS implementation would be the ITI-42 and ITI-8 stuff. In HIEOS that is in hl7v2 pidfeed code.
Also, did you get a chance to look at the Vangent license? Is it compatible with the licenses used in OpenSHR?
Ryan Crichton
Hey Justin,
Thanks for the tips. I'l take a look at XDR as well.
I have had a look at the licenses and it seems the Vangent license is adapted from Apache 2.0. We have been using the standard OpenMRS license for our SHR work and that is adapted from MPL. So, it seems to me that the licences are pretty compatible. I'm not expert though.