OpenMRS vs. Couch

[Matt Adams]

Hi folks,

I'm a little late to the party but I'll make an effort to chip in at
Daniel's request.

First off, I see very little point in attempting to take the middle path
and assume that REST calls to OpenMRS will translate effectively to a
REST layer implemented on top of Couch where no such REST layer
currently exists. Starting off by using OpenMRS/REST and then hoping to
switch to Couch is going to be a very painful process and will add undue
complexity to this project.

In other words, it either makes sense to go the route of OpenMRS or
Couch but not both. I know that Manor has mentioned other storage
engines but I am not familiar with them so I can't comment on those
specifically. I don't think that it matters much *which* storage engine
that we're referring to at this stage. The point I'm making is that
Raxa either uses OpenMRS or it does not use OpenMRS. There is no viable
middle path.

Issues concerning OpenMRS/Couch scalability and efficiency are moot
points right now. SQL/Couch tuning are known quantities and solved in
projects far larger than this one. If, as Shuro alluded to, Raxa ever
gets the dedicated interest of significantly bigger parties there will
be resources to go along with those endeavours. Worrying about that
right now is premature optimization.

Having installed OpenMRS 1.8.2 and taken a look at the OpenMRS schema I
do not think that reorganizing it into something that is suitable for
Couch will be especially arduous (this includes dictionaries and some
other concepts although I am not certain about the HL7 bit). I can't
give any firm estimates but a couple of weeks worth of solid work should
be enough to establish a framework for this and a foundational Couchapp.

If it is simply the intent of the project to use OpenMRS via REST as
nothing more than a persistence layer than there is little that we will
loose in terms of "business logic" from OpenMRS. As Roger has alluded
to most of the add-on smarts come from modules.

I think that the leadership of Raxa need to determine whether or not the
loss of existing and potential functionality in terms of stock and
extended OpenMRS is worth the capabilities that can be realized by
moving to a Couch system. The realization that going Couch will be
more-or-less starting anew is rather monumental in my mind.

I am going to echo Roger's most recent comments because I think they are
particularly sane and echo the sentiment that I expressed during the
conference call this past Sunday.

> 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.

My general expectation is that a Couch-based system would give Raxa JSS
flexibility that they would otherwise only begin to dream about but the
road to that is quite possibly longer and harder than you have the
stomach or resources for, especially as this project appears to be
largely reliant on volunteers.

Cheers,

Matt
--
Matt Adams
Radical Dynamic
www.radicaldynamic.com

[Gregory Kelleher]

Matt,

I don't understand the part in the first paragraph about CouchDB not having a REST interface. It's in fact CouchDB's only interface. .???

-- 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.
>

[Matt Adams]

On 03/11/11 05:32 PM, Gregory Kelleher wrote:

> I don't understand the part in the first paragraph about CouchDB not

> having a REST interface. It's in fact CouchDB's only interface. ???

My point is that the REST interface to OpenMRS (see link below) is
entirely different than the REST interface to Couch. One REST interface
is not necessarily equivalent to another. If Raxa modules are built
against the former they will not be directly compatible with Couch.

In addition there is also the matter of the JSON payload and document
structure not being necessarily equivalent to the best document
organization in Couch.

https://wiki.openmrs.org/display/docs/REST+Web+Services+Technical+Documentation

Hopefully that clarifies what I'm referring to.

Also, Raxa modules built against the OpenMRS interface won't be
Couchapps in any sense of the word and there is more than just GET and
POST to take into account when interfacing with Couch.

[Gregory Kelleher]

Matt,

Yes, that helps, thanks. I imagine that some difference in REST requests can be handled by rewrite rules, though that could still leave differences in document content.

-- Greg

[Gregory Kelleher]

Matt, 

Also, Raxa modules built against the OpenMRS interface won't be Couchapps in any sense of the word ...

I suppose it's a minor point, but the web interface for OpenMRS could indeed be CouchApps.  CouchApps are HTML5 served up by a CouchDB having access to the same DB for persistance.  There's no reason they can't use websockets for arbitrary ip connections, including to the OpenMRS API or the RabbitMQ service.

This web interface could become a fuii-blown layer in a "middle way" in which the couchdb provides (pre-fetch loaded) caching for self contained apps.  A more advanced scenario (for which I have a sketch somewhere) adds a couchdb library of the latest JSON-encoded medical record produced by OpenMRS.  The message queues cache unprocessed obs (in accessible form) until OpenMRS processes them and pushes the revised documents to the library.

This approach uses all of OpenMRS except for the hapless web forms tolerates downtime in the EMR.

-- Greg