PackagedProductDefinition FHIR Resource Proposal

RegulatedPackagedProduct

Draft resource in build:

Owning work group name

BR&R

Committee Approval Date:

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

Contributing or Reviewing Work Groups

• Pharmacy
• Orders and Observations

FHIR Resource Development Project Insight ID

1367

Scope of coverage

PackagedProductDefinition is to be used when describing the package structure and physical packaging of a medicinal product.

This includes all "layers" from outer box to the inner carton, blister pack or bottle etc - down to whatever it is that touches the actual medication inside. It also covers (by references to ManufacturedItemDefinition) the items present at all levels, such as a cardboard packet containing a cream in a tube (metal with a plastic top), plus another carton containing a plastic and foil blister pack with a tablet inside.

It provides the link between the Medicinal Product and the various packaging options that may exist. These can be licensed either at product level (one authorization for all packs) or at package level (different authorizations for different).

New packages types can be created and updated with different life cycles to the overarching products that they belong to, so this information is suited to be being a standalone resource, rather than an component of another.

This detail would very rarely, be needed when prescribing – for which the correct resource is Medication. If you need to know package details (size, shape, material etc.) this resource has that level of detail. It also allows tracking which tablets are available in which package variations.

In scope:

Packaging structure, for all levels (inner and outer packaging), and references to the items contained in each (tablets, bottles, devices etc), with quantities.

Legal status (e.g. over the counter, or prescription only) and the relevant regulated authorization

Manufacturer

Materials used, physical characteristics, e.g. size

Not in scope:

For day to day prescribing, the resource to use is Medication. This covers basic drug information – code, form, strength, batch number.

Closely related scope:

Some other closely related information is in scope of other proposed resources, but not in scope of this resource:

MedicinalProductDefinition - the overarching medicine that can come in different pack types, and is typically the entity that is legally authorised for sale.

ManufacturedItemDefinition - the actual physical item of medication, not including any packaging. This however not always the unit that is administered, for which see AdminstrableProductDefinition, since the manufactured item may need combining (dissolving etc) in another item.

Pharmaceutical aspects of the product (AdminstrableProductDefinition) - can be created from one or more ManufacturedItemDefinitions (possibly mixed together)

Regulatory authorizations (RegulatedAuthorization) - legal aspects of the product as a whole (of which the manufactured item is a key component).

Details of ingredients (Ingredient) and their substances (SubstanceDefinition).

RIM scope

Similar in scope to the product parts of CPM. Entity: Material (EntityClass="MAT")

Resource appropriateness

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

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

RegulatedPackagedProduct 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). They are required to move to IDMP, and this is a good opportunity to use a standards-based FHIR solution.

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

Norwegian SAFEST project implementation https://github.com/HL7Norway/SAFEST (TODO more information)

Content sources

The core basis for the resource is the information in ISO 11615 Medicinal Products standard, which is in turn partly based on the existing implementations in the EU and US. A large amount of actual data exists in the EMA EU XEVMPD data base (and XEVPRM XML messages). Example FHIR data for several full product data sheets exists based on draft resources.

Also, information gained from early stage implementation of these 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).

Also from FDA requirements (for PQ/CMC) and other workgroup review (BR&R, Pharmacy) and their comments.

Example Scenarios

Pharma companies submit details of new products to regulators, including the different packages that exist. The same "product" (drug, etc.) can be packaged in different way (20 tablet pack, 50 tablet pack etc), and may have different physical details and be licensed differently. Hence these are "addressable" entities, requiring a stand-alone resource.

Pharmacies and prescribers can view and download this information for reference and integration with their systems.

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.

The Norwegian national project SAFEST, has this scenario:

The SAFEST project aims to deliver detailed packaging information in order to lay the groundwork for a “closed loop medication management”. A closed loop medication management requires bar codes on both the single dose administered by the patient and the outer packaging, in order to track the medicine from ordering, verifying, preparing to administering the medication.

The concept Packaged Medicinal Product holds information about each level of the package, including the place for the data carrier identifier for each level, and thus supports a closed loop medication management.

The concept Manufactured Item represent the medicinal product contained in the inner packaging, e.g «0,5 ml» in an ampoule with solution for injection.

Resource Relationships

For the relationship to other resources, see the diagram below.

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

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

The PackagedProductDefinition references the manufactured items within it (ManufacturedItemDefinition) as well as any devices (DeviceDefinition).

The packaging is part of the range of packages that form the overall medicinal product, so MedicinalProductDefinition is referenced as a subject.

Some notable resource references:

Reference to Organization, for the manufacturer.

Reference to RegulatedAuthorization, for a possible legal authorization at package level.

So:

   MPD – as licenced 
     / \
   /    \____PPD1  or  PPD2 – as supplied
 /           /  \
APD   <--  MID1+MID2 (mixed)
 \
  as administered to the patient

MPD Medicinal Product (definition)

MID Manufactured Item (definition)

PPD Packaged Product (definition)

APD Administrable Product (definition)

Timelines

Draft content is modelled in the FHIR build PackagedProductDefinition, 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