In Regenstrief’s upcoming phase of work with CDC, improving integration of OpenMRS registration with an HIE is a priority. Our goal was going to be adapting the registrationcore module to integrate with an HIE (e.g., via PIX/PDQ). So, we’re very interested in this work you mention.
When are you planning on doing the OpenEMPI integration work? Our work on this will likely start after the summer, so, depending on the timing or your efforts, perhaps we could collaborate either in parallel or in serial in a way that benefits everyone.
Were you planning on adapting the registrationcore module to integrate via PIX/PDQ with an HIE? Or were you planning going a different direction?
I’m actively researching and scoping the work to integrate using PIX/PDQ HL7 v3 or PIX/PDQm that uses FHIR. I will then compare this against the custom REST endpoint that was built in registrationcore for the GSoC project. We have a demonstration due at the end of June.
@wyclif I saw that you were working on this in March. Do you have any updates?
Here’s my working outline as I’m discovering the requirements:
We would have to add HL7 v3 PIX and PDQ handlers or bring out this PIXPDQ module from the svn repository
When we query the MPI during the registration process, we would have to link registrationcore to the PDQ handler, wait for a response from the HL7 module, parse the results into the OpenMRS data model and return them to registrationcore.
When a patient is saved in registrationcore, we would have to follow the same mechanism that’s currently coded into the OpenEMPI integration where it creates a PIX message, sends it to OpenEMPI, receives the response from OpenEMPI and stores the identifier locally.
I’m just beginning to look into the PIXm PDQm standards that rely on FHIR.
@craigappl, do you think we could chat about this or help you brainstorm on an upcoming design call? We (Regenstrief) are very interested in this topic. We might even be able to put some experienced dev time into helping.
OpenEMPI doesn’t currently support PIXm/PDQm, but Odysseas says they would be able to add it with our support.
The OpenSHR work done by Jembi is able to push messages (XDS.b, CDA/CCD) up to OpenHIM, which then validates the patient registration information against the MPI using PIX/PDQ. However, it won’t create patients if the patient doesn’t already exist.
OpenSHR comes with its own PIXPDQ manager embedded in OpenXDS, so the validation isn’t against an external EMPI. Last time I checked, I didn’t figure out a way to use an external PIX/PDQ manager in the OpenSHR, may be the Jembi folks know a way.
I schedule this as a design topic for Wednesday June 7th.
I’m building my baseline understanding of the platform’s ability to interact with third party systems. Can you confirm my understanding in the following areas and fill in where I’m not certain?
The HL7 feature in OpenMRS core and FHIR modules focus on providing interfaces for converting the OpenMRS classes into these standards. The HL7 feature has limited support for HL7 v2 and no support for HL7v3. These features are able to receive these messages, not post messages using these standards.
I can’t find a clear way to push HL7 messages from OpenMRS to an external service. Here’s what I found on groups integrating with third party tools:
Mirth Connect is commonly used to read CREATE statements in the OpenMRS database, queries the database, builds an HL7 message and posts it to the external service. (PACS-Integration is an example of this)
The ICT4H Atom Feed module listens for events that are published by the Events module and posts them to an atom feed. This feed is read by an atom server on a regular schedule, then kicks off REST API calls to get the information for a particular atom feed. This process is being used by Bahmni, OpenSRP and MOTECH.
The OpenSHR work done by Jembi is able to create XDS.b and CDA documents on demand when requested by a third party system. OpenXDS acts as a repository for these files and @wyclif just mentioned that there’s an embedded PIXPDQ manager in this process, but I don’t understand exactly how this works.
I can’t find much documentation on this. The Indiana University CHIRDL project has a module called Socket HL7 Listener that has an outbound queue for posting HL7 v2 messages. @burke, @tmdugan or @sjmckee could provide more information on this.
@craigappl In our case, we use Mirth Connect to read directly from the OpenMRS database, but I doubt this is a normal use case. Mirth can also listen on ports and receive HL7 via http or tcp… in fact, our PACS system sends HL7 messages to Mirth via LLP, which is basically a very lightweight wrapper around TCP (https://blog.interfaceware.com/common-hl7-transports/).
Our read-from-the-database solution always seemed a bit hacky to us (giving another application access to a table in the OpenMRS DB in particular), but it allowed us to quickly implement it without having to build a queue on the OpenMRS side. But, for what it’s worth, it’s worked without issue for the past 4 years. Would probably be worth building a “proper” queuing mechanism in this case though.
Our Socket HL7 Listener module can send outbound ORU messages. We also
send MDM_T02 messages from our CHICA module to get clinical notes into
Epic and Cerner.
Thanks again for attending yesterday’s design meeting. The next step is to break the project down into tangible steps as suggested.
Here are some ideas:
Integrate PDQ into registration core because it’s a synchronous call. Focus on enriching the results of patient information during the registration process. This work builds off of the OpenEMPI integration done during GSOC 2015. A core decision is whether to use the PIXm,
which is FHIR based, the PIX profile, which is HL7 v2 based or both (@burke and @wyclif could you guys contribute to this over the next month?)
Work on generating PIX messages when the patient registration is complete as part of registration core. This will need design work to identify the standards to use (HL7 v2 appears to be the easiest, but FHIR appears to be the future)
Work on generating PIX messages when a patient record is updated. This will also need a design specification. We need to determine what changes are appropriate to trigger an update and the role of registration-core in this process.
Start a thread discussing the different architecture approaches of atom feed sync vs a local queue.
Define a reference implementation of an MPI that can be tested against. MedicCR should be considered in this, including an analysis of running this on Linux with mono vs the costs associated with running it on Windows Server. I should also note that we have a docker container for OpenEMPI.
The PIXm standard is really meant for mobile and lightweight browsers and still has some limitations, I strongly believe that a lot of existing systems haven’t really caught up with the whole FHIR phenomenon and this is the reality however it’s nice to align the design with FHIR. I also believe that most likely existing PIX/PDQ implementations don’t support FHIR, so I would personally go the route of PIX messages.
We’re making good progress with the PIX/PDQ integration planning. We aim to develop synchronous calls to the MPI using PIX and PDQ. When a synchronous call fails, we need to develop a way to handle those failures.
Sample failures:
There is a failure in the internet connection
PDQ - Log the failure as INFO
PIX - Store the failed document in a central location so it can be audited, reviewed, and accessed by Mirth for a retry
The MPI Returns an invalid message type in the ACK ERROR section
PDQ - There is likely an issue that needs to be addressed by an administrator. We need to expose these to an admin.
PIX - There could be a number of issues that each need a response to follow a particular set of business logic
Questions:
Is there a way to persist these messages within OpenMRS?
We would effectively need a way to log the datetime of the message, the actual document and metadata around the failure.
If not, I assume this shouldn’t be handled by registration core and expect that we should persist these messages using a different module. Is this appropriate?
Hey @craigappl. We have some impending resources that could help with this effort (i.e., help bring this functionality to the wider OpenMRS community). Has there been more progress since June?
The core development for real-time PIX and PDQ interaction is complete and we’re testing the feature in our iSantéPlus configuration before creating a Pull Request. @pgesek and the SolDevelo team performed the primary development.
Our OpenEMPI Docker container can be found at this link. Note that we have configured the global identifier domains in OpenEMPI to reflect the Haitian Context.
The global properties are set by default in our iSantePlus module’s MetadataBundle, Note that the biometric and ECID identifiers are added in the HaitiCore module
We’re working on updating our online demo and I’ll send a message when that’s ready for others to view.
Regarding asynchronous calls:
The PIX and PDQ interactions happen in real-time. We are working on a solution when the PIX interactions fail.
When there is a failure in the PIX interaction, an event is raised and our outgoing exception module stores the failed message.
We are in the process of identifying workflows for each type of failed message.
We will use Mirth as the mechanism to retry failed events in the outgoing exception module. Mirth will communicate with OpenMRS through a REST API.
We are not storing failures in the PDQ interactions because they are queries and are meant to support the real-time identification of patients as the user is completing the form.
