I’m just coming back to this thread because I’m just now noticing that the refapp is including an ordertemplates module, which I am assuming is the byproduct of the above conversation.
Is anyone using this module? I’m still a little confused as to why we need this separate module to introduce an order_template table, which is essentially just a way to link a concept or drug orderable to a free-text (likely json) template string.
We already have exactly this thing in core, in the order_set_member table. Using this was discussed in the thread above, and it seems at one point like this was going to be used, but then ultimately it wasn’t?
@burke / @ibacher / @samuel34 - can you guys summarize here what was decided in terms of why this module was created and what it offers vs. using and/or adapting the core data model?
We needed to iterate on the API, i.e., we needed to be able to get order templates by the concept or drug being ordered, but the OrderService doesn’t provide mechanisms to do that.
Order sets add a level of complication to the API that we didn’t need for this feature—and we’d be abusing the concept to slot the templates in to single-item order sets. The goal of the order templates is to associate a particular drug with various metadata about the form(s) and dose(s) it is available in.
Many implementations are hesitant about updating versions of core for both good and bad reasons; part of the goal with O3 is to be able to layer the new UI on top of an existing implementation; making these changes in core would require upgrading the core version, and this could lead to hesitancy in adopting O3.
So, assuming we want a first class order_template domain object to exist, and this has now been sufficiently iterated upon, it would seem straightforward to just add order_template to core?
Yeah, that’s fair. I was more envisioning that we could just have one core order_set called something like “Single Order Templates”, which would then have as many members as needed, each of which would represent the same thing as one row in the new order_template table provides. The order_set would just be a grouping of these, it wouldn’t require creating single-member order sets for everything.
Perhaps order templates are conceptually different from order set members, in which case having these totally distinct and unrelated seems fine. But if actually it would be more accurate if, say, OrderSetMember extends OrderTemplate in core, then that 's something we might want to consider evolving into.
I get this, though that’s only really true if we are talking about O3 as a whole, and not about some optional feature. I would think it’s perfectly acceptable to say - if you want order templates within the order basket, you need to upgrade to OpenMRS xxx, or run a bridge module in the meantime.
Yes. I think we’d like to see some results with lab orders and maybe referral orders first, but, yeah.
It would probably make more sense for each order template to be treated as an order set with a single member, then we would have a unified structure for both single-order sets (perhaps the majority) and multi-order sets (for well-defined protocols).
Order templates are currently a non-optional feature if you want the order basket to work. That may not be the desirable state of things (maybe we should be searching the concept dictionary directly?), but its currently how the flow works.
Oh! So the intention is that the order_template module gets incorporated into core at some point and we figure out at that point how it does or does not relate to order_set_member?
I’m not entirely sure I follow. We already have domain objects for order_set and order_set_member in core. And order_set_member has properties for orderTemplateType and orderTemplate, which is typically going to be some sort of structured (json) text in exactly the same way that this new order_template table has done. Is there a plan for how these are intended to evolve together? It feels…messy.
That’s surprising. So if I am not running the order_template module and/or I have no order templates defined within this module, I can’t order drugs with the order basket? Really?
One more thing. Talking to @aojwang , it is clear that we need to understand the relationship between a drug REGIMEN, the ingredient concepts and the dispensed drugs. Right now we have separate concepts for each of these, with the last one in the DRUG table. There is an explicit link between the drug concepts in the CONCEPT table and the dispensable drugs in the DRUG table. However, the regimen concepts (in the CONCEPT table) are not directly connected to either of the others. The REGIMEN concepts have RxNORM or SNOMED codes for the ingredients, which theoretically can be used to link back to what the patient was given. However, this is not easy.
It is important for reporting to be able to document that a patient is on a particular regimen (HIV, TB and Oncology are particular examples). A regimen can be dispensed in numerous different ways… a three drug regimen could be dispensed as A + B + C pills, or an A/B pill + C pill, A + B/C etc… Knowing that in a particular pharmacy that the regimen is given as A/B+C seems to be a pharmacy decision. Even if we ORDER using a template which makes it easy to select the components, wrapping them together for coding as a single concept needs to be designed. This is particularly true if pharmacy is making the final decision on dispensing.
@burke and others, can we have a design session about this?
@burke/@aojwang/@grace, on the SMART guidelines call today they were working on modeling workflows that include not just prescribing but also administration and dispensing of medications. I mentioned that I thought OMRS had some use cases that involved things like pediatric dosing (mg/kg) or that required dispensing in ML or bottles. Would it be possible to bullet point those use cases so that Bryn and others could ensure that their test cases are robust enough?