SubstanceDefinition FHIR Resource Proposal

SubstanceDefinition

Draft resource in build :

(note that this was previously known as SubstanceSpecification, but the word "specification" has a different but related connotation in the regulatory world)

Owning work group name

BR&R

Committee Approval Date:

6th May 2019

Contributing or Reviewing Work Groups

• Pharmacy
• O&O

FHIR Resource Development Project Insight ID

1367, 1338

Scope of coverage

To support the detailed definition of substances, including to molecular level, manufacturing processes and ingredients.

Data items in scope:

Naming in different contexts and languages

Molecular weight and structure

Active parts of the molecule (moieties)

Defining properties

Details specific to polymers, nucleic acids etc.

Relationships to other substances (including how they are related, qualitatively and quantitatively)

Out of scope:

Basic "instance" use of a substance - for which the Substance resource is used. This is an "identified" substance - using little more than a code - behind which all the details live (and which could refer to a SubstanceDefinition).

Batch numbers, expiry dates - things specific to an instance/use of this substance, rather than to the substance itself.

For the overall differences between Substance resource and SubstanceDefinition, see below.

RIM scope

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

Resource appropriateness

There is a requirement to support the standardised exchange of detailed definitional Substance data

This resource does not intend to clash with the existing Substance FHIR resource, but complements with an extra level of detail. It is seen as a sibling rather than a parent or a superclass to be profiled.

It is intended to add an extra level of substance detail - beyond what is covered for day to day prescribing by the Substance resource - such as is typically used by regulators. This data is only indirectly used during normal medication related work flows (e.g. for occasional look-ups of unfamiliar substances).

Manufacturers of medicinal products submit this detailed substance data to regulators. When they seek authorization for a new product, they submit details of all the ingredient substances. They re-submit when substance parameters change (ingredient manufacturer change, manufacturing process etc).

This is implemented EU-wide with the current XEVMPD standard, and there is a wish to move to FHIR for the EMA "SPOR" system currently in development. The substance catalogue (pre-registration of substances to be later used as ingredients) is intended to be the first part to go live.

This resource can also be used when downloading substances information from repositories such as the FDA Ginas system (G-SRS). This system acts as a "wikipedia" for substances, with structured and very detailed information (currently using a proprietary JSON format). Regulators also exchange this information between each other, to synchronise substance catalogues.

Expected implementations

EMA - Implementation as part of the EU-wide SPOR system. The substance catalogue is the "S" of SPOR (Substances, Products, Organizations, Referentials).

FDA - Drug Manufacturing Quality information (aka PQ/CMC, Pharmaceutical Quality). Specific plans to use this resource for that project.

FDA - Ginas/G-SRS project (Global Ingredient Archival System). This has already implemented a proprietary message solution, with similar scope to what is planned for FHIR

Content sources

A large amount of data (and specification for it) exists in the FDA GSRS substance catalogue implementation.

EMA has also developed requirements in this space, which have influenced the current draft resource. They have a FHIR API ready to be implemented (Q3 2019) that uses this resource, to cover those requirements.

Example Scenarios

Substance definitions are registered to regulators, and then referenced as (components of) ingredients for medicinal products that are seeking approval (e.g. existing EMA XEVPRM system, and new implementation in EMA SMS system).

Drug quality systems track assays of drugs and their components, to ensure reliability of manufacture (e.g. FDA PQ/CMC)

Substance catalogues make substance information available to download, and synchronise with other registries (e.g. FDA G-SRS)

Resource Relationships

For the relationship to other resources, see the diagram below (and also this associated proposal: MedicinalProduct_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:

SubstanceDefinition will reference Organization, for the manufacturer.

SubstanceDefinition and Substance

This resource is not expected to replace the existing Substance resource - which is limited in scope to the small number of items needed to support direct clinical/medicinal use. (The Substance resource could be considered to be mainly a "Substance Use".)

SubstanceDefinition is a collection of definitional information that an instance of a Substance resource (e.g. in a Medication, within a MedicationDispense) can refer to.

It is not expected that a SubstanceDefinition would ever directly substitute for the use of Substance.

The difference between Substance resource and SubstanceDefinition is not (entirely) one of instance vs kind.

Substances, like Medications, cover both kinds and instances.

SubstanceDefinition is purely for "kind", but the main difference in scope and level of detail. There is a need for a large amount of information (use cases of FDA, EMA, above) but we don’t wish to fill the existing Substance resource with an overwhelming amount of detail, to be ignored in general use for day to day prescribing.

We do NOT anticipate Medication using SubstanceDefinition. However we do think that the Substance resource could benefit from having a "definitional" link to SubstanceDefinition. This keeps things clear. Medications use Substance, and not SubstanceDefinition. But if you want the extra detail you can link your Substance to an SubstanceDefinition. (Linked in that direction because you don’t want to update your definitions to add references to things that refer to them.)

In theory, all the SubstanceDefinition information could be contained in a hugely expanded Substance resource (and then the existing Substance scope could be profiled back out again). But this would create an unmanageably large Substance resource for the very common and narrow medical/clinical use cases.

There has been much discussion on this topic in workgroups (BR&R, Pharmacy, CDS) and with FMG representatives.

Since the key regulatory use of SubstanceDefinition is almost orthogonal to the clinical use cases, it seems appropriate to have the SubstanceDefinition resource available as a sibling to Substance, not a parent. The SubstanceDefinition resource would also be used on its own, unrelated to any Substance instance, in those regulatory and drug information use cases.

Overlap between SubstanceDefinition and Substance

In practical terms there very little overlap of attributes between SubstanceDefinition and Substance. The Substance resource has only a few fields that are definitional (which are the only ones that would overlap).

Identifier and status are specific to this substance instance.

Category is definitional, and so does overlap, but could also be a local classification.

Code is the link between the two, and description could be considered a very small (possibly local) summary of the whole SubstanceDefinition, and so be a useful overlap.

The Instance component is not definitional so does not clash.

The Ingredient component is primarily for cases when the main Substance is made up on-demand - mixed rather than manufactured - and so would not itself be covered by a global SubstanceDefinition (hence no overlap).

SubstanceDefinition and Medication

The Medication resource has a reference to Substance. That is not expected to change. As described, SubstanceDefinition is additional, definitional information about substances. It is not itself expected to be used as a substance instance - which is what Substance is for.

SubstanceDefinition and other (to be proposed) detailed substance resources

The details of some substances, such as polymers and nucleic acids, can get very detailed, and go beyond what is required for "normal" chemicals. It is anticipated that these might be covered by other linked resources, or probably datatypes e.g. "SubstancePolymer". These resources are not directly a part of this proposal.

SubstanceDefinition and Device

There is no direct relationship between SubstanceDefinition and Device anticipated.

In theory, since devices are made of substances, it would be possible, as with any physical object, to use a SubstanceDefinition to describe the details of materials that comprise it. However this is not a currently proposed use case and device material is not supported by the existing Device resource.

A DeviceSpecification resource could use SubstanceDefinition to define its materials.

Timelines

Draft content is modelled in the FHIR build (http://build.fhir.org/substancedefinition.html), with outline supporting documentation. Completion planned Q4 2019.

gForge Users

riksmithies (already has commit permission)

When Resource Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org