Generalised CR/MPI Integration

Hi all,

Extending and igniting an interesting discussion initiated here by @eudson. Let’s dive in!

OpenMRS has previously been integrated with HIE components, including a CR/MPI. Thus, this thread isn’t about figuring out how to integrate an CR/MPI but rather about implementing generalized support.

Existing O3 CR/MPI integrations:

Various implementations have emerged for CR integration in O3:

KenyaEMR:

KenyaEMR appears to have the simplest use case. The EMR queries for Patients from the registry by an Identifier.

UgandaEMR:

UgandaEMR supports both a simple and advanced mode for patient matching. This should work perfectly; the only issue is the duplication of fields, which forces the registration clerk to capture some fields twice. The UgandaEMR team had to resort to this approach because it was their best option to work within the premises of the supported configuration options within registration.

SIGDEP-4:

Capture demo:


Patient CR review:

We had to fork the Registration ESM to implement the workflow above. The registration clerk captures the demographics, then proceeds with “Next”. A POST search is made to the CR, returning the found matches; the clerk decides whether to start over or submit the drafted patient as is. (We used a modal here, which may not conform to the O3 aesthetics; hopefully, the UX experts will suggest a better paradigm).


Generalizing CR support

Patient Registration: We need to figure out how to accommodate mutual workflows, especially the “advanced mode”. This will help mitigate redundancy in the registration form. It should be possible for me to repopulate the form from a CR search result without navigating to the standard patient search (assuming this support will be added as part of this initiative).

Patient Search: We should support both basic and advanced modes as per the PDQm spec.

Backend CR Client: There are probably many client registries out there, but within the ecosystem, OpenMRS has been integrated with a handful of CRs:

Looks like most MPIs support PDQm or at least FHIR (It’s fair to say that PDQm is a subset of FHIR search) which gives us a landscape of abstraction. We can develop a generic MPI module that basically:

It seems most MPIs support PDQm or at least FHIR (It’s fair to say that PDQm is a subset of FHIR search), giving us a landscape of abstraction for developing a generic MPI module that:

  • Registers the OpenMRS local node to the hub, or simply connects to the MPI for simpler setups.
  • Implements a lightweight API layer that follows the PDQm profile.
  • Defines and exposes necessary endpoints (based on FHIR) in the web layer:
    • Patient Search
    • Patient Creation
    • Patient Matching
    • Patient Linking & Unlinking
    • Patient Deletion
    • Etc

The above is probably not close enough to the ideal approach; that’s why I’m reaching out to you for your thoughts!

cc: @ibacher @mksd @burke @mseaton @aojwang @slubwama @janflowers @caseynth2


In conclusion, the discussion surrounding the integration of CR/MPI in OpenMRS is both intriguing and essential for advancing healthcare systems. By examining existing implementations and considering the generalization of CR support, we pave the way for more efficient workflows and improved patient care.

Cheers!

7 Likes

@samuel34 great topic, nice to see this coming back up.

When you talk about the advanced mode are you talking about the Advanced search results pulling patients from external datasources as per @pauladams designs illustrated here and the implementation done by @OHRI (check screenshot bellow)?

Also the backend support of a generalised integration has been started already by @pmanko and @amugume on this module.

This whole idea is inline with what was discussed during the OPD Workshop a couple of weeks ago which is basically the intention of having a layer that allows OMRS to speak with the different systems in a generalised way (based on the context) - what the @Mekom team has started with ozone.

Happy to be part of this conversation.

3 Likes

When you talk about the advanced mode are you talking about the Advanced search results pulling patients from external datasources

The search functionality can be categorized into two modes:

  1. Basic: This mode allows searching by an Identifier or the patient’s name.
  2. Advanced: In this mode, a refined search is conducted, with additional data points such as names, gender, date of birth (DOB), etc., directly contributing to the score or results.

basically the intention of having a layer that allows OMRS to speak with the different systems in a generalised way (based on the context) - what the @Mekom team has started with ozone.

Interesting! Has the work regarding the CR already commenced? Is there an existing epic? Is this a perfect time to set up a squad?

1 Like

For those interested in this discussion and more, please note that CR integration will be one of the topics to be discussed during this week’s TAC call. The call is scheduled for 15/02 (This Thursday) at 17:00 EAT. You can join the call here.

6 Likes

Here are some links for the dev work we were doing on the client registry module:

https://openmrs.atlassian.net/jira/software/c/projects/HIE/issues/?filter=allissues

2 Likes

@rugute - This may interest you given the work you are doing in migrating to o3 and the need to hit CR when registering a patient. This may be helpful for patient registration and patient search.

1 Like