Data Model - Drug Order, Order Set and Drug Regimen

Continuing this discussion - Summarizing drug orders into treatment regimens

Context As part of endTB project, we are looking at implementing robust drug regimen and templates.

I feel the best place to start is from the order extension module already developed for <=1.9 ( In the light of how OpenMRS has evolved around drug orders in parallel since, this is my proposition. If you feel there are other improvements please discuss, I am putting this as a straw man proposal.

Key Classes Drug Regimen (Order Group) OrderSet (and OrderSetMember and its variations) ExtendedDrugOrder

Order Set, Drug Regimen and OrderSetMember can be used mostly as it is.

Extended Drug Order class needs to go away. Some of the fields are already accommodated in Drug Order. The indication field is not. What should be done about it?

What are the things I am missing? This seems too easy :smile:

1 Like

Since the goal for this project is to go live before openmrs-core 1.12 is released, I guess the most feasible option is to update the orderextension module to be compatible with openmrs-core 1.10-era orders (or more likely, fork orderextension).

One difficulty of taking this approach is that the OrderService API has changed quite a bit, in ways that may introduce problems. (E.g. you can’t edit orders in-place anymore, only revise to a new order.)

Also, I’m afraid that if we take the orderextension approach we still need the equivalent of ExtendedDrugOrder because of the implements GroupableOrder (no need for extra fields though–I don’t expect a need for indication for the TB use case).

I hesitate to suggest this, I think we should also consider finding a way to make these changes directly in openmrs-core (this would mean forking a release version, implementing order-related changes directly in openmrs-core, and then forward-porting to the master branch, like was done with OpenMRS 1.9->1.10).

The cycleNumber field in DrugRegimen is not necessary: it’s a chemotherapy thing. (But it doesn’t hurt, if we’re trying to change as little code as possible).

1 Like

Thanks Darius,

I know this is not ideal practice, but I think my tendency might be to advocate for us to include the necessary minimum data model changes for this in the 1.10.x release line, if we can do so by adding only fields that will be nullable by default (like what was suggested for the birthtime field). I think this could vastly simplify things, and would also reduce order-related upgrade headaches to the 1.9->1.10 transition. Thanks being said, I know this is generally considered bad practice.

To my knowledge, only PIH Rwanda uses the orderextension module, and that implementation will have major work to upgrade orders to work with 1.10 anyway, so preserving existing orderextension functionality as it is in the module should not be the highest priority.

Moving these changes into a “new 1.12” implies that 1.11 is already the optimal platform to base this work from. PIH currently has no plans to upgrade to 1.11 in the near future, mainly due to risk avoidance. Is Bahmni moving to 1.11? 1.12 seems like it is clearly out due to all of the major changes happening around Java 8, Hibernate 4, etc, unless (as you say), we actually make the current 1.12 into 1.13 (or, dare-i-say “2.0”) and make 1.12 something we could actually consider using.

It would be worth thinking through what will introduce the least disruption for the most benefit.

What would be the impact of adding a nullable orderGroup property to Order + a minimal OrderGroup and OrderSet construct to 1.10.x?

What would be the impact of changing our design approach to one that does not actually put any knowledge of an OrderGroup into the order itself (eg. only loosely couple an Order with the group it belong(s) to)? This would remove all need for any immediate core changes to support groups and sets.

Looking forward to other thoughts and opinions out there.



A variation on this approach would be to have REST web services that emulate the new API we want to have (i.e. including order groups, as a link from the order) but to do this without changing the core Java objects (which could be added later on).

On this specific point: having lucene and hibernate-search in 1.11.x will likely be the driver for Bahmni to move to it.

That discussion trailed off here:

1 Like