HL7 CDA® R2 Implementation Guide:
Public Health Case Report, Release 2
(PI ID:1216)
[HL7 IP boilerplate]
Acknowledgements
The Project Team that produced this document included:
(alphabetical list of all project team memebrs, with affiliation, including both employer and organizational affiliations)
Examples:
Laura Conn, Centers for Disease Control and Prevention
Erin Holt Coyne, Tennessee Department of Health, Co-chair, HL7 PHER Work Group, and CSTE PHCR Task Force
MariBeth Gagnon, Centers for Disease Control and Prevention
John Loonsk, CGI Federal
John Roberts, Tennessee Department of Health, and Co-chair, HL7 PHER Work Group
The following organizations contributed to this document:
Examples:
ASTHO
CDC
CSTE
PHII
Others who contributed to this document include:
(alphabetical list)
****************************************************************************
Notice to HL7 Ballot Readers
Thank you for your interest in this implementation guide and for participating in the HL7 balloting process. We appreciate your comments on any content included in this document to help improve the usefulness of this implementation guide. There are several items to which we would like to draw your attention while you review and comment. These items are outlined below.
Changes in the C-CDA Header
Similar to other HL7 Consolidated-Clinical Document Architecture (C-CDA) implementation guides, the header is constrained to accommodate the needs of this implementation while maintaining its conformance to the US Realm Header for CDA Documents.
Relationship to the Common Clinical Data Set
A goal of this implementation guide was to take advantage of certified electronic health record (EHR) technology and the associated supporting standards by not requesting or requiring the development of new data requirements for EHRs to support this implementation. Data requirements identified for this implementation guide were mapped to those included in C-CDA Release 2.1. It is expected that the data elements included in this implementation represent those needed from the Common Clinical Data Set defined in the 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications.
Trigger Codes
Initial electronic case report documents may be generated by the use of trigger codes identified in electronic health records. The specific trigger codes are not in scope for this implementation guide and therefore not included in this document. The use of trigger codes represents one mechanism by which an initial electronic case report can be initiated.
Mapping of Data Elements and Additional Data Elements for Consideration
In August of 2015, the Council of State and Territorial Epidemiologists (CSTE) convened task force aimed at identifying and documenting the minimum EHR data for an Electronic Initial Case Report (eICR) to Public Health. This information was provided in draft as contribution to the development of this implementation guide, however is not considered a part of the normative content. Forty data elements were identified for the minimum recommended EHR data for an eICR with an additional ten data elements identified for possible future implementation. Data elements were mapped to Consolidated Clinical Document Architecture (C-CDA) and the associated templates. Mapping was not always straightforward and for those unfamiliar with C-CDA, the mapping may not seem to easily translate. Please refer to the attached supplemental documentation “Public Health Initial Case Report Mapping Guide” that provides the mapping of those data elements for your review and comment.
Additional Data Elements for Consideration
Many of the ten future data elements that were identified by the CSTE task force are already included in the Common Clinical Data Set or are already included in the templates chosen for this implementation guide (i.e. Patient Class). PHER seeks comment on the usefulness of inclusion of this data for an initial case report, and on the availability of these data elements in electronic health records today.
The ten data elements in question are:
§ Facility Fax
§ Provider County
§ Hospital Unit
§ Insurance
§ Immunization Status
§ Travel history
§ Patient Class (already included)
§ Date Discharged
§ Laboratory Results
(REMOVE THIS NOTICE FROM THE DOCUMENT WHEN PUBLISHED)
**********************************************************************************
Table of Contents
1 Introduction 9
1.1 Purpose 9
1.2 Audience 10
1.3 Background 10
1.4 Scope of the implementation Guide 11
1.5 Stakeholders 12
1.6 Future work / relationships to other projects / standards 12
2. Use Cases for eICR 14
2.1 Use Cases Assumptions 14
2.2 Pre-Conditions 14
2.3 Post Conditions 15
2.4 Actors and Roles 16
2.5 Use Case Flow Diagram 17
2.6 Scenarios for reporting an initial case report to public health 18
3 Data Requirements and IG Template Specifications Organization 20
3.1 Conventions used in this implementation guide 20
3.2 Use of vocabulary standards 21
3.3 Template Hierachy 22
4 document Templates 23
4.1 Initial Public Health Case Report Document (eICR) - Ballot 23
4.1.1 Properties 23
4.2 US Realm Header (V3) - Published 29
4.2.1 Properties 29
5 section Templates 42
5.3 Encounters Section (entries required) (V3) - Published 42
5.4 History of Present Illness Section - Published 43
5.5 Medications Administered Section (V2) - Published 43
5.6 Problem Section (entries required) (V3) - Published 44
5.7 Reason for Visit Section - Published 45
5.8 Results Section (entries optional) (V3) - Published 45
5.9 Social History Section (V3) - Published 46
6 entry Templates 48
6.3 Encounter Activity (V3) - Published 48
6.4 Encounter Diagnosis (V3) - Published 49
6.5 Indication (V2) - Published 50
6.6 Medication Activity (V2) - Published 51
6.7 Medication Information (V2) - Published 55
6.8 Problem Concern Act (V3) - Published 56
6.9 Problem Observation (V3) - Published 58
6.10 Result Observation (V3) - Published 60
6.11 Result Organizer (V3) - Published 61
6.12 Social History Observation (V3) - Published 62
7 Datatype Templates 64
7.3 US Realm Address (AD.US.FIELDED) - Published 64
7.4 US Realm Date and Time (DTM.US.FIELDED) - Published 64
7.5 US Realm Patient Name (PTN.US.FIELDED) - Published 65
7.6 US Realm Person Name (PN.US.FIELDED) - Published 66
8 Template Ids in This Guide 67
9 Value Sets In This Guide 68
10 Code Systems in This Guide 91
Table of Tables
Table 30: Administrative Gender (HL7 V3) 21
Table 1: Initial Public Health Case Report Document (eICR) Contexts 23
Table 2: US Realm Header (V3) Contexts 29
Table 3: Encounters Section (entries required) (V3) Contexts 42
Table 4: History of Present Illness Section Contexts 43
Table 5: Medications Administered Section (V2) Contexts 43
Table 6: Problem Section (entries required) (V3) Contexts 44
Table 7: Reason for Visit Section Contexts 45
Table 8: Results Section (entries optional) (V3) Contexts 45
Table 9: Social History Section (V3) Contexts 46
Table 10: Encounter Activity (V3) Contexts 48
Table 11: Encounter Diagnosis (V3) Contexts 49
Table 12: Indication (V2) Contexts 50
Table 13: Medication Activity (V2) Contexts 51
Table 14: Medication Information (V2) Contexts 55
Table 15: Problem Concern Act (V3) Contexts 56
Table 16: Problem Observation (V3) Contexts 58
Table 17: Result Observation (V3) Contexts 60
Table 18: Result Organizer (V3) Contexts 61
Table 19: Social History Observation (V3) Contexts 62
Table 20: US Realm Address (AD.US.FIELDED) Contexts 64
Table 21: US Realm Date and Time (DTM.US.FIELDED) Contexts 64
Table 22: US Realm Person Name (PN.US.FIELDED) Contexts 66
Table 23: Template Containments 67
Table 24: EncounterTypeCode 68
Table 25: Reportable Condition Trigger Codes - RCTC 69
Table 26: Race 69
Table 27: HL7 BasicConfidentialityKind 70
Table 28: Language 70
Table 29: Telecom Use (US Realm Header) 70
Table 30: Administrative Gender (HL7 V3) 71
Table 31: Marital Status 71
Table 32: Religious Affiliation 72
Table 33: Race Category Excluding Nulls 72
Table 34: Ethnicity 72
Table 35: Personal And Legal Relationship Role Type 73
Table 36: Country 73
Table 37: PostalCode 73
Table 38: LanguageAbilityMode 74
Table 39: LanguageAbilityProficiency 74
Table 40: Detailed Ethnicity 75
Table 41: Healthcare Provider Taxonomy (HIPAA) 76
Table 42: INDRoleclassCodes 77
Table 43: x_ServiceEventPerformer 77
Table 44: ParticipationFunction 78
Table 45: Problem 79
Table 46: Problem Type 80
Table 47: MoodCodeEvnInt 80
Table 48: Medication Route FDA 81
Table 49: Body Site 82
Table 50: UnitsOfMeasureCaseSensitive 83
Table 51: AdministrationUnitDoseForm 83
Table 52: ActStatus 84
Table 53: Medication Clinical Drug 84
Table 54: Clinical Substance 85
Table 55: ProblemAct statusCode 86
Table 56: Result Status 86
Table 57: Observation Interpretation (HL7) 87
Table 58: Social History Type 88
Table 59: PostalAddressUse 89
Table 60: StateValueSet 89
Table 61: EntityNameUse 90
Table 62: EntityPersonNamePartQualifier 90
Table 63: Code Systems 91
1 Introduction
1.1 Purpose
The purpose of this implementation guide (IG) is to specify a standard for the submission of an electronic initial case report (eICR) in Clinical Document Architecture, Release 2 (CDA R2) US Realm format built upon Consolidated CDA (C-CDA) templates. The submission of public health case reports for specific infectious and non-infectious conditions is required by law in all States and Territories in the United States. In addition to supporting critical public health functions in State, Local, and Territorial Public Health Agencies (PHAs), the data from these case reports will also indirectly support notifications by PHAs to the Centers for Disease Control and Prevention (CDC) for the Nationally Notifiable Disease Surveillance System (NNDSS) and nationwide disease monitoring.
This interoperability standard will enable the reporting of events of public health interest from clinical care Electronic Health Record (EHR) technology and associated workflows. It offers the potential of enabling improved public health reporting by facilitating information exchange between clinical care and public health with less burden for both. Doing so may also involve other new interoperability standards and potential functional changes in EHRs and public health surveillance systems. Case reporting from EHRs is important to public health surveillance for under-reported clinical cases, emergency management of new conditions and for conditions for which a lab result is not a definitive criterion. Case reporting from EHRs also complements electronic laboratory reporting by providing critical clinical and demographic data that lab results do not convey.
The eICR is termed “initial” because the report will usually be the first report made to public health, containing just enough pertinent data for PHAs to initiate investigation or other appropriate public health activities as necessary. In some instances this report may be initiated after a phone call is made to public health in the event that an immediately telephonically reportable event is suspected. These electronic reports could be initiated manually by the clinician, or may be automatically initiated by the EHR when updated patient data is matched against a series of public health reportable condition trigger codes. The eICR will also, at times, be manually initiated. The eICR will then convey core, initial case data to a PHA that will be the same for all reportable conditions in all jurisdictions to ease integration by EHR vendors and clinical care organizations so they can support this critical public health function. Common data elements for the eICR were identified by a task force of the Council of State and Territorial Epidemiologists (CSTE) (Appendix A). The data for the eICR are drawn from those known to be in electronic form in certified EHRs and are critical for reporting or the initiation of a public health investigation. These data elements were mapped to Consolidated Clinical Document Architecture (C-CDA) templates.
In some circumstances the eICR will be all that is needed to support public health reporting. This will represent a significant advance in the electronic data PHAs receive from EHRs on reportable conditions. The eICR may also lead to additional reporting or follow-up intended to confirm reportability, provide condition-specific or public health jurisdiction-specific reporting data, or support public health investigation, contact tracing, and/or countermeasure administration.
The eICR itself may be conveyed or referenced by a number of different transport methods. It will serve as input to reportability evaluation, including public health decision support systems, such as the CSTE / CDC Reportable Conditions Knowledge Management System (RCKMS[1]) and others. The HL7 Structured Data Capture (SDC) standard may be a good complement to the eICR for the purpose of manually capturing supplemental disease-specific data into forms. Receiving an eICR will also allow PHAs to communicate the reportability of a condition back to clinical care personnel and provide information about the health status of individual patients and of the community.
1.2 Audience
This IG is designed to provide EHR vendors with the specifications for developing the functionality of EHRs used in hospitals and by ambulatory care providers to report potential cases of reportable conditions to PHAs. This IG is also designed to provide public health surveillance systems developers the specifications for implementing functionality used by PHAs to receive and process the eICRs. The IG will also be informative to health care providers, public health staff, analysts, and health information exchange organizations. Users of this IG must be familiar with the details of the HL7 CDA R2 document construction and the C-CDA templates.
1.3 Background
State, Local and Territorial laws and regulations require the reporting of cases and, at times, suspected cases of certain infectious and noninfectious conditions to public health agencies to support disease monitoring and surveillance. For the purpose of this implementation guide, related notifications to the Centers for Disease Control and Prevention (CDC) and between PHAs is not in scope. At times, Electronic Laboratory Reporting (ELR), the transmission of lab results from a Laboratory Information Management System (LIS) has, for those diseases where lab testing is diagnostic, been helpful in identifying cases. Clinical laboratory result messages, however, frequently lack critical clinical data and demographic data needed for surveillance.
While case reporting from clinical care to Public Health Agencies is considered to be a core public health function, its electronic implementation has been slow to advance nationally because of a number of challenges. Laws requiring the reporting of infectious and non-infectious conditions are written individually by each State and Territory. Geographic differences in condition prevalence and other jurisdictional variations have created a complex array of reporting expectations for providers to know when, where, and what to report. Healthcare providers, for their part, have been historically inconsistent in reporting from clinical care by any process. A recent CDC study indicated that of the cases of Lyme disease recorded as a clinical diagnosis in clinical care, only about one out of ten are reported to the appropriate Public Health Agency.