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 (https://wiki.openmrs.org/display/docs/Order+Extension+Module). 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
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).
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).
