Integrating OpenMRS with Motech

[Chris Ford]

Hi everyone,

At my company ThoughtWorks we have a small team working on an Atom feed implementation, which can be used as a library by various Java projects. Specifically, we're hoping to use it to integrate OpenMRS with Motech, which is a robust system for scheduling messages to patients and caregivers.

The use case we're tackling first is creating a pill regimin in OpenMRS, exposing that event as an Atom entry, and then scheduling reminder messages to be sent from Motech.

Our code is based on the Rome Atom/RSS library and is inspired by the book REST in Practice. We've written up some details of our approach and would be very open to suggestions from the OpenMRS community.

To start with we're concerned with broadcasting events from OpenMRS, but we are also looking into consuming events from OpenMRS as well as implementations in other technology stacks e.g. python. Our vision is that mHealth applications should be free to concentrate on what they do best, and to delegate functionality outside their core purpose through simple integration with other mHealth applications.

Cheers,

Chris

[Friedman, Roger (CDC/CGH/DGHA) (CTR)]

Chris --

                Please take a look at the Atom Feed module in the wiki.  Hopefully Andy Kanter and whoever is tending Atom Feed since Ben's departure can help.  We already have a way of defining a drug regimen which you can see looking at DrugConcept, Drugs and the Regimen tab of the patient dashboard.  

                The primary way of assigning a regimen to a patient would be a drug order, which may require the Atom Feed module to be extended to broadcast order events.  However, many sites have a regimen observation instead.

                I question whether it is desirable to provide daily reminders to people on regimens, I think they would quickly learn to ignore the messages.  Perhaps it would make sense to send messages randomly about once a week.

                It would definitely be good to send appointment reminders.  There are two main ways of implementing appointments.  One is via the appointment module, another is via a "Next appointment date" observation.  There may also be some sites which use an interval until next appointment observation; this is an integer expressing weeks or months.

Saludos, Roger

--
OpenMRS Developers: http://go.openmrs.org/dev
Post: d...@openmrs.org
Unsubscribe: dev+uns...@openmrs.org
Manage your OpenMRS subscriptions at https://id.openmrs.org/
 
 

[Joaquín Blaya]

Chris,
This sounds great. When you say appointment reminders do you mean SMS?  If so there's already the messaging module which supposedly does SMS, email, twitter and other things, do when I tried to use it a little while ago it was confusing enough where we built our own SMS module.

We've already connected OpenMRS to Verboice for automated phone calls, which I believe is part of the MoTech core. The code is at https://bitbucket.org/ehs/callscheduler, and we've also created modules to send SMS and another to send emails which I'd be more than happy to send you if you thought it helpful.

Joaquín
___________________________________________________________________
Gerente de Desarrollo, eHealth Systems
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org

--

[Chris Ford]

Hi Roger,

Your suggestion about appointment reminders is a good one. Right now we're concentrating on drug regimins as a proof-of-concept because it's a use-case we're familiar with from Motech's in India, but that's just a start.

We took a look at the OpenMRS Atom module when we started on this project, but we found its design isn't compatible with what we want to do, in particular supporting multi-server deployments. We're also working with other Java-based systems, so it makes sense for us to build a library that we can share between OpenMRS and other projects.

Cheers,

Chris

[Chris Ford]

Hi Joaquin,

Thanks for the link to Call Scheduler.

Motech mainly deals with SMS and IVR, though it's the scheduling itself that is its strong point e.g. particularly hairy schedules, retries etc.

Our feeling is that for sufficiently complicated requirements, it makes sense for OpenMRS to delegate to a system whose bread-and-butter is scheduling. Otherwise OpenMRS (and other mHealth applications) will eventually end up rewriting each others' functionality.

That's not to say that a native OpenMRS implementation isn't also very useful, but it's a different set of tradeoffs. :-)

Cheers,

Chris

[Daniel Kayiwa]

Hi Chris,

I first of all thank you and team for the great work you are doing. Keep it up!!!
I have a small question to help me understand how we can best leverage your work and other teams that develop functionality that is not part of OpenMRS core.

Here we go:

I see OpenMRS simply as a framework for building medical applications. And that is exactly why the module infrastructure is in place to support extensions for enabling other sorts of things that the core does not do or do as you would love it. Infact i do not think any one can use it in the real world without any module. :)
So i see the messaging module simply as one you can replace with another which does things tailored to meet your exact needs.
The same way we have infopath, htmlformentry and xforms, etc, as a pool for form entry modules from which one can choose that which best fits their needs.

So the question, can what you are developing be done simply as another OpenMRS module?
If not, what prevents you from taking that route? This will be very useful feedback for us towards improving the OpenMRS framework!!!

If we keep uppermost in our minds the unkind and unjust acts of others, we shall find it impossible to love them as Christ has loved us; but if our thoughts dwell upon the wondrous love and pity of Christ for us, the same spirit will flow out to others.

[Chris Ford]

Hi Daniel,

We intend to create a library that is of use to other applications, but we also intend to plug that in through an OpenMRS module.

So to answer your question, there isn't anything that we think modules can't do, and we aren't intending to hack core OpenMRS.

Cheers,

Chris

[Joaquín Blaya]

Chris,
So if I understand, for now you'll focus on scheduling and if needed in the future this could be extended for IVR? 

Do you have more info on the MoTech scheduling system because I'd love to know how it does the scheduling, if SMS, IVR, or something else.

Thanks,

Joaquín
___________________________________________________________________
Gerente de Desarrollo, eHealth Systems
Research Fellow, Escuela de Medicina de Harvard
Moderador, GHDOnline.org

[Chris Ford]

HI Joaquin,

Motech is an existing system with field deployments that:

• Understands and implements certain (regularly occurring) patterns found in background scheduling.
• Defines a DSL (now UI) allowing end user to define these schedules.
• Is built on top of Quartz
• Has retry logic etc

It's funded by the Grameen Foundation, and much of the development effort has been done by my company, ThoughtWorks. Grameen have a page up with documentation here - http://motechsuite.org/?page_id=460.

Our feeling is that there are two main categories of use case for SMS/IVR scheduling in systems like OpenMRS. Simpler cases would benefit from something built into OpenMRS directly as a module, which would be simpler to deploy, but more complicated cases would benefit from integrating with another system that has been built specifically around scheduling/IVR/SMS.

So we're not so much focussing on developing scheduling and IVR as on providing access to existing functionality.

Cheers,

Chris