Data Element
Submitted By: Scott Gordon / Food and Drug Administration
Data Element Information
Use Case Description(s)
Use Case Description Healthcare usecase: The assurance of the accuracy and details of a recorded drug will differ depending on it being officially recorded in the healthcare system versus conversationally reported information. This does not inherently place more or less intrinsic value between primary source-of-truth records versus reported records.But it does supply critical differential information with which a physician can make a more informed judgement regarding treatment options, potential drug-drug interactions, etc.

An FDA/cliinical research context: Retrospective analyses of healthcare data are becoming a more common tool in clinical research for saftey or efficacy for new indications of existing medications. In such analyses there may be one or more “exposure” drugs (ie, the drug of interest) and one or many “concomitant” medications. Researchers and regualtory reviewers will need to know whether or not a listed medication was reported versus captured in a source-of-truth system as a prescription. This does not inherently place more or less intrinsic value between primary source-of-truth records versus reported records.But it does supply critical differential information with which a researcher or regulatory reviewer can assess the relative value of the listed drug in the context of the specific research and evidence generation needs of any given clinical study
Estimate the breadth of applicability of the use case(s) for this data element All Electronic Healthcare Record systems, healthcare systems, clinical research users of healthcare data, regulatory reviewers of healthcare data
Link to use case project page https://confluence.hl7.org/display/FHIR/2021-09+Vulcan+-+Real+World+Data+%28RWD%29+Submission+to+FDA
Healthcare Aims
  • Improving patient experience of care (quality and/or satisfaction)
  • Improving the health of populations
  • Reducing the cost of care
  • Improving provider experience of care
Maturity of Use and Technical Specifications for Data Element
Applicable Standard(s) In FHIR R4, MedicationRequest.reported[x] (https://www.hl7.org/fhir/medicationrequest-definitions.html#MedicationRequest.reported_x_) supplied either a boolean or Reference(Patient | Practitioner | PractitionerRole | RelatedPerson | Organization)
In FHIR R4 MedicationStatement - FHIR v4.0.1 (https://www.hl7.org/fhir/medicationstatement.html) which is still sometimes used to represent reported medications, a number of key terminologies are utilized
Additional Specifications Present in US Core Profiles
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html
The MedicationRequest resource can represent that information is from a secondary source using either a boolean flag or reference in MedicationRequest.reportedBoolean, or a reference using MedicationRequest.reportedReference to Practitioner or other resource.
Although both are marked as must support, the server system is not required to support both a boolean and a reference, but SHALL support at least one of these elements.
The client application SHALL support both elements.
Current Use This data element has been used at scale between multiple different production environments to support the majority of anticipated stakeholders
Supporting Artifacts HL7.FHIR.US.CORE\US Core MedicationRequest Profile - FHIR v4.0.1
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html
Specifications - Epic on FHIR
https://fhir.epic.com/Specifications?api=996
MedicationRequest | R4 API (cerner.com)
https://fhir.cerner.com/millennium/r4/clinical/medications/medication-request/
Extent of exchange 5 or more. This data element has been tested at scale between multiple different production environments to support the majority of anticipated stakeholders.
Supporting Artifacts HL7.FHIR.US.CORE\US Core MedicationRequest Profile - FHIR v4.0.1
https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-medicationrequest.html
Specifications - Epic on FHIR
https://fhir.epic.com/Specifications?api=996
MedicationRequest | R4 API (cerner.com)
https://fhir.cerner.com/millennium/r4/clinical/medications/medication-request/
Potential Challenges
Restrictions on Standardization (e.g. proprietary code) none
Restrictions on Use (e.g. licensing, user fees) Other than what is required for use of HL7 FHIR, none.
Privacy and Security Concerns none
Estimate of Overall Burden Some standards and system implementations provide more than one location for this type of information – and different options are used by different implementations resulting in highly non-standardized usage of this critical information. Proposal is that this information is captured ONLY in one way, universally across systems. Transitioning legacy data and/or business practices from current state to desired future stat may be challenging.
ONC Evaluation Details
Each submitted Data Element has been evaluated based on the following criteria. The overall Level classification is a composite of the maturity based on these individual criteria. This information can be used to identify areas that require additional work to raise the overall classification level and consideration for inclusion in future versions of USCDI
Criterion #1
Maturity - Current Standards		 Level 2 - Data element is represented by a terminology standard or SDO-balloted technical specification or implementation guide.
Criterion #2
Maturity - Current Use 		Level 2 - Data element is captured, stored, or accessed in multiple production EHRs or other HIT modules from more than one developer.
Criterion #3
Maturity - Current Exchange		 Level 1 - Data element is electronically exchanged between two production EHRs or other HIT modules using available interoperability standards.
Criterion #4
Use Case(s) - Breadth of Applicability		 Level 0 - Use cases apply to a limited number of care settings or specialties, or data element represents a specialization of other, more general data elements.
Evaluation Comment This data element represents a specialized use or subset of the data element Medications in the Medications data class in USCDI v4.

Comment

Submitted by gsgordon on

The lack of consistency in…

  • The lack of consistency in how an "asserted" or "reported" medication is only growing.  MedicationStatement (and MedicationUsage in FHIR R5) is often used as a destination for this, meanwhile US Core puts asserted medication records as a qualifier in MedicationRequest, while Europe (via the International Patient Summary FHIR IG) seems to be also pushing MedicationStatement.
  • To be clear - my point is not what the correct place is to put reported medications.  My point is there needs to be ONE agreed-upon way to represent a Reported/Asserted medication and everyone use it.  Without that the concept of reported medications in EHRs remains a bit of a zoo a variations with no hope for interoperability

 

Log in or register to post comments