Provider or hospital sends update to regional or national quality registry

State: Draft

Story

Perspective: A Provider at an outpatient clinic or a hospital that participates in a regional or national clinical registry for outcome quality studies.

Context: The practice or hospital has made the determination that it is clinically and legally appropriate to send patient care data to the registry.

Story: At each participating health care site, a patient encounter is the trigger event that leads to the preparation of content for submission to the registry. In response to this trigger, the EHR service at the inpatient or outpatient setting creates an electronic file containing patient care data elements which match the data elements collected by the registry. The site sends the data file to the registry, and the registry receives and incorporates the file.

There may be subsequent communications regarding the file submission, such as a confirmation from the registry, or follow up communication to clarify data elements in the file originated by the EHR, especially if the registry submission contains narrative data. All confirmation and follow up communication is out of scope for this transport specification, which is narrowly focused on an original automated event that pushes an electronic file to a registry.

Details

Actors

Actor	Details
Addressees	The Provider or Hospital EHR and the regional or national Registry
Source	The Provider or Hospital EHR
Destination	The regional or national Registry

The goal of a registry is quality analytics on detailed population level data. Most registries are narrowly focused data silos, typically with strict field level validation and frequently with manual data element massaging. Registries are generally populated with coded content originating at a wide number of participating health care delivery sites.
 

1. Registries are typically populated with multiple data streams from various source systems.
2. At some facilities, multiple actors within the facility originate separate portions of data files to be combined and then submitted to the registry, and multiple registry trigger events may occur separated by time, clinical department and by separate software systems. Or, optionally, rather than assemble a single facility-level registry submission file, the individual trigger events spread across the facility can each initiate separate registry submission files.
3. The opportunity to accept automatically generated data submission files is likely to be too complex for less automated or less sophisticated registry environments, many of which operate with flat files in batch workflows; however, this opportunity can also enable HISPs (or registries) to create adaptive listeners which queue incoming registry submission files sent by EHRs using the NHIN Direct protocol.
4. The transition to automatically generated registry submissions may substantially improve the opportunity for smaller health care facilities to participate in registries, as current manual business rules for registry file preparation may be out of scope for a thinly staffed facility.
5. Teaching EHRs to automatically originate correctly formatted registry submission files is out of scope for this user story, but the opportunity carries much promise for reducing the cost and complexity of registry operations.
6. There is a high likelihood of HISPs as intermediary actors in the registry file submission process.

Data Exchanged

The typical registry integrates data from various primary or secondary sources. Primary data are collected for direct purposes of the registry, while secondary data has been collected for purposes other than the registry, and may therefore lack appropriate structure or coding for direct import by the registry.
 

1. Primary data is sufficiently coded and structured to be consumed directly by the inbound data validation process of the registry. An example of primary data is an inventory of device components implanted in a patient during a joint replacement surgery.
2. Secondary data will be pushed to a queue for scrubbing and validation prior to presentation to the registry. An example of secondary data is preventative health screening assessments (e.g., lead exposure, hearing assessment, developmental risk screening, blood spot screening, etc.).

User Acceptance Tests

To be named.