2022 - 09 Vulcan - Real World Data (RWD) for Research and Regulatory Submissions

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 – for now primarily Electronic Health Record (EHR) systems - and ultimately transform that data into a format suitable for submission to pharmaceutical regulatory agencies.  

Long Description

The main goal of this track is to help define a minimal set of clinical research FHIR resources and elements in an EHR that can be utilized in an interoperable and consistent manner for clinical research objectives (e.g., academic, regulatory, etc.). An implementation guide is being developed that defines FHIR profiles that can be used in an EHR setting to represent data that will be supportive of RWD research needs and also to retrieve relevant research data from Real World Data (RWD) sources to facilitate downstream use (directly or after transformation) for submissions to pharmaceutical regulatory agencies.  The downstream use of retrieved data is not covered in this guide but separate efforts exist to give advice for such use (for example, the FHIR to CDISC Joint Mapping Implementation Guide). Many sources of RWD exist, but for the current phase of work, the scope of this Implementation Guide is limited to the use of Electronic Health Record (EHR) systems as sources of RWD. The intent is for future iterations of the Implementation Guide to have a wider scope of RWD such as from Registries, Payer systems, and HIEs.  Additionally, our focus is currently limited to the use of EHR data for retrospective analysis of data which already exists as part of normal healthcare encounters - not data created as part of prospective clinical studies.   

We are very aware that 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 also of great interest. While this is not currently in scope of this implementation guide, we consider it highly likely that types of solutions developed for eSource and for RWD will have significant overlap.

The guide is dependent on the International Patient Summary (IPS) project for a baseline dataset from which to build its profiles. The profiles built will enhance the IPS profiles for the purposes of conveying data needed for clinical research.  

This guide defines the FHIR building blocks to meet use cases which will eventually mature the minimal set of common resources and elements. It is being developed using an iterative use case approach, identifying the minimal set of EHR-based information needed to answer a small set of research questions and creating a set of FHIR profiles for representing this needed information in an EHR, then repeating the process with a new question.  As more use cases are considered, more common resources and elements will be added to the guide. It provides an opportunity to help establish future US Core, Australia Core, Japan Core, etc. as they wish to scale their guides and profiles. The mappings to achieve different outcomes are dependent on other projects (eg. FHIR to CDISC, FHIR to OMOP, etc.).

Type

Test an Implementation Guide

Track Lead(s)

Scott Gordon, Damion Nero, Jean Duteau

Track Lead Email(s)

gideon.gordon@fda.hhs.gov; Damion.Nero@pfizer.com; jean@duteaudesign.com

Specification Information

Vulcan Project page, notes, etc: https://confluence.hl7.org/display/VA/Real+World+Data

Last Connectathon (January 2022): 2022-01 Vulcan - Real World Data (RWD) Submission to FDA

Current Implementation Guide draft: http://build.fhir.org/ig/HL7/vulcan-rwd/index.html 

Call for participants

• Source: an “EHR” or FHIR data source/server, with medical records (synthetic is acceptable) containing example patients conforming to the RWD Implementation Guide being created.
• Retriever: some actor with any form of application or code that will be used to query and retrieve data needed from the Source.

Track Pre-requisites

1. Have read the current Vulcan/RWD Implementation Guide draft: http://build.fhir.org/ig/HL7/vulcan-rwd/index.html 
2. Any or all of the following:
   
   1. Environment (ie, Server) to server as a Source of data which adheres to the requirements of the RWD implementation guide (preferred to test our assumptions and server as a "proof of concept" for interoperability in RWD research)
   2. Environment (ie, Server) to server as a Source of data which does not necessarily adhere to the RWD IG requirements - to serve as a "real world" check on the delta between the needs of the IG versus the "average" EHR that currently exist
   3. Access to an environment that will allow us to compare the use and population of all data elements of interest in the IG with one or many real EHR systems - a combination of conformance statements and actual "survey" of whether elements contain data or do not.  This can even include data that was not in FHIR at the source but was subsequently converted to FHIR.  There is NO need for anyone but the data owner to have access to the actual data in this option.  It will serve as another "real world" assessment of the gap between the IG and average EHRs
   4. Development environment with code that supports any "implementation" use: Retriever or Source.

https://chat.fhir.org/#narrow/stream/267892-Vulcan.2FRWD

Tuesday September 6th, 11am-11:30am Eastern

Missed the call?  View the recording here

Testing Scenario:

For initial testing of this IG, the RWD track needs two types of “implementers”:

1. A Source: an “EHR” or FHIR data source/server, with medical records (synthetic is fine) conforming to the RWD Implementation Guide being created. This setup should have typical abilities to be queried and data retrieves as per normal FHIR mechanisms (FHIR queries, other APIs, etc).
2. A Retriever: some actor with any form of application or code that will be used to query and retrieve data needed from the Source. The Retriever will also be fully aware of the Profile definitions/IG rules so they will have a common understanding of exactly what resources and sub-elements will contain the information they are looking for.

In upcoming testing, we would like:

• Source implementers to have a publicly accessible EHR analog or FHIR server (not connected to any PHI/PII a sandbox system) ready with a reasonable quantity of data conforming to the RWD IG. To meet the requirements of this IG, it is likely that such data will need to be synthetic in some way.
• Retriever implementers, with only basic instructions about accessing the Source (instructions on access, the available methods of querying, etc), to be able to accurately and completely retrieve the needed data (perhaps with a few different queries).

A simple demonstration of success may be a comparison of the Retrieved data set to the Source data to assess if everything was retrieved which should have been any nothing was retrieved that should not have been.  Our initial goal in the upcoming September Connectathon is that we either demonstrate success or, just as useful, reveal issues to be remedied somewhere in the process (either in implementation logic or the IG itself).  

Sample Testing Scenario:

Details from the ClinicalTrials.gov study: NCT02190123

Find patients that match the following criteria:

• female or male aged 18 years or older
• have a Encounter record representing a hospitalization with an initial diagnosis of Acute Coronary Syndrome where the patient was discharged alive some time between September 2020 to September 2021 :
  • ACS is represented for this scenario one of these ICD 10 codes (I21 Acute myocardial infarction; I20-I25  Ischemic heart diseases; I24  Other acute ischemic heart diseases)
    
  • the Encounter diagnosis will point to a Condition with one of those codes
  • the Encounter will have hospitalization information included
  • the Encounter hospitalization discharge disposition code is not 'exp' (expired)
• have been given one of ticagrelor, prasugrel or clopidogrel after the date of diagnosis of ACS (as represented by the Condition or Encounter record found above)

For patients that meet the criteria above, retrieve the Extended Patient Summary (in one of the two ways defined in the Implementation Guide) for the patient, ensuring it includes as a minimum:

• patient demographics
• all Medications from the date of initial diagnosis of ACS to 1 year after diagnosis date
• all Encounters from the date of initial diagnosis of ACS to 1 year after diagnosis date, including the outcomes of the Encounters
• all Conditions from the date of initial diagnosis of ACS to 1 year after diagnosis date, showing the status of the Conditions
• other relevant Medical History from the date of initial diagnosis of ACS to 1 year after diagnosis date

Artifacts:

Droice review of public server capability statements: Excel list of links,  Zip file of outputs. 

Report-out Slide Deck: Vulcan RWD Track September 2022 Connectathon Report-out.pptx