Thanks, that’s helpful context. Since EMRAPI was just one example of where this could live, wanted to add a couple more options to the mix and think through the tradeoffs together.
One thing that gives me pause about EMRAPI specifically: it’s a shared dependency for a lot of modules, so if the merge/de-dup logic lived there, EMRAPI would end up depending on ordertemplates, a small, optional module, which is the reverse of the usual direction. That’d mean either every EMRAPI consumer picks up a dependency they don’t need, or we’d want an explicit optional-dependency pattern for it.
A couple of other candidates worth weighing:
- Put the merge logic in
ordertemplatesitself, as a new search endpoint that calls into the core Drug API. That keeps the dependency direction the normal way around. - Hold off on backend merging for V1 and compose it client-side instead, two calls, de-duped in the frontend. O3 already does this kind of composition in a few places, and since we don’t have real numbers yet on result-set sizes or query volume, it might be worth deferring the backend work until we know we need it. (need further discussions)
Curious which of these feels closest to what you had in mind, or if there’s another location you were thinking of that’d sidestep the dependency-direction question entirely.
On the response shape, in case it’s useful either way: here’s roughly what I’d picture a merged endpoint returning. I collapsed concept-level and drug-level templates into a single result type rather than two, since keeping them separate would add a second selection step for concept-level matches, which seemed to go against the one-step select-and-sign goal we talked about. The concept-vs-drug origin just rides along as a matchSource field, enough to show a “general default, verify dose for this strength” note on concept-level matches.
GET /orderableSearch?q={text}
{
"results": [
{
"resultType": "template",
"matchSource": "drug",
"template": { uuid, name, dosingType, dosingInstructions },
"drug": { uuid, display, strength, dosageForm }
},
{
"resultType": "template",
"matchSource": "concept",
"template": { uuid, name, dosingType, dosingInstructions },
"drug": { uuid, display, strength, dosageForm }
},
{
"resultType": "drug",
"drug": { uuid, display, strength, dosageForm }
}
]
}
Two other things worth pinning down whichever direction we go:
- Would the current
drug?q=andordertemplates/orderTemplate?drug=endpoints stay in place for flows that already have a known drug (like the edit-order lookup)? My instinct is to keep them and add this on top rather than replace them outright, but wanted to check that lines up with your thinking. - If a concept has a lot of formulations under it, resolving its template at search time could produce a pretty wide result set for one query. Not sure if that’s a real concern at our expected scale, just flagging it in case it’s worth a quick gut-check.
Class Diagram – Represents the main classes, their attributes, methods, and relationships within the proposed Drug Order Templates model.
Design Documentation:
