DTSoF

Appearance

DigitalTWINs on FHIR ​

Digital Twins on FHIR (DToF) is a conceptual FHIR based framework to standardise key concepts, tools and data within the context of a workflow. In this sense a workflow comprises one or more steps where certain (software) tools take relevant data (e.g. from EHR) and feed into computational models (of human physiology & anatomy) to generate derived data which may be used to predict disease progression or treatment effects. We are using FHIR to make the data and models FAIR (findable, accessible, interoperable, and reusable).

DigitalTWINs on FHIR enables users to store patients' hospital EHR data and research data (such as clinical descriptions, mathematical models, and medical images). The foundational concept of DigitalTWINs on FHIR version 1 is the use of FHIR R4 resources to build the DigitalTWINs FHIR Specification. This specification is divided into four parts: Primary Measurements, Workflow, Workflow Tools, and Workflow Tool Process.

  • Primary Measurements: Raw EHR data from hospitals or research institutes.
  • Workflow: Defines the steps, actions, inputs, and outputs of a research study.
  • Workflow Tools: Tools used in each step or action of the workflow.
  • Workflow Tool Process: Generated by executing a tool or step within a workflow.

The core idea behind DigitalTWINs on FHIR is to develop a digital twin system for patients, clinicians, and researchers.

  • Patients can view historical medical reports and predictions of disease progression.
  • Clinicians can access patient history report data and review predicted clinical reports generated by researchers’ workflows.
  • Researchers can create patient cohorts and use their raw EHR data as input for their studies.

Version 1 ​

image-20241028171850455

FHIR version: R4

  • Finding all primary measurements for a patient.
  • Find which workflow, tool, and primary data was used to generate a specific derived measurement observation.
  • Find all tools and models used by a workflow and their workflow tool processes.
  • Find inputs and outputs of a given tool in a workflow.

Tutorials ​

Development ​

Discussion ​

  • Version control of Task (Workflow tool process)
    • If a researcher run a same workflow tool for a same patient's measurements, it is hard to find their relationship
      • Scenario 1 ( run different workflow tool): Researcher A run breast workflow tool A for patient A with measurements A. Then run breast workflow tool B for patient A with measurements B.
        • This situation is very simple, we can search the workflow tool process by patient's id, dataset'id, researcher'id, workflow'id and workflow tool's id , and then use measurements A and measurements B or their title to distinguish the workflow tool process A and workflow tool process B. Because the measurements should be as a reference in workflow tool process input.
      • Scenario 2 (run same workflow tool for same patient' measurements): Researcher A run breast workflow tool A for patient A with measurements A twice.
        • This situation is a little bit tricky, but we still can solve it by execution time. The basic solution is same to above, but this time we will receive two almost same workflow tool process with same title, input measurements referece, dataset's reference researcher reference, patient reference, workflow reference, workflow tool reference. The differences between them are uuid, output observation reference, execution time . So, once we find these two workflow tool process via forward way (dataset -> patient -> workflow -> workflow tool -> workflow tool process), we cannot distinguish them by title or measurements , but need title or measurements to get them first and then we can distinguish them by their execution time.
      • Scenario 3 (run same workflow tool for same patient): Researcher A run breast workflow tool A for patient A without measurements A twice.
        • This situation is tricky, because some workflow tool don't have EHR data as their input. So we cannot use measurements now, and when we search workflow tool process via forward way we will get all workflow tools' processes. At this stage we also can use title to get these two workflow tool process and then distinguish them by their execution time.
      • Conclusion: As for the Task (workflow tool process), we can use their execution time for the version control.
  • Image format
    • Currently, we are using ImagingStudy to store one patient's Dicom MRI data. But in some tools (e.g, tumour position and extent report App) they need other image format, such as NRRD. Therefore, when we want to annotate one patient's image via tumour position and extent report App , we cannot sent the MRIs' endpoint directly to the target App, but we need to do below steps:
      • Send the patient ImageStudy's endpoint uuid to backend, and get the Dicom images
      • Convert the Dicom MRIs to NRRD format
      • Send the images to tumour position and extent report App
    • Time consuming
      • Request the images from PACs
      • Convert Dicom to NRRD
      • Send NRRD to the target tool
  • Patient cohorts
    • Missing patients research cohorts

Version 2 ​

image-20241028204424450

FHIR version: R5

Search ​

  • Finding all primary measurements for a patient. - No
  • Find which workflow, tool, and primary data was used to generate a specific derived measurement observation. - Conditional Yes, (only if the workflow tool process has input/output EHR data.)
  • Find all tools and models used by a workflow and their workflow tool processes. - Yes
  • Find inputs and outputs of a given tool in a workflow. - No (there is no links between workflow tool process and workflow.)

Discussion ​

  • What exactly information that we want to store for workflow, workflow tool and workflow tool process?
  • We are using PlanDefinition to store the workflow information, the PlanDefinition has already fields to store workflow title, description, actions/steps, action's input/output, what information we want to store in ActivityDefinition?
  • The DeviceDefinition we are used to store the workflow tool information, so the Device is the workflow tool process? We can save the execution time in manufactureDate , but here is a issue, consider this scenario if two different workflow use the same workflow tool and they run the same patient's measurements and same dataset, how can we distinguish workflow tool processes belong to which workflow by search workflow tool process directly?
  • Under this architecture, we cannot find the relationship between workflow tool process and patient
    • Patient can be in different ResearchStudy
    • The patient primary measurements may be used in same workflow actions (workflow tools) as input data
    • Some workflow tool may not have EHR input/output data, so their workflow tool process don't have reference to result observation and primary observation.
  • Under this architecture, we cannot find the relationship between workflow tool process and ResearchStudy
    • This diagram is using ResearchStudy level to connect workflow not in Patient level
      • We cannot find a patient's workflow tool process precisely, because its under ResearchStudy level, we only search like this:
        • From ResearchStudy
          • Find the PlanDefinition via protocol
          • Find all the patients belong to this ResearchStudy
          • Find workflow tools belong to this PlanDefinition (workflow)
          • Then choose one DeviceDefinition (workflow tool) find all Devices (workflow tool processes) , Notice: all Devices here means the Device may generate from other ResearchStudy (dataset) and PlanDefinition (workflow) , because there is no constraints/reference among Device (workflow tool process), ResearchStudy (dataset), PlanDefinition (workflow).
            • We may find some relationship between Device (workflow tool process)'s reslut Observations and Primary Measurements, But we cannot guarantee all Device has EHR input/output data.
        • From PlanDefinition
          • We can find a PlanDefintion (workflow)'s ResearchStudy by search protocol in ResearchStudy
          • Then we will meet the same issue.