Difference between revisions of "RegulatedAuthorization FHIR Resource Proposal"
(migrate to Confluence) |
Riksmithies (talk | contribs) |
||
(4 intermediate revisions by the same user not shown) | |||
Line 52: | Line 52: | ||
Regulated items - those subject to local, regional or international legislation for their use - are subject to authorization procedures and outcomes. | Regulated items - those subject to local, regional or international legislation for their use - are subject to authorization procedures and outcomes. | ||
− | These authorizations, and the items they relate to, need to be tracked and made available. | + | 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. | 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: | In scope: | ||
Line 70: | Line 83: | ||
Dates of application, granting, and associated dates such as special case initial periods, end dates, renewal dates 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). | + | 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) | ||
<!--==RIM scope== | <!--==RIM scope== | ||
Similar in scope to the product parts of CPM. Entity: Material (EntityClass="MAT")--> | Similar in scope to the product parts of CPM. Entity: Material (EntityClass="MAT")--> | ||
+ | |||
==Resource appropriateness== | ==Resource appropriateness== | ||
Latest revision as of 21:31, 15 January 2020
Contents
- 1 RegulatedAuthorization
- 1.1 Owning work group name
- 1.2 Committee Approval Date:
- 1.3 Contributing or Reviewing Work Groups
- 1.4 FHIR Resource Development Project Insight ID
- 1.5 Scope of coverage
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Example Scenarios
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
- 1.13 When Resource Proposal Is Complete
- 1.14 FMG Notes
RegulatedAuthorization
Draft resource in build:
Owning work group name
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:
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