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

Difference between revisions of "RegulatedAuthorization 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...")
 
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  
 
<div class="messagebox cleanup metadata">
 
<div class="messagebox cleanup metadata">
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
+
Corrent version: https://confluence.hl7.org/display/FHIR/RegulatedAuthorization+FHIR+Resource+Proposal<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="background:#F0F0F0">
 
<div style="background:#F0F0F0">
 
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
 
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
Line 13: Line 13:
  
  
=RegulatedMedicinalProduct=
+
=RegulatedAuthorization=
  
 
Draft resource in build:  
 
Draft resource in build:  
[[Image:RegulatedMedicialProduct_June2019.png|center||Relationship to other resources]]
+
[[Image:RegulatedauthorizationNew.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.
+
Regulated items - those subject to local, regional or international legislation for their use - are subject to authorization procedures and outcomes.
  
==RIM scope==
+
This may cover:
  
Similar in scope to the product parts of CPM. Entity: Material (EntityClass="MAT")
+
Overall marketing of medicinal products (possibly including biological - which would probably be medicinal products, but ''may'' be BiologicallyDerivedProducts), and devices (which could include software).
  
==Resource appropriateness==
+
Approval for the manufacturing of medicinal products
 +
 
 +
Authorisation to perform a certain procedure (such as the right to use sedation/anaesthesia or radiation therapy). This a general licence, not related to any particular instance or patient.
 +
 
 +
Clinical Trial authorizations
 +
 
 +
Recording whether a laboratory test is, for instance, FDA approved,
 +
 
 +
These authorizations, and the items they relate to, need to be tracked and made available.
 +
 
 +
Regulatory systems keep full details of authorizations, and these may be referenced by other users to check the legal and usage parameters of a medicinal product, or a device.
 +
 
 +
 
 +
In scope:
 +
 
 +
The item that is being authorized (e.g. reference to a product or device)
 +
 
 +
The holder (receiver) and the regulator (creator) of the authorization.
 +
 
 +
Type of authorisation - Marketing approval (or suspension), orphan drug approval, special uses for veterinary medication etc.
 +
 
 +
Status, e.g. pending, approved, withdrawn.
 +
 
 +
Location of applicability, local, regional, national etc.
 +
 
 +
Dates of application, granting, and associated dates such as special case initial periods, end dates, renewal dates etc.
 +
 
 +
The legal framework under which the authorisation was granted (e.g. EU CAP Centrally Authorised Product).
 +
 
 +
Out of scope:
 +
 
 +
Consent - this represents the choices and rights of an individual. Although there is a general legal right to give or withhold consent, consent is a record of a patients choice. This differs from the high level authorization of class of events or products to be used in general (within some legal framework). The concepts are very broadly similar in concept, they are very different use cases in software terms, with little likelihood of confusion or overlap of implementation and properties.
  
There is an outstanding requirement to support the standardised exchange of detailed "Product" data, for regulatory and other use cases.  
+
Contract - a contract is a legal agreement between two entities about a specific arrangement. It is optionally entered into by the parties, but then binding. This is different from a generalised legal framework (law) that exists (legislation about controlled drugs), but is then applied to a series of instances of, say, drugs and organizations. The contract is more similar to the legislation itself, rather than the applications of it (although the legal frameworks themselves are mostly static and are not generally represented in clinical systems)
  
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.  
+
Authorizations of drugs - although the word is the same, the common concept of a physician authorizing a patient to have a certain drug is very different from the legal authorization to, say, market that drug in a territory. The same word is used in both domains, but the context usually makes it very clear which is which. (RegulatedAuthorization vs MedicationRequest)
 +
<!--==RIM scope==
  
(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.)
+
Similar in scope to the product parts of CPM. Entity: Material (EntityClass="MAT")-->
  
This resource has been designed in close consultation with Pharmacy WG, and in conjunction with the MedicationKnowledge resource
+
==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),
 
FDA for Pharmaceutical Quality (HL7 PSS approved, based on this resource, June 2019),
Line 82: Line 113:
 
==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 134:
  
 
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 Organization, for the licence holder and the regulator that established the authorization/licence.
  
Most aspects of RegulatedMedicinalProduct are not present in Medication at all, and are not current candidates for inclusion in the prescribe/dispense/administer workflow.
+
To a MedicinalProductDefinition or PackagedProductDefinition (authorization can happen at different levels, per specific pack, or product wide), or a DeviceDefinition, as the subject, that is authorized.
  
===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 147:
 
==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==

Latest revision as of 21:31, 15 January 2020



RegulatedAuthorization

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

Regulated items - those subject to local, regional or international legislation for their use - are subject to authorization procedures and outcomes.

This may cover:

Overall marketing of medicinal products (possibly including biological - which would probably be medicinal products, but may be BiologicallyDerivedProducts), and devices (which could include software).

Approval for the manufacturing of medicinal products

Authorisation to perform a certain procedure (such as the right to use sedation/anaesthesia or radiation therapy). This a general licence, not related to any particular instance or patient.

Clinical Trial authorizations

Recording whether a laboratory test is, for instance, FDA approved,

These authorizations, and the items they relate to, need to be tracked and made available.

Regulatory systems keep full details of authorizations, and these may be referenced by other users to check the legal and usage parameters of a medicinal product, or a device.


In scope:

The item that is being authorized (e.g. reference to a product or device)

The holder (receiver) and the regulator (creator) of the authorization.

Type of authorisation - Marketing approval (or suspension), orphan drug approval, special uses for veterinary medication etc.

Status, e.g. pending, approved, withdrawn.

Location of applicability, local, regional, national etc.

Dates of application, granting, and associated dates such as special case initial periods, end dates, renewal dates etc.

The legal framework under which the authorisation was granted (e.g. EU CAP Centrally Authorised Product).

Out of scope:

Consent - this represents the choices and rights of an individual. Although there is a general legal right to give or withhold consent, consent is a record of a patients choice. This differs from the high level authorization of class of events or products to be used in general (within some legal framework). The concepts are very broadly similar in concept, they are very different use cases in software terms, with little likelihood of confusion or overlap of implementation and properties.

Contract - a contract is a legal agreement between two entities about a specific arrangement. It is optionally entered into by the parties, but then binding. This is different from a generalised legal framework (law) that exists (legislation about controlled drugs), but is then applied to a series of instances of, say, drugs and organizations. The contract is more similar to the legislation itself, rather than the applications of it (although the legal frameworks themselves are mostly static and are not generally represented in clinical systems)

Authorizations of drugs - although the word is the same, the common concept of a physician authorizing a patient to have a certain drug is very different from the legal authorization to, say, market that drug in a territory. The same word is used in both domains, but the context usually makes it very clear which is which. (RegulatedAuthorization vs MedicationRequest)

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

FDA for Pharmaceutical Quality (HL7 PSS approved, based on this resource, June 2019),

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 Organization, for the licence holder and the regulator that established the authorization/licence.

To a MedicinalProductDefinition or PackagedProductDefinition (authorization can happen at different levels, per specific pack, or product wide), or a DeviceDefinition, as the subject, that is authorized.


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