RENCI / pds

PDS application (tx-router plugin)
MIT License
1 stars 0 forks source link

[Feature] Use OMOP to define clinical variables and selectors #257

Open krobasky opened 3 years ago

krobasky commented 3 years ago

What problem(s) do you aim to solve? We need to specify the list of clinical variables supported for pds.

What feature solves it and why? We raised the idea in the #pd slack channel on Nov 2 to use the OMOP CDM, and here is the more detailed plan:

If we just use the OMOP common data model, we don't have to specify the clinical variables because the OHDSI consortium has done it for us, including the efforts of many over many days.

What implementation(s) do you suggest? The following steps are required:

  1. Copy pdspi-mapper-parallex-example repo to pdspi-mapper-omop and use the OMOP schema to create a schema.
  2. When a patient is requested from the mapper, look to see if they are in the schema, and if not, insert a patient's fhir data into the schema.
  3. Add the capacity to age-out patients on a regular interval. That is, the following requirements must be met: a. A sys admin must be able to set an interval using cron-like notation to remove all the patient data every day at a certain hour so that patient data are refreshed daily. b. The admin must also be able to disable any refresh in order to support static, data pull for a bounded study. c. The admin must be able to remove any interval so the patient is refreshed on every query, such is the case in the clinic. This translation + guidance calculatio must complete in realtime, so likely the database will need to be subverted in that case.
  4. Copy pdspi-fhir-example to pdspi-fhir-omop, and instead of ingesting with CAMP-FHIR, use OMOP-on-FHIR to ingest OMOP to FHIR. Serve the patients one record as before.
  5. Update pds-release/modules with any new repos, removing any obsolete ones.
  6. Publish and share the results with OHDSI group, possibly the FHIR working group will have the most interest.

Break the steps above into stand-alone tickets that can be diveded among multiple developers, Refer to this ticket in each new ticket.

Anything else? Two items to consider while closing this ticket:

  1. These elements will also define selectors. Recall, selectors are used to communicate the clinical path used to select particular plugin; for example, a selector for _developmentstage may be pre-populated by the client/EHR softare based on patient age, with values (pediatric,adult,geriatric), while also allowing the clinician to override chronological age as needed. Or a clinician's path through the EHR software may cause the software to pre-populate a drug selector to gentamicin. Work with clinical champions and EHR software integrators (ISD) will help to define the selectors. Modify this ticket and add new tickets to address selector needs as they come up.
  2. OMOP is a common data model for evidence generation, but The Common Data Model Harmonization (CDMH) project is led by FDA in collaboration with NIH and HHS/Office of the National Coordinator for Health Information Technology (ONC) and aims to harmonize CDMs from the following projects: Sentinel, PCORnet, OHDSI(OMOP) and i2b2-ACT. (see HHS 2018 annual report, in the section of "Harmonization of Various Common Data Models and Open Standards for Evidence Generation"). Mitra Rocca writes that in addition to the cdm harmonization effort, the goal is to be able to "leverage open, consensus-based standards (e.g. HL7 FHIR and Clinical Data Interchange Standards Consortium (CDISC) standards). In this project, we leveraged the Biomedical Research Integrated Domain Group (BRIDG 3) as the intermediary model and mapped the 4 CDMs to the BRIDG model." This is similar to the PDS approach, whereas CDMH focuses on data modelling and PDS focuses on architecting and designing the software and cyberinfrastructure. At some point, the NIH CDE Repository and (NCI) Cancer Data Standards Registry and Repository ((caDSR) may be helpful in dovetailing this OMOP work into the CDMH.

Some other useful resources: