Looking at/for the bigger picture

[Gregory Kelleher]

All,

David's suggested task would probably help sort out some of the confusion, but I think we have to first take step back, along the lines Paul has suggested. David (and Roger, as I read them) suggest that the decision for JSS is simply which technology to use in implementing the functionality of OpenMRS. However, this discussion is only one thread of a broader proposal (presented a few weeks ago) to refactor the architecture in order to take advantage the most suitable technology available.

Unfortunately (for me), I've been using mind maps, drawings and conference calls to discuss the original proposal and none of them survived conversion to this forum. I've said I would reconstruct the original context in a message to this group -- and I am working on it; meanwhile, here's a very brief synopsis:

OpenMRS is designed to be a comprehensive EMR, built on a relational DB foundation, to serve clinical, medical management, clinical research and reporting requirements. It can be extended by means of a modular framework and is intended to provide for decision support. At the core and in its data model OpenMRS has extremely fine granularity so as to be able to satisfy today's requirements and those that are not foreseen.

This comprehensive design, implemented with the best persistence approach available until quite recently (relational database), has met with serious challenges in regions having unreliable infrastructure. The design is inherently tightly coupled and synchronous and thus highly susceptible to power and network outages, and yet very difficult to synchronize across a network of installations. These problems are not unique to EMRs or healthcare. Other industries, notably banking and telecom, have been addressing these issues for decades and the explosive growth of mobile applications has been driving the development of solutions at a remarkable rate.

That's the motivation. What does JSS need? Or rather: Who needs what and when? A partial list:

The clinician needs the patient's "medical record", including reminders, during a patient encounter.
The clinician may need resource availability (drugs, consultant appointments, etc) while entering orders.
The pharmacist needs current inventory, including lead times and usage rates, at re-order time.
The research statistician needs a stable snapshot of the normalized longitudinal medical record, refreshed monthly.
The public health epidemiologist needs graphs of trends and a tally of real-time patient registrations categorized by presenting complaint, clinic, and residential location.
The chronic disease nurse needs to know rent failed appointments by treatment regimen, and record of follow up actions.
The patient billing department needs a list of services provided at time of discharge, at the end of a visit, or at month-end, whichever is first.

Reflecting on these and similar data needs, it seems to me that most fall into one of three categories:

1) simple real-time event notices or accumulations of such;
2) Highly/broadly available patient-specific, human readable documents, reports and suggestions;
3) Monthly snapshots of highly normalized longitudinal patient records.

These requirements can be met, I think, using a combination of standard practices and new but proven technology.

a) Decouple systems by channeling inter-system communication through an enterprise messaging system (RabbitMQ or ejabbard);

b) Divide the duties of the EMR between 2 separate: clinical and analytical;

1) Make OpenMRS the analytical repository, with a relaxed schedule of monthly deadlines to resolve or reduce fault-tolerance;

2) Use CouchDB/CouchApps to serve the clinical and operational data needs, taking advantage of its fault-tolerance, replication & sync, speed and position in the mainstream of mobile and web development;

c) Use the message queuing system to: share data that have multiple uses; enable concurrent systems through authorized pub/sub; manage processing priorities; create workflow systems; etc.

Note that OpenMRS would naturally be the master of the concept dictionary though CouchDB would control when to use the dictionary concepts. Data made available to OpenMRS would probably be limited to what's properly controlled.

Note also that part of the solution to fault-tolerance issue is the selection of the named FOSS systems -- RabbitMQ, ejabbard, CouchDB -- because of their use of Erlang/OTC.

I believe there are other benefits to this direction, but I've already made a short story long.

-- Greg

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

What Greg is proposing is starting from scratch. There is a lot of merit in the event bus design he proposes. I can see that there would be advantages in using a dual transactional/analytical storage strategy. But OpenMRS would not be anyone's first choice for the AVR data store, the KAV data structure is not so good for that. Nothing of what he proposes makes any use of OpenMRS.

People feel their frustrations with systems more strongly than their satisfactions. I think that the "middle path" reflects Saptarshi's particular frustrations. It's only when you try to replace the features of a multi-person-year product that you realize you've thrown out a lot of hard-won experience.

I don't think that the JSS Raxa team is up to producing a new- or dual-technology product. Just handling the UI issues over the various devices it wants to use will be a challenge. OpenMRS didn't get where it is by magic; it's received a lot of support and had a lot of paid, experienced developers working on the project; it's spent years evolving its development methodology and building its community. Even its not outstanding documentation has taken years to create; the only thing developers want to write is code (so merely participating in this discussion proves you're not a developer).

Frankly, if the goal of the project is to produce a working product in a short time, I'd prefer to see the project use more OpenMRS rather than less. I'd rather see it using API calls rather than REST to interact with the DB. I'd like it to be able to use existing modules with minor modifications. I'm fine with abandoning the main screen and the patient dashboard, there are even tools to help us do that. But people would have to make a firm decision and be willing to learn the details of OpenMRS.

All,

-- Greg

--
You received this message because you are subscribed to the Google Groups "Raxa JSS EMR Database" group.
To post to this group, send email to raxa-jss-e...@googlegroups.com.
To unsubscribe from this group, send email to raxa-jss-emr-dat...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/raxa-jss-emr-database?hl=en.