# "Administration rate" constraints are quite strict for rate therapy medication order **Category:** [Ask IEB](https://discourse.openehr.org/c/ask-ieb/37) **Created:** 2026-03-23 15:41 UTC **Views:** 73 **Replies:** 7 **URL:** https://discourse.openehr.org/t/administration-rate-constraints-are-quite-strict-for-rate-therapy-medication-order/11867 --- ## Post #1 by @HHeiser 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`](https://ckm.openehr.org/ckm/archetypes/1013.1.5948), 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`, 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` → 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](https://discourse.openehr.org/t/adding-to-the-dv-quantity-units-options/1964/53) → 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. --- ## Post #2 by @HHeiser After discussing internally and doing some more research, we discovered that both aforementioned problems already have change requests in the CKM: * [CR-1309: FHIR supports range for administration rate](https://ckm.openehr.org/ckm/archetypes/1013.1.5948/changerequests/1013.36.1309) submitted by @SevKohler on 11.02.2026 and already supported by @ian.mcnicoll * [CR-1161: Expand possible units of administration rate quantity](https://ckm.openehr.org/ckm/archetypes/1013.1.5948/changerequests/1013.36.1161) submitted by Angela Merzweiler on 11.12.2024 I am not confident in the CKM workflow, but I have taken the initiative of creating a new branch to implement those changes: https://ckm.openehr.org/ckm/archetypes/1013.1.8248 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? ![grafik|475x500](upload://rWkbmHm6Mn80LpMsAmFKn5pyp3J.png) --- ## Post #3 by @siljelb 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` 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. --- ## Post #4 by @ian.mcnicoll 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. --- ## Post #5 by @siljelb [quote="ian.mcnicoll, post:4, topic:11867"] I did wonder about mass/time as an administration rate but I did find a few examples of use. [/quote] Which examples did you find? --- ## Post #6 by @ian.mcnicoll I was hoping you would not ask as I could not rememebr but here is an example. https://litfl.com/drug-infusion-doses/ ![CleanShot 2026-04-01 at 13.23.53|690x146](upload://82b6zgIs6OFFThnpMc3HHnkRxsA.png) --- ## Post #7 by @siljelb 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? --- ## Post #8 by @HHeiser Thanks @ian.mcnicoll and @siljelb for your contributions! 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::126`property 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. --- **Canonical:** https://discourse.openehr.org/t/administration-rate-constraints-are-quite-strict-for-rate-therapy-medication-order/11867 **Original content:** https://discourse.openehr.org/t/administration-rate-constraints-are-quite-strict-for-rate-therapy-medication-order/11867