Registration Core GSoC project

[approce (Roman Zayats)]

What have we done?

1. We have implemented functionality for querying to remote MPI server to find similar patients.
2. Import patient functionality.
3. Covered mpi functionality with 52 tests. Created integration test for import patient workflow.

As you remember, we are using OpenEMPI utility as Master Patient Index repo, which is hosted on remote server. So now, when you are going through registration workflow - we are not only searching for similar patient in local DB, but also perform querying to remote server for searching similar patient. In result we receive list of possible matches, which contains both: local and MPI matches. For local matched clerk is available to “open” patient page and see all information, but for MPI patient (as they are not located in local DB) we implemented “ImportPatient” functionality, which flow is next:

1. Get patient from MPI server.
2. Get mpi custom identifiers, for each of them try to find “Mapping by name”, create it, set to patient. (more about “Mapping by name” see below).
3. If mpi patient already contains OpenMRS identifier - import it, else - generate new one.
4. Save it to db.

About “Mapping identifier type by name” - the point it that when we receive patient from OpenEMPI we have to import all patient identifiers too. But, for this we have to know which local identifier type to use for each Mpi identifier. So, we implemented it through Global Properties, so Administrator can set, for example that for OpenEMPI identifier should be used patient_identifier_type=4, which was created for imported patient and named OpenEMPI identifier too.

Functionality we are going to implement in near future:

1. Export newly crated patient to MPI server.
2. Provide “handling” edited patient, so if they have been edited locally - push it to MPI server, if edited in mpi - import them to local DB.

Bugs which have to be fixed/issues in which we need advices/suggestions of community.

1. UI for exact matches. Here we are interested in opinion of community. What do you think about UI that we implemented for “Similar matches”? And what should we do with exact matches UI?
2. Patient duplication in “matched patients” after importing patient to DB. Now after importing patient to local DB when we will query to find “similar patients” we will receive one from local DB and exactly the same patient from MPI server. We are going to fix it my creating something like “filter”.
3. Saving instance of MpiPatient to local DB. We have problem with this issue. Our MpiPatient is extending Patient class, and we want to save it to DB but during saving we get Exception “java.sql.SQLException: Field ‘date_created’ doesn’t have a default value”. Right now, we do not want to save additional fields/columns to DB (probably we will want in future) but we just want to operate with instance of MpiPatient when we are performing “converting”, “saving”, etc. Currently we are using workaround when save it to DB, and that’s not OK.

[darius (Darius Jazayeri)]

@approce

Saving instance of MpiPatient to local DB. We have problem with this issue. Our MpiPatient is extending Patient class, and we want to save it to DB but during saving we get Exception “java.sql.SQLException: Field ‘date_created’ doesn’t have a default value”. Right now, we do not want to save additional fields/columns to DB (probably we will want in future) but we just want to operate with instance of MpiPatient when we are performing “converting”, “saving”, etc. Currently we are using workaround when save it to DB, and that’s not OK.

I haven’t had a chance to look at the code yet, but I wonder if it would make more sense to structure it as

class PatientSearchResult {
    Origin origin // Enum of LOCAL vs MPI
    Patient patient
    Object rawMpiResult  // if you want to use this for something
}

Also, please add screenshots to the above!

[approce (Roman Zayats)]

Global properties related to MPI:

• properties “registrationcore.mpi.import.identifierType.*” are using to match imported identifiers with local.
• property “registrationcore.mpi.url” - defines url to MPI server.
• properties “registrationcore.mpi.username” and “registrationcore.mpi.password” defines credentials for accessing MPI server.

Founded similar patients in local DB and in MPI:

Founded similar patients in MPI:

Imported MPI patient to local DB and created OpenMRS identifier for him:

[approce (Roman Zayats)]

importing patient with existing OpenMRS identifier to local db:

Imported patient page:

[approce (Roman Zayats)]

The thing which worries me. Do we need another one UI for “Similar patients”, and if we need that, how we should change it? For me, second one UI is redundant. The thing we can do is just change colour of “Similar patients” div from Green to orange on “Confirm” stage.

[approce (Roman Zayats)]

I have deployed OpenMRS with our enhanced Registration module to server: http://188.166.68.46:8080/openmrs You can access it by credentials: clerk/Clerk123, admin/Admin123. Check it out and give your feedback

[r0bby (Robert O'Connor)]

Great work @approce

[approce (Roman Zayats)]

Thanks a lot! Have you viewed new UI for “matched patients” during registration workflow? What do you think about it?

[approce (Roman Zayats)]

We have implemented Filter for “matched patients”. So now, after importing patient to local DB, you will receive that patient as “found similar patient” only from local DB, but not from both local DB and MPI.

1. Register patient in OpenEMPI server:

   

2. Try to register patient in OpenMRS with same family and given name:

   

3. Import Mpi patient to local DB:

   

4. Try again register patient with same family and given name (notice that similar patient found in Local DB, since you see “Open” button"):

   

[approce (Roman Zayats)]

We have done with “Export patient to MPI server on registration event” If you are interesting, check out my screenshots on my blogpost: link . Soon I will update module on my dev server, sorry about server is down now.

[darius (Darius Jazayeri)]

UI comments:

• Use the standard system font and color. Why blue?
• Use a bigger font for the name and/or any other details which you want to draw attention to. Generally, it should look kind of like what the header looks like on the regular patient pages.
• But unlike on the regular patient page, I think we should be showing all the information we have available, including all identifiers (and not just the preferred one, or the one of the main type).
• Get rid of the word “Patient:”. If it isn’t obvious that what we’re displaying is a patient, we’ve failed.
• Fit more things on each line – there’s no need for all this whitespace.
• Have a border all the way around each result, so it looks like a panel, and it’s clear what is grouped with what. (I would also suggest a thinner border.)

See this mockup to give a sense of what I mean. (I also added the “last visit”, which I know you haven’t implemented yet, but I think we should prioritize. Obviously local patients may have this, but MPI patients never will.)

[darius (Darius Jazayeri)]

Definitely we should only be showing one UI widget on the confirmation screen.

Note that we have the idea of two distinct algorithms for “fast” vs “precise” and in general we want to preserve this distinction.

The idea is supposed to be:

• After each field, we perform the “fast” search so we can show results quickly in the background
• After all fields are completed, we perform the “precise” search, and we block them from Confirming until this search has returned, and we are displaying the match (if any).

My suggestion is:

1. Do not do the “fast” search on the confirmation screen (or, just don’t show the results, if you can’t avoid the query)
2. Instead, show the results of the “precise” search on top, expanded (i.e. there’s no “x patient(s) found [review]”), because we want to force the user to review them at this point.

• in the current UI it’s confusing to have this result between the confirmation fields and the buttons

3. Use the same display template for the precise matches as the fast ones.

[approce (Roman Zayats)]

Thanks for your reply, this part is important for me, and your advices will help me to move forward

[approce (Roman Zayats)]

Ok, so we have improved a little bit UI So no matched patients looks like:

[approce (Roman Zayats)]

I have updated modules on openmrs test server and turned on it link: http://188.166.68.46:8080. Credentials: admin/Admin123 Enjoy

[r0bby (Robert O'Connor)]

I added Horatio Hornblower – it’s the sample patient that always made me giggle

[approce (Roman Zayats)]

Yep, we have pushed him after registration to MPI server:

[r0bby (Robert O'Connor)]

When I was a GSoC student, that always made me laugh…I think it has @burke written all over it…@paul made John T. Patient I think it was? It’s been so long.