"Administration rate" constraints are quite strict for rate therapy medication order

Clinical Ask an editor
1

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.

2 Likes