General Public Health Connectathon Thread: https://chat.fhir.org/#narrow/stream/238751-Public-Health.202020-05.20Connectathon
eCR Now
eCR website: ecr.aimsplatform.org
eCR Now presentations and COVID-19 reporting: https://ecr.aimsplatform.org/ecr-for-covid-19-reporting/
eCR Now App Connectathon Thread: https://chat.fhir.org/#narrow/stream/236764-eCR-Now.20FHIR.20App
eCR Now Schedule (All Times ET)
Thursday, May 14, 2020
9:30 - 10:30 AM Welcome and Set-Up
- Context
- Endpoints and other resources
- eRSD registration and configuration
- Direct set-up
- Sandbox configuration
11:30 AM - 12:30 PM Trigger and Loading Queries
- Trigger queries and eRSD trigger codes
- Editing queries
- Lab feed mapping needs
- Loading queries and populating the HL7 eICR v1.1
- Optimizing queries
2:00 - 3:00 PM Automated App Launching Alternatives
- Manual launch (for Connectathon testing)
- SMART on FHIR App launch with refresh tokens
- SMART on FHIR App launch followed by system access
- CDS Hooks or auto pages launch
- ADT integration
4:30 - 5:00 PM Day's Wrap-Up
Friday, May 15, 2020
9:30 - 10:30 AM Day Two Welcome and Set-Up
- Issues and discussion
- App hosting
- Handling of CDA Reportability Responses and eICR copies
- Transport options
1:30-1:45 PM Demonstration and Report-Out
3:00 PM Connectathon Written Report-Outs Are Due-In
3:00 - 4:00 PM Wrap-Up and Final Items
Submitting WG/Project/Implementer Group
Public Health Work Group (PHWG)
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.
Because the data exchange is inherently inter-organizational, and because initiating events ("triggers") frequently occur in healthcare, unsolicited “push” exchange is prominent as are other technical components involved in supporting the needs of reporting / surveillance / connection to population health systems with minimal 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 use cases (and use case lead):
- eCR Now - Automated Reporting App for COVID-19 (John Loonsk)
- eCR Now - electronic Reporting and Surveillance Distribution (eRSD) for CDA, FHIR, and FHIR App use (Rick Geimer)
- EIP Flu Surv NET (Jason Hall)
- Integrating Cancer Reporting Standards (Wendy Blumenthal)
- Bidirectional Services e-Referrals (Sarah Gaunt)
- Electronic Case Reporting (Sarah Gaunt)
And connection to other places where public health will be working:
- Advancing reporting / surveillance "triggering" - Rick Geimer
- Advancing electronically established EHR system interfaces - John Loonsk
This track will use these versions of FHIR.
4.0.0, 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
Track Leads
John Loonsk (john.loonsk@jhu.edu)
Rick Geimer (Rick.Geimer@lantanagroup.com)
Arun Srinivasan (fos2@cdc.gov)
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
- Carradora
- Dynamic Content Group
- Hi3 Solutions
- Lantana Consulting Group
- Medical University of South Carolina
- Michigan Department of Health and Human Services
- Northrup Grumman
- YMCAs of America
Track Orientation
HL7 FHIR Connectathon eCR Now FHIR App Webinar
Scenarios
eCR Now - Reporting App for COVID-19 Electronic Case Reporting
Case reporting is a core outbreak management need for public health agencies (PHAs). PHA case management, situational awareness, reporting, contact tracing, lab results connection, as well as isolation and other countermeasure coordination need case data to function. These needs have again been made clear through the COVID-19 events, but currently only some EHR vendors have implemented electronic case reporting (eCR) solutions in CDA even with it being in CMS's "Promoting Interoperability" incentives. To try to help provide COVID-19 eCR for more EHR vendors, a FHIR app is being developed, meeting existing deployed FHIR standards. This app should provide automated eCR for COVID-19 now without the need for EHR updates.
The eCR Now COVID-19 app does not require manual data entry, but instead, like the rest of the eCR, automates the reporting of data using the standards (HL7 CDA eICR version 1.1, HL7 CDA Reportability Response) and shared services platform that are in use now to route to, and integrate with, public health agency systems nationwide. When COVID-19 is over, an updated backend services version of the eCR Now COVID-19 app that supports full eCR services will also be made available.
The eCR Now COVID-19 app and its back-end support services will be provided to EHR vendors to allow them to enable their existing installed EHR base with automated COVID-19 electronic case reporting. For EHR vendors that do not already have an implemented eCR solution, we are seeking their participation in implementing and testing the eCR Now COVID-19 app in sandboxes that represent their installed EHR environment(s). Before this Connectathon, the eCR Now COVID-19 app will be shared with EHR vendors for implementaion in their sandboxes.
Consume Reporting Specifications
- See electronic Reporting and Surveillance Distribution (eRSD below).
App Launch
The eCR Now COVID-19 app supports automated reporting to minimize provider burden, but needs to use SMART on FHIR App Launch security, patient context, and other aspects of the provider app "plug-in" paradigm because that is what is in place in installed health system EHRs. In this scenario, different approaches to app invocation will be tested. Invisible app invocation at the start of the encounter workflow is preferred, but absolutely minimal app invocation steps that are situated in provider / staff workflow at the start of the encounter and that insure reliable invocation for all patients is expected.
- Action: The app is invoked for all patient encounters by an EHR-initiated process, auto-pages, an omnipresent CDS rule, or some other existing EHR event for all patient encounters
- Success Criteria: The app is invoked for all patients without any provider or provider staff effort or action
- Action: The app is invoked for all patient encounters though a link that is clicked by the provider or by provider staff
- Success Criteria: The app is reliably invoked for all patient encounters near the start of the encounter workflow with minimal provider workflow intrusion
Query-Based COVID-19 Triggering for Electronic Initial Case Report (eICR) Initiation
The triggering and initiation of reports in the app will be based on specific queries executed a short time after the start of the encounter and a period of time after the encounter is closed. These data queries will be initiated by the app but the app needs to know when the encounter started and when it is closed for them to be executed. Trigger times will be truncated for testing in the Connectathon.
- Action: The app accesses and uses encounter.period.start and encounter.period.end to time and execute queries to determine if specific COVID-19 trigger data are present.
- Success Criteria: Queries for specific data (see eRSD trigger code distribution for the EHR data queried, the specific COVID-19 trigger codes, and the timing parameters) are successfully executed by the app at the right times near the start and after the encounter has been closed.
- Action: The app accesses and uses different available EHR data to time and execute queries to determine of specific COVID-19 trigger data are present.
- Success Criteria: A method for EHR vendor configuration of the app to access variant data is established and tested. Queries for specific data (see eRSD trigger code distribution for the EHR data queried, the specific COVID-19 trigger codes, and the timing parameters) are successfully executed by the app at the right times near the start and after the encounter has been closed.
Create a Electronic Initial Case Report Document
The app will execute FHIR data queries and create and populate an HL7 CDA eICR STU Release version 1.1 document that can be validated and used by the APHL AIMS platform and processed and rendered public health agencies that the platform routes it to using existing infrastructure and connections.
- Action: App initiated FHIR data queries will be executed to retrieve as much eICR data as possible and populated in the created CDA eICR 1.1
- Success Criteria: eICR data are successfully retrieved and used to populate a CDA eICR 1.1 and the created document is validated using he AIMS Platform eICR CDA validator (https://validator.aimsplatform.org/).
Resources
HL7 CDA® R2 Implementation Guide: Public Health Case Report, Release 2: the Electronic Initial Case Report (eICR), Release 1, STU Release 1.1 - US Realm (View STU) (Download)
Electronic Initial Case Report (eICR) Transmission, Direct and XDR Integration, and Reportability Response Receipt
The app will need to connect to Direct or XDR transport services and a Direct HISP or eHealth Exchange hub depending on what is in use in the health system environment to send eICRs out and receive eICRs back. The app will be configurable for connection to HISPs using SMTP or XDR connections. A CDA Reportabilty Response will be returned to the EHR, but will not be processed by the app.
- Action: Vendors will test configuration of the app to transmit to available healthcare Direct HISP services
- Success criteria: The app will be successfully configured and then transmit a validated eICR to the provided APHL AIMS Direct test address. The APHL AIMS shared service will successfully process the eICR and the sandbox will receive a returned Reportability Response.
- Action: Vendors will test configuration of the app to transmit to the eHealth Exchange hub or a Health Information Exchange that is so connected
- Success criteria: The app will be successfully configured and then transmit a validated eICR to a provided XDR endpoint. The APHL AIMS shared service will successfully process the eICR and the sandbox will receive a returned Reportability Response
Resources
- An APHL AIMS test Direct address will be provided. When test eICRs (***not containing actual PHI***) are sent to it, this service will return a Reportability Response to the Direct address it received the eICR from.
HL7 CDA® R2 Implementation Guide: Reportability Response, Release 1 STU Release 1.0- US Realm (View STU) (Download)
Electronic Case Reporting - electronic Reporting and Surveillance Distribution (eRSD)
The eRSD service has been developed for general electronic case reporting needs. It accessible by registration and once registered will notify and deliver HL7 eCR eRSD standard trigger value sets and reporting metadata. Once registered, users can also get a digital token that allows the service to be polled for the same content. The use cases for the eRSD include routine and emergency updates. In the context of COVID-19 the eRSD will be tested and utilized to access the full eRSD specification, but also to use the eCR Now COVID-19 app or directly access the eRSD data and selectively access the specific COVID-19 trigger codes.
- Precondition: User has registered for the eRSD service (eRSD Service)
- Action: EHR Vendor accesses the eRSD service and uses the COVID-19 specific trigger codes from it
- Success criteria: A successful load of COVID-19 trigger codes into the EHR environment
- Precondition: User has registered for the eRSD service (eRSD Service)
- Action: EHR Vendor uses the eCR Now COVID-19 App to access the eRSD service and the app uses the COVID-19 specific trigger codes from it
- Success criteria: Successful triggering of a simulated COVID-19 eICR using fresh trigger codes from a newly accessed eRSD
Access Knowledge Distribution / Trigger Codes Updates
Action: Provider organization registers and subscribes to changes to the eRSD PlanDefinition and trigger code value sets / reporting logic using any legal notification method.
Original PlanDefinition and trigger code value sets / reporting logic exist on test server
Success Criteria: Provider organization is notified and receives a copy of any PlanDefinition and trigger code value sets / reporting logic specifications that are updated
Ingest Knowledge Distribution / Trigger Codes into EHR
Action: Provider organization receives a PlanDefinition trigger code / reporting logic update, and ingests them into their EHR to support case report initiation.Precondition: PlanDefinition trigger codes / reporting logic updates have been received by provider organization
Success Criteria: Updates successfully ingested into EHR.
Scenarios (Bidirectional Services e-Referrals)
Create and Send Referral
Action: EHR prepares and POSTs an electronic referral. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral receiver does a GET on each successive referral and processes it. Some may test FHIR messaging for transmissions.
Precondition: Referral exists on a FHIR server.
Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here:
Receive Referral
Action: Referral creator prepares referral and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. Referrals may be queued. The referral consumer does a GET on each successive referral and processes it. Some may test FHIR messaging for transmissions.
Precondition: Referral exists on a FHIR server.
Success Criteria: Referral is successfully retrieved from a FHIR server and validates against the profiles found here:
Create and Send Report Back
Action: A referral report is created and POSTed it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange. Some may test FHIR messaging for transmissions.
Precondition: Referral report information exists sufficient to populate a referral report.
Success Criteria: Referral report is successfully posted to a FHIR server and validates against the profiles found here:
Receive Report and Attach to Patient Chart
Action: Referral report creator prepares a referral report and POSTs it to a FHIR server. This POST may be one of several different transport methodologies supported for exchange with clinical care. The referral consumer does a GET on each referral report and processes it. Some may test FHIR messaging for transmissions.
Precondition: Referral report exists on a FHIR server.
Success Criteria: Referral report is successfully retrieved from a FHIR server and validates against the profiles found here:
Scenarios (Integrating Cancer Reporting Standards)
Scenarios (Cancer Reporting)
Cancer Reporting requires inclusion of cancer pathology and biomarker test results, physician and facility information, and patient demographics. This activity involves leveraging the FHIR REST API to share the specific integrating the Healthcare Enterprise (IHE) Structured Data Capture (SDC) form between the laboratory and public health cancer registry. Pathology laboratories are already deploying the College of American Pathologist (CAP) SDC forms to collect structured cancer pathology and biomarker data.
The ultimate goal is to test the use of the FHIR REST API to share the CAP SDC form and create FHIR Observations based on the CAP SDC form, so that each observation will be queriable on the Public Health Cancer Registry FHIR server. SDC is already in production as the new pathology-reporting standard in North America. Enabling interoperability between SDC and FHIR will encourage easier data retrieval at a more granular level, better data collection, and easier aggregated reporting to public health agencies.
Use FHIR REST API to GET the CAP SDC form
Action: Laboratory will use the existing FHIR REST API to request using GET a blank CAP SDC form using the GET to be populated by the laboratory system. Form Manager FHIR Server will host CAP SDC forms and upon receiving the GET command will return a FHIR Document Reference with the blank SDC Form included as an attachment. Success Criteria: Laboratory receives the blank CAP SDC form using the FHIR REST API (FHIR Document Reference with the blank SDC form as an attachment) from the Form Manager FHIR Server.
Populate and share CAP SDC form
Action: Laboratory system populates CAP SDC form and uses FHIR REST API to POST the completed CAP SDC form in a new FHIR Document Reference with populated SDC Form as an attachment to the Public Health FHIR server. Precondition: Laboratory has blank CAP SDC form for completion. Success Criteria: Public Health FHIR server receives FHIR Document Reference with populated CAP SDC form attached from Laboratory.
Create FHIR Observations from SDC form
Action: Public Health FHIR server will store the populated CAP SDC form in a database for the cancer registry program to query data. When Public Health FHIR server receives a QUERY for the CAP SDC form data, then the SDC Form elements will be used to create FHIR Observations. Precondition: Public Health FHIR server receives FHIR Document Reference with completed CAP SDC form included as an attachment from laboratory. Success Criteria: CAP SDC form XML data is stored in database on Public Health FHIR server for querying by cancer registry program. Query request creates FHIR Observations with requested data and returns data to cancer registry.
TestScript(s)
Indicate any test scripts that will be used to help verify system behavior
TBD
Security and Privacy Considerations
Identify any expectations around security (e.g. will TLS, mutual-TLS, OAuth, etc. be required to participate
TBD