OMOP Quality Measurement 23 March 2022

Demo: Jack Brewster from IQVIA quick demo to show how to import VSAC into Atlas automatically using R packages. 

Jack Brewster provided a demonstration of work to automate the import of VSAC value sets starting with a CSV file and using R packages, process all eCQM value set packages in under 1 hour without any performance issues on the Atlas production environment. This capability is a significant improvement on prior demonstrations of manual mapping to the OMOP concept codes. There were only 2 value set concepts that did not map, the hospital location codes (ICU), for which there is no corresponding concept in OMOP. There were no ambiguous mappings since all involve specific terminology code (SNOMED, LOINC, ICD, CPT, etc.) to OMOP concept codes. The process did not use the VSAC FHIR API but it could be considered as part of the methodology; this effort started with the CSV output from VSAC. A number of participants indicated interest in the code for reuse, and Jack Brewster agreed to make it available for others to use.

Refer to the recording of the discussion for specific details.  Some specific points in the discussion:

• Gravity HL7 Accelerator value sets are part of the Social Determinants of Health (SDOH) content referenced by the US Clinical Data for Interoperability (USCDI) version 2 that is now being incorporated into US FHIR Core. Davera Gabriel indicated some effort to work with these value sets and that they are not yet incorporated into OMOP. She referenced Jake Gillberg (gillberg@ohdsi.org) as the lead of the OHDSI Health Equity Working Group for such efforts.
• The group had some discussion about licensing permission for use of terminologies in the VSAC requires an NLM license to access any content. Kristin Kostka noted some work to address licensing, especially around SNOMED already exists in OHDSI and may be applied. 

See the recording (referenced at the top of this page) for the detailed conversation and the demonstration.

Review of proposed Oncology FHIR-to-OMOP process for May Connectathon to provide context (2022-05 FHIR-OMOP Oncology)

Discussion of OMOP-Atlas to FHIR-CQL conversion

The use case this dQM/OMOP group has designed is the reverse of the FHIR-OMOP Oncology group design, basically requesting all patients who meet criteria for a phenotype defined in Atlas with OMOP and SQL. In the dQM-OMOP workflow, the patients are not known and the retrieve request is to provide all patients meeting criteria for the cohort.

Thomas White (MedStar) presented another use case similar to the "gaps in care" approach addressed in Data Exchange for Quality Measures (DEQM), except that all patients meeting the cohort are known in an OMOP data set. The use case uses bulk query to obtain all new data for specific resources for just that patient set (known Atlas-based cohorts) and subsequently uses the retrieved data to determine which patients the existing dataset have gaps in care that can be addressed. Currently FHIR bulk query is not available in all EHRs, it is required by the end of 2022.  He noted that the existing dQDM-OMOP use case (I.e., provide all patients meeting a cohort definition) is still critically important; the gaps-in-care use case in an additional requirement for OMOP to FHIR efforts.

Paul Denning provided a link to the FHIR Quality Measure IG (the build version to be published very soon: http://build.fhir.org/ig/HL7/cqf-measures/capabilities.html. The directory for published versions is located at http://hl7.org/fhir/us/cqfmeasures/history.html (this new publication should be version 4.1.0).

Discussion about potential synthetic patient set in (a) FHIR, (b) OMOP

Terminology:

• Infrastructure:
  • VSAC value sets and FHIR API
  • Programmatic methodology for extracting VSAC value sets and mapping terms to OMOP terminology (current manual upload)
  • Recommendations for handling concepts missing from OMOP (such as examples Qi experienced for HSLOC and CDC Race and Ethnicity Codes)
  • Subscription or periodic requery when VSAC updates the terminology
• Participants:
  • TBD

Expression:

• Infrastructure:
  • Atlas - SQL capability exists - need Atlas SQL instance for pilot testing
  • FHIR - CQL capability exists - need FHIR CQL instance for pilot testing
  • Expression conversion (what infrastructure is required here):
    • Atlas phenotype to FHIR cohort conversion
    • FHIR cohort expression with CQL to Atlas phenotype conversion
• Participants:
  • TBD

Data Query and Response:

• Infrastructure:
  • Atlas data store for synthetic patients
  • FHIR data store for synthetic patients
  • Query capability for Atlas patients and retrieve of OMOP cohort(s)
  • Query capability for FHIR patients and retrieve of FHIR synthetic cohort(s)
  • Structure to compare OMOP cohort with FHIR cohort, identify concordance and challenges
• Participants:
  • TBD

Next Steps from March 9:

• Continue to build on Project Scope Statement PSS-1981 such that it can be progressed.
• Further discussions with Vulcan to understand potential Accelerator support.
• At this point, if folks want to move forward with the project and/or Connectathon piloting, we definitely need people to step up to do the work to define the elements, to create the prototypes, and to pilot them.

abdullah.rafiqi@esacinc.com

Ben Hamlin

NCQA

hamlin@ncqa.org

Floyd Eisenberg

iParsimony, LLC

FEisenberg@iParsimony.com

Telligen

SRankins@telligen.com