Higher-level APIs and back-end configuration for O3

One of the great strengths of OpenMRS is it’s modularity. Another is it’s configurability. However, with both of these come some limitations. One can configure any kind of patient identifier or person attribute that one wants, but there is no clear, shared representation of “what is the patient’s telephone number” or “what is their primary identifier”. One can also add modules that extend the API with rich features for things like “appointments” and “queues”, but these are generally interacted with in isolation - we lack higher-level APIs for things like “Check-In Patient” that can orchestrate these components and can manipulate encounters, visits, queue entries, and appointment data for a configured workflow transactionally.

In refapp 2.x we attempted to address some of this via the emrapi module, but that module is not currently part of refapp 3.x and none of the O3 frontend modules are designed to work with it. My recollection is that this exclusion was intentional in the initial development of refapp 3.x, mainly in an effort to reduce module-dependency bloat, but I believe we need to revisit this.

I would like to propose a path in which we review the current state of the emrapi module and evolve it such that it is relevant for today’s O3 context, and then establish a plan for introducing these higher level APIs and more shared backend configuration into O3. I have created an initial ticket along these lines here, but wanted to get more community feedback on this and am interested in hearing other opinions and thoughts about the best way to approach these challenges.

Some specific examples that we can target initially if helpful for framing:

  • The front-end should be able to retrieve shared configurations for things like “patient phone number” and “patient primary identifier” from the back-end, without needing to introduce (multiple) front-end configurations for how these are defined

  • The front-end should be able to “Start a visit, create an encounter, update an appointment, and create a queue entry” transactionally with one REST submission, rather than the current process that makes multiple independent submissions and can leave the data in a potentially inconsistent state.

If we do take this approach with EMR API, one initial question is what is the highest version of OpenMRS we can get away with moving towards as a minimum for something that O3 will depend upon.

Thanks for reading and considering!

1 Like

Looks like a good plan. Thanks @mseaton.