See Vanessa Holley’s Comments on the USCDI+ Platform under Public Health Use Case.
The Association of Public Health Laboratories (APHL) thanks ONC for the opportunity to comment on USCDI+. We have submitted several specific comments, but also wanted to comment on the overall philosophy of USCDI+
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 be contemplating could 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
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
APHL strongly 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 reporting and to addressing some investigation needs. The public health audience 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. ONC should not be trying to re-adjudicate or minimize the importance of the data even as it laudably tries to have a consistent and harmonized ask for them.
APHL recommends providing information about the boundaries between Laboratory Reporting and the Cancer use case (but also lab data included in electronic case reporting or for Real World Data use). It would also be important to clarify that the goal of the Laboratory Data Exchange use case is the exchange of any lab data that includes public health, not only reportable lab results, but also electronic test ordering and result reporting (ETOR). This use case should also include elements such as:
consumer performed testing
genomics for reportable
HAI reporting
Newborn screening
Environmental testing
In terms of effectively harmonizing public health programs, there is also a need for a more specific representation of USCDI+ as well. 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.
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, pointing to just the US Core FHIR resource only instead of identifying the element within that resource itself is misleading, as often the USCDI+ elements are only optional in the US Core resources, hence not really expected to be supported. All data elements should be represented with mappings to all HL7 product families.
If we are imprecise in the definitions of the data elements, then we will not get good implementations. We must clean up the definitions and narrow the terminology bindings as much as possible for each of the coded data elements and should include relationships between elements, where applicable – example here would be “Result/Values” and “Result Unit of Measure” for quantitative results. In addition, all identifiers should always have the assigning authority and support identifier type, where needed (like for patient identifier).