Difference between revisions of "201809 Clinical Research"
Wayne Kubick (talk | contribs) (Created page with "Track Name[edit] Clinical Research Track Submitting WG/Project/Implementer Group[edit] Biopharma FHIR project group; TransCelerate Biopharma eSource Work Stream Justification...") |
Wayne Kubick (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | Track Name | + | [[Category:201805_FHIR_Connectathon_Track_Proposals|May2018 Proposals]] |
| − | Clinical Research | + | __NOTOC__ |
| − | + | =Track Name= | |
| − | + | Clinical Research | |
| − | This track will continue to | + | ==Submitting WG/Project/Implementer Group== |
| + | <!-- Who is asking for this track? --> | ||
| + | Biopharma FHIR Project Group | ||
| + | |||
| + | ==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 evaluate use of FHIR for clinical research of new biopharmaceutical experimental treatments, seeking 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. Plans for this connection include participation from at least 3 clinical data system implementers and pharmaceutical companies. 3 detailed use case scenarios will be proposed, 2 of which build on prior work at previous connectathons, and one exploring a new area for writing back with updates to clinical data from a clinical system. This work will inform development of profiles and IGs to support clinical research using FHIR, which will likely inform projects of the BR&R workgroup. | ||
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. 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. 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 | + | |
| − | + | ==Proposed Track Lead== | |
| − | Expected participants | + | <!-- Name, email and Skype id of individual who will coordinate the track at the connectathon --> |
| − | + | Geoff Low, Medidata; | |
| − | + | Wayne Kubick, HL7 | |
| − | Adoption of the LAB Model using FHIR Resources | + | |
| + | See [[Connectathon_Track_Lead_Responsibilities]] | ||
| + | |||
| + | ==Expected participants== | ||
| + | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track --> | ||
| + | Medidata, UCB, Parexel | ||
| + | |||
| + | ==Roles== | ||
| + | |||
| + | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on --> | ||
| + | ===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. | ||
| + | |||
| + | ===FHIR Server=== | ||
| + | Supports a FHIR API which can respond to requests from a clinical research FHIR clinical research client. | ||
| + | |||
| + | ===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. | ||
| + | |||
| + | ===Clinical Trial Designer=== | ||
| + | Clinical Trial Designer[edit] Identifies data relevant to research studies that may be collected from EHRs . 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 send to the EHR for keeping EHR and study databases in sync. | ||
| + | |||
| + | ===Data Collector=== | ||
| + | Queries API to identify patients by Study and Subject identifiers to pull EHR data for demographics, medications, observation and Condition data that maps directly to variables on eCRF. Provides data generated by patients to add to study databases or EHRs. | ||
| + | |||
| + | ==Scenarios== | ||
| + | <!-- What will be the actions performed by participants? --> | ||
| + | |||
| + | ===Scenario 1: Adoption of the LAB Model using FHIR Resources === | ||
| + | |||
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. | 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: | + | :Action: |
1. 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). | 1. 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). | ||
2. Convert extracted resource data into CDISC LAB data structures or alternative standard data structures (such as ODM-XML) as an intermediate step before submission and ingest into a Sponsor clinical data system (note, Sponsor data ingest is out of scope for this use case). Goal is to prove out the transformation of FHIR resources into a common Pharmaceutical/Sponsor data structure. | 2. Convert extracted resource data into CDISC LAB data structures or alternative standard data structures (such as ODM-XML) as an intermediate step before submission and ingest into a Sponsor clinical data system (note, Sponsor data ingest is out of scope for this use case). Goal is to prove out the transformation of FHIR resources into a common Pharmaceutical/Sponsor data structure. | ||
3. Use the FHIR R4 bulk data mechanism to extract all relevant FHIR resource records for the three patients in (1a) and convert them CDISC-LABLDM/XML as in (1b). Goal is to prove out use of the bulk data transfer mechanism in the context of lab results. | 3. Use the FHIR R4 bulk data mechanism to extract all relevant FHIR resource records for the three patients in (1a) and convert them CDISC-LABLDM/XML as in (1b). Goal is to prove out use of the bulk data transfer mechanism in the context of lab results. | ||
| − | Precondition: | + | :Precondition: <!-- What setup is required prior to executing this step? --> |
1. At least 3 patients are enrolled as a ResearchSubject for a ResearchStudy with available lab data. | 1. At least 3 patients are enrolled as a ResearchSubject for a ResearchStudy with available lab data. | ||
2. Source FHIR server that implements the following resources -- Location, Organization, Practitioner, Observation, Encounter, Specimen, Research Subject, Study, Patient, Procedure | 2. Source FHIR server that implements the following resources -- Location, Organization, Practitioner, Observation, Encounter, Specimen, Research Subject, Study, Patient, Procedure | ||
| Line 25: | Line 60: | ||
4. Data model mapping the FHIR resources to CDISC-LAB, SDTM of CDASH LB domain (to be supplied). | 4. Data model mapping the FHIR resources to CDISC-LAB, SDTM of CDASH LB domain (to be supplied). | ||
5. An example of code to transform FHIR resources into CDISC-LAB/XML (to be supplied). | 5. An example of code to transform FHIR resources into CDISC-LAB/XML (to be supplied). | ||
| − | Success Criteria: | + | :Success Criteria: <!-- How will the participants know if the test was successful? --> |
1. Data from the listed FHIR resources can be extracted from the test FHIR server. | 1. Data from the listed FHIR resources can be extracted from the test FHIR server. | ||
2. Extracted data can be converted into the appropriate format (e.g., CDISC-LAB/XML) to allow import into a clinical study database. | 2. Extracted data can be converted into the appropriate format (e.g., CDISC-LAB/XML) to allow import into a clinical study database. | ||
3. Data transfer mechanism demonstrated for at least 30 patient lab results as CDISC-LAB/XML output | 3. Data transfer mechanism demonstrated for at least 30 patient lab results as CDISC-LAB/XML output | ||
| − | Bonus points: | + | :Bonus points: |
1. Explore use of analytics such as R on FHIR for trend analysis of lab data. | 1. Explore use of analytics such as R on FHIR for trend analysis of lab data. | ||
2. Establish what happens with not complete records (a la Real Lab Data Files) | 2. Establish what happens with not complete records (a la Real Lab Data Files) | ||
| − | + | ===Scenario 2: Facilitating Real World Evidence Studies using FHIR resources === | |
| − | Facilitating Real World Evidence Studies using FHIR resources | ||
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. | 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. | 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: | + | :Action: |
1. Build or use models to bridge between FHIR resources and data formats/structures used in clinical research. Research Systems. Build on/Validate the work of the CDISC E2C project for core clinical domains (DM, VS, MH, HO). Identify gaps in the bridging models. | 1. Build or use models to bridge between FHIR resources and data formats/structures used in clinical research. Research Systems. Build on/Validate the work of the CDISC E2C project for core clinical domains (DM, VS, MH, HO). Identify gaps in the bridging models. | ||
2. Create a triggering event that recognizes when new data is entered in EHR for a current ResearchSubject after patient encounters, and notify subscribing parties of the event. | 2. Create a triggering event that recognizes when new data is entered in EHR for a current ResearchSubject after patient encounters, and notify subscribing parties of the event. | ||
3. 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. | 3. 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: | + | :Precondition: |
1. A FHIR server supporting SMART-on-FHIR, CDS Hooks or Subscription Resource 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. | 1. A FHIR server supporting SMART-on-FHIR, CDS Hooks or Subscription Resource 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: | Success Criteria: | ||
| Line 49: | Line 83: | ||
2. Import patient-reported data from a SMART-on-FHIR app. | 2. Import patient-reported data from a SMART-on-FHIR app. | ||
| − | Exploring the AdverseEvent resource for communication of Adverse Events in a Clinical Study | + | ===Scenario 3: Exploring the AdverseEvent resource for communication of Adverse Events in a Clinical Study === |
| + | |||
The AdverseEvent resource is a draft resource in the FHIR standard. It presents a useful resource for clinical investigations; the semantics of an Adverse Event in a clinical study are such that it can be difficult to align with other resources - examples of possible mappings have included AllergyIntolerance, Condition (Problem), ClinicalImpression, DetectedIssue, DiagnosticReport. | The AdverseEvent resource is a draft resource in the FHIR standard. It presents a useful resource for clinical investigations; the semantics of an Adverse Event in a clinical study are such that it can be difficult to align with other resources - examples of possible mappings have included AllergyIntolerance, Condition (Problem), ClinicalImpression, DetectedIssue, DiagnosticReport. | ||
Use of the AdverseEvent resource will be a useful mechanism for the standardized representation of Adverse Event data for the purposes of exchange (and reporting). | Use of the AdverseEvent resource will be a useful mechanism for the standardized representation of Adverse Event data for the purposes of exchange (and reporting). | ||
| − | Precondition: | + | :Precondition: |
1. An EHR system supporting the AdverseEvent Resource | 1. An EHR system supporting the AdverseEvent Resource | ||
2. An EHR system with Patient Data that may be associated with an AdverseEvent | 2. An EHR system with Patient Data that may be associated with an AdverseEvent | ||
3. CLINFHIR to construct resources | 3. CLINFHIR to construct resources | ||
| − | Action: | + | :Action: |
1. Construct an AdverseEvent Resource for a sample non-Serious Adverse Event | 1. Construct an AdverseEvent Resource for a sample non-Serious Adverse Event | ||
2. Construct an AdverseEvent Resource for a sample serious Adverse Event | 2. Construct an AdverseEvent Resource for a sample serious Adverse Event | ||
| − | Success Criteria: | + | :Success Criteria: |
1. Two sample AdverseEvent resources are provided | 1. Two sample AdverseEvent resources are provided | ||
2. Example gaps are provided back to the BR&R team | 2. Example gaps are provided back to the BR&R team | ||
3. Goal is to work towards developing and refining a healthcare-standard FHIR Resource data model for expressing Adverse Events; i.e., the data model is the key deliverable, not the code | 3. Goal is to work towards developing and refining a healthcare-standard FHIR Resource data model for expressing Adverse Events; i.e., the data model is the key deliverable, not the code | ||
| − | Bonus points: | + | :Bonus points: |
1. Map a sample ICG E2B message structure or a CDISC AE record to an AdverseEvent resource | 1. Map a sample ICG E2B message structure or a CDISC AE record to an AdverseEvent resource | ||
| − | + | ||
| − | Matching an ODM based Schedule of Activities to a PlanDefinition | + | ===Scenario 3: Matching an ODM based Schedule of Activities to a PlanDefinition === |
| + | |||
Scheduling can be a difficult problem for patients, investigators and sites in a clinical trial. Many EHR systems have built-in calendaring systems that incorporate patient, staff and facilities management; this is often provided on site and via mobile apps. If a participant in a clinical study were able to incorporate their study activities into their existing calendar then that would aid them in managing their time (eg fasting before a blood test, completing an assigned questionnaire, etc) | Scheduling can be a difficult problem for patients, investigators and sites in a clinical trial. Many EHR systems have built-in calendaring systems that incorporate patient, staff and facilities management; this is often provided on site and via mobile apps. If a participant in a clinical study were able to incorporate their study activities into their existing calendar then that would aid them in managing their time (eg fasting before a blood test, completing an assigned questionnaire, etc) | ||
The CarePlan resource summarises the activities a site will undertake in the delivery of care to the patient for one or more conditions. The activities in a CarePlan are defined abstractly in the PlanDefinition resource. If it were possible to take the Schedule of Activities from the protocol and convert it to a PlanDefinition then it would be possible to use this artifice to integrate with the patient calendar. For the purposes of simplicity we will use the CDISC ODM as our source model from which to build the PlanDefinition | The CarePlan resource summarises the activities a site will undertake in the delivery of care to the patient for one or more conditions. The activities in a CarePlan are defined abstractly in the PlanDefinition resource. If it were possible to take the Schedule of Activities from the protocol and convert it to a PlanDefinition then it would be possible to use this artifice to integrate with the patient calendar. For the purposes of simplicity we will use the CDISC ODM as our source model from which to build the PlanDefinition | ||
| − | Precondition: | + | :Precondition: |
1. An EHR system supporting the PlanDefinition and CarePlan Resource | 1. An EHR system supporting the PlanDefinition and CarePlan Resource | ||
2. An EHR system with Patient Data that may be associated with an AdverseEvent | 2. An EHR system with Patient Data that may be associated with an AdverseEvent | ||
3. A simple schedule of activities (as an ODM metadata file) | 3. A simple schedule of activities (as an ODM metadata file) | ||
| − | Action: | + | :Action: |
1. Develop a PlanDefinition that matches the ODM | 1. Develop a PlanDefinition that matches the ODM | ||
2. Create a CarePlan for a Patient based on the PlanDefinition | 2. Create a CarePlan for a Patient based on the PlanDefinition | ||
| − | Success Criteria: | + | :Success Criteria: |
1. A functional PlanDefinition is producted | 1. A functional PlanDefinition is producted | ||
2. Example gaps are provided back to the BR&R team | 2. Example gaps are provided back to the BR&R team | ||
| − | Bonus point: | + | :Bonus point: |
1. Match the activities in the ODM to ProcedureRequests | 1. Match the activities in the ODM to ProcedureRequests | ||
Revision as of 17:31, 14 June 2018
Track Name
Clinical Research
Submitting WG/Project/Implementer Group
Biopharma FHIR Project Group
Justification
This track will continue to evaluate use of FHIR for clinical research of new biopharmaceutical experimental treatments, seeking 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. Plans for this connection include participation from at least 3 clinical data system implementers and pharmaceutical companies. 3 detailed use case scenarios will be proposed, 2 of which build on prior work at previous connectathons, and one exploring a new area for writing back with updates to clinical data from a clinical system. This work will inform development of profiles and IGs to support clinical research using FHIR, which will likely inform projects of the BR&R workgroup.
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. 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
Geoff Low, Medidata; Wayne Kubick, HL7
See Connectathon_Track_Lead_Responsibilities
Expected participants
Medidata, UCB, Parexel
Roles
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.
FHIR Server
Supports a FHIR API which can respond to requests from a clinical research FHIR clinical research client.
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.
Clinical Trial Designer
Clinical Trial Designer[edit] Identifies data relevant to research studies that may be collected from EHRs . 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 send to the EHR for keeping EHR and study databases in sync.
Data Collector
Queries API to identify patients by Study and Subject identifiers to pull EHR data for demographics, medications, observation and Condition data that maps directly to variables on eCRF. Provides data generated by patients to add to study databases or EHRs.
Scenarios
Scenario 1: Adoption of the LAB Model using FHIR Resources
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. 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). 2. Convert extracted resource data into CDISC LAB data structures or alternative standard data structures (such as ODM-XML) as an intermediate step before submission and ingest into a Sponsor clinical data system (note, Sponsor data ingest is out of scope for this use case). Goal is to prove out the transformation of FHIR resources into a common Pharmaceutical/Sponsor data structure. 3. Use the FHIR R4 bulk data mechanism to extract all relevant FHIR resource records for the three patients in (1a) and convert them CDISC-LABLDM/XML as in (1b). Goal is to prove out use of the bulk data transfer mechanism in the context of lab results.
- Precondition:
1. At least 3 patients are enrolled as a ResearchSubject for a ResearchStudy with available lab data. 2. Source FHIR server that implements the following resources -- Location, Organization, Practitioner, Observation, Encounter, Specimen, Research Subject, Study, Patient, Procedure 3. 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. 4. Data model mapping the FHIR resources to CDISC-LAB, SDTM of CDASH LB domain (to be supplied). 5. An example of code to transform FHIR resources into CDISC-LAB/XML (to be supplied).
- Success Criteria:
1. Data from the listed FHIR resources can be extracted from the test FHIR server. 2. Extracted data can be converted into the appropriate format (e.g., CDISC-LAB/XML) to allow import into a clinical study database. 3. Data transfer mechanism demonstrated for at least 30 patient lab results as CDISC-LAB/XML output
- Bonus points:
1. Explore use of analytics such as R on FHIR for trend analysis of lab data. 2. Establish what happens with not complete records (a la Real Lab Data Files)
Scenario 2: Facilitating Real World Evidence Studies using FHIR resources
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:
1. Build or use models to bridge between FHIR resources and data formats/structures used in clinical research. Research Systems. Build on/Validate the work of the CDISC E2C project for core clinical domains (DM, VS, MH, HO). Identify gaps in the bridging models. 2. Create a triggering event that recognizes when new data is entered in EHR for a current ResearchSubject after patient encounters, and notify subscribing parties of the event. 3. 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:
1. A FHIR server supporting SMART-on-FHIR, CDS Hooks or Subscription Resource 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: 1. 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 points: 1. Use the Subscription resource or CDS Hooks to trigger update after new patient encounter is recorded. 2. Import patient-reported data from a SMART-on-FHIR app.
Scenario 3: Exploring the AdverseEvent resource for communication of Adverse Events in a Clinical Study
The AdverseEvent resource is a draft resource in the FHIR standard. It presents a useful resource for clinical investigations; the semantics of an Adverse Event in a clinical study are such that it can be difficult to align with other resources - examples of possible mappings have included AllergyIntolerance, Condition (Problem), ClinicalImpression, DetectedIssue, DiagnosticReport. Use of the AdverseEvent resource will be a useful mechanism for the standardized representation of Adverse Event data for the purposes of exchange (and reporting).
- Precondition:
1. An EHR system supporting the AdverseEvent Resource 2. An EHR system with Patient Data that may be associated with an AdverseEvent 3. CLINFHIR to construct resources
- Action:
1. Construct an AdverseEvent Resource for a sample non-Serious Adverse Event 2. Construct an AdverseEvent Resource for a sample serious Adverse Event
- Success Criteria:
1. Two sample AdverseEvent resources are provided 2. Example gaps are provided back to the BR&R team 3. Goal is to work towards developing and refining a healthcare-standard FHIR Resource data model for expressing Adverse Events; i.e., the data model is the key deliverable, not the code
- Bonus points:
1. Map a sample ICG E2B message structure or a CDISC AE record to an AdverseEvent resource
Scenario 3: Matching an ODM based Schedule of Activities to a PlanDefinition
Scheduling can be a difficult problem for patients, investigators and sites in a clinical trial. Many EHR systems have built-in calendaring systems that incorporate patient, staff and facilities management; this is often provided on site and via mobile apps. If a participant in a clinical study were able to incorporate their study activities into their existing calendar then that would aid them in managing their time (eg fasting before a blood test, completing an assigned questionnaire, etc) The CarePlan resource summarises the activities a site will undertake in the delivery of care to the patient for one or more conditions. The activities in a CarePlan are defined abstractly in the PlanDefinition resource. If it were possible to take the Schedule of Activities from the protocol and convert it to a PlanDefinition then it would be possible to use this artifice to integrate with the patient calendar. For the purposes of simplicity we will use the CDISC ODM as our source model from which to build the PlanDefinition
- Precondition:
1. An EHR system supporting the PlanDefinition and CarePlan Resource 2. An EHR system with Patient Data that may be associated with an AdverseEvent 3. A simple schedule of activities (as an ODM metadata file)
- Action:
1. Develop a PlanDefinition that matches the ODM 2. Create a CarePlan for a Patient based on the PlanDefinition
- Success Criteria:
1. A functional PlanDefinition is producted 2. Example gaps are provided back to the BR&R team
- Bonus point:
1. Match the activities in the ODM to ProcedureRequests
