This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "ManufacturedItemDefinition FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
 
(11 intermediate revisions by the same user not shown)
Line 15: Line 15:
 
=MedicinalProductDefinition=
 
=MedicinalProductDefinition=
  
Draft resource in build:  
+
Draft resource in build:
[[ManufacturedItemDefinition.png|center||ManufacturedItemDefinition.png]]
+
 
 +
[[Image:ManufacturedItemDefinition.png|||ManufacturedItemDefinition.png]]
 
<!-- Resource names should meet the following characteristics:
 
<!-- Resource names should meet the following characteristics:
 
* Lower camel case
 
* Lower camel case
Line 51: Line 52:
 
==Scope of coverage==
 
==Scope of coverage==
  
ManufacturedItemDefinition is to be used when you need to describe an actual physical medication item such as a tablet or capsule. These are typically for regulatory or manufacturing use cases.   
+
ManufacturedItemDefinition is to be used when you need to describe an actual physical medication item such as a tablet or capsule. This is typically for regulatory or manufacturing use cases.   
  
TODO need to clarify dividing line between this resource, devices and packaging. e.g. items such as a dropper, scissors, a bottle. Are these manufactured items or devices or packaging.  
+
This is the only resource that treats the "tablet" (or whatever it may be) as a physical object. It is still definitional however - it describes all instances of this tablet.  
  
This detail would very rarely, be needed when prescribing – for which the correct resource is Medication. The manufactured item describes the physical characteristics of the item, as opposed to its pharmaceutical aspects (which may only apply after mixing with other items),or its packaging, or legal aspects (which apply only to the whole group of packing and manufactured items). The rationale for this being a standalone resource, rather than just characteristics of another resource is that the same item commonly occurs in different packaging.  
+
The resource aims to capture the definition of a single medication item type, such as a tablet of aspirin with a certain form, shape, manufacturer.  
  
TODO add references to gforge tracker items that as how to represent manufactured items.  
+
It is not intended to describe and be instantiated for each medication item, i.e., it’s not an actual real instance of a tablet, but rather represents e.g., all tablets of the same medication item type that are described by the ManufacturedItemDefinition.
  
===In scope:===
+
To define several package variations, e.g. pack of 10 tablets and of 50 tablets, you would need only one ManufacturedItemDefinition, referenced from both (and associated with a numeric quantity of 10 or 50 in the respective PackagedProductDefintions).
 +
 
 +
To prescribe or dispense 100 tablets, you would not generally need this resource at all, because usually the code of the medication as a whole is sufficient, plus a quantity, e.g. 100 of "ABC123" (=aspirin 75 mg).
 +
 
 +
The definition needs to be a resource, rather than just a shared concept such as a data type, because the same physical item can appear in many different package types (which may come along after the item has been defined). (Gforge tracker item [https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=23924&start=0 23924] specifically requests this use case:  "How to express multiple package configurations of the same manufactured item?") 
  
Drug form and unit of presentation (e.g. solid, tablet).
+
This resource excludes devices and other items found in medication packaging such as scissors, bottle stoppers, applicators and so on (which would use DeviceDefinition).
  
Manufacturer and ingredients.
+
This detail would very rarely be needed when prescribing – for which the correct resource is Medication. If you need to know what size, shape or colour the tablet is, or which packaging variations it can appear in, this resource has that level of detail. 
  
Physical characteristics, e.g. size, shape, color, image, imprints (logo)
+
The manufactured item describes the physical characteristics of the item, as opposed to its pharmaceutical aspects (which may only apply after mixing with other items - to become an AdministrableProductDefinition), or its packaging, or legal aspects (which apply only to the whole group of packing and manufactured items). This further differs from the administrable item in that the manufactured quantity may be different to the administered quantity, due to "overage" (manufacturing more in case some gets lost in the final preparation that the patient performs)
  
===Closely related scope:===
+
Note that there can be several types of manufactured item in one package (e.g. a combination pill product, or a cream and a tablet).
  
Some other closely related information is in scope of other proposed resources, but not in scope of this resource:
+
There are typically multiple instances of the item in the packaging and this is indicated by the quantity within the package (e.g. a package of 12 tablets), referencing a single copy of the manufactured item.
  
Detailed packaging information (PackagedProductDefinton),
+
===In scope:===
  
Pharmaceutical aspects of the product (AdminstrableProductDefinition)  
+
Drug form and unit of presentation (e.g. solid, tablet, film-coated tablet).
  
Regulatory authorizations (RegulatedAuthorization)
+
Manufacturer and ingredients.
  
Details of ingredients (Ingredient) and their substances (SubstanceDefinition).
+
Physical characteristics, e.g. size, shape, color, image, imprints (logo/text)
  
 
===Not in scope:===
 
===Not in scope:===
For day to day prescribing, the resource to use is Medication.  
+
For day to day prescribing, the resource to use is Medication. This covers basic drug information – code, form, strength, batch number.  
This covers basic drug information – code, form, strength, batch number, simple ingredients.  
 
  
Devices. This does not cover non-medication devices. See discussion below.
+
Devices - this does not cover devices, unless they have a pharmaceutical aspect, such as an impregnated bandage.
  
Pricing and contextual or local formulary information. For that see MedicationKnowledge.
+
(Note that the lines between devices, biologicals and medicinal products are unclear in the real world, and this resource does not attempt to solve that issue by being prescriptive.)
  
===Scope discussion:===
+
Pricing and contextual or local formulary information - for that see MedicationKnowledge.
“Devices” are not typically covered by this resource (except the small items that commonly come packaged with a drug, e.g. a bottle stopper), unless they have a pharmaceutical aspect.  
 
  
Note that the lines between devices, biologicals and medicinal products are unclear in the real world, and this resource does not attempt to solve that issue by being prescriptive.
+
===Closely related scope:===
 +
Some other closely related information is in scope of other proposed resources, but not in scope of this resource:
 +
 
 +
Detailed packaging information (PackagedProductDefinition) - this resource "contains" ManufacturedItemDefinitions
 +
 
 +
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 of the manufactured item (Ingredient) and their substances (SubstanceDefinition).  
  
 
==RIM scope==
 
==RIM scope==
Line 100: Line 112:
 
There is an outstanding requirement to support the standardised exchange of detailed "Product" data, for regulatory and other use cases.  
 
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.)  
+
This resource does not intend to clash with the existing Medication resource, but complements it with an extra level of detail. It is definitional 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  
 
 
(The superclass option has widely discussed and rejected, since this would mean the Medication resource - much more commonly used - would become more complicated, being a very small profile of a very large model. We don't want to introduce such confusing complexity in that space - which is largely separate.)
 
 
 
This resource has been designed in close consultation with Pharmacy WG, and in conjunction with the MedicationKnowledge resource
 
 
 
MedicinalProductDefinition 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.
 
Drug manufacturers currently submit this data electronically to regulators, when products are registered or altered, or marketing situations change.
Line 118: Line 124:
 
FDA for drug submission (currently using SPL, which is not likely to change in the near term, but have expressed an interest in FHIR).
 
FDA for drug submission (currently using SPL, which is not likely to change in the near term, but have expressed an interest in FHIR).
  
FDA for Pharmaceutical Quality (HL7 PSS approved, based on this resource, June 2019),
+
Norwegian SAFEST project implementation https://github.com/HL7Norway/SAFEST
 
 
Norwegian company that is implementing TODO
 
  
 
==Content sources==
 
==Content sources==
Line 129: Line 133:
  
 
Also from FDA requirements (for PQ/CMC) and other workgroup review (BR&R, Pharmacy) and their comments. Current active work on this project, with this resource.
 
Also from FDA requirements (for PQ/CMC) and other workgroup review (BR&R, Pharmacy) and their comments. Current active work on this project, with this resource.
 +
 +
This content is supported by the HL7 V3 SPL (Structured Product Labeling) standard.
  
 
==Example Scenarios==
 
==Example Scenarios==
  
Pharma companies submit details of new products to regulators. Updates are made when necessary e.g. clinical particulars change (a new contra-indication), a new marketing authorization exists etc.
+
Pharma companies submit details of new products to regulators. These include full product details down to the actual tablet level (also with packaging and other physical aspects).
  
Pharmacies and prescribers can view and download this information for reference and integration with their systems.
+
Tablets or other physical representations can be stored and linked to multiple package variations, that may be created at later times.
  
 
Specific use cases include:
 
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 scenarion is currently being re-implemented, using this resource, as part of the EU wide SPOR project.
+
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.
  
Drug Manufacturing Quality information (aka PQ/CMC, Pharmaceutical Quality), as used by the FDA in the US. Specific plans to use this resource for that 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. This information is also needed in the above mentioned closed loop and calculations needed for dosing of the medication. The amount of medicinal product, together with the strength gives how much of the active substance is given to the patient. When registered i electronic patient journal, the system can calculate based on this data. When the nurse is going to prepare an injection of 0,5 ml of a particular medicinal product, the system may show that an ampule from both the package with 3 ampoules of 0,5 ml and the package with 10 ampoules of 0,5 ml can be used.''
  
 
==Resource Relationships==
 
==Resource Relationships==
Line 151: Line 163:
 
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]]
 
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]]
  
Some notable resource references:
+
The manufactured item is always physically within some packaging, so the PackagedProductDefinition resource has a reference to this item.  
Reference to Organization, for the manufacturer, regulator and other establishments.
 
Reference to DocumentReference, for the regulatory submission documentation.
 
Reference to directly supporting resources such as RegulatedPackagedProduct.
 
Incoming reference from resource RegulatedAuthorization.
 
Indirect reference to DeviceDefinition, via the other proposed resources (DeviceDefinition was created with O&O with input from this IDMP project and includes our all of our device requirements).
 
Indirect reference to proposed SubstanceSpecification resource to describe ingredients in detail.
 
  
===MedicinalProductDefinition and Medication===
+
One or more manufactured items eventually forms the product that is directly administered to the patient, so the AdministrableProductDefinition also has a reference to this resource.
  
This resource is intended to complement the Medication resource, which is focused on what is commonly needed for medical/clinical use cases. MedicinalProductDefinition adds information needed for regulatory use cases, of which there is little overlap to day to day prescribing.
+
Some notable resource references:
 
 
Most aspects of MedicinalProductDefinition are not present in Medication at all, and are not current candidates for inclusion in the prescribe/dispense/administer workflow.
 
 
 
===MedicinalProductDefinition and MedicationKnowledge===
 
 
 
MedicationKnowledge resource is aimed at drug knowledge bases. There is partial overlap in scope between that resource and some aspects of regulatory use cases. To fulfil that, the common associated resources of MedicinalProductDefinition will be used (e.g. Ingredient, ClinicalUseIssue). MedicationKnowledge includes some local specifics such as pricing. The boundaries between all these resource have been carefully thought out and have had much discussion in workgroups (BR&R, Pharmacy, CDS) and with FMG representatives.
 
 
 
===MedicationKnowledge===
 
This resource differs from MedicationKnowledge in that MedicinalProductDefinition is a context-less, complete definition of the drug (typically as defined by the manufacturer and validated by a regulatory body), including all the intrinsic properties.
 
  
MedicationKnowledge is a description of the product in a context, such as a local formulary, and can include costing and local usage information.  
+
Reference to Organization, for the manufacturer.
  
There is some overlap in scope between MedicationKnowledge and the entirety of definitional information about the “Product” (which is more than is covered in MedicinalProductDefinition itself). Where the same data element exists in both contexts this is factored into a shared resource (e.g. ClinicalUseIssue, Ingredient, which are referenced from both).
+
Reference to Ingredient for the ingredients of this manufactured item.
 
 
The MedicinalProductDefinition resource differs from other proposed resources:
 
 
 
===AdministrableProductDefinition===
 
this covers the pharmaceutical as it is mixed, from the “manufactured” components in the pack, and as ready administered to the patient. This is a different concept to the overall product and to MedicinalProductDefinition specifically (though the “product” does incorporate both aspects, and this is managed by the APD being referenced from the MedicinalProductDefinition. 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.
 
 
 
===PackagedProductDefinition===
 
this covers one of the possible packaging versions of the product. There can be different packages (e.g. 10 tabs, 20 tabs) in the same “product”, but still treated as one product for licensing etc. This is managed by the multiple PPDs being referenced from the overarching MedicinalProductDefinition. The package can contain multiple Manufactured Items (ManufacturedItemDefinition) (the physical drug and solvents etc) which are then mixed to make the APD.
 
  
 
So:
 
So:
Line 194: Line 183:
 
   as administered to the patient
 
   as administered to the patient
  
 +
MPD Medicinal Product (definition)
  
 +
MID Manufactured Item (definition)
  
MPD Medicinal Product (definition)
 
MID Manufactured Item (definition)
 
 
PPD PackagedProduct (definition)
 
PPD PackagedProduct (definition)
 +
 
APD Administrable Product (definition)
 
APD Administrable Product (definition)
  
 
==Timelines==
 
==Timelines==
  
Draft content is modelled in the FHIR build (http://build.fhir.org/MedicinalProductDefinition.html), with outline supporting documentation. Completion planned Q4 2019.
+
Draft content is modelled in the FHIR build [http://build.fhir.org/manufactureditemdefinition.html ManufacturedItemDefinition], with outline supporting documentation. Completion planned Q4 2019.
  
 
==gForge Users==
 
==gForge Users==

Latest revision as of 19:28, 31 October 2019



MedicinalProductDefinition

Draft resource in build:

ManufacturedItemDefinition.png

Owning work group name

BR&R

Committee Approval Date:

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

Contributing or Reviewing Work Groups

  • Pharmacy
  • Orders and Observations

FHIR Resource Development Project Insight ID

1367


Scope of coverage

ManufacturedItemDefinition is to be used when you need to describe an actual physical medication item such as a tablet or capsule. This is typically for regulatory or manufacturing use cases.

This is the only resource that treats the "tablet" (or whatever it may be) as a physical object. It is still definitional however - it describes all instances of this tablet.

The resource aims to capture the definition of a single medication item type, such as a tablet of aspirin with a certain form, shape, manufacturer.

It is not intended to describe and be instantiated for each medication item, i.e., it’s not an actual real instance of a tablet, but rather represents e.g., all tablets of the same medication item type that are described by the ManufacturedItemDefinition.

To define several package variations, e.g. pack of 10 tablets and of 50 tablets, you would need only one ManufacturedItemDefinition, referenced from both (and associated with a numeric quantity of 10 or 50 in the respective PackagedProductDefintions).

To prescribe or dispense 100 tablets, you would not generally need this resource at all, because usually the code of the medication as a whole is sufficient, plus a quantity, e.g. 100 of "ABC123" (=aspirin 75 mg).

The definition needs to be a resource, rather than just a shared concept such as a data type, because the same physical item can appear in many different package types (which may come along after the item has been defined). (Gforge tracker item 23924 specifically requests this use case: "How to express multiple package configurations of the same manufactured item?")

This resource excludes devices and other items found in medication packaging such as scissors, bottle stoppers, applicators and so on (which would use DeviceDefinition).

This detail would very rarely be needed when prescribing – for which the correct resource is Medication. If you need to know what size, shape or colour the tablet is, or which packaging variations it can appear in, this resource has that level of detail.

The manufactured item describes the physical characteristics of the item, as opposed to its pharmaceutical aspects (which may only apply after mixing with other items - to become an AdministrableProductDefinition), or its packaging, or legal aspects (which apply only to the whole group of packing and manufactured items). This further differs from the administrable item in that the manufactured quantity may be different to the administered quantity, due to "overage" (manufacturing more in case some gets lost in the final preparation that the patient performs).

Note that there can be several types of manufactured item in one package (e.g. a combination pill product, or a cream and a tablet).

There are typically multiple instances of the item in the packaging and this is indicated by the quantity within the package (e.g. a package of 12 tablets), referencing a single copy of the manufactured item.

In scope:

Drug form and unit of presentation (e.g. solid, tablet, film-coated tablet).

Manufacturer and ingredients.

Physical characteristics, e.g. size, shape, color, image, imprints (logo/text)

Not in scope:

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

Devices - this does not cover devices, unless they have a pharmaceutical aspect, such as an impregnated bandage.

(Note that the lines between devices, biologicals and medicinal products are unclear in the real world, and this resource does not attempt to solve that issue by being prescriptive.)

Pricing and contextual or local formulary information - for that see MedicationKnowledge.

Closely related scope:

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

Detailed packaging information (PackagedProductDefinition) - this resource "contains" ManufacturedItemDefinitions

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 of the manufactured item (Ingredient) and their substances (SubstanceDefinition).

RIM scope

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

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 definitional 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.)

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

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

Content sources

A large amount of actual data of this kind 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. Current active work on this project, with this resource.

This content is supported by the HL7 V3 SPL (Structured Product Labeling) standard.

Example Scenarios

Pharma companies submit details of new products to regulators. These include full product details down to the actual tablet level (also with packaging and other physical aspects).

Tablets or other physical representations can be stored and linked to multiple package variations, that may be created at later times.

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. This information is also needed in the above mentioned closed loop and calculations needed for dosing of the medication. The amount of medicinal product, together with the strength gives how much of the active substance is given to the patient. When registered i electronic patient journal, the system can calculate based on this data. When the nurse is going to prepare an injection of 0,5 ml of a particular medicinal product, the system may show that an ampule from both the package with 3 ampoules of 0,5 ml and the package with 10 ampoules of 0,5 ml can be used.

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:

Relationship to other resources

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 manufactured item is always physically within some packaging, so the PackagedProductDefinition resource has a reference to this item.

One or more manufactured items eventually forms the product that is directly administered to the patient, so the AdministrableProductDefinition also has a reference to this resource.

Some notable resource references:

Reference to Organization, for the manufacturer.

Reference to Ingredient for the ingredients of this manufactured item.

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 PackagedProduct (definition)

APD Administrable Product (definition)

Timelines

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

FMG Notes