Table of Contents

Submitting Work Group

Public Health Work Group (PHWG)

Communication Channels

Scheduled discussions (Electronic Case Reporting Related)

Scheduled Discussions (Birth and Fetal Death Reporting)

Justification and Objectives

Public health includes a number of use cases involving the exchange of information between Electronic Health Records (EHRs) in clinical care and governmental Public Health Agencies (PHAs) or other extra-clinical organizations. The use cases differ, but they frequently have a number of common design elements as well. A major point of emphasis is seeing that these common design elements are broadly shared to minimize divergent requests of clinical care and minimize provider burden. Some participant use cases have FHIR ballots in development or in-process that they seek to test with partners. Other participants will focus on fleshing out technical elements of a common framework for reporting from EHRs.

In this Connectathon, the public health track will include several scenarios (scenario lead):

FHIR Versions

4.0.1,  3.0.1, and 2.X

Clinical input requested

Clinical participation is always sought and welcome in the Public Health Track

Related tracks

To be determined

Public Health Track Leads

John Loonsk (john.loonsk@jhu.edu)

Sarah Gaunt (sarah.gaunt@lantanagroup.com)

Cindy Bush (pdz1@cdc.gov)

Rick Geimer (Rick.Geimer@lantanagroup.com)

Expected participants

Specific participant lists are still developing, but previous participants in this track have included:

  • Association of Public Health Laboratories
  • Centers for Disease Control and Prevention
    • National Center for Health Statistics
    • National Center for Chronic Disease Prevention and Health Promotion
    • Center for Surveillance, Epidemiology, and Laboratory Services
  • California Department of Public Health
  • Carradora
  • District of Columbia Department of Health
  • Dynamic Content Group
  • Georgia Department of Public Health
  • Georgia Tech Research Institute
  • Hi3 Solutions
  • Lantana Consulting Group
  • Medical University of South Carolina
  • Michigan Department of Health and Human Services
  • MITRE
  • National Association for Public Health Statistics and Information Systems
  • New Hampshire Division of Vital Records Administration
  • New York State Department of Health
  • Northrup Grumman
  • Utah Department of Health

Scenarios

Report Out

Electronic Case Reporting

eCR Now FHIR App

Goal

Support needs of moving into vendor production

Notable Achievements

  • Refining FHIR R4 queries to CDA eICR output

  • Progressed FHIR messaging bundle output and submission

  • Continued work on SMART on FHIR alternative launch implementations for background services app

Next Steps

  • Production implementation by several large EHR vendors

  • Nearly automated consumption of eRSD in production

eCR electronic Reporting and Surveillance Distribution (eRSD)

Goal

Advance eRSD specification to streamline electronic implementation and include CQL for advanced eICR filtering in healthcare

Notable Achievements

  • Refined eRSD planDefintion specification for:
    • EHR triggering logic
    • Filtering CQL inclusion
  • Supported COVID-19 specific existing eRSD testing and use

Next Steps

HL7 eCR (eICR, RR, eRSD) specification update

MedMorph / eCR

Notable Achievements

  • Demonstrated Data Submission Workflow via Trusted Third Party (eHealth Exchange Hub POC) using FHIR
    • MedMorph has multiple workflows, however the focus was on the Data Submission workflow for this connectathon
    • APHL has a project to stand up fully compliant FHIR Services for receiving Electronic Case Reports which is similar to the MedMorph Data Submission workflow.
    • Payloads used for testing were from the eICR FHIR IG


  • Identified defects in the PHA Receiver/Validator of the submitted reports

Birth & Fetal Death Reporting (BFDR)

Goals

  • Test the draft version of the Birth and Fetal Death Reporting (BFDR) FHIR Implementation Guide
  • Test and validate BFDR FHIR Bundles generated by EBRS
  • Discuss/determine issues with live birth and fetal death data availability

  • Review Hospital Business Practice and EMR interface opportunities and constraints to query or ‘push’ data needed to populate the Facilities Worksheet

Participants

  • Georgia Department of Public Health
    • Genesis Systems
  • Michigan Department of Health and Human Services
    • Altarum
  • Utah Department of Health (Utah DoH Report_BFDR)
  • Epic
  • NCHS
  • Lantana Consulting Group

Notable Achievements

  • Workflows tested:
    • EHR to Jurisdictional Vital Records Office Electronic Birth Registration System (EBRS) (EMR FHIR query by EBRS transform to BFDR FHIR Document Bundle)
      • Tested generation, validation, and consumption of FHIR Bundles for both Live Birth and Fetal Death 
        • Working through validation errors (started with close to 80 errors in some cases, down to 0 for Live Birth now)
        • Provided feedback to update profiles within the BFDR FHIR IG
      • Genesis is working with EPIC on connect to SMART on FHIR app to enable querying EHR
        • Currently running into secure URL issues, but working through these issues (SOLVED)
        • Running in an issue with value set value (update)
      • Discussion on EHR data availability
        • Epic working through data elements to determine data availability
        • Where data isn’t currently exposed, EPIC working on exposing data
      • Discussion on Query vs PUSH method for birth and fetal death data
    • Jurisdictional Vital Records Office: EBRS to EBRS
      • Currently manually testing this flow sending Document Bundles over email
      • Utah to Georgia
        • Georgia was able to consume Document
        • Iterations of:
          • Georgia flagged issues
          • Utah update the code and re-sent Document
      • Georgia to Utah
        • issues arose with Document consumption due to the API being dependent on not-required meta.profile fields
        • work is now underway to adjust the API to use references to traverse the document instead of the meta.profiles - the size of this change is non-trivial, and would not be completed in time to properly consume this document before the end of the Connectathon

Discovered Issues / Questions

  • Problematic fields due to reasons such as some data not currently available/sparsely populated etc.:
    • SHALL fields: Zip code of delivery, certifier's name, date certified, facility id (NPI), attendant's NPI, date report completed,
    • SHOULD fields: mailing address same as residence indicator, principal source of payment for delivery
    • MAY fields: father's education, planned to deliver at home, date of last other pregnancy outcome, person providing info for mother's worksheet, relationship of person providing info for mother's worksheet, SSN request signature
  • Some data not currently exposed in the EHR
  • Validation errors
  • Secure URL issues
  • Implementation Guide issues
  • FHIR Validator issues
    • the validator would throw an error when attempting to process a document that contained a reference to a resource that did not exist in the document. Specifically, our document included a Reference to a plurality observation in a fetal death document, but no actual plurality Observation was included in the document
  • FHIR Validator terminology server connection issues
    • At various points of the day, the validator would stop connecting to the terminology server and would not process – this may have been due to local connection issues, or the terminology server having problems.

Screenshots

Georgia Department of Public Health/Genesis:

Utah DoH:

Live Birth Validation first attempt (74 errors):

These errors were caused by a wide variety of issues with the document; structural issues, missing references, missing IDs, and other issues largely based on the structure of a FHIR document. Following is a set of screenshots showing the validator’s progress as the errors were tackled one at a time: 

After a bit more validation and ensuring that the data isn’t including empty fields, has the needed references, required IDs, required URLs, etc., we were able to reduce the errors to a single error which we were ultimately unable to determine the cause of. Sarah mentioned that this error may be an IG issue.

Fetal Death Validation:

First attempt (49 errors):

(Sometimes we would increase the number of errors when trying to fix them!)

Next Steps

  • Incorporate changes into BFDR Implementation Guide in preparation for ballot in January with resolutions to issues identified during testing
  • Continue to work with states and vendors
  • Provide input to USCDI for BFDR and Birth Defects related observations (e.g. apgar scores, prenatal care observations, pregnancy related observations), since this FHIR resource covers such a broad range of concepts

Birth Defects Reporting (BDR)

Goals

The Birth Defect Reporting (Public Health) track was looking for feedback on the draft FHIR IG (https://build.fhir.org/ig/HL7/fhir-birthdefectsreporting-ig/index.html). We are looking for feedback on the clinical content of the IG, the organization of the FHIR resources and proposed use cases.

Participants

Altarum, State of Michigan, Epic, CDC (joint with Birth and Fetal Death)

Notable Achievements

We were able to meet with Epic (joint with the Birth and Fetal Death (Public Health) track) to learn more about what pregnancy/delivery related data Epic currently exposes via FHIR APIs. Epic also described their future approach for extending the data available to external sources such as Public Health. We discussed possible workflows for accessing data collected in the Epic EHR.

Discovered issues / questions

We were unable to connect with other EHR vendors to determine what data they currently expose.

Next Steps

  • Follow up with Epic to identify which data elements proposed by the IG are/are not collected within the EHR and determine which are currently accessible via FHIR API
  • Connect with other EHR vendors to get similar information on which data elements are collected and exposed via API
  • Continue to work with Public Health birth defect reporting programs to confirm the data content of the IG
  • Continue to work with the CDC MedMorph project to ensure that the reference architecture they are developing fits the birth defect reporting use case

Death Reporting (VRDR)

Goals:

Vital records death reporting is focused on adopting best practices for information exchange that lessen the burden on data providers (e.g., vital records offices, electronic health records, medical examiner and coroner offices, toxicology labs) while providing a seamlessly automated data feed to public health and public safety data requestors.  There are two use cases that will be tested. These use cases include Jurisdiction’s Electronic Death Registration System (EDRS) to National Center for Health Statistics (NCHS), and Medical Examiners’ / Coroners’ Case Management Systems (ME/C CMS) to EDRS workflows. A stretch goal scenario will also be tested. It will include that an EDRS send a FHIR Death Record to a Cancer Registry.

Participants:

  • Centers for Disease Control and Prevention
    • National Center for Health Statistics
  • Georgia Tech Research Institute
  • MITRE
  • eHealthsign
  • Hi3 Solutions
  • MDI log
  • VertiQ*
  • California Department of Public Health
    • Outcome healthcare
  • District of Columbia Department of Health*
    • Axiell*
  • Georgia Department of Public Health
    • Genesis
  • Michigan Department of Health and Human Services
    • Altarum
  • National Association for Public Health Statistics and Information Systems*
    • Ruvos*
  • New Hampshire Division of Vital Records Administration
    • CNSI
  • New Mexico Department of Health
    • VitalChek
  • New York State Department of Health
    • VitalChek
  • Utah Department of Health

*Not present at Connectathon. Participated in pre-Connectathon preparation and meetings.

Notable Achievements

  • Over 30 participants consisting of (7) vital records offices, (6) EDRS vendors, (1) ME/C CMS vendors
  • EDRS to NCHS
    • Tested bidirectional workflow including acknowledgment message and coded cause of death
    • Sent VRDR FHIR bundles to Cancer team endpoint
    • Validation of test messages provides feedback to update profiles within the VRDR FHIR IG
  • CMS to EDRS
    • Record from (GTRI) ME/C CMS server POSTED record to EDRS endpoint
    • ME/C CMS automated service of pushing a record to EDRS
    • Identified specific gaps during transmission of messages within two systems tested.

Next Steps

  • Vet business processes of using FHIR messaging and continue testing of death reporting scenarios at the NCHS Implementers’ Community Meeting – Developers track Septemeber 21, 22
  • Address gaps and issues found within the workflows or updates needed to be applied within the next release of the VRDR FHIR Implementation Guide
  • Changes to consider for future testing: parallel testing, submit IJE versus FHIR for comparison.

Screenshots

Examples of creating FHIR VRDR Bundles:

Georgia:

Utah:

VRDR FHIR bundles sent through Canary validation tool: https://github.com/nightingaleproject/canary

Examples of FHIR bundle sent to NCHS via STEVE:

Georgia:

Utah:

Examples of:

  • NCHS return coded cause of death to EDRS
  • ICD codes loaded into EDRS database

Georgia:

Utah:

New Hampshire test results:

1.EDRS receives the bundle

2. Successfully parses to the display

Discovered Issues

  • Identified gaps between two systems (EDRS to FHIR Server – CMS).
  • Identified custom jurisdictional ID issue within FHIR messaging header
  • Identified missing fields within return message (coded cause and race and ethnicity return message)

What next?

  • Continue testing of death reporting scenarios at the NCHS Implementers’ Community Meeting – Developers track September 21, 22
  • Assess gaps identified and update VRDR FHIR implementation guide based issues found during Connectathon.

Integrating Cancer Reporting

Goals

The objective of our track was to leverage Fast Healthcare Interoperability Resources (FHIR), specifically DocumentReference and Observation resources, as a standard to exchange and process the College of American Pathologists (CAP) electronic Cancer Checklists (eCC) in IHE Structured Data Capture (SDC) format. This will provide central cancer registries (CCRs) with another method to exchange cancer surveillance data with pathology laboratories utilizing both the push- and pull-based electronic data exchange mechanisms available in FHIR allowing for potential real-time reporting.

Participants

California Department of Public Health (CDPH), Canada Health Infoway, CDC, College of American Pathologists (CAP), The MITRE Corporation,  and mTuitive

Notable Achievements

We captured the data using IHE SDC forms stored as Base64 encoded attachments inside DocumentReferences with relevant metadata on the forms. Those forms can be transformed into FHIR Observations using the IHE SDC to FHIR Parser created by Canada Health Infoway. This parser was hosted as a cloud based service by Infoway where actors could submit their IHE SDC forms for transformation into a FHIR Transaction Bundle containing a Patient, a DocumentReference with a Base64 encoded SDC form, and the generated Observations. The Parser leveraged the HAPI Library in order to communicate with other FHIR servers.

In May 2020, we had issues knowing who created and submitted a Bundle to a specific endpoint. We were able to identify all of the resources appropriately, but not the Message or Transaction Bundle itself. This Connectathon, our track attempted to use the Transaction Bundle with an X-Provenance Header in order to remedy this, however, we found that not all servers were able to read and process the Provenance from the header. Effectively, our track has identified a need for a Provenance that can target a Bundle. 2 potential approaches are putting a Bundle inside a Bundle with the Parent bundle containing a Provenance that targets the child bundle, or using a FHIR Document Bundle with a Composition. The Parent-Child Bundle does not seem to be consistently supported or specified, and the FHIR Document is immutable, and some of the DocumentReferences may require updates or addendums to be added to the attachments (e.g. updated lab results). Updates a strong feature of our use case, that we aim to explore more in a future connectathon.

Inside these bundles it makes sense to include DocumentReferences and Observations with other relevant resources to our use case, such as Patients, Practitioners, Locations, Organizations, etc. Our group needs to ensure that all the applicable information is present in the FHIR messages without needing to decode the SDC form. We have covered many use cases, but there are several where we need to provide information in FHIR to avoid additional processing. This may come in the form of data that can be captured in the DocumentReference as a type or category code.

We also developed a parsing script to convert FHIR Observation resources to HL7 V2.5.1 OBX segments. The motivation for developing this parsing script was to demonstrate this capability because most software leveraged by the CCRs utilize HL7 V2.5.1 messages as the data input, not FHIR. While this was tested again, no additional functionality was added.

During the September 2020 Connectathon, we introduced three new scenarios for testing. The first scenario focused on testing the ability for a laboratory to POST a discretely mapped electronic pathology FHIR bundle to a public health FHIR server. The bundle contained information about a single patient including resources for Patient, Practitioner, Procedure, Condition, and Observations. During the Connectathon, we successfully tested the ability to POST and GET data from this Bundle resource. During the Connectathon, we discussed challenges identified during the Connectathon with turning the example test bundle into a scalable, automated effort for production. The difficulty lies in the fact that there really isn’t a simple, direct way to represent an SDC forms concepts as mCODE concepts without a complex translation layer somewhere in the process that would require maintenance of translation tables for each SDC form. The second scenario focused on the ability to extract an SDC form from a FHIR DocumentReference and display it as a form in an application or using XHTML to transform into a webpage. During the Connectathon, we were able to display an SDC form, submitted as a Document Reference, to a web page. The third scenario focused on the ability to extract an SDC form from a FHIR DocumentReference and save it to a database. During the Connectathon, we were able to save SDC data submitted inside a DocumentReference to a database.

Screenshots

Opioids CDS - Clinical Opioid Summary App with Rx Integration (COSRI)

Summary

Our goal for the Connectathon was to test our SMART on FHIR clinical decision support tool for opioid prescribing (COSRI, https://project.cosri.app/) with launches against an R4 endpoint, and validate the use of R4 for our CQL alerts and calculations.  COSRI is our evolution of the AHRQ Clinical Pain Summary app, which are now have approval to use in production applications for providers in Washington State. 

Participants

U of Washington, WA State DOH, and Epic, plus valuable technical assistance from several folks

Achievements

  • Fixed SoF app launch, issues will translate to production deployments
  • More learning about R4 variation, Epic and other implementations
  • Developed fix configurable in React app using our containerized SoF hosting (hard)

Screenshots and links

Here's a pretty general oversimplification - from console errors to successful launch and CQL evaluation...

One moment we had errors


And then we didn't!

In case you're not reading the fine print, we'd warn you that details are note quite as simple...!

(We tested in Epic, so we may not be able to get screenshots showing the visual integration w/ the EHR, but this screen capture was from our EHR partner, who must have gotten it from their launch - though it looks just like ours!)

Issues discovered

  • Needed to break testing into Phase 1 (launch, accessing resources) and Phase 2 (validation of CQL alerts and calculations).
  • Still roughs spots w/ the testing - the endpoint didn’t deliver R4 for a variety of resources, requiring various tweaks
  • A bit of a challenge to do “arms-length” debugging - in general we’ve had tighter integration in working with partners at IHE, however this all came together pretty quickly for us, and we didn’t do the coordinating we probably should have done.

Now What?

  • We pretty much finished our Phase 1 testing, now need to remove a few hacks
  • We also use the app in our own SoF launch environment to allow use outside of an EHR, so we need to ensure our launch follows the same details (it does broadly follow the same SoF pattern, of course)
  • Make Phase 1 more robust so we can continue Phase 2 testing as we improve our CQL
  • Continue to work towards a production deployment

COVID-19 Medication Reporting

Goal

  • The goal of the Nandina Pillbox scenario in the Public Health track is to test an approach for efficient, scalable reporting of medication exposure data during public health emergencies. The line-level approach, leveraging the FHIR API, is proposed to reduce the challenges of time-, labor- and cost-intensive methods and to achieve results that are representative of the population of interest. The demo uses a FHIR query of active inpatient encounters for a defined reporting period and stores results in a secure data repository (sample results below).
    • Nandina Pillbox is an open source tool that queries FHIR interfaces for information to pre-populate public health study data. The tool is not intended for electronic case reporting, but rather as a means of querying data at the patient-level directly from any EHR w/ a FHIR API.
    • Nandina Pillbox is also a proposed open, vendor-neutral standard for fully electronic patient-level queries of medication data among U.S. inpatient.

 Now what?

  • Refining queries against FHIR API in Cerner Sandbox
  • Implementing Direct integration via Rosetta Health
  • Refining approach to aggregate line-level reporting
  • Approaching HL7 WGs to discuss the development of the data standard

Screenshots



  • No labels