Difference between revisions of "201801 Clinical Research"
Wayne Kubick (talk | contribs) (Initial draft of clinical research draft; to be updated after design meeting scheduled for Oct. 25-26.) |
James agnew (talk | contribs) |
||
| (22 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
| − | Clinical Research | + | [[Category:201801_FHIR_Connectathon_Track_Proposals|Jan 2018 Proposals]] |
| − | + | __NOTOC__ | |
| + | =Clinical Research= | ||
| − | Biopharma FHIR project group | + | ==Submitting WG/Project/Implementer Group== |
| − | Justification | + | <!-- Who is asking for this track? --> |
| + | Biopharma FHIR project group - consisting of research sponsors through the Transcelerate Biopharma eSource project and technology vendors. | ||
| + | ==Justification== | ||
| + | <!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. --> | ||
| + | This track will continue to further explore the benefits of FHIR for clinical research of new biopharmaceutical experimental treatments, and to increase visibility of FHIR within the biopharmaceutical community. This track advances 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. This builds on previous explorations in Connectathon 13-16. Plans for this connection include participation from at least 5 Pharmaceutical companies, Members of TransCelerate Biopharma, Inc. and technology implementers will simulate using FHIR to populate and manage clinical study databases. A set of 2-3 detailed use case scenarios will be proposed. This work will inform development of profiles and IGs to support clinical research using FHIR. | ||
| − | + | Clinical Research studies currently require the redundant entry of clinical data that already typically reside in Meaningful Use conformant EHR systems. EHR data represents original records in electronic format that can be used as eSource and directly imported into clinical research EDC databases so as to improve the quality and consistency of data between EHR and EDC systems and eliminate the need for redundant data entry and to improve the ability to use real world data in research. 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 and to use FHIR to gain increased visibility into patient encounters and patient-originated data. As stated in its May 2016 FDA draft guidance titled “Use of Electronic Health Record Data in Clinical Investigations” 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. . . Establishing interoperability between EHR and EDC systems to streamline and modernize clinical investigations should improve data accuracy, patient safety, and clinical research efficiency.” | |
| − | |||
| − | Clinical Research studies currently require the redundant entry of clinical data that already typically reside in Meaningful Use conformant EHR systems. EHR data represents original records in electronic format that can be used as eSource and directly imported into clinical research EDC databases so as to improve the quality and consistency of data between EHR and EDC systems and 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. | ||
| − | FDA | ||
| − | Establishing interoperability between EHR and EDC systems to streamline and modernize clinical investigations should improve data accuracy, patient safety, and clinical research efficiency. | ||
| − | |||
| − | |||
| − | See Connectathon_Track_Lead_Responsibilities | + | ==Proposed Track Lead== |
| − | + | <!-- Name, email and Skype id of individual who will coordinate the track at the connectathon --> | |
| + | See [[Connectathon_Track_Lead_Responsibilities]] | ||
| + | Responsibilities Geoff Low (glow@mdsol.com); Trisha Simpson (trisha.simpson@ucb.com) | ||
| − | TransCelerate Biopharma, Inc., UCB, Pfizer, GSK, Merck, Lilly, Medidata, Oracle Health Sciences, Clinical Ink, others | + | ==Expected participants== |
| − | + | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | |
| + | TransCelerate Biopharma, Inc., UCB, Pfizer, GSK, Merck, Lilly, Medidata, Oracle Health Sciences, Clinical Ink, Smile CDR, others | ||
| + | ==Roles== | ||
Please include information here regarding how much advance preparation will be required if creating a client and/or server. | Please include information here regarding how much advance preparation will be required if creating a client and/or server. | ||
| − | FHIR Client | + | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> |
| − | Support the sending from an EHR or patient device of clinical research study data: create, read, search and update to a clinical study database system. | + | ===FHIR Client=== |
| − | + | <!-- Provide a description of the capabilities this role will have within the connectathon --> | |
| − | + | : Support the sending from an EHR or patient device of clinical research study data: create, read, search and update to a clinical study database system. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ===Clinical Trial Designer=== | |
| − | + | Identifies data relevant to research studies that may be collected from EHRs or SMART-on-FHIR devices. Sets up patient matching criteria and identifiers for ResearchStudy and ResearchSubject for a synthetic test study. Creates study database, mappings/interfaces, EDC case report forms with variable mappings to FHIR that will receive EHR patient data for clinical trial subjects. Generate updates from EDC to apply to the EHR. Data Collector[edit] Queries API to identify patients by Study and Subject identifiers to pull EHR data for demographics, medications and lab data that maps directly to variables on eCRF. Provides data generated by patients to add to study databases or EHRs. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ===Subject Matter Expert=== | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | SME creates and tests queries to identify patients who match eligibility criteria for a study or review data. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ==Scenarios== | |
| − | + | <!-- What will be the actions performed by participants? --> | |
| − | + | ===EMR to EDC=== | |
| − | + | 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. Run test scripts to verify reliability and accuracy of transfer. | |
| + | :Action: <!--Who does what? (Use the role names listed above when referring to the participants --> | ||
| + | Identify a Patient in an EHR who is enrolled in a ResearchStudy, extract relevant EHR data that can be mapped to a clinical research Electronic Data Capture (EDC) database, import into EDC Study Database to auto-populate eCRFs. | ||
| + | Identify changed data in the EHR that needs to be updated in the EDC database. | ||
| + | :Precondition: <!-- What setup is required prior to executing this step? --> | ||
| + | Values for ResearchStudy and ResearchSubject for a named study exist in EHR. Patient records include demographics, MedicationStatement, Lab observation data, possibly problems, diagnosis. | ||
| + | At least one patient has at least 2 sets of lab observations for at least 3 lab tests. Additional information, such as LOINC codes for the set of lab tests to be used and mappings to CDISC for these will be specified in advance. | ||
| + | :Success Criteria: <!-- How will the participants know if the test was successful? --> | ||
| + | Test script verifies that the App is able to import EHR data for at least one subject from FHIR servers of at least 2 different EHR products and auto-populate eCRFs in an EDC database. | ||
| + | :Bonus point 1: <!-- Any additional complexity to make the scenario more challenging --> | ||
| + | identify and extract an example of unstructured data (such as from a narrative or patient note) that may provide additional context for the subject record. | ||
| + | :Bonus point 2: <!-- Any additional complexity to make the scenario more challenging --> | ||
| + | Explore how to apply changes to the eSource (perhaps using a flag that identifies changes) and verify existence of a Resource Audit ID in the EDC system. | ||
| + | |||
| + | <!-- Provide a description of each task --> | ||
| + | |||
| + | ===Real World Evidence Scenario=== | ||
| + | Receive and apply Real World Evidence updates to the study database as new or changed data is recorded in the site EHR or received from patients for participating study subjects. Explore collection of both EHR and patient-provided data to support outcomes research. | ||
| + | |||
| + | In the Real World, Patients seek care from many healthcare institutions (Sites) as needed, with few or any pre-scheduled visits. Clinical Research needs a scalable and automated way to know about and extract EHR data from Sites where Patients participating in a Study receive care. Key Point – no one knows when or at what Sites the Patents receive care beforehand. Direct transfers from Site EHR systems to Study databases are ideal. Alternately, patient may extract data from an EHR via SMART apps and send the data to a Study database themselves. | ||
| + | |||
| + | :Action: <!--Who does what? (Use the role names listed above when referring to the participants --> | ||
| + | Create a triggering event that recognizes when new data is entered in EHR for a current ResearchSubject after patient encounters. Or create an App which allows the recording of data by patient and remote site. If an App is used, integrate the captured data with the site EHR if possible and transfer the data to the study database. New data may be collected via a patient aggregator app or a Broker that recognizes patient, site and study identifiers before being transmitted to the EHR or sponsor study database in a standardized dataset format. | ||
| + | :Precondition: <!-- What setup is required prior to executing this step? --> | ||
| + | A FHIR server supporting SMART-on-FHIR, CDS Hooks or Subscription should be available with test data for more than one encounter for at least 3 patients. Patient is enrolled as a ResearchSubject for a ResearchStudy with available clinical data. Data that might be suitable for this scenario (for a sample HCRU study) may include duration of visit, procedures any diagnoses or treatments and questionnaires. A Broker of Patient Aggregator may participate to store and forward medical records for a given patient, which may include data from multiple EHRs. | ||
| + | :Success Criteria: <!-- How will the participants know if the test was successful? --> | ||
| + | A means of aggregating data from multiple EHR sources and potentially patient-provided apps has been tested, and a transfer from the aggregator/broker has been successfully completed to the sponsor study database. | ||
| + | :Bonus point 1: <!-- Any additional complexity to make the scenario more challenging --> | ||
| + | Use the Subscription resource or CDS Hooks to trigger update after new patient encounter is recorded. | ||
| + | Import patient-reported data from a SMART-on-FHIR app. | ||
| + | |||
| + | : | ||
| + | |||
| + | ===Lab Data Import=== | ||
| + | Some clinical trial Sites contain in-house laboratory capability allowing them to quickly assess patient health from analysis of lab samples (e.g., blood draws). Many such sites capture lab analysis results in their local EHR systems. When lab results are of interest to clinical research Study Teams, both the Site and the Study Team benefit from direct exchange of lab results from the Site EHR to the Study database as this reduces data latency and data exchange effort. To achieve direct lab data exchange at scale the Site must (1) implement a FHIR server and expose the requisite FHIR resources, the Study Team must (2) be able to convert the retrieved FHIR resources into data structures usable by Sponsor data systems, and (3) high volume lab-result data exchange between Site FHIR server and Study Team data system must be possible. | ||
| + | |||
| + | :Action: <!--Who does what? (Use the role names listed above when referring to the participants --> | ||
| + | 1. Actions. | ||
| + | a. Extract FHIR resources from a FHIR server for three patients for a limited number (less than 10) of lab results. Goal is to prove out the use of FHIR resources to express patient lab results for clinical research as well as the underlying data model. (It is assumed lab data will be analyzed in the analysis database). | ||
| + | b. Convert extracted resource data into CDISC-LDM/XML or alternative standard data structures (such as ODM-XML). Goal is to prove out the transformation of FHIR resources into a common Pharmaceutical/Sponsor data structure. | ||
| + | c. Use the FHIR R4 bulk data mechanism to extract all relevant FHIR resource records for the three patients in (1a) and convert them CDISC-LDM/XML as in (1b). Goal is to prove out use of the bulk data transfer mechanism in the context of lab results. | ||
| + | |||
| + | :Precondition: <!-- What setup is required prior to executing this step? --> | ||
| + | a. At least 3 patients are enrolled as a ResearchSubject for a ResearchStudy with available lab data. | ||
| + | b. Source FHIR server that implements the following resources -- Location, Organization, Practitioner, Observation, Encounter, Specimen, Research Subject, Study, Patient, Procedure | ||
| + | c. Source FHIR server with test data for at least 3 patients for the FHIR lab-related resources for at least 10 complete lab results per patient – total of at least 30 lab results. | ||
| + | d. Data model mapping the FHIR resources to CDISC-LDM, SDTM of CDASH LB domain (to be supplied). | ||
| + | e. An example of code to transform FHIR resources into CDISC-LDM/XML (to be supplied). | ||
| + | |||
| + | :Success Criteria: <!-- How will the participants know if the test was successful? --> | ||
| + | a. Data from the listed FHIR resources can be extracted from the test FHIR server. | ||
| + | b. Extracted data can be converted into the appropriate format (e.g., CDISC-LDM/XML) to allow import into a clinical study database.. | ||
| + | c. Data transfer mechanism demonstrated for at least 30 patient lab results as CDISC-LDM/XML output | ||
| + | |||
| + | |||
| + | :Bonus point 1: <!-- Any additional complexity to make the scenario more challenging --> | ||
| + | Explore use of analytics such as R on FHIR for trend analysis of lab data. | ||
| + | Bonus point 2: <!-- Any additional complexity to make the scenario more challenging --> | ||
| + | Use new R4 Bulk Data Access ndJSON format. | ||
| + | |||
| + | ==Test Data== | ||
| + | |||
| + | A test server with a representative set of data has been made available at: https://try.smilecdr.com:8001/ | ||
| + | |||
| + | FHIR Endpoint: https://try.smilecdr.com:8000/ | ||
| + | |||
| + | ==TestScript(s)== | ||
| + | <!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested. | ||
| + | These should be committed to SVN under trunk/connectathons/[connectathon] | ||
| + | --> | ||
| + | |||
| + | ==Security and Privacy Considerations== | ||
| + | <!-- Optional (for initial proposal): Address the topic of Privacy and Security. | ||
| + | * What Authentication/Authorization will be used (e.g. SMART on FHIR (OAuth), HEART (UMA/OAuth), IHE IUA (OAuth), generic OAuth, generic SAML, mutual-Auth-TLS), or explicitly indicate that it is out of scope and left to implementations. | ||
| + | * What Privacy Consent management will be used? When the Consent Resource is used, define how. | ||
| + | * What Audit Logging will be used? When the AuditEvent Resource is used, define expectations of what events will be logged and what each AuditEvent will contain. | ||
| + | * How will Provenance be used? Provenance use should be mandated when data is imported from other systems, so as to track that source of that data. Provenance should be used when data is authored by unusual sources, such as the Patient themselves or devices. | ||
| + | * How will security-labels be used? Security-labels are meta tags used to classify the data into various confidentiality, sensitivity, and integrity classifications. These security-labels are then available for use and available for access control decisions. | ||
| + | I am happy to help: JohnMoehrke@gmail.com -- security co-chair | ||
| + | --> | ||
Latest revision as of 11:18, 26 January 2018
Clinical Research
Submitting WG/Project/Implementer Group
Biopharma FHIR project group - consisting of research sponsors through the Transcelerate Biopharma eSource project and technology vendors.
Justification
This track will continue to further explore the benefits of FHIR for clinical research of new biopharmaceutical experimental treatments, and to increase visibility of FHIR within the biopharmaceutical community. This track advances 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. This builds on previous explorations in Connectathon 13-16. Plans for this connection include participation from at least 5 Pharmaceutical companies, Members of TransCelerate Biopharma, Inc. and technology implementers will simulate using FHIR to populate and manage clinical study databases. A set of 2-3 detailed use case scenarios will be proposed. This work will inform development of profiles and IGs to support clinical research using FHIR.
Clinical Research studies currently require the redundant entry of clinical data that already typically reside in Meaningful Use conformant EHR systems. EHR data represents original records in electronic format that can be used as eSource and directly imported into clinical research EDC databases so as to improve the quality and consistency of data between EHR and EDC systems and eliminate the need for redundant data entry and to improve the ability to use real world data in research. 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 and to use FHIR to gain increased visibility into patient encounters and patient-originated data. As stated in its May 2016 FDA draft guidance titled “Use of Electronic Health Record Data in Clinical Investigations” 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. . . Establishing interoperability between EHR and EDC systems to streamline and modernize clinical investigations should improve data accuracy, patient safety, and clinical research efficiency.”
Proposed Track Lead
See Connectathon_Track_Lead_Responsibilities Responsibilities Geoff Low (glow@mdsol.com); Trisha Simpson (trisha.simpson@ucb.com)
Expected participants
TransCelerate Biopharma, Inc., UCB, Pfizer, GSK, Merck, Lilly, Medidata, Oracle Health Sciences, Clinical Ink, Smile CDR, others
Roles
Please include information here regarding how much advance preparation will be required if creating a client and/or server.
FHIR Client
- Support the sending from an EHR or patient device of clinical research study data: create, read, search and update to a clinical study database system.
Clinical Trial Designer
Identifies data relevant to research studies that may be collected from EHRs or SMART-on-FHIR devices. Sets up patient matching criteria and identifiers for ResearchStudy and ResearchSubject for a synthetic test study. Creates study database, mappings/interfaces, EDC case report forms with variable mappings to FHIR that will receive EHR patient data for clinical trial subjects. Generate updates from EDC to apply to the EHR. Data Collector[edit] Queries API to identify patients by Study and Subject identifiers to pull EHR data for demographics, medications and lab data that maps directly to variables on eCRF. Provides data generated by patients to add to study databases or EHRs.
Subject Matter Expert
SME creates and tests queries to identify patients who match eligibility criteria for a study or review data.
Scenarios
EMR to EDC
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. Run test scripts to verify reliability and accuracy of transfer.
- Action:
Identify a Patient in an EHR who is enrolled in a ResearchStudy, extract relevant EHR data that can be mapped to a clinical research Electronic Data Capture (EDC) database, import into EDC Study Database to auto-populate eCRFs. Identify changed data in the EHR that needs to be updated in the EDC database.
- Precondition:
Values for ResearchStudy and ResearchSubject for a named study exist in EHR. Patient records include demographics, MedicationStatement, Lab observation data, possibly problems, diagnosis. At least one patient has at least 2 sets of lab observations for at least 3 lab tests. Additional information, such as LOINC codes for the set of lab tests to be used and mappings to CDISC for these will be specified in advance.
- Success Criteria:
Test script verifies that the App is able to import EHR data for at least one subject from FHIR servers of at least 2 different EHR products and auto-populate eCRFs in an EDC database.
- Bonus point 1:
identify and extract an example of unstructured data (such as from a narrative or patient note) that may provide additional context for the subject record.
- Bonus point 2:
Explore how to apply changes to the eSource (perhaps using a flag that identifies changes) and verify existence of a Resource Audit ID in the EDC system.
Real World Evidence Scenario
Receive and apply Real World Evidence updates to the study database as new or changed data is recorded in the site EHR or received from patients for participating study subjects. Explore collection of both EHR and patient-provided data to support outcomes research.
In the Real World, Patients seek care from many healthcare institutions (Sites) as needed, with few or any pre-scheduled visits. Clinical Research needs a scalable and automated way to know about and extract EHR data from Sites where Patients participating in a Study receive care. Key Point – no one knows when or at what Sites the Patents receive care beforehand. Direct transfers from Site EHR systems to Study databases are ideal. Alternately, patient may extract data from an EHR via SMART apps and send the data to a Study database themselves.
- Action:
Create a triggering event that recognizes when new data is entered in EHR for a current ResearchSubject after patient encounters. Or create an App which allows the recording of data by patient and remote site. If an App is used, integrate the captured data with the site EHR if possible and transfer the data to the study database. New data may be collected via a patient aggregator app or a Broker that recognizes patient, site and study identifiers before being transmitted to the EHR or sponsor study database in a standardized dataset format.
- Precondition:
A FHIR server supporting SMART-on-FHIR, CDS Hooks or Subscription should be available with test data for more than one encounter for at least 3 patients. Patient is enrolled as a ResearchSubject for a ResearchStudy with available clinical data. Data that might be suitable for this scenario (for a sample HCRU study) may include duration of visit, procedures any diagnoses or treatments and questionnaires. A Broker of Patient Aggregator may participate to store and forward medical records for a given patient, which may include data from multiple EHRs.
- Success Criteria:
A means of aggregating data from multiple EHR sources and potentially patient-provided apps has been tested, and a transfer from the aggregator/broker has been successfully completed to the sponsor study database.
- Bonus point 1:
Use the Subscription resource or CDS Hooks to trigger update after new patient encounter is recorded. Import patient-reported data from a SMART-on-FHIR app.
Lab Data Import
Some clinical trial Sites contain in-house laboratory capability allowing them to quickly assess patient health from analysis of lab samples (e.g., blood draws). Many such sites capture lab analysis results in their local EHR systems. When lab results are of interest to clinical research Study Teams, both the Site and the Study Team benefit from direct exchange of lab results from the Site EHR to the Study database as this reduces data latency and data exchange effort. To achieve direct lab data exchange at scale the Site must (1) implement a FHIR server and expose the requisite FHIR resources, the Study Team must (2) be able to convert the retrieved FHIR resources into data structures usable by Sponsor data systems, and (3) high volume lab-result data exchange between Site FHIR server and Study Team data system must be possible.
- Action:
1. Actions. a. Extract FHIR resources from a FHIR server for three patients for a limited number (less than 10) of lab results. Goal is to prove out the use of FHIR resources to express patient lab results for clinical research as well as the underlying data model. (It is assumed lab data will be analyzed in the analysis database). b. Convert extracted resource data into CDISC-LDM/XML or alternative standard data structures (such as ODM-XML). Goal is to prove out the transformation of FHIR resources into a common Pharmaceutical/Sponsor data structure. c. Use the FHIR R4 bulk data mechanism to extract all relevant FHIR resource records for the three patients in (1a) and convert them CDISC-LDM/XML as in (1b). Goal is to prove out use of the bulk data transfer mechanism in the context of lab results.
- Precondition:
a. At least 3 patients are enrolled as a ResearchSubject for a ResearchStudy with available lab data. b. Source FHIR server that implements the following resources -- Location, Organization, Practitioner, Observation, Encounter, Specimen, Research Subject, Study, Patient, Procedure c. Source FHIR server with test data for at least 3 patients for the FHIR lab-related resources for at least 10 complete lab results per patient – total of at least 30 lab results. d. Data model mapping the FHIR resources to CDISC-LDM, SDTM of CDASH LB domain (to be supplied). e. An example of code to transform FHIR resources into CDISC-LDM/XML (to be supplied).
- Success Criteria:
a. Data from the listed FHIR resources can be extracted from the test FHIR server. b. Extracted data can be converted into the appropriate format (e.g., CDISC-LDM/XML) to allow import into a clinical study database.. c. Data transfer mechanism demonstrated for at least 30 patient lab results as CDISC-LDM/XML output
- Bonus point 1:
Explore use of analytics such as R on FHIR for trend analysis of lab data. Bonus point 2: Use new R4 Bulk Data Access ndJSON format.
Test Data
A test server with a representative set of data has been made available at: https://try.smilecdr.com:8001/
FHIR Endpoint: https://try.smilecdr.com:8000/
