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:
- SantéMPI - OSS, seems to support PDQm and PIX profiles and has an existing OpenMRS module.
- OpenCR - OSS, supports FHIR, has an existing OpenMRS module.
- OpenEMPI - Seems like it used to be an Open Source project but I failed to find any public repository. It supports PDQm and PIX profiles, and there is an existing project proposal tangential to the development of an OpenMRS EMPI module but seems like the implementation never happened.
- (I probably left out 1 or 2)
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!
