ELR Technical Assistance (ELRTA) Overview

• HL7 Coding and Gap Analysis Tool Assistance (Data Element Mapping)

• Standardize Vocabulary Mapping for Interoperability

• Creation or Maintenance of Codes

• Evaluate ELR Infrastructure and Discovery

• Facility Capacity and Utilization of Data Automation

• ELR Onboarding

• Data Extraction and Enrichment

• Assistance to Make or Utilize Open-Source Tools

• Access to Shared Microservices and Tools

• Evaluate and Automate ELR Error Tracking and Alert Processes

• Standardize and Automate Jurisdictional ELR Processes

• Integration Engine Support

• Related: Cross jurisdictional data exchange using InterPartner Data Exchange

What is ELR Technical Assistance?

Electronic Lab Reporting Technical Assistance (ELRTA) is APHL’s collaboration with the CDC to offer technical assistance to public health agencies and laboratories for implementation and advancement of their electronic laboratory reporting with their messaging partners.

Electronic Lab Reporting (ELR) allows laboratories and public health agencies to report (exchange) data via fast and potentially more streamlined processes. This technical assistance (TA) enables such ELR capabilities on a larger scale, including supporting commercial labs with HL7 lab results messages, in addition to public health agencies and public health laboratories.

ELRTA provides support and assistance to many jurisdictions and requests are continuously accepted via the ELR Technical Assistance Request Form.

Who qualifies for ELR Technical Assistance?

Funding is provided by the CDC Epidemiology and Laboratory Capacity (ELC) Grant, which supports several key activities within three key focus areas:

• Surveillance, detection, and response

• Prevention and intervention

• Communications, coordination, and partnerships

Technical assistance is available to all ELC award recipients, which includes public health agencies and laboratories from 64 jurisdictions.

How do I request ELR Technical Assistance?

Submit your request via the ELRTA Request Form at this page:

ELR Technical Assistance Request Form

What types of Technical Assistance do you provide?

• HL7 Coding and Gap Analysis Tool Assistance (Data Element Mapping): Assistance in understanding potential updates or changes needed to establish data exchange there is a need to understand which data elements must be available in the system, what format and associated vocabularies are expected and where in the selected data exchange format they will be represented (HL7 v2, HL7 FHIR, HL7 CDA).

• Standardize Vocabulary Mapping for Interoperability: Assistance with mapping of a larger set of the concepts you use (tests, results, units, specimen, diagnosis, organisms / animals, demographics, etc.) to standard code systems required for data exchange; this is hands-on mapping, but also proper selection of the standard to use. This will also include education around the standards being mapped to and tools to use to do this going forward.

• Creation or Maintenance of Codes: Assistance setting up a new test in your system that requires standard code assignment (test, result, units, specimen) or advice on best practices for code assignment, or need help with a submission for a new standard code.

• Access to Shared Microservices and Tools: Assistance in managing and connecting microservices and tools.  Assistance, for example, to enable RestAPI connectivity into the SpringML application

• Assistance to Make or Utilize Open Source Tools: Assistance with many different tools such as; the National HL7 Generator tool, created by APHL, which can be configured for STLT PHAs to convert national-standard flat file data into an HL7 message that can be consumed by STLT jurisdictions.  Or, assistance with configuring a data validation/processing tool using Python/Excel/VBA to help provide QC of facility data prior to submission to STLT PHA.  And, in another example, assistance in creating automated process improvement tools and dashboards in RStudio/RShiny and PowerBI to help locate data processing and reporting anomalies internally.

• Data Extraction and Enrichment: Assistance in multiple types of data extraction procedures for the automation and improvement of data transformations from point-of-care APIs to state surveillance system standards. As needed, assistance can also provide applications to extract unstructured data from PDFs and other text- and image-based documents (using optical character recognition (OCR) into formatted flat files (CSVs)) to meet state surveillance system standards. 

• ELR Onboarding: Assistance with onboarding facilities to address the need for automation of reporting records inflow into STLT health surveillance systems where there is inefficient message ingestion and processing.  Specifically, onboarding assistance can also provide automation solutions, if needed, to address data quality issues due to CSV/flat file reporting and/or manual data entry due to paper reporting.

• Evaluate and Automate ELR Error Tracking and Alert Processes: Assistance with automating data validation, and error alerts and storage tools, for incoming data messages received from submitting facilities.  Specifically, this technical assistance can improve HL7 message handling in Rhapsody, BizTalk, and Mirth.

• Evaluate ELR Infrastructure and Discovery: Evaluate current ELR infrastructure and make recommendations for alternate transport mechanisms, as needed, and for messaging processes such as Rhapsody to improve efficiency of ELR processing. In addition, recommend and develop, as required, alternate data cleanup and processing of non-HL7 messages.

• Facility Capacity and Utilization of Data Automation: Establish data pipelines and connectivity between submitting facility to state PHL using, where applicable, REST Web Services, SFTP, AIMS and/or AWS S3.

• Standardize and Automate Jurisdictional ELR Processes: Assistance with developing, and or enhancing, current, connections to new and alternate data transport systems such as STFP, AWS S3, and AIMS connections.  For example, assistance in building a Rhapsody route to convert state CSVs to HL7 2.5.1.

• Integration Engine Support: Assistance in developing error or message validation routes with commonly-used integration engines;  Rhapsody, Mirth, Cloverleaf.  For example, the creation of an enhanced message validator to generate readable error reports for triaging, and a configurable email notification process to sender to automate the error notification process.

What is InterPartner Data Exchange?

InterPartner Data Exchange is an interstate-style message file naming format that allows for sending and receiving messages between any two trading partners on the AIMS platform, not just states. This filename structure is fixed, rigid, and endures validation. The first InterPartner message transfer was completed in November 2019. From January 1st, 2020 through October 31st, 2020, almost 7.5 million InterPartner files have passed through AIMS.

As part of an overall mission to increase AIMS trading partners’ self-reliance, this message format was designed to allow a trading partner to add additional use cases once they have been initiated by AIMS support the first time. AIMS trading partner to exchange data with virtually any other AIMS trading partner, regardless of the sender’s or receiver’s transport mechanism.

The InterPartner filename is a great way to simplify sending and receiving files with AIMS. Trading Partners should find that the number connections with AIMS will decrease, which should save money and time. Visit the InterPartner page to learn about InterPartner filename format and how to use it with PHINMS, SFTP, and Amazon S3.

More information is available on the InterPartner Technical Assistance page.

How do I check the status of my ELR Technical Assistance Request?

You may send an email Raymond Lewis or respond to the initial response from the Project Manager sent to you with the start of the work on your request.

How long does a Technical Assistance Request response and solution usually take?

The request is usually responded to within a few days. The timing for request resolution varies widely. It depends on the queue of work the team is currently managing and the complexity of the work requested.