Integration with OpenEMPI

registration
hie
integration
Tags: #<Tag:0x00007f23d9a4fca0> #<Tag:0x00007f23d9a4fae8> #<Tag:0x00007f23d9a4f9a8>

(Burke Mamlin) #1

Continuing the discussion from Reference Application 2.7 Planning, Ideas, Features and Road Map:

@craigappl,

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?


Sync 2.0 Planning
Integration with Hearth
Propose a Design Forum Topic
Design Forum 2017-06-07: OpenMRS PIX/PDQ registration integration with OpenEMPI
(Craig Appl) #2

Hi Burke,

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.

Craig


(Darius Jazayeri) #3

If you have the option, and you’re setting the standard for future systems to work with, I highly recommend FHIR over HL7v3.


(Wyclif Luyima) #4

I did install OpenEMPI as the client registry in my OpenHIE instance, I didn’t have to write any code


(Burke Mamlin) #5

@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. :slight_smile:


(Craig Appl) #6

Hi @burke

I’ll propose to have it added to the design call on Wednesday next week.

Craig


(Craig Appl) #7

Hi Everyone,

I have a few more updates on the research:

  • 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.

@rcrichton, @pierredane & @pascal I want to make sure you’re included on this conversation.


(Wyclif Luyima) #8

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.


(Craig Appl) #9

Hi Everyone,

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.

Thanks for your help with this! Craig

FYI @rcrichton , @darius, @nathaelf, @mseaton, @mogoodrich


(Mark Goodrich) #10

@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.

Take care, Mark


(Tammy Dugan) #11

Craig,

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.

Tammy


(Craig Appl) #12

Hi Everyone,

I created a design spec as a pre-read for tomorrow’s call. I know it’s the day before and hope you have a chance to review it before the call.

Preread Resources: [Design Specification] (https://docs.google.com/document/d/1Ta2MsZuw77jWZpTsHiihfKi2NIBLuFLX8RefKOdA7Mw/edit#) Local Queue Design Characteristics

I hope to achieve the following during the call:

  • Review the design spec
  • Verify that my research is in line with the community’s understanding of existing support
  • Discuss whether this should be accomplished with native support in OpenMRS or if a third party connection is appropriate.
  • Discuss whether the HL7 Query module is the appropriate module to convert items from registration core into standard HL7 messages to be sent.
  • Share our plans for the local queue
  • See if anyone else in the community is able to contribute developer time to this over the coming month and beyond

FYI: @mogoodrich, @tmdugan, @wyclif, @darius, @nathaelf, @burke, @mseaton, @pascal, @janflowers, @pgesek


(Craig Appl) #13

Hi Everyone,

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:

  1. 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?)
  2. 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)
  3. 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.
  4. Start a thread discussing the different architecture approaches of atom feed sync vs a local queue.
  5. 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.

FYI: @burke, @mogoodrich, @darius, @wyclif, @pgesek, @nathaelf


(Wyclif Luyima) #14

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.


(Craig Appl) #15

Hi Everyone,

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?

Thanks, Craig

FYI @pgesek, @wyclif, @burke, @darius, @mogoodrich, @nathaelf


(Wyclif Luyima) #16

You’ll need to come up with a custom way to store the failed submissions in OpenMRS.


(Burke Mamlin) #17

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?

/cc @jthomas


(Craig Appl) #18

Hi @burke and @jthomas,

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.

Here are core pieces:

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.

Craig

FYI @nathaelf


(Wyclif Luyima) #19

I looked at some of the code and I realized they try to find similar matches, shouldn’t that be left to the mpi?


(Craig Appl) #20

Hi @wyclif ,

Can you describe this in more detail?

Thanks, Craig