OHRI / O3 Client Registration Integration

, , ,
1

Hi All,

I believe CR and MPI are the “sexiest” acronyms of the past weeks for most of us. We have currently interest from many stakeholders from different countries (Nigeria, Ethiopia and Kenya) and community organisations (@UCSF with the @OHRI implementation and @Mekom with the Ozone work, just to name a few).

Luckily this interest comes in a time that a Hackathon happening where the main stakeholders are the countries listed above and the @OHRI team is tasked to work on the integration between the EMR and MPI. Our team has already started working on this and I would like to use this post to share the approach we are taking and also move some conversation that is already happening on Slack with folks like @mksd @burke @ibacher and others.

Disclaimer: it is not my intention to discuss patient matching strategy or UPI (unique patient identifier) generation on this post but am happy to do that if needed. And I also recognise that there few posts about this topic but since they are pre O3 I thought would be nice to create a new one.

Soooo, the approach our team is taking is:

We are creating an MPI Client module (currently leaving on OHRI-Core module, will get promoted once we agree on this post if this is indeed the best approach). We decided to this to decouple the frontend with the MPI, we don’t think is the responsibility of the frontend to know how to call an MPI or any other external APIs, we think the frontend should only speak to the OpenMRS API layer.

This mpiclient as @burke and @mksd named it (and we agree) will act as proxy and provide the frontend with the necessary APIs for searching, creating and perhaps merge patients on the MPI of choice. This module should also not be aware of the MPI he is talking to because we strongly believe that since there multiple MPI available and we would not like to couple OpenMRS with a particular MPI solution neither have to develop and maintain multiple MPI Clients. In order to accomplish this level of abstraction we propose that calls to MPIs or CRs are made thru standardised APIs that can be exposed using a middleware like OpenHIM and the specifics of how to call the different MPIs would be implemented on their respective mediators (this can also be standardised and “OpenSourced”) and the only mandatory aspect would be that all exchange is done using FHIR standardised messages.

With this the only API we would have to call from this mpiclient module would be:

Auth

POST middleware-url/auth | Authentication

Basic Search

GET middleware-url/patient?freetext=Pete Basic Search

Advanced Search

GET middleware-url/patient?family=Peter&given=Ken

Create Patient

POST middleware-url/patient

…

And the frontend workflow would be has illustrated below, thanks @Mekom and @pauladams for this amazing designs.

There would be many scenarios for the workflow but the main one would be searching for patient and if not found try to search the external source (in this case the MPI/CR)

DS4_HC_Patient Search-Results-PMRSprompt

DS4_HC_Patient Search-Results-PMRSresults

4 Likes
2

Awesome! The FHIR squad has already built a lot of MPI exchange work. @mozzy @herbert24 @pmanko @ibacher @grace can you provide some info about the work that could be leveraged here to accelerate the project?

3

Thanks a lot of laying this out all out here @eudson :pray: I would say that I second most of what you have written.

Let us stress however that using an OpenMRS module to transact with an MPI is, in our opinion, a mere workaround - which is mostly fine for reading/searching operations. I wouldn’t write into an MPI that way, syncing patient identities to the MPI should be done with a middleware layer. That middleware layer’s idealised target would be the national interoperability layer (if there is one, and if there is one this may be for example OpenHIM). IMHO this is somewhat out of OpenMRS’ scope, but happy to keep brainstorming of course.

Our use case here with the RGC (Royal Government of Cambodia) is first and foremost to demonstrate that we can query the national MPI, and thereby enhance the patient search when using the EMR. Writing into that MPI is a whole other ball game that is out of scope for now.

Cc @ahabib

4

@mksd yes it is a workaround but I think it is the cleanest way for us to control what the frontend consumes, I would want to have the frontend to process anything (in the event that we do not have standardised messages, etc).

Yes the middleware would be national IOL and it is not our job (as the EMR developers) to take care of that but I would like us to push for a standard way of calling the MPI for the reasons I already mentioned in my initial message and this is the approach our team in Namibia team (kudos to this team) Is doing with their MPI solution, that would also allow them in case they want to change the MPI - they would just switch MPIs (less likely to happen).

So looking at your use case (for now), the way we are approaching this you would just switch off the interceptor that pushes data to the MPI.

5

@eudson Thanks for laying this out. A number of thoughts.

  • A small critique of the proposed API
    • The AUTH piece shouldn’t be part of any API we’re building into OpenMRS. If transactions to the actual MPI are handled by middleware, than that middleware should be appropriately configured. If the middleware itself needs some configuration passed, this should come from the OpenMRS server. I really dislike the idea that an OpenMRS REST client is passing credentials that then get echoed, etc. Even if the underlying MPI requires named credentials, these should be stored (in a secured fashion) as part of the User record in OpenMRS. We may want to introduce an, e.g., GET_MPI_RECORDS permission in OpenMRS, which would be fine to do.
    • I think the freetext parameter is… overly ambitious. If the idea is to mirror what OpenMRS search does, we should probably just call the parameter q, but we should also consider how that would be implemented in practice, that is, we can’t remain entirely ignorant of the underlying APIs for communicating with a MPI in designing this.
    • The advanced search is fine, but we should probably think through what attributes we will support and the feasibility of supporting those attributes.
    • Overall, though, even if it’s purely for internal use, I’d rather support a standardised API rather than something we’re inventing for this purpose. My initial proposal would be just to use PDQm, which is, in essence, a stripped-down version of the FHIR Search API supporting just the Patient resource and a subset of the queryable parameters. Doing this will ensure that we are basing our MPI API on something likely to be supported by real MPIs (PDQm, query-wise, has the same querying capabilities as both the HL7v2 and HL7v3 versions of the PDQ transactions).

Some broader considerations:

  • In most environments where we could reasonably expect OpenMRS to be deployed, it’s probably a bad idea to try to live-query an MPI, especially a national-level MPI. For example, the IHE PMIR profile specifies both an operation to request all “new and updated patients” or just to subscribe to live updates; the results of either of these could be written to a facility-local datastore—including, if appropriate, the OpenMRS database—which would enable us to query the results faster without needing to rely on a live connection to the MPI. I’ve at least discussed similar implementations with the I-TECH team for the facility registry work they were doing. Things might be different depending on the HIE architecture in place though (e.g., live querying might be less of a concern if the nation HIE has regional mirrors with dependable up-time).
  • It’s worth spending a minute to consider the things we might need to connect to and the APIs they provide. I put this on Slack at some point, but, quickly, the MPIs / CRs we might consider connecting to are things like:
    • OpenEMPI (there is a module for this, though it hasn’t been worked on in a while. OpenEMPI supports interfacing either via it’s custom API or PDQ / PIX and (possibly) the full PMIR specification.
    • SantéMPI (an older version of this was actually built on OpenMRS) - Provides an MPI interface to the SanteDB CDR. This claims to support the same sort of APIs as OpenEMPI, including FHIR and there’s an old module that supports querying from OpenMRS via PIX and PDQ, which was used as a basis for some work integrating OpenCR with OpenMRS.
    • OpenCR, as mentioned above, there’s a modernised version of the openmrs-module-mpi-client that has some FHIR support and a fork of that built specifically for supporting OpenCR. OpenCR does not support any IHE profiles, but it does provide a FHIR API (PDQm is really just the FHIR Search API for patients with some guarantees about the minimum supported elements).
    • Other existing national solutions (PMRS in Cambodia, TRACnet in Rwanda, etc.) that do not implement a standard MPI interface at al.
3 Likes
6

@eudson It’s very exciting to see other looking to work on Client Registry/ MPI workflows with OpenMRS. We actually started down this path already, and are implementing Client Registry interoperability in projects for Botswana and Cote d’Ivoire. For our work, we’re interfacing with OpenCR through FHIR-based transactions. Like Ian mentioned, there’s no IHE profiles or FHIR implementation guide for this communication, but it does basically follow the PDQm profile but using FHIR objects. We’re currently developing an OpenMRS module for this FHIR-based MPI functionality, which you can find here: GitHub - openmrs/openmrs-module-clientregistry: A module that enables OpenMRS to communicate with a FHIR-based Client Registry for patient search and registration.. I would love to talk through how we could collaborate on these efforts, since our goals of being able to search an Client Registry, import patients from the registry, and push OpenMRS patients to the registry seem to overlap with what you’re trying to accomplish. The module is still in the early stages, so it would be useful to meet sometime and see to what extent our requirements match up, and whether we can collaborate on this effort. We’ve previously used a modified version of the GitHub - santedb/openmrs-module-mpi-client: MPI Client Modules for OpenMRS that was updated to use FHIR-based workflows, and are now transitioning to a new module that only focuses on FHIR. Let me know if you’d like to talk in more detail, and again I’m very excited to have a wider need for this kind of work. We also have built adapter modules for Facility Registry workflows (mCSD profile) and laboratory order workflows that follow a similar architecture. You can find them at GitHub - openmrs/openmrs-module-facilityregistry: A Facility Registry Client module to enable OpenMRS to communicate using FHIR resources with a Facility Registry and act as a Facility Registry Consumer in the mCSD Profile Workflows. and GitHub - openmrs/openmrs-module-labonfhir: A FHIR-based Lab Workflow for iSantePlus. Looking forward to hearing from you!

4 Likes
7

Actually this would be easy enough to do with OpenMRS EIP and its system of Camel routes. I largely prefer this kind of approach. openmrs-module-mpiclient would merely be used to store the data obtained through the subscription with the MPI.

8

Sounds like a lot of alignment in 3+ teams here wanting to make this happen. Can we spin up a squad for this @grace @jennifer @ibacher @pmanko @moses @mksd @eudson ?

1 Like
9

Hi @eudson , we have implemented openHIM as a middleware layer at UW,we mainly spin this using docker, and we configure the different services that talk with openHIM within the docker-compose file,you might want to look at this https://github.com/I-TECH-UW/sedish-haiti.org/blob/c79d5e07e78cb0e36b084dbcf82eace263cccb0b/docker-compose.yml#L240 we are happy to demo how all this works!

1 Like
10

Good question. @eudson @mksd @pmanko what would you prefer - I might suggest keeping this light-touch? The way some mini-squads have worked, e.g. O3 Appointments, was they mostly used asynch comms via a dedicated slack channel. We can set that up or, continue to use this thread.

And it sounds like there were 2 meetings in the last 2 weeks where UCSF, Mekom, and UW tech folks got together to discuss this further. LMK if you want a dedicated link so your calls can be recorded.

I hear @samuel34 is demo-ing at tomorrow’s O3 Squad the progress UCSF & Jembi made last week on MPI/O3 connection workflows. I’ll try to add the video snapshot of that demo here.