AdministrableProductDefinition FHIR Resource Proposal

AdministrableProductDefinition

Draft resource in build:

Owning work group name

BR&R

Committee Approval Date:

6th May 2019 (earlier approval as "MedicinalProductAuthorization" 13th September 2017)

Contributing or Reviewing Work Groups

• Pharmacy

FHIR Resource Development Project Insight ID

1367

Scope of coverage

This resource covers the pharmaceutical as it is mixed, from the “manufactured” components in the pack, and as ready to be administered to the patient.

This is a different concept to the overall "product" (and to MedicinalProductDefinition specifically).

In effect this is a new substance, that doesn’t exist in the product otherwise. In some cases e.g. a tablet, the administrable form is the same as the manufactured form, but in the general case (e.g. a powder plus a solution for dissolving it) that is not true.

An Administrable Product is a product that is ready to be taken by a patient. It may be created "on the fly" from several items of medication - not as ingredients, but as components that are combined for use.

This "product-mixed-for-use" is a very different thing to the components, or to package of all the components, or to the regulated/approved entity that it is marketed as.

The Administrable item covers the drug as it is actually used. Only at this stage does it become a "pharmaceutical", and consequently it is only here that properties such Dose Form and Route Of Administration exist.

The relationship is this:

In scope, Pharmaceutical aspects of the product:

• Dose Form - as mixed, or "reconstituted"
• Route of Administration - of the combined product (Note that the overall product will also usually have a concatenated form "powder and solvent for injection")
• Standard dosing information
• Other coded pharmaceutical characteristics (e.g. rates of absorption etc).

This is a definitional resource, representing a medication that may be taken. As with other medication definition resources It overlaps somewhat with the Medication resource, which is used in day to day prescribing (and itself has a part definition-part instance role).

But AdministrableProductDefinition provides an extra level of detail. The AdministrableProductDefinition would not be prescribed directly, but a code used in a Medication may be a link to the identifier of an Administrable Product. It would be more likely in a MedicationAdministation, rather than a MedicationDispense. (Prescribing codes exist at different levels however - sometimes active substances, sometimes products, occasionally actual pharmaceuticals, sometimes specific packs).

Resource appropriateness

There is an outstanding requirement to support the standardised exchange of detailed "Product" data, for regulatory and other use cases.

This resource does not intend to clash with the existing Medication resource, but complements it with an extra level of detail. It is defnitional rather than about an instance of a medication (also note however that when prescribing there is a duality of instance vs definition even in the Medication resource.)

It is seen as a sibling resource, in a definitional strata, rather than a parent or a "superclass" to be profiled.

This resource has been designed in close consultation with Pharmacy WG, and in conjunction with the MedicationKnowledge resource

AdministrableProductDefinition is intended to add an extra level of product specification detail, such as is typically used by regulators, and only indirectly used during normal medication related work flows (e.g. for look-ups of unfamiliar products).

Drug manufacturers currently submit this data electronically to regulators, when products are registered or altered, or marketing situations change.

Expected implementations

EMA and European drug manufacturers, who have a requirement to submit to EMA (and already do so in a proprietary format). The EU wide system is currently being redeveloped to use FHIR, and this data is directly in scope.

FDA for Drug Submission (currently using SPL, which is not likely to change in the near term, but have expressed an interest in FHIR).

Content sources

The core basis for the resource is information currently used by FDA (as SPL) and the EMA EU XEVMPD data base (and XEVPRM XML messages).

Also, information gained from early stage implementation of this resources at EMA (2018, 2019), and from many many received to EMA about the draft API specification from the European medicines regulatory network (https://www.ema.europa.eu/en/about-us/how-we-work/european-medicines-regulatory-network).

Example Scenarios

Pharma companies submit details of new products to regulators, and include authorization details, which in turn may be updated by the regulators.

Pharmacies and prescribers can view and download this information for reference and integration with their systems. They may be able to see why a product was withdrawn for instance.

Specific use cases include:

Submission of products from drug companies and NCAs (National Competent Authorities - the national regulators) to regional regulators.

This is already implemented in Europe (by EMA and EU-wide stakeholders) with an earlier non-HL7 format (XEVPRM/XEVMPD). That scenario is currently being re-implemented, using this resource, as part of the EU wide SPOR project.

Resource Relationships

See diagram below.

Some notable resource references:

To a MedicinalProductDefinition, which contains the components that this is derived from. (Incoming relationships) from the components themselves.

Also refer to the logical model which was used to clarify the resource relationships, at the request of FMG, in the preparation of this proposal (linked to the approved MedicationKnowledge proposal page): MedicationKnowledge_FHIR_Resource_Proposal

High level relationships of the main prescribing resources and the regulatory strata below:

Timelines

Draft content is modelled in the FHIR build (http://build.fhir.org/regulatedauthorization.html), with outline supporting documentation. Completion planned Q4 2019.

gForge Users

riksmithies

When Resource Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org