by: Sima Morgenstern

Dosage and Timing

If you’ve had the chance to implement any of the following resources: ActivityDefinition, Dosage and Timing

If you’ve had the chance to implement any of the following resources: ActivityDefinition, MedicationDispense, MedicationKnowledge, MedicationRequest, MedicationStatement, Parameters, StructureMap, or Task, then you’ve surely become acquainted with the super-element called Dosage. While there’s no actual element type called a “super-element,” if there were, dosage would probably earn that title. Instead, we’ll call it a BackboneElement, because that’s what it is. Remember, there are three types of elements:

1. Primitive data type: A simple type containing values like a number or code without a code system. Identified as string, integer, code, etc.
2. Complex data type: A complex type containing other elements (both complex and simple). For example, CodeableConcept, Range, Identifier, and more.
3. BackboneElement: A complex element with the possibility of a modifierExtension, which is an extension that cannot be ignored. This element often contains many additional elements, and many of us spend hours deciphering the meaning of each one.

In our case, as if it weren’t complicated enough, dosage itself hosts another backboneElement, equally complex, as one of its elements.

On the other hand, if you stumbled upon this article just before implementing any of the resources mentioned above, consider yourself lucky. Sit back and let this article guide you through the intricacies of this super-complex element called dosage.

---

Dosage

As its name suggests, this element defines the dosage instructions and timing for taking a medication or performing a task with a repetitive aspect. It comprises several simple data types:

1. text: Can contain verbal instructions, such as those received from a pharmacist or doctor.
2. sequence: Indicates the order of taking the medication. For example, specifying the dose number of a vaccine or indicating an action that comes as number X in a sequence of tasks to perform.
3. patientInstruction: Additional text that describes the interpretation of the administration for the patient.

Beyond these elements, there are quite a few complex elements. We’ll proceed according to complexity, leaving the most complex for last.

1. additionalInstruction: Additional coded instructions for administration, preferably using SNOMED CT.
2. asNeeded[x]: A Boolean value indicating that the medication can be taken as needed within the defined time range. A coded value describes the preconditions for taking the medication or performing the action.
3. maxDosePerPeriod: Specifies the maximum ratio of medication dose within a defined time period. It consists of two Quantity elements indicating a relative amount and a maximum amount to administer.
4. maxDosePerAdministration and maxDosePerLifetime:
   1. maxDosePerAdministration: Specifies an upper limit on the amount of medication to administer at one time, such as Otrivin, which is recommended for no more than three days.
   1. maxDosePerLifetime: Specifies a lifetime upper limit, for medications limited to a one-time use.
   1. Both are complex elements called SimpleQuantity.

Here, we use an element called Quantity, which consists of a numerical value, a comparative value (+, <, >), unit of measure, code system for units (like UCUM or SNOMED), and the code from the code system. We also use SimpleQuantity, similar to Quantity but without the comparative value.

---

Method, Route, and Site of Administration

The next group of complex elements describes the method, route, and site in the body for administering the medication. Each element seems straightforward but can be managed differently in various databases. Therefore, it’s important to clarify:

• method: Injection, ingestion, spraying, application.
• route: Nasal route, oral route.
• site: Physical location on the body for administering the medication, like the oral region of the face or the root of the nose.

These are examples from extensive lists of values existing separately in each code system. Remember to represent a code system for each need.

---

Defining the Dose to Administer

The next complex element, doseAndRate, explains the medication dosage to administer, whether over a period or in a single dose.

• type: A CodeableConcept element indicating the type of dose, such as calculated or pre-ordered.
• dose: Indicates the amount of medication per dose. You can specify a range (e.g., 1–2 pills) or a simple value (e.g., 2 pills). And just to emphasize, it’s called SimpleQuantity, but it’s not really simple—a bit of humor there.
• rate: Indicates the amount of medication per unit of time. It can be specified in three ways: a value like 5 ml/h, a range like 5–10 ml/h, or a ratio of 5 ml/h. The ratio represents the relationship between two values within the element and differs from the simple value.

---

So far, so good. To introduce the last element, let’s delve into relativity. Familiar with the saying “Time is relative”? The timing element contains various components that can interpret any timing logic: every 8 hours, 3–4 times a day, twice a week for an hour, one pill every other day in the morning 10 minutes after a meal until 30 pills are taken—you name it.

timing comprises three elements: event (an array of timing dates), code (a CodeableConcept with code system for predefined timing patterns), and repeat (a set of rules for timing). The repeat element includes nine rules to implement timing logic. It’s crucial to adhere to these rules to avoid validation errors.

---

Repetition

repeat—when and how often does the action or medication administration occur? It consists of the following elements:

• bounds: Boundaries, which can be defined in three ways:
  • duration: A limit by time, age, or duration. If a value exists, the element instructs to use a code to describe the value, and the code will display an expression of time.
  • range: Boundary with two values of type SimpleQuantity.
  • period: Boundary with a start date and an end date.

The other elements in repeat describe the repetition of the action or administration in various ways—number of times to repeat the action, duration of each administration, frequency of actions within one time period, and the period indicating how often to repeat the action. These four elements come together and are interrelated, as we’ll see in the examples. Additionally, you can specify exact days of the week, times, or specific times of day, and even count the minutes after/before administration. The four main types of elements the rules refer to are:

• count / countMax: Number of times to repeat the action. countMax is the maximum number of times to repeat the action.
• duration / durationUnit: Duration of each action and its unit of time.
• frequency / frequencyMax: Frequency within a period.
• period / periodUnit / periodMax: The period and its unit, indicating how often to repeat the action.

---

Examples

Below is a table illustrating how these elements are used in different scenarios:

Description	duration	durationUnit	frequency	frequencyMax	period	periodUnit	periodMax	count
Every 8 hours			1		8	h
3–4 times a day			3	4	1	d
Twice a week for an hour	1	h	2		1	wk
Every 21 days for two hours	2	h	1		21	d
Every 4–6 hours			1		4	h	6
One pill every other day, 30 pills total			1		2	d		30

Note: For illustration purposes, in the last example, we might also specify when = MORN (morning), when = PCM (after meal), and offset = 10 (minutes) to indicate taking the pill in the morning, 10 minutes after a meal.

---

Unit of Measure Coding Issue

Here, we highlight an open issue around the world regarding coding units of measure. HL7’s guideline states: “If the unit can be coded in UCUM and a code is provided, it SHOULD be a UCUM code.” The clear preference is for UCUM coding because it allows for automation of conversions between different units of measure. However, dosages are sometimes given in units that are not classic units, such as capsule, drop, etc. Some of these units don’t have an agreed-upon UCUM code and can’t be automatically converted to other units, requiring a decision on how to represent them.

One option is to use a format defined by UCUM for such needs, where a “code” can be created using any string within curly braces. For example: {TAB} or {CAP}. Seemingly, this uses the recommended code system. On the other hand, it’s not truly a standard code. Different implementers are likely to provide different “codes” for the same units of measure. Moreover, the advantage of UCUM in converting between units isn’t manifested here.

Another option is to use SNOMED, which contains codes for all types of dosage forms and can be used for those units not standardized in UCUM. The advantage is the standardization of codes; the disadvantage is deviating from the recommendation. In such a case, it’s unclear what the standard’s preference is and which solutions organizations will adopt. We note that ILCore has yet to formulate a recommendation on the matter.

Since projects cannot wait for a national recommendation, it’s advisable to formulate a reasoned decision and submit it as a recommendation to the community. Notably, the NHS recommends using UCUM, and if the desired unit of measure isn’t available, then using SNOMED-CT descendants of 732935002 (Unit of presentation).

And that’s basically it. Simple.

---

Dosage and timing got you twisted? Converting legacy data to FHIR can be hard! Come check out FUME, our FHIR-Converter, to learn how it can be made easy!