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)