Hello! I am working on Registration module MPI integration. For now I want to advice which UI we should create for MPI querying results. In current registration workflow you will receive message that similar patient already exist if patient credentials are similar:
But in result of my project registration module will also querying to remote Master Patient Index server and get similar patients from there too. So, me and Darius think that position for result of querying to MPI should be in same place we are already showing the local possible matches. Here is the example: What do you think about this? Has anyone more preferable ideas?
I’m glad to see you working on this.
For me, it would make sense to only show one message that similar patients are found, and when reviewing them, indicate which patients are from the MPI. Having to click to review similar patients twice (once for local and once for MPI) would not be optimized. The user should also be able to see all of the similar patients at the same time so they can compare them, no matter where they exist.
That’s just my opinion; take it or leave it; no hard feelings either way. Thanks again for working on this.
Thanks for your reply 
Yep, it makes sense to make only one message which indicates that found similar patients and then indicate which of them where are located.
For me this solution is preferably
Yes, I think I agree with James that it would be more user-friendly to have a single list of patients–though the distinction would have to be clear in this list, since opening a local record and importing a patient from an MPI have different implications.
One other thing that will have to be handled is duplicates… assumedly, if the MPI is properly populated with all patients, then every patient in the local database would also be in the MPI, but we won’t want to show that patient twice. (Assumedly whether it was the “same” patient would be determined by the primary patient identifier).
However, it would be nice to have the ability to synchronize functionality between the records. For example, if 1) a patient goes to health center A and is registered, and pushed up to the MPI, and then 2) she goes to health center B, she is found in the MPI and imported into health center B’s database, but during registration at health center B she updates her phone number, and finally 3) she returns to health center A… at this point it would be nice to be able to update her phone number locally. This is probably a phase 2 (or 3) feature, however, and might be out of scope of your project… 
Even in phase 2 or 3, do you think that this synchronization would be visible in the UI or would it just happen in the background?
Oh… Mark, you have pretty impressed me 
I think this is at least out of current scope. But for future its great idea! I believe that it your idea can be implemented.
So, as a result I think we can follow James suggestions and use current UI for MPI results. Are you OK with this idea? )
+1000 to hiding this complexity from users. It would be great if we could fix the patient matching UI (i.e., not hide an obvious match behind a click), but that may be out of scope for this project.
Can’t we hide this complexity from the client (i.e., the UI layer) as well? I would think that an MPI integration would influence (essentially take over) the results reported for a patient search and, ideally, handle synchronization issues behind the scenes rather than expecting clients of the API to perform MPI-specific business rules.
@burke, I’m not sure I understand. Are you implying that once integrated with an MPI, then the user no longer sees a distinction between a local search match and an MPI one? (That doesn’t sound right.)
@approce, can you do a quick mockup of having a single notification about possible matches, and the popup list indicating some are local and some from the MPI?
@darius hmm… not sure if it would visible or not. Ideally it would happen in the background, but we could only do that if there were clear business rules on winners (which I think would be either MPI always wins or last update always wins?)
Actually, if we want to go Burke’s way, we may want to design it like this… the registration app would have two modes of funcitonality, based on whether or not it could currently access the MPI.
- MPI available:
The registration process is driven solely from the MPI–search results come only from the MPI, and updates are applied directly to the MPI. Then, at the end of the process, the local record is updated by pulling in the changes from the MPI.
- MPI not available:
The registration process driven solely from the local database. Then, at the end of the process, the patient record is flagged/queued to be sent up to the MPI when it is next available.
1 Like
The primary purpose of using a Master Patient Index is to avoid having to consider multiple pools of patients. The very job of an MPI is to coordinate patients across systems and, in the best scenario, this would be done silently for both applications (client code calling the API) as well as users. Using an MPI shouldn’t mean that you now have two pools of users; rather, it should be that your single pool of users is coordinated with other servers/sites sharing the same MPI. The more invisible this outside of the API (to users & clients), the better.
For example, showing duplicate hits for the same patient (one from the local pool of patients and one from the attached MPI) isn’t integrating with an MPI; rather, it’s accessing an external MPI and leaving it up to the client application and the end user to perform the job that the MPI should be doing.
So, @approce, I think the initial approach to take here should be:
- In the UI, display a single list of possible matching patients (which merges local and remote results)
- Display something “last visit here on xyz date” (for local matches), but otherwise there is no visual distinction
I think we should have the browser do two separate queries (one against the local server, another against the remote MPI, though it probably goes through the local server too) and merge the results together itself as they come back. This is to cover the very-common case where you have a fast connection to your local server, and a slow connection to a remote MPI.
(As long as we’re doing this, we should make sure that our data representation of the “possible match” supports something like “match quality” which we can ultimately use to improve the UI, e.g. we shouldn’t hide a near-exact match behind a button.)
What would the strategy be for applying updates locally and or to the MPI (or is that out of scope)?
The project is “Integrate Registration Module with a Master Patient Index.”
The first target is to be able to do one-way import patients from the external MPI.
After that, we will look at full two-way integration (which isn’t specific to the Registration Module at all).
We are currently implementing something similar for KenyaEMR using a custom MPI implementation developed by I-TECH a few years ago under the OpenEMRConnect project: https://sites.google.com/site/oeckenya/. This particular MPI uses PIX/PDQ v3 for communication.
One slightly different way to present matching records and synchronize between the MPI and the local data source is to present a merged view of records that match from both places. So fields that match completely would be collapsed into one and those that differ (and typically these should be few) would be presented separately. The user then gets an opportunity to establish from the patient which of the differing fields is most up-to-date and marks it as the one to be persisted in both sources.
This synchronization approach relieves the system of having to make a potentially wrong decision about which information is up-to-date and instead relies on the authoritative confirmation of the patient himself. The problem with an automated resolution mechanism is that whichever source is designated as “always wins” might actually contain the wrong/out-of-date information. Consider for example if the MPI failed to receive the last telephone number update from a given facility due to network problems. When the patient next returns, automatically overwriting the telephone number at the facility with the one from the MPI would be replacing new and correct information with old and wrong information.
2 Likes
Darius, not sure if I agree that two-way integration isn’t specific to the Registration module. It seems like an argument could be made that all upward syncing to the MPI would only happen during registration, to provide control and/or manual merge functionality like Gitahi mentions. Not sure if that is the right approach, but seems worth considering.