This page is part of the FHIR Specification (v4.6.0: R5 Draft Ballot - see ballot notes). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B

Work Group Biomedical Research and Regulation

Standards Status: Informative

15.0 Medication Definition Module

15.0.1 Introduction

This module is concerned with resources and functionality in areas such as:

• The regulation and manufacturing of drugs, medicinal products and other medically-related substances or co-packaged devices.
• Detailed description of these same items, typically for regulators but also for any context where this level of detail is necessary, such as pharmacopoeias, or prescribing support.
• Indications and contra-indications for medications.
• The details of the chemical substances that may be ingredients for medications.

These resources are not typically used in direct patient care or day-to-day prescribing functionality (for which see the Medications Module), 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.

15.0.2 Index

MedicinalProductDefinition Ingredient ClinicalUseIssue

PackagedProductDefinition AdministrableProductDefinition SubstanceDefinition

ManufacturedItemDefinition RegulatedAuthorization

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

15.0.2.1 Products and Packaging

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:

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:

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.

15.0.2.2 Ingredients and Substances

Medication Definition also has resources for the detailed chemical composition of medications:

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.

15.0.2.3 Authorizations and Usage/Warnings

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.
ClinicalUseIssue	ClinicalUseIssue 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.

15.0.3 Common Use Cases

• Submitting a drug to a regulator for approval
• Creating a national level drug catalogue, including with virtual and actual medicinal products and packs
• Capturing information about the manufacturing of a drug

15.0.4 Other resources

There are other resources that are of particular interest to the medication definition domain.

• Medication This is the resource to use for prescribing use cases, and anywhere that an actual medication instance is needed.
• Substance The substance resource has a limited subset of data, and is aimed at prescribing use cases. Unlike SubstanceDefinition, it can be an actual instance of a substance (e.g. an amount of an ingredient or raw material).
• DeviceDefinition A DeviceDefinition can be used to represent a device that is inside the package of a medicinal product, within the PackagedProductDefinition resource.
• Organization Many regulatory processes are centred around organizations (pharma companies, drug manufacturers, regulatory agencies). These are all represented by Organizations, and are referenced by many of the module's resources.

15.0.5 Definitions and Instances

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.

15.0.6 Security and Privacy

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.

15.0.7 Developmental Roadmap

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.