Offline Patient Tracking

[Jeremiah Chienda]

Hi all

My name is Jeremiah, a Software Architect at Baobab Health Trust in Malawi.

I am pretty sure that this topic has already been covered, but I am looking for pointers to how we can implement unique patient records in an environment where connectivity is a big hindrance.  Jeniffer from OpenHIE hinted towards documentation of the same.

Regards

Jeremiah

[Derek Ritz]

Hi Jeremiah.

 

My name is Derek; I’m happy to (virtually) meet you. I did some work with UNICEF a little over a year ago that was on behalf of AeHIN – the Asia eHealth Information Network. One output of the project was a set of 3 short videos focusing on unique IDs for health and ways that we can operationalize these to support national-scale healthcare programmes in low resource settings. The videos can be found, here: http://www.aehin.org/AboutUs/AeHINREACHCOIL.aspx.

 

I have first-hand experience on a number of CR implementation projects leveraging the concepts outlined in the videos. On some of these projects I had the pleasure of working with colleagues at the Mohawk College mHealth & eHealth Development and Innovation Centre (MEDIC). Information about MEDIC’s open source client registry software (MEDIC CR) can be found here: https://mediccr.codeplex.com/.

 

I hope this is helpful to you.

 

Warmest regards,

 

Derek.

 

Derek Ritz, P.Eng, CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality.

--
You received this message because you are subscribed to the Google Groups "Client Registry" group.
To unsubscribe from this group and stop receiving emails from it, send an email to client-regist...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Craig A.]

Hi Jeremiah and Derek,

@Derek, I really appreciate the videos that you shared. I think they are a great introduction and have shared them with my team at I-TECH. 

@Jeremiah, I'd like to share some of our work around patient identification in areas with intermittent internet connectivity. The concepts shared in the AeHIN videos are the appropriate path for cross-enterprise unique patient identification. The core question for BHT is how you structure the information systems within your control near the Point of Service and what human workflows should take place to interact with the infrastructure client registry. The registration core module in OpenMRS is a fully functional Master Person Index for OpenMRS. The feature set includes the critical component to merge patients at the clinical level. So, within your system. you already have the core features to manage your patient populations. The problem to solve now has to do with interactions between OpenMRS and the central client registry.

We're working on the same problem in our I-TECH Haiti implementation of SEDISH (OpenHIE) and iSantePlus (OpenMRS). Here are the core issues we're working on:

• Real time interaction with the HIE to query the client registry using HL7 v2 messages (IHE PDQ profile)
• First, query to see if a person exists in the clinic system by fingerprint, ID number or demographic information
• If not, then post a PDQ message to the client registry. If the person exists, import their master record into OpenMRS as a person and patient
• Post any new registration information to the client registry using HL7 v2 messages (IHE PIX profile), both when a new patient is created and when their demographic information is updated.
• When the internet is out, queue messages so they can be retried when a connection is available
• This is a tricky workflow because timing is critical. For example, what happens if a clinic has been offline for 6 months and the record in the client registry is newer than the one in the OpenMRS queue.
• We are storing failed PIX messages in a database and planning to use Mirth to perform the retries on a regular schedule.
• Establish local workflows and policies for merging patients at the clinic level, this includes identifying what types of records to generate and push to the client registry when a merge has been completed.
• This is actively on our road map to work on before the end of the calendar year.
• Establish national workflows and policies around identifying duplicates and communicating them with client systems.
• We haven't done this yet.

Our work is on GitHub and we are working this month to merge the registration core and registration app features in to the core OpenMRS repositories.

Sincerely,

Craig