Commcare & OpenMRS module

107 views
Skip to first unread message

Christian Neumann

unread,
Jun 23, 2016, 9:07:19 AM6/23/16
to MOTECH Developer
Hi all,

Im currently working with Partners In Health (Boston) to explore options of bringing CommCare into the set of their tools. With this a potential integration of CommCare and OpenMRS via MOTECH seems like a promising approach.

For this I'm looking closer into the MOTECH modules for OpenMRS and CommCare. I'm particular interested to find out how the 'gap' between case data (CommCare) and patient data (OpenMRS) can be bridged. 

Therefore my first question: Is this the right place to discuss details and implications of these modules? (am using this dev list as the users lists seems ... a bit quiet)

And if yes, is there additional documentation about current (or future) ways about the scenarios you already (or want to) cover with these modules?

Thanks a lot,
christian

Craig A

unread,
Jun 23, 2016, 10:31:40 AM6/23/16
to Motech-dev
Hi Christian,

This is the right place! Thanks for reaching out. We have significantly improved our CommCare and OpenMRS integration over the past few months for field deployments in Nepal and Mozambique. I'll contact you in a separate email with Nick Reid copied so we can share the details.

Sincerely,
Craig

--
You received this message because you are subscribed to the Google Groups "MOTECH Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to motech-dev+...@googlegroups.com.
To post to this group, send email to motec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/motech-dev/d56ea6b8-611d-484f-a40a-8beee5f661c4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Craig Appl
Lead Technical Program Manager, Mobile Health Innovations
Grameen Foundation
2101 4th Ave | Suite 1550 | Seattle, WA 98121
Skype:craigappl
Connecting the World's Poor to Their Potential

Craig A

unread,
Jun 24, 2016, 5:47:34 PM6/24/16
to Motech-dev
Hi Everyone,

We had a discussion and realized that this information should go on the dev list for everyone to see. Please see my email below that details the current capabilities of OpenMRS and CommCare integration. Please feel free to add anything or message me with any questions.

Craig

-----------------------------------------------------------------------------------------

Nick has been driving the Bahmni-MOTECH-CommCare integration in Nepal with a partner organization and can provide details, documentation and workflows as needed. We have another project in Mozambique that's getting started tracking HIV/TB defaulters in CommCare integrating multiple clinics with OpenMRS Platform 1.11.x.

In a nutshell, we offer two way integration between CommCare forms and cases and OpenMRS patients, programs, encounters and obs. We are able to identify changes in each system, match/modify the information and push it to the other system. 

Here's a list of current integration capabilities:
- CommCare Create Case <-> Create Patient in OpenMRS
- CommCare Update Patient details <-> Update OpenMRS Person information
- CommCare Form submitted -> Create encounter with obs in OpenMRS
- MOTECH can connect to multiple OpenMRS instances and CommCare Projects

Development is in progress for the following:
- OpenMRS Enroll in Program -> Update CommCare Case properties (to display the appropriate forms for the program)
- CommCare Form submitted -> Update OpenMRS program stage/complete program
- OpenMRS Relationship Created -> Update Case Property in CommCare (to assign mobile workers to cases)
- MOTECH can receive CSV reports from the OpenMRS reporting module, parse each row and update CommCare cases for each patient. This is used to identify defaulters in the Mozambique implementation because they are identified by time since last visit, not trigger events in OpenMRS. A manual upload is currently available, but we're working on a report processor to post the report to the MOTECH URL to automate the process.

The CommCare module documentation can be found here and the OpenMRS module documentation can be found here. The OpenMRS module doesn't have the information for the features currently under development, but we can supplement that as needed.

I should also mention that we use the Bahmni atom-feed module in OpenMRS to identify the changes to patient records. We're working to identify an appropriate port of that module to OpenMRS Platform so the same information can be made available on both systems.

Sincerely,
Craig

Christian Neumann

unread,
Jun 27, 2016, 5:10:40 AM6/27/16
to motec...@googlegroups.com
Hi Craig,

You are (or already have been) addressing quite a few things - this is pretty exciting!

I know a bit about OpenMRS, but am still new to CommCare and have a few questions. Hope you don’t mind if I start to shoot them out in an unstructured way:
  • How do you match a newly created OpenMRS patient to a CommCare case? 
  • Where and how do you decide which CommCare user should ‘own’ this case?
  • Will both CommCare and OpenMRS always have the same set of data (e.g. number of CommCare cases == number of OpenMRS patients)?
  • How do you handle multiple CommCare cases happening to the same OpenMRS users, e.g. multiple pregnancies of one female patient over time?
  • Did you encounter (or expect) an upper limit of patients and/or cases that you can handle?
Before sending out more question I’ll try to sort my thoughts a bit!

Thanks so far,
christian

You received this message because you are subscribed to a topic in the Google Groups "MOTECH Developer" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/motech-dev/s7o9WvaMjfo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to motech-dev+...@googlegroups.com.

To post to this group, send email to motec...@googlegroups.com.

Nick Reid

unread,
Jun 27, 2016, 1:22:50 PM6/27/16
to MOTECH Developer
Christian~

Since Craig might be a little slow to respond, let me try to answer a couple of your questions...

Overall, MOTECH integrates systems via user created tasks, which means most of the specific logic about what gets moved from one system to another is up to you. With that in mind, I'll try to answer your questions, mostly by referencing how we are implementing in Nepal with PossibleHealth and Dimagi — just remember this is one possible way to have MOTECH plug OpenMRS into CommCare, and alternative approaches might make more sense for PIH or the business logic you are supporting...

Its worth noting that PossibleHealth is using Bahmni, not vanilla OpenMRS

How do you match a newly created OpenMRS patient to a CommCare case? 
MOTECH consumes an Atom feed of newly created or updated OpenMRS patients — so when there is a new OpenMRS patient, we receive the patient's UUID and create a new case in CommCare.

Where and how do you decide which CommCare user should ‘own’ this case?
Right now this is a manual process with in OpenMRS because in Accham, Nepal, some VDCs are served by two or more CHWs — which made it hard to figure out when to assign one person or another.

Currently, there is a matching list of providers for each CHW in CommCare, and we check for a Patient->Provider relationship. If we have a provider/CHW for that patient/case, then we assign the created case to that CHW.

Will both CommCare and OpenMRS always have the same set of data (e.g. number of CommCare cases == number of OpenMRS patients)?
It doesn't have to, and is probably easier to not have matching datasets.

In our implementation with FGH in Mozambique, only patients who 'default' on their HIV-related appointments get sent to CommCare for follow up. These patients are identified in an OpenMRS report, and that report is sent to MOTECH, which then moves the needed data from OpenMRS to CommCare.

Forms from CommCare are forwarded to MOTECH, and only the needed information is sent back to OpenMRS. 

How do you handle multiple CommCare cases happening to the same OpenMRS users, e.g. multiple pregnancies of one female patient over time?
OpenMRS patients and CommCare cases are loosely linked by a mapping table that is created and updated within MOTECH. This means you can choose to enforce a one to one relation between OpenMRS and CommCare, which is basically what we are doing with PossibleHealth in Nepal.

It is possible to map one OpenMRS record to multiple CommCare cases, but it sounds like you want to have the CommCare case only update when it is open — so there is a one-to-one mapping when the CommCare case is open, and otherwise there are multiple possible relationships that are not updated.

Did you encounter (or expect) an upper limit of patients and/or cases that you can handle?
MOTECH can handle as many patients as you can throw at it...


As a sidenote, we (Dimagi, PossibleHealth, and MOTECH) are formalizing our integration plan in a slide deck here, its still a working draft so its not complete or perfect...yet...

--- nick ---





For more options, visit https://groups.google.com/d/optout.



--

Nick Reid
Grameen Foundation, Mobile Health Innovations

2101 4th Ave | Suite 1550 | Seattle, WA 98121

nreid@grameenfoundation | +1.510.410.0020 | Skype: nickdotreid
GrameenFoundation.org | Twitter│MOTECH Project

Christian Neumann

unread,
Jun 28, 2016, 10:42:48 AM6/28/16
to motec...@googlegroups.com
Pretty neat! And incredible helpful for me to understand scope and potential.

Its worth noting that PossibleHealth is using Bahmni, not vanilla OpenMRS

I think this was mentioned earlier already. But to make sure I get it: This dependency is mainly due to the Atom feed component of Bahmni? Or are there other things you rely on which are not available in OpenMRS?

How do you match a newly created OpenMRS patient to a CommCare case? 
MOTECH consumes an Atom feed of newly created or updated OpenMRS patients — so when there is a new OpenMRS patient, we receive the patient's UUID and create a new case in CommCare.

Makes sense. Is it fair to say that OpenMRS is the lead in terms of patient creation? Not sure if I’ve thought everything through, but I could see problems when both CommCare and OpenMRS are technically able to create new patients. Well, maybe the patient creation is not that problem, but rather a patient reconciliation / de-duplication later on.

Will both CommCare and OpenMRS always have the same set of data (e.g. number of CommCare cases == number of OpenMRS patients)?
It doesn't have to, and is probably easier to not have matching datasets.

In our implementation with FGH in Mozambique, only patients who 'default' on their HIV-related appointments get sent to CommCare for follow up. These patients are identified in an OpenMRS report, and that report is sent to MOTECH, which then moves the needed data from OpenMRS to CommCare.

Forms from CommCare are forwarded to MOTECH, and only the needed information is sent back to
OpenMRS. 

I like that. And it is also easy to understand that here CommCare cases are only for a subset of patients and are only ‘temporarily’. Could be a very useful thing in Malawi too.

How do you handle multiple CommCare cases happening to the same OpenMRS users, e.g. multiple pregnancies of one female patient over time?
OpenMRS patients and CommCare cases are loosely linked by a mapping table that is created and updated within MOTECH. This means you can choose to enforce a one to one relation between OpenMRS and CommCare, which is basically what we are doing with PossibleHealth in Nepal.

It is possible to map one OpenMRS record to multiple CommCare cases, but it sounds like you want to have the CommCare case only update when it is open — so there is a one-to-one mapping when the CommCare case is open, and otherwise there are multiple possible relationships that are not updated.

Does this mean that in Nepal you basically have the CommCare case open as long as you have a (active) patient record in OpenMRS? And then once the patient record becomes inactive (moves out of catchment area, dies, defaults, no longer in care), then you close the case?

Did you encounter (or expect) an upper limit of patients and/or cases that you can handle?
MOTECH can handle as many patients as you can throw at it…

I understand. I would think the because of the event-based approach of MOTECH it could scale nicely and depends more on number of events than one absolute patients or cases. So just like I’ve learned with our prototype it seems key to properly dispatch/divide the users to discrete CommCare users.

As a sidenote, we (Dimagi, PossibleHealth, and MOTECH) are formalizing our integration plan in a slide deck here, its still a working draft so its not complete or perfect...yet…

Thanks for this link. Will have a closer look later today.

And again another thanks for the good and fast feedback! Gives me plenty of brain-food.

christian

Nick Reid

unread,
Jun 28, 2016, 6:08:00 PM6/28/16
to MOTECH Developer
To reply to your points as concisely as possible:

Integration dependance on Bahmni
Yes, the main dependance on Bahmni is only for the Atom Feeds — and Craig has mentioned there is a "pure OpenMRS" Atom Feed module (but I don't remember where that is). MOTECH can read and write to a bunch of the OpenMRS APIs using tasks defined in the MOTECH UI — the real trick is triggering an even to take an action

Patient creation and deduplication
Yes, both CommCare and OpenMRS can create entities, and yes that means the potential creation of duplicates. In both of our implementations, we focus on OpenMRS as the 'master database' and do deduplication there. Unfortunately record duplication with any system is a constant problem, so the real pain point is deciding how, organizationally, you will deal with deduplication

Nepal open cases/patients
PossibleHealth had decided to keep their patient records open, so we mimic the same workflow with CommCare. There are exceptions when a CommCare case will be closed, but that won't effect the OpenMRS record. An example of this is if a patient working with a CHW leaves the area with out telling us where — in which case the CommCare case will get closed, and an email will be sent to an administrator to see what action should be taken (ie remove address from OpenMRS, or assign to other CHW to see if they can find the patient) — but these "defer to a human" are the types of examples I love about MOTECH as its easy to program that email. PossibleHealth deeply uses Asana, so we can actually send emails to Asana which will turn into an action item for someone to take care of....

Assigning CommCare cases to Mobile Workers
Yes, you need to come up with some logic to assign workers — currently we are keeping this process manual, but if an organization wanted to make a module in MOTECH, it would be trivial to write complex logic in code (but the pain point there is having that capacity)

-- nick -- 


Christian Neumann

unread,
Jun 29, 2016, 7:11:05 AM6/29/16
to MOTECH Developer
This all makes total sense to me. Except one thing: What do you mean by 'PossibleHealth deeply uses Asana'? I only did a 5 seconds web search, but nothing significant came up. It sounds as I want to know more about it...

Thanks,
christian

Christian Neumann

unread,
Jun 29, 2016, 7:12:05 AM6/29/16
to motec...@googlegroups.com
This all makes total sense to me. Except one thing: What do you mean by 'PossibleHealth deeply uses Asana'? I only did a 5 seconds web search, but nothing significant came up. It sounds as I actually want to know more about it...

Thanks,
christian

--
You received this message because you are subscribed to a topic in the Google Groups "MOTECH Developer" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/motech-dev/s7o9WvaMjfo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to motech-dev+...@googlegroups.com.
To post to this group, send email to motec...@googlegroups.com.

Nick Reid

unread,
Jun 29, 2016, 11:43:37 AM6/29/16
to MOTECH Developer
Asana is a to do list type app developed for teams. PossibleHealth would make a great case study for Asana, as they have taken the time to really integrate it into their daily workflow. 

Apparently it took time for them to get everyone on board, and using it "correctly" — but its helped decrease their internal email and be more transparent/managed as an organization — it was conveyed to me when I asked about it, that the transition was not easy, and getting people to use OpenMRS was far easier...

-- nick --



--
You received this message because you are subscribed to the Google Groups "MOTECH Developer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to motech-dev+...@googlegroups.com.

To post to this group, send email to motec...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/motech-dev/6B0DE405-201C-411E-8345-E2EE45EBD6A1%40gmail.com.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages