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

Difference between revisions of "Ingredient FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with " <div class="messagebox cleanup metadata"> <div style="float: left;">35px| </div> <div style="background:#F0F0F0"> This page documents a :category...")
 
Line 13: Line 13:
  
  
=RegulatedMedicinalProduct=
+
=Ingredient=
  
 
Draft resource in build:  
 
Draft resource in build:  
[[Image:RegulatedMedicialProduct_June2019.png|center||Relationship to other resources]]
+
[[Image:Ingredient.png|center||Relationship to other resources]]
 
<!-- Resource names should meet the following characteristics:
 
<!-- Resource names should meet the following characteristics:
 
* Lower camel case
 
* Lower camel case
Line 35: Line 35:
  
 
==Committee Approval Date:==
 
==Committee Approval Date:==
6th May 2019 (earlier approval as "MedicinalProduct" 13th September 2017)
+
6th May 2019 (earlier approval as "MedicinalProductAuthorization" 13th September 2017)
  
 
==Contributing or Reviewing Work Groups==
 
==Contributing or Reviewing Work Groups==
  
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the resource (optional) -->
 
<!-- Additional work groups that may have an interest in contributing to, or reviewing  the content of the resource (optional) -->
* Pharmacy
+
*Pharmacy
* Orders and Observations
 
* Clinical Decision Support
 
  
 
==FHIR Resource Development Project Insight ID==
 
==FHIR Resource Development Project Insight ID==
Line 52: Line 50:
 
==Scope of coverage==
 
==Scope of coverage==
  
To support the content of the ISO 11615 IDMP Medicinal Product standard and other domain areas with similar requirements. 11615 covers detailed definition of products, their submissions to regulators, authorization activities, ingredients, packaging, accompanying devices, clinical particulars etc. Not all of those are expected to be covered in this single resource.
+
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.
  
==RIM scope==
+
This is a different concept to the overall "product" (and to MedicinalProductDefinition specifically).
  
Similar in scope to the product parts of CPM. Entity: Material (EntityClass="MAT")
+
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.
  
==Resource appropriateness==
+
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: 
 +
[[Image:Core_product_classes.png|center||Relationship to other resources]]
 +
 
 +
In scope, Pharmaceutical aspects of the product:
  
There is an outstanding requirement to support the standardised exchange of detailed "Product" data, for regulatory and other use cases.  
+
*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).
 +
*<!--==RIM scope==
  
This resource does not intend to clash with the existing Medication resource, but complements it with an extra level of detail. It is seen as a sibling rather than a parent or a "superclass" to be profiled.
+
Similar in scope to the product parts of CPM. Entity: Material (EntityClass="MAT")-->
  
(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 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).  
  
This resource has been designed in close consultation with Pharmacy WG, and in conjunction with the MedicationKnowledge resource
+
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==
  
RegulatedMedicinalProduct 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).
+
There is an outstanding requirement to support the standardised exchange of detailed "Product" data, for regulatory and other use cases.  
  
Drug manufacturers currently submit this data electronically to regulators, when products are registered or altered, or marketing situations change.
+
Regulators (EMA, FDA, and national "Competent Authorities"), as well as more local organisations, hospital and payer networks etc, need to record the legal authorizations that apply to medicinal products.
 +
This is a key focus of what organizations such as FDA and EMA do - they regulate and authorize the ability to make drugs available.  
  
 
==Expected implementations==
 
==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.
+
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).
+
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),
 
  
 
==Content sources==
 
==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.
+
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 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.
+
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==
 
==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, 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.
+
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:
 
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.  
  
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.
+
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==
 
==Resource Relationships==
Line 105: Line 114:
  
 
Some notable resource references:
 
Some notable resource references:
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.
 
 
===RegulatedMedicinalProduct and Medication===
 
  
This resource is intended to complement the Medication resource, which is focused on what is commonly needed for medical/clinical use cases. RegulatedMedicinalProduct adds information needed for regulatory use cases, of which there is little overlap to day to day prescribing.
+
To a MedicinalProductDefinition that contains the components that this is derived from. (Incoming relationships) from the components themselves.
 
 
Most aspects of RegulatedMedicinalProduct are not present in Medication at all, and are not current candidates for inclusion in the prescribe/dispense/administer workflow.
 
 
 
===RegulatedMedicinalProduct 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 RegulatedMedicinalProduct 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.  
 
  
 
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]]
 
  
 
High level relationships of the main prescribing resources and the regulatory strata below:
 
High level relationships of the main prescribing resources and the regulatory strata below:
Line 130: Line 124:
 
==Timelines==
 
==Timelines==
  
Draft content is modelled in the FHIR build (http://build.fhir.org/regulatedmedicinalproduct.html), with outline supporting documentation. Completion planned Q4 2019.
+
Draft content is modelled in the FHIR build (http://build.fhir.org/regulatedauthorization.html), with outline supporting documentation. Completion planned Q4 2019.
  
 
==gForge Users==
 
==gForge Users==

Revision as of 19:11, 4 September 2019



Ingredient

Draft resource in build:

Relationship to other resources

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:

Relationship to other resources

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.

Regulators (EMA, FDA, and national "Competent Authorities"), as well as more local organisations, hospital and payer networks etc, need to record the legal authorizations that apply to medicinal products. This is a key focus of what organizations such as FDA and EMA do - they regulate and authorize the ability to make drugs available.

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 that 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:

Relationship to other resources

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

FMG Notes