Help
Login
Busy
Search
Public Health Case Reporting - Datasets

 
Concept locked
Concept locked
Select Target
Select Concept
De-inherit concept

Select object
 
Edit
Filter
Edit
true50
Provenance
Id phcrg-dataelement-14 Version 2015-11-03 05:17:40
Status Draft Version Label
Description
Describes entities and processes involved in producing and delivering the Initial Public Health Case Report.
/
<<  !<<  (r) 
-
/
-
/
/
false
Usage (0)
Busy
/
false
Issues (2)
Busy
false
Request for Information/Education Status = Open ( phcrg-issue-26 ): candidate stuff
Type Request for Information/Education Status Request for Information/Education Status = Open Priority Normal
Events
Tracking / Status = Open 2015-11-03 16:22:55 : Tracking by Eric M Haas
Description
Finding:

-decide on candidate stuff - easy vs harder to add.

Suggestion:

-

Further explanation:

-

Request for Information/Education Status = Open ( phcrg-issue-27 ): Bettter definitions needed
Type Request for Information/Education Status Request for Information/Education Status = Open Priority Normal
Events
Tracking / Status = Open 2015-11-03 16:24:18 : Tracking by Eric M Haas
Description
Finding:

-Bettter definitions needed

Suggestion:

-input from CSTE

Further explanation:

-

 
 
true50
Dataset Public Health Case Reporting Dataset
Id phcrg-dataset-1 Version 2015-10-12 23:17:33
Status Draft Version Label
false
Description
Public Health Case Reporting Dataset:
3 - Minimum eICR Data Elements of Interest

This draft recommendation defines the minimum data elements of interest for an electronic initial case report (eICR) from electronic health record technologies (EHRT) to state, tribal, local and territorial public health agencies for healthcare providers to comply with jurisdictional reportable diseases and conditions laws. The focus is on eICR data that are necessary for public health agencies to initiate follow-up actions for individual case investigations (e.g., Measles, Ebola, lead or carbon monoxide poisoning, etc.).

 

With this draft recommendation, the CSTE eICR task force intends to meet the needs of:

·         Public health surveillance professionals who are planning to enhance agency surveillance systems and data sharing partnerships with eICR from EHR technology; e.g., Epidemiologist, public health surveillance directors, informaticians, infectious disease control program directors, etc.

·         Health data standards development organizations who are developing electronic messaging standards for communicating reportable conditions information between healthcare providers and public health departments; e.g., HL7

·         Health and public health information technology vendors who are plan to develop and provide information technologies to health care providers or public health agencies for eICR; e.g., EPIC, CERNER, STC, Consilience, Orion Health, etc.

·         Health IT policy makers who are developing or influencing national policies that will support stakeholders in adopting and using health IT for eICR; e.g., CDC, ONC, CMS, Health IT Policy Committee, National Committee of Vital and Health Statistics, etc.

·         Healthcare providers and associations who provide or support the provision of reportable disease or condition data to public health agencies; e.g., Healthcare professionals, hospitals, infection control practitioners, HIEs, RHIOs, National Hospital Association, American Medical Association, etc.

The minimum data elements of interest (DEOIs) represent a floor, or base-level requirement suitable to current practice. With time, new capabilities and business practices will emerge and the conditions upon which this recommendation has been drawn will change.

 
Scope

There are important topics that, although related, are beyond the scope of this recommendation. These topics include:

1.      Conditions or rules that trigger an EHR technology to generate and send the eICR

2.      Internet protocols or methods used to provision or transmit the eICR

3.      Processes used to extract, receive, transform and translate eICR data

4.      Communication of case report information and data between public health jurisdictions

5.      Determination of report-ability; i.e., whether or not the patient's health condition is a reportable case

6.      Other case-based public health reporting processes; e.g., electronic laboratory results, cancer, birth defects, new born screening, adverse events, hospital acquired infections, etc.
Key assumptions

In creating this draft recommendation, CSTE’s eICR task force made the following assumptions:

1.      eICR production is triggered or initiated upon rules that match jurisdictional disease and condition reporting regulations;

2.      Local and state laws may further impact what patient health data can be shared between HIPAA covered entities (e.g., healthcare organizations) and public health agencies;

3.      Participating PHAs have or will have to develop the infrastructure, capability and capacity to receive, manage, analyze, and meaningfully use the specified health data; ?

4.      Healthcare providers will collect data during their routine workflow and have the infrastructure, capability, and capacity to send the heath data specified by these Guidelines; and ?

5.      EHR installations vary from a single integrated system to multiple individual departmental, functional, or modularized systems; this may potentially affect data consistency and the complexity of system implementation and use. ?

 

Table 2: Key terms and definitions

Column Name
    

Definition

Element Name
    

Name for the data set element

Description
    

Defines the information that the element must convey

Justification
    

Explanation of why the element is critical for a report and how it is used by PHAs for reportable conditions surveillance and related public health activities

Sender Usage
    

Refers to whether an electronic health record technology must provide the data element. The usage codes are:

R – Required: Indicates that the field is a required field and must be supported by the EHR system. A value must be present in the field in order for the message to be accepted.

RE – Required, but can be empty: Indicates that the field is a required field and must be supported by the EHR system. The reporting of data is setting-specific. If data are present, then they must be reported. However, if there are no data captured in the field due to the setting (e.g. no chief complaint data for a trauma patient) and the field is blank, the message may be sent with the field containing no data.

O – Optional: Indicates that this field must be supported by the EHR system, but the transmission of the values captured in these fields is optional. Specific usage of these data elements shall be determined at the state or local-level jurisdiction.

Justification
    

The rationale for a minimum data element that describes how public health agencies use the element for surveillance and disease prevention and control purposes.

Notes
    

Description of a future data element’s utility and concerns that presently limit feasibility.




false
Usage (1)
Busy
Transaction Project
Summary IPHCR data (not used) Public Health Case Reporting
Busy