Release 4B
Medication DefinitionWork Group Biomedical Research and Regulation  | Standards Status: Informative |
This module is concerned with resources and functionality in areas such as:
These resources are not typically used in direct patient care or day-to-day prescribing functionality (for which see the Medications Module, and further down on this page: Relationship to Prescribing), but play a supporting role. They can specify the "full" version of the product type, with all its information, including the licensed packages available, with their physical details and containers, through to individual tablet level and on to ingredients and component substances.
The main medication definition resources and their relationships are shown below (any can be used when required, but there is no need to use all of them).
The core is a three level model: product, package, item:
You can vary the levels used, according to the application needs:
Even just using one resource, for a basic representation:
An example of a single resource version is here
The core resources of Medication Definition deal with products and their packaging:
| Name | Description |
| MedicinalProductDefinition |
The MedicinalProductDefinition resource covers the detailed defining data of medicinal products, to a level beyond what is typically needed for day-to-day prescribing, but that is commonly required by manufacturers and regulators, and also for use in drug catalogs and pharmacopoeias. (For direct patient care when prescribing, dispensing etc. the correct resource is Medication). |
| PackagedProductDefinition |
The PackagedProductDefinition resource represents one pack type of a product, and can also capture all aspects of the physical packaging of a product. These pack types can be associated with an "owning" MedicinalProductDefinition, to represent the range of different pack sizes for that product. These may have different legal statuses and availability, or be packaged in different ways. The resource allows describing which drug items and associated co-packaged devices are within them. The actual contained items are handled by specific resources (e.g. ManufacturedItemDefinition and DeviceDefinition). |
| ManufacturedItemDefinition |
ManufacturedItemDefinition is used when you need to describe a physical medication item type such as a tablet or capsule, or some continuous substance such as liquid or powder. This is typically for regulatory or manufacturing use cases, rather than day-to-day prescribing or dispensing. It can carry the definition and characteristics of a medicinal (or medically-related) manufactured item, usually to be contained in a packaged medicinal product, and not found on its own. The package definition carries the quantity of each contained item, allowing re-use for different amounts |
| AdministrableProductDefinition |
A medicinal product may consist of several items, which need to be combined before administration to the patient. The administrable (or "pharmaceutical") product - which differs in that it is now "mixed" from its components (if necessary) and is ready for use - is covered by the AdministrableProductDefinition resource. The components are ManufacturedItemDefinitions. |
The product and packaging resources listed above can be combined to represent a product with different packs:
National level drug dictionaries typically have a split between products and the packs that exist for them. The product level has the common data such as name, strength, form, indications etc. Medications are usually prescribed at product level, rather than specifying a particular pack. But eventually it is an actual pack that gets dispensed, with a specific size or item count and packaging configuration (carton, bottle, blister pack etc).
Packaging information can be complex, and the PackagedProductDefinition resource allows any combination of items and packaging to be represented.
Here is a representation of a widely available combination product pack of a tablet and cream:
.png)
An example of a combination product is here, shown as a bundle and here, shown instead using contained resources (either can be selected according to preference)
Co-packaged devices can be represented, as well as items that need to be combined before administration:
.png)
A full example of a co-packaged device with a powder and solvent is here.
A simpler example of a co-packaged device and liquid is here.
The PackagedProductDefinition resource can be used for different aspects of package information:
The resource elements must be used in a consistent way for each case. This diagram shows how these three cases are handled. See the PackagedProductDefinition resource for more information.
| Name | Description |
| Ingredient |
The Ingredient resource describes a material used in the preparation of a medicinal/pharmaceutical product, within the context of a particular use. An ingredient is part of a product, either alone or in combination with other ingredients. It is essentially a substance with the addition of the specific role it is playing in the product, which may include whether it is an active or inactive substance and what the strength is (the quantity of substance compared to the whole product). |
| SubstanceDefinition |
The detailed description of a substance, typically at a level beyond what is used for prescribing. |
Medication Definition covers the surrounding context of medications, their use and legal status:
| Name | Description |
| RegulatedAuthorization |
RegulatedAuthorization is a resource covering the authorization of a type of product, item, device, process, treatment, facility or service, from a regulatory point of view. |
| ClinicalUseDefinition |
ClinicalUseDefinition is a resource to capture a usage issue - either an indication, contraindication, interaction or an undesirable effect for a medicinal product, medication, device or procedure. The resource represents one single issue, in one of several types. |
There are other resources that are of particular interest to the medication definition domain.
The main Medication Definition resources for products and substances are purely about kinds of things - definitions - and not physical instances. Instances of products, such as things that are actually dispensed, administered or tested, are Medications. "Kinds" can be prescribed, either as a code (which represents a definition) or as a reference to a FHIR product. A concept in a code system, such as SNOMED CT, NDC or UK dm+d, and a concept as a FHIR MedicinalProductDefinition, are equivalent. Both represent a type of drug. In use these must always go via a Medication resource. Instances of substances and ingredients (a substance in a role) are Substances. Data such as batch numbers, and actual manufacturing dates belong on instances of products or substances rather than definitions.
This diagram shows the principles of how these sets of resources relate:
The Medication resource, and others in the Medications Module (shown at the top of the diagram), mainly cover the use of a medication "by reference" (using a code), with only some basic extra optional information: form, strength, perhaps batch number and even less commonly used - simple ingredients. Many of those are rarely populated because they are implicit in the code. So the Medication resource doesn’t define medicinal products to any extent, it is more of a selector.
The MedicinalProductDefinition resource, and the others in this module (show lower in the diagram), cover the detailed defining data of medicinal products, to a level that is only occasionally needed for day-to-day prescribing (e.g. for look-ups of unfamiliar products), but that is commonly required by manufacturers and regulators.
These Medication Definition resources are information about drugs (and related products), and drug product information is useful any time that a drug is part of a scenario or is in the attention of a clinician or patient.
If the drug is in scope of a workflow then these resources and their content data may be in scope of the software. But these resources are not themselves directly "prescribed". You usually prescribe a shorthand drug reference - a code (with varying specificity) - and not the page from the pharmacopeia or drug catalogue - which is more what these resources represent. But it is clear that the prescribed drug and the information in the catalogue or database about that drug are two sides of the same thing, and not two different worlds. Those detailed properties always exist, in all settings.
So the main difference between the Medication resource and the Medication Definition ones is level of detail, or more accurately the "extent" of information. To prescribe a drug all you need to do is identify what drug it is (or substance etc.). But there are times when you need to open your book (national formulary, or maybe a national drug regulator's website) and want to know the color of the tablet, or if it can be given for children, or if it has a syringe in the package. You may need to know if it is licensed as prescription only (in France), or if an excipient is present that the patient is allergic to - and who manufactured that. Or if it comes in a smaller or bigger pack. All of this is in these Medication Definition resources. You don't prescribe that information (or the book) but it is useful to support prescribing, and other patient processes, such as adverse event investigation.
You therefore prescribe a "code", but these resources sit behind this code, providing context and definition, giving more detail than even most drug code systems/ontologies tend to have. Also, this information forms the product dossier when people want to decide if this drug is safe and effective, and this is separate from prescribing use.
The distinction between the two sets of resources is not "regulatory" versus "prescribing". It is important to realise that there is only one set of defining information in the real world about the drug, no matter what context, or who needs it, or what subset is relevant to them. The drug info is the drug info and it exists whether it's a clinical trial, a drug licence approval, or a dispense. It always has this set of properties - though some parts of the information set vary depending on the geography and over time.
Hence the information in the Medication Definition resources is not correctly scoped as "regulatory". It is just the facts about the drug, same as always, from when it was first created and trialled, to when it is manufactured, distributed, prescribed and then tracked after administration. However at dispense and especially at prescribe time only a smaller subset of this information is usually of direct interest. Regulators on the other hand, by the nature of their role, study the drug in great depth (down to molecular level perhaps) and consider more of the same set of information, which these resources cover.
The medication definition resources don't cover any aspect of direct patient care, and in some cases the information is even in the public domain. However drug development often involves confidential data of a commercially sensitive nature, and as such the resources are susceptible to data breaching. Necessary privacy and security provisions must be in place when transmitting, searching and fetching this information. For more general considerations, see the Security and Privacy module.
BR&R workgroup recognises that there are different ways a medicinal product could have been modelled, when we created these resources in collaboration with Pharmacy and other workgroups.
We now seek interested parties to implement the resources for their own requirements, and to provide feedback with evidence of what works and what may be missing. This will help us to cover the appropriate scope of medicinal products.
Development Rationale:
Some different modes of design for these resources were considered.
One large model, with a profile for Medication:
A decision was made by the joint committees to retain Medication as a core resource, without it needing to be a profile. The profile approach was rejected because it would mean that Medication, a very key resource in FHIR, would be appear much more complicated, with a lot of concepts that are unfamiliar to pharmacists. No other core resources mandate the use of profiles.
One generic "product" entity resource, profiled for use as product, packages, internal structure, tablets and ingredients:
Although these things have some features in common, this was seen as too confusing in use. All these items would look the same in the data instances and at searchable end points. There would be a jumble of products containing products with products inside those, consisting of products that are made of products. It was felt it was necessary to distinguish as clearly as possible between the main entities that are common concepts. For example, a distinction between products and packs exists in many drug dictionaries.
This compares with resource concepts of Observation, Condition and Procedure, or Patient and Practitioner. While those closely related clinical entities have many data items in common, it is considered helpful to distinguish which are which as clearly and simply as possible, and not rely on context or relationships to show what are they are (or the use of optional profiles).
Boundaries:
While we seek to be clear which parts of the model to use for which item, this does occasionally lead to difficult choices in boundaries, given the wide range of products and items that exist. This is similar to issues sometimes faced when deciding if something is, for instance, actually a procedure or an observation - or both - or is an observation or condition (or a diagnosis). Having these categories as resources, while not fool proof, does help to guide the initial choices.
A related example is deciding on the split between a medicated device and a medication, or a device. The workgroup doesn't attempt to define clinical opinion and recognises that different practice may occasionally lead to different implementations even with the same resources.
Terminology:
It is also acknowledged that, as with clinical data representation, there is overlap in what can be achieved with the resources and what can be modelled with rich terminology. Some of what can be represented by these resources can also be covered with structured code systems. The FHIR representation is intended to also cover transactional use (updates and submissions), rather than read-only, and recognises that implementers may prefer a consistent FHIR representation interface for both modes.
BR&R welcomes feedback with evidence to show if these design decisions have made a solution that works, and is implementable, for users across a range of domains.
FHIR ®© HL7.org 2011+. FHIR Release 4B (v4.3.0) hl7.fhir.r4b.core#4.3.0 generated on Sat, May 28, 2022 12:58+1000.
Links: Search |
Version History |
Table of Contents |
QA Page |
Compare to R4 |
|
Propose a change