I am currently working on extending our medication order template to support a “rate therapy” direction. In doing so, I’ve encountered some conflicts between the application requirements and the constraints of the underlying archetypes, primarily CLUSTER.dosage.v2, especially regarding the quite restrictive handling of administration rate.
Two specific challenges have come up:
1. Representing a rate range (min/max + target)
The application requires that the administration rate supports not only a single ordered value, but also a minimum and maximum acceptable rate, allowing some flexibility during administration.
However:
The “administration rate” element in CLUSTER.dosage.v2 is not repeatable.
* It does not support DV_INTERVAL<DV_QUANTITY>, which would be the most natural fit.
Options I’ve considered:
Within DV_QUANTITY, the available RM attributes such as normal_range or other_reference_ranges, but they do not seem semantically appropriate for this use case.
Extending the archetype to allow DV_INTERVAL<DV_QUANTITY> → feels technically possible, but questionable
Using multiple elements or different fields → not obvious which ones within current constraints.
2. Supporting additional units (e.g. per day, mass/time)
The application also requires support for a broader range of units, such as time units like “per day” (e.g. l/d, ml/d) or potentially mass/time units (e.g. mg/h). Currently, the archetype restricts units to [l/h, ml/h, ml/min, ml/s]
Options I’ve considered:
Extending the unit list via t.json as discussed before → somewhat hacky
Converting units in the application into supported ones before persistence, while storing the originally prescribed unit separately (e.g. using feeder_audit)
I would greatly appreciate any insights, best practices, or examples from existing implementations.
I will adapt the ADL and upload the adjusted version to that branch soon, and submit it for editorial review.
While expanding the list of allowed units for CR-1161, the question of orderability came up. Ideally, the unit list would be (somewhat) sorted by unit and magnitude. However, the unit list in ADL seems to be numbered, so we assume that changing the order of that list would constitute a breaking change, which should be avoided. Thus, for now, I would add the new units at the end of the list, sacrificing order for backwards compatibility. Is our assumption correct, or could we reorder the list without inducing a breaking change to the archetype?
I think these suggestions of adding units like l/d, ml/d and the more generic VOLUME/TIME, as well as adding the data type DV_INTERVAL<DV_QUANTITY> are reasonable additions.
I’m wondering whether mass/time would be more of a dose formula rather than an administration rate? Do we have practical examples of medications that are actually administered at a “rate” and whose administered form is measured as mass and not volume?
Tbh I’m not entirely sure whether changing the order of units would be a breaking change. I would suspect not, since actual persisted data only contains the UCUM unit symbol, and not the numerical order from the archetype.
I did wonder about mass/time as an administration rate but I did find a few examples of use. I guess the line between dose formula and admin rate is a bit blurred depending on local practice.
Thanks Ian! I’ve also had a chat with a colleage who’s an ICU nurse, and he could inform me that a lot of medications are dosed in this way in the ICU setting. So I’m happy with the mass/time units as well then.
@HHeiser, seeing as you’ve created a new branch for these CRs, will you be uploading a new revision to that branch?
I discussed the “mass/time” unit issue internally, and our project lead agreed that, where needed, we could convert to volume/time prior to CDR submission. However, similar to Ian’s examples, there are valid use cases for retaining mass/time directly, so supporting both options gives us more flexibility.
I’ve uploaded the proposed changes to the active branch in three commits (versions 2–4), the changes should be fairly self-explanatory.
One point that needs feedback: the property terminology group openehr::126 is removed for the administration rate unit set. The newly introduced units (l/d, ml/d) don’t align with the openEHR terminology group (L for litre), which from my understanding is based on the UCUM system. This creates an inconsistency with existing rate units (l/h, ml/min…), where l is consistently used.
For now, I followed a “capitalization consistency” approach with the existing units, but I’d appreciate guidance on whether we should instead strictly conform to the openEHR terminology, or re-insert the openehr::126property as a reference, as the discrepancy is minor (and from what I see even UCUM is not completely decided whether l or L is preferred…).
I can revise the archetype accordingly if needed. Otherwise, if no changes are required, I will submit the branch for review.
