Skip to content

Home

Jump to bottom
Ken Gersing edited this page Apr 25, 2019 · 43 revisions

Title:

Pluri-Potent FHIR Common Data Model (Clinical Adapter)

Proposal:

Use the FHIR Resource model to enhance the reuse of Real-World Data (RWD):

  1. Query Portal: Universal Query Builder can create a query that can run against all common data models. The query builder creates a “FHIR Query “ using HL7 CQL engine.
  2. Query Management tool packages “FHIR query” and is security transported to data partners
  3. Deidentified FHIR Server Appliance is created behind the data partners fire wall
    • Clinical Data Warehouse is de-identified prior to being placed on the FHIR Server
    • FHIR Server pulls de-identified form clinical data warehouse using HL7’s FHIR Bulk
  4. “FHIR Query” is run against institutional research data warehouse
    • De-identified FHIR Server Appliance
    • CDM (PCORI, OMOP, ACT/i2b2, Sentinel)
  5. “FHIR Query” results are securely transported to the aggregation server
  6. Aggregated query results exported in multiple formats for different use cases
    • FDA: Direct submission of RWD as an STDM data submission
    • CDC: Surveillance Data to monitor cases of communicable diseases
    • NIH: Investigative resource for scientific discovery and further analysis

Clinical Adapter Overview

Objective:

Develop a prototype that uses the HL7 FHIR Resource model as the “Lingua Franca” of the data flow between de-identified real-world data from EHR/EMR for secondary uses.

  1. Reduce loss of data integrity and granularity (see FHIR vs CDM image),
  2. Decrease complexity and eliminate need to build separate queries for each data model and proprietary database for all existing common data models (CDMS)
  3. Reduce CDM data mapping curation and maintenance by implementing HL7 FHIR standards.

CDM-Vs-FHIR

Workflow:

  1. Investigator(s) will use existing CDMH tools to build queries.
  2. Queries will be transformed into a corresponding set of FHIR Queries (API calls)
  3. The FHIR queries will be securely distributed to data partners, who will execute the search against the institutions de-identified FHIR-enabled server.
  4. The results (de-identified) will be securely transported back a FHIR Results Staging Server.
  5. Results can be exported in multiple formats for different use cases

Initial Adapter Agency Assignments

Phase I: Common Data Model Harmonization (CDMH) Project

The Clinical-Adapter project uses assets generated from the initial project CDMH, funded by PCORITF. That project focused on data harmonization of the four Common Data Models (CDM) (PCORI, OMOP, ACT/i2b2, Sentinel). In that project four CDM specific outbound queries were generated from each CDMH query. Inbound results from the four CDMs were transformed into a single harmonized model where aggregate results could be visualized and / or exported as CSV and CDISC SDTM files.

Phase I Deliverables

Architecture Design and Software development:

  • Query Builder
  • Query Transformer - single query to 4 CDM specific queries
  • CDMH Database (Based on a subset of BRIDG)
  • CDMH Reference Database
  • Results Receipt and Ingestion
  • CDSC SDTM file format

Transformational Mapping:

  • CDMs-to-BRIDG mapping
  • CDMH/BRIDG-to-SDTM mapping
  • Controlled Terminologies
  • RxNorm to NDC

Phase II FHIR Common Data Model

Step 1 Create CQL Query Builder: Investigator builds query and forwards to data partners

  1. Investigator uses builds a FHIR Query Builder Builder that produces a FHIR API call to define the query A. Proposed Solution CDL 1. text editor for complex queries 2. CDS Authoring tool for a UI driven query builder

Query Tool Options

  1. Provide query to data partner(s) by placing it in a folder using the appropriate secure protocol (e.g., TLS, sFTP) )
  2. Authentication/Authorization to all tools will be based on NCATS federated Services

Step 2 Process FHIR Query: Local Institution/Data partners processes FHIR query

  1. The local institution processes the FHIR query via one of the following options;
  2. Creation of a de-identified FHIR Research data warehouse. A Bulk FHIR data request is run against the institution’s identified data warehouse pulling all data into a FHIR de-identified server (https://github.com/smart-on-fhir/fhir-bulk-data-docs/blob/master/export.md). The bulk load or the FHIR data warehouse must be repeated on a regular basis (~ every night) in order to update the information.
  3. The de-identified result set is encrypted and transmitted using the FHIR Bulk Data Export standard or analogous approach such as sFTP, etc. See: https://www.hl7.org/documentcenter/public_temp_55017B08-1C23-BA17-0C6E8EAF09AE3EF0/calendarofevents/himss/2018/HL7%20FHIR%20Bulk%20Data%20API.pdf

Step 3 Build De-identification FHIR Server (Institutional Appliance)

  1. Create FHIR Server: The FHIR Server is an an appliance that sits behind the data partners fire wall.
  2. De-identified Service of Identified Clinical Data Warehouse: The De-identification Process needs to be built to populate the a HIPPA / Safe Harbor compliant de-identification server.
  3. The FHIR Server - is populated using HL7 FHIR Bulk. Must confirm that institutional EMR support FHIR Search API (http://www.hl7.org/fhir/search.html) and/or the FHIR Bulk Data API (https://github.com/smart-on-fhir/fhir-bulk-data-docs). Note initial pull will be limited to ONC US core data sets

Step 4 Create Result Export Formats: CDISC SDTM, FHIR, CSV

  1. CDISC SDTM: Mapping of FHIR Query Results to BRIDG/CDMH for FDA
    • BRIDG-to-FHIR mappings were created for the first phase of the CDMH project and should be used to inform the FHIR to BRIDG mapping.
  2. CSV/FHIR Export for Investigators
    • CSV/FHIR format export is a general export format more that can imported into common tools like excel or SAS or R for further analysis

Step 5 Build Common Data Model to FHIR Adapter

Common data model providers represent a very large investment by the federal government. In addition, they have established networks and strong relationships to large data partners. Forging alliances with the CDM providers, while at the same time helping them transition to newer technologies, would be a good use of resources.

  1. Build a CDM-specific ‘adapters’ The Adapter pulls data from the original CDM into a the de-identified FHIR Server. The advantages for the CDM partners are that it lowers their own multiple query creation burden because now their propriety models can be accessed through a single FHIR API call. In addition, for institution that do not have a de-identified FHIR server their support of one of the existing CDMs can be leveraged.
  2. FHIR Query: Once data from the CDMs is pulled into the FHIR server the FHIR query can be run against it

Step 6 Distribute Local Institution Manager / Agent

  1. The “Agent” is a local tool that resides on the institution’s FHIR server and is needed because each institution will want dashboard where they control the local processing of federated data calls.
  2. The “Agent” also contains local business rule, ETL functionality included access to the FHIR Terminology Server.

Proposed Agent Functionality (still in the planning phase.)
• Local Institution Dashboard to manage query’s and outbound data • Local ETL for institution specific data values • Exe. For creation of FHIR server and de-identification process • Business Rules for data access

Appendix

HL7 relevant projects

  1. Synthetic Data Sets/ FHIR servers: http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing
  2. Argonaut Project http://argonautwiki.hl7.org/index.php?title=Main_Page
  3. Smart on FHIR: https://smarthealthit.org/

Other HL7 Projects

Touchstone NLP project: https://www.healthit.gov/techlab/ipg/node/4/submission/156 Clinical Decision support and CDS hooks: https://cds-hooks.org/quickstart/ Terminology Services: https://www.hl7.org/fhir/terminology-service.html

CQL Resources

https://github.com/DBCG/cql_runner https://cql.hl7.org/ https://github.com/esacinc/CQL-Formatting-and-Usage-Wiki/wiki “Cooking with CQL” on GitHub: https://github.com/esacinc/CQL-Formatting-and-Usage-Wiki/tree/master/Source/Cooking%20With%20CQL Educational presentations for CQL: https://ecqi.healthit.gov/cql-clinical-quality-language#quicktabs-tabs_cql3

AHRQ’s: Clinical Decision Support (CDS) Connect

https://cds.ahrq.gov/cdsconnect

CQL Specification:

https://cql.hl7.org/

Github links:

https://github.com/cqframework/cql-execution https://github.com/dbcg/cql_engine https://github.com/DBCG/cqf-ruler https://github.com/cqframework/healthedecisions https://github.com/DBCG/cql_runner

eCQI Resource Center:

http://ecqi.healthit.gov/cql

CQL Formatting and Usage Wiki:

https://github.com/esacinc/CQL-Formatting-and-Usage-Wiki/wiki

FHIR-based examples

HEDIS Measures: https://github.com/cqframework/hedis-ig

CMS Measures: https://github.com/cqframework/cqf-measures

Opioid Decision Support: https://github.com/cqframework/opioid-cds

De-identification Resources

NLP Deidentification: MITRE MIST (MITRE Identity Scrubber Toolkit) https://www.mitre.org/research/technology-transfer/open-source-software/mist-mitre-identity-scrubber-toolkit-version-13

Clone this wiki locally