USCDI+ JPHIT Comments

The Joint Public Health Informatics Taskforce (JPHIT) is pleased to provide the following comments regarding USCDI+ for consideration. While we have submitted several specific comments, we also are taking the opportunity to comment on the overall philosophy of what USCDI+ is and is not.
We believe the mission of USCDI is clear. Healthcare Organizations (HCOs) and Electronic Health Records (EHRs) that are addressed by current, relevant Federal regulation(s) are required to have Health Information Technology (HIT) products that can exchange the USCDI data. USCDI does not obligate the HCOs and EHRs to produce the data in these formats, but they must be able to support these for data exchange purposes. While USCDI certification does not currently affect other HIT systems in the healthcare ecosystem that interact with HCO and EHR and may therefore not implement to USCDI standards, setting an expectation with clear definitions for all to eventually use as a baseline is invaluable.
USCDI+, however, is not required of HCOs / EHRs by regulation and its purpose has been less clearly articulated. We believe that possible purpose(s) ONC may consider include:

To limit the data that public health asks of HCOs / EHRs through funding or certification of PHAs;
To harmonize the data that public health asks of HCOs / EHRs;
To use non-regulatory levers to get HCOs / EHRs to deliver the data to public health and promote voluntary adoption by the health care and public health ecosystem of data elements and standards included in USCDI+; and
To expand the use cases beyond typical EHRs to more specialized systems like LIS/LIMS and support harmonization of data elements outside of EHRs to so that in the future it will be delivered to HCOs / EHRs in USCDI compliant format and to inform standards development for public health or other domain-specific purposes.

JPHIT believes that while #2, #3 and #4 above are laudable, #1 is not. The eCR data, as an example, were identified by a task force of epidemiologists to be important for initial reporting of cases. The public health programmatic need for some data is larger than others, but all of them have been identified through other processes as being important to one or more public health program.
In terms of effectively harmonizing public health programs, there is also a need for a more specific representation of USCDI+. If USCDI+ is to be effective in harmonizing public health programs, there will be a need for more cross-program conversations about the vision of USCDI+ and the consistent relevance, applicability, and scalability of data elements to various domains. Just as USCDI has USCore and implementation guides in FHIR to help get to the practical specificity needed, USCDI+ needs specific, template or profile-level representation to effectively do this in all standards families . JPHIT recommends that the purposes of USCDI+ should be clearly stated. The intended purpose of USCDI is to feed into standards development organizations and to support the initiation of additional processes to develop consensus and promote adoption of standardized data to support the specific domains. They are insufficient in and of themselves as currently represented in USCDI+ and there is a need for further clarity as to how these data elements will impact data exchange across health care and public health.
In FHIR, the US Public Health Profiles Library (USPHPL) in combination with implementation guides can meet these needs, but support needs to be broadened. For the laboratory data exchange use case the current industry standard is based on HL7 V2, with several available implementation guides for different aspects of the lab data exchange. In CDA, the C-CDA serves some, but not all, of the process needs here. ONC should help make sure that processes and artifacts are available for harmonization in all standards families.

In addition, we believe it will be useful to explain the differences between USCDI and USCDI+ in terms of implications for standards development and/or for certification, inclusion of the data elements into the US Core and availability for data exchange.
There are several data elements included in the domains outside of public health that remain very useful for public health though they are not included in the core case data (e.g., birth weight useful for specific conditions such as congenital syphilis, vital signs useful for many infectious disease cases, etc.). Will these data elements be available to pull into the public health domain as well? What are the implications of not listing them as important for public health?
For data elements that are included in BOTH USCDI (whether in a published final version, or in the level 2, 0 or comment versions) it is unclear to us whether these data elements will be kept “in synch”, e.g., will comments or modifications to metadata or value sets made in USCDI be visible in USCDI+ and vice versa? Also, if public health strongly feels a particular element should be included in USCDI, do we request it there and write justification for its inclusion or in USCDI+, hoping that it will be pulled into USCDI in the future? Or do we request it in both places? What are the implications of requesting new data elements or modifications to existing elements in one place vs the other? We would appreciate clarification.
For many data elements it would be helpful to provide examples of what the value sets may be. For example - the variable disability status - is that a yes, no field? Or is it meant to support the ability to indicate specific disabilities - if so, would be helpful to provide a tentative value set - such as disability related to vision, hearing, smell, cognition, movement. mental health etc.
Regarding the description of case reporting on the use cases in the domain page - case reports are not just used for investigation and patient follow-up, they are also used to track trends, distribution of the condition across the population, link patients to care, detect outbreaks or clusters, evaluate interventions such as vaccine etc. Similarly, for the lab data exchange the goals are not necessarily for treatment. If the use case includes electronic ordering it needs to include additional data.
Laboratory Data Exchange
The Joint Public Health Taskforce (JPHIT) is pleased to provide the following comments regarding USCDI+ (Laboratory Data Exchange) for consideration.
What additional data elements should be included in this dataset to support these use cases ?

All data elements included in the HL7 2.5.1 ELR standard should be included in lab data exchange use case

o Current elements listed for the laboratory data exchange use case represent a limited core set of data elements leveraged by HHS during the COVID-19 pandemic to compare aggregate data on laboratory-confirmed cases across sources. STLTs require fully identifiable information and the data set should include the expanded list of data elements as represented in ELR HL7 2.5.1 IG .

In addition, for ordering of tests, it is critical that health care be able to exchange additional data including first and last name, medical record number or other patient identifier, patient address (number, street, city, state, zip), patient phone number, DOB, race, ethnicity, sex at birth, gender identity, submitting facility, contact person at facility, phone at facility, submitting laboratory PFI or CLIA, provider name, provider phone, provider address, test being requested, reason for test, specimen type, specimen source, date of specimen collection, symptom onset date, patient hospitalization, if meets criteria for testing, and Lab name; lab type (private/public).

What data elements may be unnecessary outside of the COVID-19 pandemic?

Some information currently captured via Ask on Order Entry (AOE) questions is better represented through eCR. These include: employment in healthcare and resident of a congregate care setting.

What additional laboratory data exchange use cases may be valuable to include within the dataset?
The listed use case represents the data variables sent from laboratories to CDC (COVID results only) and not what is necessary for STLTs receiving ELR results. A new use case should be developed to document what is needed by STLT and reference all data elements included in the HL7 2.5.1 ELR standard. The other critical use case is for test ordering, particularly at public health laboratories during emergencies. All elements identified in ELR R1 also need to be included in orders for tests for potentially reportable conditions or for orders from public health laboratories.
Electronic Case Reporting
The Joint Public Health Taskforce (JPHIT) is pleased to provide the following comments regarding USCDI+ (Electronic Case Reporting) for consideration.
Which data elements being received by your PHA electronically via electronic case reporting are most useful?

Complete, high quality, and standardized data is the most useful in general.
Specifically, race, ethnicity, patient name, patient address, patient phone number, facility name, facility phone, facility identifier, provider name, provider contact information, provider NPI, patient language, pregnancy status, job, occupation data elements, medical record number, gender identity, vital status, congregate living, admission date/time, encounter diagnosis, disability status, date of onset (though not often populated well), medications (administered, prescribed)

Are there any data elements you would remove from this initial common/core set? 

Pregnancy Status (appears to be listed twice); would recommend including but just listing pregnancy status once
Medication Administered Performer

Are there data elements within the dataset that are rarely used, or have other, reliable, primary (non-EHR) data sources? 

We believe that it may be too early to determine as eCR is scaling up. However, certain data elements may be better obtained through non-EHR sources. These elements may include travel history, exposure/contact data (direction, date, type, agent/contact source/target participant).

Are there any high-priority data elements missing from the dataset? 

Sending application, report submission date and time, patient birth sex, emergency outbreak information,
Currently the eCR does not include the condition being reported – it would be useful to include this in the message itself.
Variables should be consistent with the eCR IG standard
Weight, Height for BMI calculations
Comorbidities (not clear from description if included in the Past Medical History; explicit in description to include comorbidities); people experiencing homelessness; Congregate setting (non-living)
Sexual orientation
Congregate care facility (i.e. nursing home)
Visit start date
Visit end date
Medical record number (how is this different from identifier?)
Assigning authority for patient identifier (e.g., which health care facility is assigning the medical record number, Medicare for Medicare identifier etc)
Recommend renaming identifier to be patient identifier
Type of patient identifier (e.g., The type of identifier specified for the patient (e.g., medical record number, medicare number, laboratory patient identifier, Social security number)
Recommend renaming date of diagnosis to date of clinical diagnosis (as per this CSTE brief - https://cdn.ymaws.com/www.cste.org/resource/resmgr/briefs/DSWG_Dates_of_PH_Importance_.pdf

Are there any data classes and/or elements in the dataset that commonly present data quality issues when received electronically within an electronic case report today? 

Lab data represented in EHRs are frequently subject to a lot of errors, including wrong LOINC with the correct test name, correct LOINC test name with wrong LOINC.
Some jurisdictions are having issues with HCOs using the incorrect value sets – we recommend that ONC establish standard value sets as this would help immensely with data quality and PHAs ability to utilize the data received.
Many data are missing for eCRs. Some of the most problematic are those relating to which facility is treating the patient, which facility is sending the report, tribal enrollment is often missing as well.
Data classes and/or elements in the dataset that commonly present data quality issues specifically, include (representative list):

o Medications (either these are not standardized and/or EHRs provide different standards), medication dosages also appear to use local, non-standard, codes
o Discharge disposition and healthcare service location/unit
o Occupation
o Some procedures are not coded using the correct value sets
o Race/ethnicity (confused with race, missing, misclassification)
o Onset (missing; important to collect)
o Comorbities (missing; important to collect)
o Tribal enrollment (not usually reported but important to collect)
o Contact information for provider/case (wrong number, not updated)
o Patient assertion of vaccine credentials (need clarification on the definition for this data element)
If specific code/value-sets are referenced, are the value/code-sets referenced for the dataset appropriate for public health’s purposes? Are there alternative, standard, value/code-sets that are commonly used by public health and should be referenced instead? 

For congregate facilities, there should be a specific value set proposed which at a minimum includes correctional facility, long-term care facility, assisted living facility, shelter, dormitory, group home, other.

ONC included a broad range of Medication data elements in the dataset but seek additional feedback. Specifically, what Medication data elements are most needed from a public health perspective?
Medications should be reported in association with the condition reported:

medication administered,
medication dose administered,
date medication administered,
medication administered route of administration
medication prescribed
medication dose prescribed,
medication prescribed date
medication prescribed route of administration,
medication dispensed

What elements should be prioritized for cross use case alignment? Where is alignment potentially not possible, and what are the implications?

Recommend utilization of eICR standard

The eCR dataset currently includes several occupation related data elements. Based on previous feedback received, we request information on (a) Use of these data elements during response and (b) Availability of data elements and frequency of documentation by providers  

Occupation is a critical data element for Public Health. During emergencies in particular, certain occupations may be at higher risk, and it is important to target interventions and prevention messages at those workplaces or workers (e.g. health care workers, home health aides, food handlers). During foodborne outbreak investigations, to prioritize interventions (food handlers, healthcare, frequent travelers, teachers, folks working with children/elderly), to identify outbreaks in specific settings, for contact tracing and case investigation follow-ups.
Certain conditions are already known to occur at higher frequency in specific occupations (e.g., asbestosis, silicosis in miners, lung disease or cancer in persons exposed to certain chemicals, injuries in persons working in meat packing plants etc.).
It is important to include a free text data element for job, as well as work address (ideally repeatable since many people have multiple jobs and worksites), as well as occupation and industry. The latter can be standardized by tools made available at NIOSH which conduct natural language processing to categorize text data into standard values.

JPHIT Core Members:
American Immunization Registry Association (AIRA)
Association of Public Health Laboratories (APHL)
Association of State & Territorial Health Officials (ASTHO)
Big Cities Health Coalition (BCHC)
Council of State and Territorial Epidemiologists (CSTE)
National Association of County and City Health Officials (NACCHO)
National Association of Public Health Statistics and Information Systems (NAPHSIS)
Network for Public Health Law (NPHL)
Public Health Informatics Institute (PHII)

JPHIT Affiliate Members:
American Medical Informatics Association (AMIA)
CDC Foundation*
Healthcare Information and Management Systems Society (HIMSS)
JPHIT Ex-officio Members:
Office of the National Coordinator for Health Information Technology*
U.S. Centers for Disease Control and Prevention*
*Asterisk indicates organizations that did not provide input to the comments in this letter