Short Description

The purpose of this track is to develop methods to use the HL7 FHIR standard to retrieve relevant data from Real World Data sources – specifically for this track, Electronic Health Record (EHR) systems - and ultimately transform that data into a format suitable for submission to pharmaceutical regulatory agencies.  The destination format for this track is the SDTM (Study Data Tabulation Model) standard, created by the Clinical Data Interchange Standards Consortium (CDISC) standards development organization, which optimized for clinical research and regulatory uses and is the data standard used for regulatory submissions of study data to the US Food and Drug Administration.

Long Description

Background and Scope

Real World Data can be considered data created in the “real world” of everyday experience, such as a routine patient visit to a healthcare provider, as opposed to data created under clearly defined protocols typical of controlled clinical trials.  The primary purpose for such data, collected for a purpose other than use in a clinical trial, is in support of clinical care of patients and knowledge for their healthcare providers.  However, large amounts of such information could potentially be used for the secondary purpose of supporting clinical research to analyze the data and generate supporting evidence for, as an example, a new indicated use for an already approved pharmaceutical drug or safety-related analyses. 

Many sources of RWD exist, but for the current phase of work, the scope of the track is firmly limited to the use of Electronic Health Record (EHR) systems as sources of RWD.  Additionally, broad use case is currently limited to the use of EHRs for retrospective analysis of data (to generate evidence for new indications, comparisons, and/or safely) and preparation of such data for submission to governmental regulatory bodies covering pharmaceutical approvals such as the United States Food and Drug Administration (FDA).  The use of EHRs as a mode of direct data collections for traditional prospective clinical trials (sometimes called “electronic source data” or “eSource” activities) is not currently in scope.  However, we consider it highly likely that types of solutions developed for eSource and for RWD will have significant overlap.

The challenge faced by the track is: How, with the aide of HL7 FHIR, can we most efficiently and comprehensively migrate data and bridge the many syntactic and semantic gaps from the healthcare data sphere to the research and regulatory sphere? 

Previous Work

January 2022 starts the second year of this connectathon track.  In the first year of this work, to better understand the end-to-end challenges faced when moving information from a healthcare setting to a research and regulatory setting, we focused on the specific data domain of concomitant medications (other medications taken by people at the same time as a medication of interest).  Specifically, we focused on what it takes to find, retrieve, and transform, relevant medication information for patients from an EHR data source to an acceptable SDTM format while not losing critical supplemental information in the process.

Using available test data set of fictional patients, we initially retrieved medications information from the following resources: MedicationStatment;  MedicationRequest.  Subsequently, we expanded to allow retrieval from additional resources, MedicationDispense and MedicationAdministration, since we found that different EHRs implement and use the suite of these 4 FHIR resources (referred to as Medication[x]) in highly variable ways.  We explored the challenges of differing levels of “certainty” in EHRs regarding the actual ingestion of a drug,  how best to package results of data queries in FHIR for transport and transformation, and the use of SDTM SUPPxx supplemental domains to represent additional supplemental when such information semantically different from that typically stored in the core domains of SDTM.

Finally we identified key attributes of the Medication[x] Resources that we felt to be critical for implementation in EHRs if such data is to support clinical research and submissions.  Some of these findings resulted in new proposal submissions to the US Core Data for Interoperability (USCDI) requirements created by the US Office of the National Coordinator for Health IT (ONC).  Specific attributes such as Status and Patient for MedicationRequest and MedicationAdministration are now in queue for potential inclusion in USCDI version 3.


Date SubmittedData ClassData ElementStatusClassification LevelLINK

09/30/2021

Medications

Medication Prescription Patient

Published

Level 2

Link

09/30/2021

Medications

Medication Administration Patient

Published

Level 1

Link

09/30/2021

Medications

Medication Administration Status

Published

Level 2

Link

09/30/2021

Medications

Medication Prescription Status

Published

Level 2

Link

09/30/2021

Medications

Medication Prescription Do-Not-Perform

Published

Level 2

Link

09/30/2021

Medications

Reported Medication (unique)

Published

Level 2

Link


Plan for January 2022 Connectathon Track

In the new year, we aim to move beyond the focus on a single data domain and, instead, take a practical and realistic, query-based approach.  Specifically, we intend to begin with a data query that can ask a (very small) question, based on some existing study or protocol, which calls on very specific information from a range of different data domains.  This will allow us to increase out breadth of understanding of the challenges and solution.   Another Vulcan track, Schedule of Activities, is working with a public domain study protocol H2Q-MC ZZT(c),  https://wiki.ihe.net/images/4/47/Lzzt_protocol_redacted.pdf, which will serve as the protocol and will also create a cross-cutting synergy between the two tracks.  Additionally we will be exploring revising the technical approach by working with a software developer who has worked on this set of issues (see his background and coding approach here: https://sourceforge.net/projects/fhirloinc2sdtm/ ).

Type

Test the design of a Resource/set of Resources

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

Vulcan Accelerator

Track Lead(s)

Scott Gordon, Lauren McCabe

Track Lead Email(s)

Gideon.Gordon@fda.hhs.govLauren.McCabe@pfizer.com

Related Tracks

FHIR Version

FHIR R4 is current primary focus, also US Core.  However, since many other implementations exist, we are not limiting this exclusively.  Further, as R5 moves forward in balloting, we will keep an eye on relevant changes.

Specification(s) this track uses

Artifacts of focus

Expanding to multiple resources.  Medication[x]; Probably Observations, Patient, etc.

Expected participants

Vulcan members, Regulators, EHR Vendors, EDC Vendors, Academic Medical Centers, Pharma Companies.  Additionally:

  • People who have FHIR data (FHIR servers, files, reference EHRs) that they would like to test against the xml4pharma implementation (see Useful Artifacts section below) being used for this track. This can be used both the check the ability of this implementation to pull desired information from a given data set and also exercise the mappings of the recently published CDISC-FHIR mappings.
  • People wanting to test their own implementations against our FHIR sample data set.  This data set is currently very small and custom created (and also synthetic), yet optimized for maximal usage from a clinical research perspective.  In other words, this FHIR sample patient set (which will be present on a FHIR server or as a file-based option) does not represent typical EHRs of today - with widely variable implementation and population of FHIR resources - but, instead, a deliberate and consistent use of canonical FHIR R4 resources which we hope to exercise and revise to demonstrate a preferred FHIR profiles approach that will best support the needs of clinical research and ultimate use in a pharmaceutical regulatory submission.  


Zulip stream

#Vulcan/RWD

Track Details


Kick-off Call

Artifacts from Previous Tracks

Draft of decision algorithms based of Medication[x] Status field

med-status.xlsx


Draft identifying all elements of all Medication[x] resources which we recommend be implemented and utilized consistently (where relevant) in all EHRs in order to make concomitant medication determination more reliable.  (There are absolutely strong pure healthcare justifications as well for these elements being present).

MedicationX Resources and ConMed.docx


Useful artifacts for January 2022 Track

SDTM Data Set in CSV format:

LZZT output in CSV format.zip

SPECIAL NOTE: Please be aware that the CSV files, exported from the .xml file tables, has all dates/times represented in the required ISO 8601 date format (ie, 2022-01-25).  We noted that when loading the CSV files into Microsoft Excel, Excel automatically converts some dates to local format and not others.  Attempts to manually convert columns to YYYY-MM-DD resulted in dates that were just a year (ie, "2013") to be converted into very incorrect dates.  We didn't have sufficient time to figure the magic words to make Excel do what we wanted (smile).

The data in the actual CSV files is in the correct format.


OUTPUT ARTIFACTS from January 11-12, 2022


Evaluation of minimal sufficient FHIR elements needed to allow LZZT study from EHR data (potential basis for Profiling).  This sheet has multiple uses, for now if you filter on the "In LZZT FHIR bundle" column for "Y", you will see just the elements present in the Bundle.

LZZT_FHIR_Elements was created by

  • Reading FHIR Resource, FHIR Element and Domain from HL7_FHIR_to_CDISC_Mapping.xlsx
    • FHIR path is just one example of a FHIR path taken from the mapping doc
  • "Pivoting" to make Domain columns with 'Y' flag
  • Doing a full join with all elements used in the LZZT bundle
  • Adding extension URL


SDTM Review Comments


Post-Connectathon developed mapping overview table Jozef Aerts,
also revealing gaps