Strategy for handling health and medical information

[Bruce MacLeod]

Does Motech have a strategy or provide support for handling health and medical information ? I understand that we have a module for MRS/OpenMRS and that will certainly serve the needs of some applications. But what happens when we target millions of users ? Or try to integrate multiple applications, each with their own set of patients, providers, facilities, health records, ... Is the EMR, with it's associated API, at the right level of granularity ?

     Should motech provide repositories/registries for some of the common health data domains ? In particular, do we need dedicated registries for

• providers
• patients
• facilities
• medical encounters/observations
• shard health record 
• federated security
  

I could easily see how OpenMRS could provide one implementation of the registries, while an application with millions of patients might have a better, high performance data store.  Currently, there is upcoming motech work in Bihar that requires many of the above categories of information. My impression is that the TAMA application built much of the above functionality from scratch ... can we do better ?

Using registries also has the advantage of isolating the health information and may reduce the amount of implementation code for an implementation. Of course, one challenge is that we will need to devote some time to developing a good core domain model and provide mechanisms to extend the core registry information.

 

[Rob LaRubbio]

Some comments inline

On 4/27/12 11:21 AM, Bruce MacLeod wrote:

Does Motech have a strategy or provide support for handling health and medical information ? I understand that we have a module for MRS/OpenMRS and that will certainly serve the needs of some applications. But what happens when we target millions of users ? Or try to integrate multiple applications, each with their own set of patients, providers, facilities, health records, ... Is the EMR, with it's associated API, at the right level of granularity ?

I think you bring up some interesting scenarios, but I'd like to get a little more detail around them before trying to come up with solutions.  When you say "integrate multiple applications" do you mean built on top of MOTECH or are they external?  Is there a concrete use case driving this that exists?  If not can we define some and then run some thought experiments about how we might solve it?

     Should motech provide repositories/registries for some of the common health data domains ? In particular, do we need dedicated registries for

• providers
• patients
• facilities
• medical encounters/observations
• shard health record 
• federated security
  

I could easily see how OpenMRS could provide one implementation of the registries, while an application with millions of patients might have a better, high performance data store.  Currently, there is upcoming motech work in Bihar that requires many of the above categories of information. My impression is that the TAMA application built much of the above functionality from scratch ... can we do better ?

By do better do you mean re-use and make generic or choose existing off the shelf solutions?

Using registries also has the advantage of isolating the health information and may reduce the amount of implementation code for an implementation. Of course, one challenge is that we will need to devote some time to developing a good core domain model and provide mechanisms to extend the core registry information.

Can you elaborate on what you mean by a registry?  Is it a module?  Or is it an existing system that we interface with?

-Rob

[Bruce Macleod]

Good questions. Will start with some quick responses for the purposes of
continuing the discussion. I do not have complete answers at this point.



>>> Rob LaRubbio 04/28/12 1:02 AM >>>

Some comments inline

On 4/27/12 11:21 AM, Bruce MacLeod wrote:
> Does Motech have a strategy or provide support for handling health and
> medical information ? I understand that we have a module for
> MRS/OpenMRS and that will certainly serve the needs of some
> applications. But what happens when we target millions of users ? Or
> try to integrate multiple applications, each with their own set of
> patients, providers, facilities, health records, ... Is the EMR, with
> it's associated API, at the right level of granularity ?
I think you bring up some interesting scenarios, but I'd like to get a
little more detail around them before trying to come up with solutions.
When you say "integrate multiple applications" do you mean built on top
of MOTECH or are they external? Is there a concrete use case driving
this that exists? If not can we define some and then run some thought
experiments about how we might solve it?

I am referring to external applications ... Commcare, OpenMRS, and now ReMeDi for the WHP project. I do not have concrete use cases at this point, but the discussion was initiated when I read some of the specifications for the WHP. The requirements documents suggest that motech will need to keep track of providers and some patient information. I could have it wrong, but some good use-cases could come from these specifications. If so, then the platform developers could coordinate work with WHP developers.


Another upcoming scenario comes from Ethiopia. Currently we are planning to duplicate provider information in both OpenMRS and Commcare. The duplication of data does not feel right and I am struggling with finding a better solution. Furthermore, there is discussion of pulling data from OpenMRS into Commcare. Can all data be pulled ? Depending on how automated this pull is, we may need an authority of some sort to specify the boundaries. This scenario is not concrete yet and it will require some more building out.

>
> Should motech provide repositories/registries for some of the
> common health data domains ? In particular, do we need dedicated
> registries for
>

> * providers
> * patients
> * facilities
> * medical encounters/observations
> * shard health record
> * federated security

>
> I could easily see how OpenMRS could provide one implementation of the
> registries, while an application with millions of patients might have
> a better, high performance data store. Currently, there is upcoming
> motech work in Bihar that requires many of the above categories of
> information. My impression is that the TAMA application built much of
> the above functionality from scratch ... can we do better ?
By do better do you mean re-use and make generic or choose existing off
the shelf solutions?

By better, I was hoping to not have to build motech code to manage the above information (providers, ...) for an implementation. If there was basic functionality to manage these core domain entities, then applications would not have to write code for the routine stuff. Any of the above possibilities work for me and would have a preference for easier (look for off the shelf, open source, first)

>
> Using registries also has the advantage of isolating the health
> information and may reduce the amount of implementation code for an
> implementation. Of course, one challenge is that we will need to
> devote some time to developing a good core domain model and provide
> mechanisms to extend the core registry information.

Can you elaborate on what you mean by a registry? Is it a module? Or
is it an existing system that we interface with?

I would view the registries as data repositories that are accessible, but not integrated into motech. The conceptual idea is to move the data to the edges of motech ... externalize it and access via WS (rest, ..) calls. Changing access to a registry should be a matter of changing the call from motech. The registries would have CRUD capabilities.


-Rob