201701 Clinical Research Track
Clinical Research Track
This track is intended to advance the use of FHIR resources as eSource data used to pre-populate clinical research case report forms for both regulated and non-regulated clinical research.
Submitting WG/Project/Implementer Group
Clinical Interoperability Council
Clinical Research studies currently require the redundant entry of clinical data that already typically resides in Meaningful Use conformant EHR systems. EHR data represents original records in electronic format that can be used as eSource to eliminate the need for redundant data entry. Establishing interoperability between EHR and EDC systems to streamline and modernize clinical investigations should improve data accuracy, patient safety, and clinical research efficiency. Given the extreme cost and extended time required for randomized clinical trials, it would be substantially better to utilize EHR source data to directly populate clinical trial databases wherever feasible. The May 2016 FDA draft guidance titled “Use of Electronic Health Record Data in Clinical Investigations” encourages the sponsors of clinical research to use EHR data as noted in the statement below.
FDA encourages sponsors and clinical investigators to work with the entities that control the EHRs, such as health care organizations, to use EHRs and EDC systems that are interoperable. EHRs may be interoperable with EDC systems in a variety of ways depending on supportive technologies and standards. Interoperable technology may involve automated electronic transmission of relevant EHR data to the EDC system. For example, data elements originating in an EHR (e.g., demographics, vital signs, past medical history, past surgical history, social history, medications, adverse reactions) may automatically populate the eCRFs within an EDC system.
Proposed Track Lead
Coordinator: Wayne Kubick
Test Support: Sam Hume
Biopharmaceutical companies (TBD), CDISC, EHR vendors supporting the FHIR API, Medidata Solutions, Clinical Ink, Oracle, Other EDC Vendors (TBD), Contract Research Organizations (TBD)
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
Clinical Trial Form Designer
Creates EDC case report forms with variable mappings to FHIR API.
Queries API to pull EHR data that maps directly to variables on eCRF.
1. Prepopulating study research data from an EHR
- Action: Prepopulate eCRFs in an EDC clinical database with data pulled via FHIR from an EHR using loose matching criteria. Multiple versions of a CRF type (e.g. vital signs) can be used to represent different types of clinical studies (e.g. observational vs. regulated).
- Precondition: A patient has been enrolled in a clinical study and assigned a subject identifier. The patient has been assigned to a primary caregiver that functions as the clinical investigator. Patient clinical data has been captured in the clinical investigator’s EHR. Initial EHR data has been mapped and loaded into an EDC system by the Clinical Research Track during Connectathon 13. Connectathon 13 saw Patient resource data mapped into the Demographics CRF including data elements DOB and gender. MedicationStatement resource data was mapped into the Concomitant Medications CRF including data elements: effectivePeriod/start, effectivePeriod/end, dosage/text, and route. Building on the Connectathon 13 work, a map of additional FHIR resources have been identified as eSource candidates for CDISC data elements. Create a table that identifies the set resources to target for data extraction and mapping to clinical research CRFs using the FHIR API. During testing this table will be expanded to include the results of mapping each FHIR resource data elements.
- Success Criteria: Data from the FHIR resources are extracted through the FHIR API and mapped to clinical research data element fields on CRFs. Each FHIR resource data element has been successfully imported for display in the CRFs, or documented in the mapping table as not for use in clinical research. The matching criteria is intentionally loose in this step, meaning the data may not be usable as-is and the assessment of data content suitability for research will be performed in step 2.
- Bonus point #1: Document the mapping of CCDS content to CDISC standard data elements.
- Bonus point #2: Seed some patient test data that has been assigned a STUDYID and a SUBJID within an EHR that can be used to look up the subject and pull their data into the corresponding eCRFs.
2. Determine the FHIR resource EHR data content and quality assessed against the clinical research requirements
- Action: Re-run Scenario #1 across different test servers representing different EHR systems and evaluate the test data suitability for use in clinical research databases by assessing what actions would be needed to (1) load the data into non-regulated clinical research databases including those supporting observational studies, and (2) load the data into regulated clinical research database that requires CDISC standards alignment. For each test server, determine if the data retrieved fully meets, partially meets with transformation needed, partially meets with terminology mapping needed, partially meets with coding needed, partially meets – other, or does not meet the requirements for loading into each category of clinical research database.
- Precondition: Using the data successfully mapped in step 1, create a test matrix for determining the suitability of the FHIR resource EHR data content for use in both categories of clinical research databases. Create a list of at least 2 test servers representing different EHR systems that will be used to evaluate the EHR content.
- Success Criteria: The resulting table should function as a map highlighting potential data content issues to be addressed in future profile development activities. Summary statistics will be derived to assess the results recorded in the table.
- Bonus point: Update the CCD mapping started on the EHR to CDASH project to include the results from these tests.