U.S. Health and Human Services
Office of the National Coordinator for Health IT
Standards & Interoperability Framework
Public Health Reporting Initiative
Data Harmonization Profile
Version 2.0
February 13, 2013
1
Office of the National Coordinator for Health Information Technology
Table of Contents
Table of Contents ............................................................................................................................... 2
Summary of Tables ............................................................................................................................ 4
Table of Figures ................................................................................................................................. 5
Acknowledgements............................................................................................................................ 6
Executive Summary............................................................................................................................ 7
1. Introduction to Public Health Reporting Initiative – Data Harmonization Profile.............................. 8
S&I Public Health Reporting Initiative.............................................................................................. 8
Intent of Public Health Reporting Data Harmonization Profile ....................................................... 8
In Scope ................................................................................................................................ 9
Out of Scope ......................................................................................................................... 9
Approach to Development............................................................................................................. 10
Data Element Categorization.............................................................................................. 11
Potential Impact of Data Element Categorization .............................................................. 15
Use of S&I Framework Clinical Element Data Dictionary (CEDD) ....................................... 16
Use of Federal Health Information Model (FHIM) ............................................................. 17
Data Harmonization Profile Principles ............................................................................... 17
Users Guide .................................................................................................................................... 18
2. Organization of Public Health Data Harmonization Profile Document ........................................... 18
Domain Definition Table ................................................................................................................ 18
Object Definition Table .................................................................................................................. 19
Data Element Definition Table ....................................................................................................... 20
Use of Additional Information/Data Elements .............................................................................. 21
Public Health Reporting Value Sets and Vocabularies ................................................................... 21
Public Health Reporting Data in the FHIM ..................................................................................... 21
3. Public Health Reporting Data Harmonization Profile: Categorization of Data Elements .................. 22
Allergy / Adverse Event .................................................................................................................. 27
Employment information............................................................................................................... 30
Encounter / Patient Visit ................................................................................................................ 32
Exposure / Injury ............................................................................................................................ 34
Facility ............................................................................................................................................ 36
Family History ................................................................................................................................ 37
Health Problem / Diagnosis ........................................................................................................... 39
Immunization ................................................................................................................................. 42
Medical Devices ............................................................................................................................. 45
Medication ..................................................................................................................................... 47
Order / Diagnostic Test .................................................................................................................. 51
Patient Contact Information .......................................................................................................... 52
Patient Information........................................................................................................................ 53
Payer Information .......................................................................................................................... 55
Physical Exam ................................................................................................................................. 56
Procedure....................................................................................................................................... 58
Provider Information ..................................................................................................................... 59
Report MetaData ........................................................................................................................... 61
Result ............................................................................................................................................. 63
Social History.................................................................................................................................. 65
Specimen........................................................................................................................................ 66
2
Office of the National Coordinator for Health Information Technology
Vital Sign Indicator ......................................................................................................................... 68
4. Public Health Data Harmonization Profile – Domain Considerations ............................................. 70
Summary of Selection Criteria by Domain ..................................................................................... 70
Adverse Event ................................................................................................................................ 72
Child Health/ Newborn Screening ................................................................................................. 72
Chronic Disease .............................................................................................................................. 72
Communicable Disease .................................................................................................................. 72
Infrastructure, Quality and Research ............................................................................................. 73
5. Data Harmonization Profile - Implementation Alignment ............................................................. 73
ISDS Syndromic Surveillance Recommendation Alignment........................................................... 73
CSTE Workgroup Recommendation Alignment ............................................................................. 74
HITSP C83 Content Modules Alignment ........................................................................................ 76
FHIM Implementation Alignment .................................................................................................. 77
Consolidated CDA Alignment ......................................................................................................... 78
6. Limitations, Lessons Learned, and Next Steps ............................................................................... 79
Data Harmonization Limitations .................................................................................................... 79
Lessons Learned ............................................................................................................................. 79
Next Steps ...................................................................................................................................... 81
Appendix A – Summary of Data Element Optionality......................................................................... 83
Data Element Optionality....................................................................................................................... 83
Examples of NULL Flavors .............................................................................................................. 83
Entity Optionality ................................................................................................................................... 83
Appendix B – Acronyms ................................................................................................................... 86
Appendix C – References .................................................................................................................. 88
Appendix D – Submitted User Stories ............................................................................................... 90
Appendix E – Federal Health Information Model (FHIM) ................................................................... 92
3
Office of the National Coordinator for Health Information Technology
Summary of Tables
Table 1 – Defining Core, Report Type, and Implementation Specific Data Elements ................12
Table 2 – Potential Impact of Data Element Classification ........................................................16
Table 3 – Quick Reference Guide .............................................................................................18
Table 4 – Current Public Health Reporting Domains .................................................................19
Table 5 – Summary of Object Definition Table ..........................................................................20
Table 6 – Summary of Data Element Definition Table ...............................................................20
Table 7 – Summary of Terminology Sources Used ...................................................................21
Table 8 – Allergy / Adverse Events Object Summary ................................................................27
Table 9 – Allergy / Adverse Events Data Elements ...................................................................29
Table 10 – Employment information Object Summary...............................................................30
Table 11 – Employment Information Data Elements .................................................................32
Table 12 – Encounter / Patient Visit Object Summary ...............................................................33
Table 13 – Encounter / Patient Visit Data Elements ..................................................................34
Table 14 – Exposure/Injury Object Summary ............................................................................35
Table 15 – Exposure Data Elements .........................................................................................36
Table 16 – Facility Object Summary..........................................................................................37
Table 17 – Facility Data Elements .............................................................................................37
Table 18 – Family History Object Summary ..............................................................................38
Table 19 – Family History Data Elements .................................................................................39
Table 20 – Diagnosis Object Summary .....................................................................................40
Table 21 – Health Problems Data Elements ..............................................................................42
Table 22 – Immunization (Vaccination) Object Summary ..........................................................43
Table 23 – Immunization Data Elements ...................................................................................45
Table 24 – Medical Devices Object Summary ...........................................................................46
Table 25 – Medical Devices Data Elements ..............................................................................47
Table 26 – Medication Object Summary....................................................................................47
Table 27 – Medication Data Elements.......................................................................................50
Table 28 – Order/ Diagnostic Test Object Summary .................................................................51
Table 29 – Order / Diagnostic Test Data Elements ...................................................................52
Table 30 – Patient Contact Information Object Summary ..........................................................52
Table 31 – Patient Contact Information Data Elements .............................................................53
Table 32 – Patient Information Object Summary .......................................................................54
Table 33 – Patient Information Data Elements ..........................................................................55
Table 34 – Payer Information Object Summary .........................................................................56
Table 35 – Payer Information Data Elements ............................................................................56
Table 36 – Physical Exam Object Summary .............................................................................57
Table 37 – Physical Exam Data Elements.................................................................................58
Table 38 – Procedure Object Summary ....................................................................................59
Table 39 – Procedure Data Elements .......................................................................................59
Table 40 – Provider Information Object Summary .....................................................................60
Table 41 – Provider Information Data Elements ........................................................................61
Table 42 – Report MetaData Object Summary ..........................................................................62
4
Office of the National Coordinator for Health Information Technology
Table 43 – Report MetaData Data Elements .............................................................................63
Table 44 – Result Object Summary...........................................................................................64
Table 45 – Result Data Elements ..............................................................................................65
Table 46 – Social History Object Summary ...............................................................................65
Table 47 – Social History Data Elements ..................................................................................66
Table 48 - Specimen Object Summary ......................................................................................67
Table 49 – Specimen Data Elements ........................................................................................68
Table 50 – Vital Sign Indicators Object Summary .....................................................................69
Table 51 – Vital Sign Indicators Data Elements.........................................................................69
Table 52 – Summary of Selection Criteria by Domain ...............................................................71
Table 53 - Summary of Implementation Alignments ..................................................................73
Table 54 - ISDS Syndromic Surveillance Recommendations - Alignment to Data Harmonization
Profile .......................................................................................................................................74
Table 55 - CSTE Workgroup Recommendations - Alignment to Data Harmonization Profile .....76
Table 56 - HITSP C83 Content Module Alignment View............................................................77
Table 57 - Federal Health Information Model (FHIM) Alignment ................................................78
Table 58 - Consolidated CDA Alignment ...................................................................................79
Table 59 - Summary of Data Element Optionality......................................................................83
Table 60 - Summary of Conformance Criteria ...........................................................................85
Table 61 - Definitions and Acronyms Used in Data Harmonization Profile.................................87
Table 62 - Data Harmonization Profile References ...................................................................89
Table of Figures
Figure 1 - Data Harmonization Process.....................................................................................11
Figure 2 – Content of Public Health Report (Example) ..............................................................13
Figure 3 – Core Common, Report Type, and Implementation Specific Data Elements (Cancer
Report Example) .......................................................................................................................14
Figure 4 - Example of Creating a Chronic Disease Public Health Report (using survey
questions) .................................................................................................................................14
Figure 5 - Core Common (Overlap across Public Health Reporting Domains)...........................19
5
Office of the National Coordinator for Health Information Technology
Acknowledgements
The Public Health Reporting Initiative would like to thank the leaders and members of the Data Mapping
Subworkgroup for their participation and work to discuss and develop the common core data elements
for public health reporting described in this Data Harmonization Profile. Nikolay Lipskiy (CDC) and Riki
Merrick (APHL) co-led the Data Mapping Sub-workgroup with support from a technical writing team led
by Erik Pupo (Deloitte Consulting, LLC).
Anna Orlova
Brian Castor
Cynthia Vinion
Dina Dickerson
Eileen Storey
Erik Pupo
Galen Mulrooney
Genny Luensman
Hwa-Gan Chang
John Abellera
John Eichwald
John Stinn
Kelly Friar
Kerry Souza
Kevin McAloon
Lindsay Brown
Lise Stevens
Lura Daussat
Maiko Minami
Margaret Filios
Michael Coletta
Michelle Williamson
Nikolay Lipskiy
Riki Merrick
Rita Altamore
Robert Savage
Seth Foldy
Sheila Abner
Steven Wagner
Sundak Ganesan
Susan Terrillion
Therese Hoyle
Wendy Blumenthal
Wendy Scharber
Public Health Data Standards Consortium (PHDSC)
Deloitte Consulting, LLC
Northrup Grumman Corporation
Oregon Health Authority
Centers for Disease Control and Prevention (CDC)
Deloitte Consulting, LLC
Federal Health Architecture (FHA)
Centers for Disease Control and Prevention (CDC)
Centers for Disease Control and Prevention (CDC)
Centers for Disease Control and Prevention (CDC)
Centers for Disease Control and Prevention (CDC)
Deloitte Consulting, LLC
Centers for Disease Control and Prevention (CDC)
Centers for Disease Control and Prevention (CDC)
Partners Healthcare Analytics
Deloitte Consulting, LLC
Food and Drug Administration (FDA)
Oz-Systems
HLN Consulting
Centers for Disease Control and Prevention (CDC)
National Association of City and County Health Officials (NACCHO)
Centers for Disease Control and Prevention (CDC)
Centers for Disease Control and Prevention (CDC)
Association of Public Health Laboratories (APHL)
Washington Department of Health
Centers for Disease Control and Prevention (CDC)
Centers for Disease Control and Prevention (CDC)
Centers for Disease Control and Prevention (CDC)
Federal Health Architecture (FHA)
Centers for Disease Control and Prevention (CDC)
Agency for Health Research and Quality (AHRQ)
Public Health Informatics Institute (PHII)
Centers for Disease Control and Prevention (CDC)
Registry Widgets
6
Office of the National Coordinator for Health Information Technology
Executive Summary
The Standards and Interoperability (S&I) Framework Public Health Reporting Initiative (PHRI) is a
community-led project focused on streamlining public health reporting and ensuring EHR
interoperability with public health information systems. In pursuit of this goal, the PHRI has developed
this data harmonization profile to reflect the common core data elements for public health reporting,
including harmonized data element names, descriptions, formats, and value sets. The common core
data elements are those elements that are widely used across public health reporting programs;
however the common core data elements are not necessarily required by all public health reporting
programs, nor does the common core set of data elements include every data element needed for most
public health report – many public health reports will use additional data elements in addition to the
common core. (Note that such “report type specific” or “implementation specific” data elements are
defined but are outside the scope of this document. This Data Harmonization Profile identifies data
elements that can be represented identically across multiple types of public health reports and may be
extended in the future.) To enhance public health reporting, the PHRI envisions a scenario in which EHR
systems would be able to create and capture all of the common core data elements described in this
document, allowing public health reporting programs to select required elements among the common
core to meet specific business needs.
To identify the common core data elements, the PHRI first solicited user stories and reporting scenarios
across the public health community. These stories were analyzed and discussed in small working groups
organized around the public health domains of adverse events, child health, chronic disease,
communicable disease, and infrastructure, quality and research. Through domain specific discussions,
data elements specific to each user story reporting scenario were requested and examined. These
submitted user story data elements were evaluated for commonality and re-usability across user stories
to determine common core data elements for public health reporting. These submitted elements were
also mapped to reusable clinical elements identified in other S&I Framework activities, documented in
the S&I Framework Clinical Element Data Dictionary (CEDD). The Data Mapping Subworkgroup
examined the names and definitions of each of these data elements and spent a considerable amount of
time identifying, discussing, and harmonizing applicable value sets, referencing the Public Health
Information Network (PHIN) Vocabulary Access and Distribution System (VADS), for the common core
data elements. The outcome of this work is presented in this Data Harmonization Profile.
The Data Harmonization Profile documents the common core data elements (organized into objects),
their alignment to International Society for Disease Surveillance (ISDS) and Council of State and
Territorial Epidemiologists (CSTE) recommendations as well as Healthcare Information Technology
Standards (HITSP), Federal Health Information Model (FHIM), and Clinical Document Architecture (CDA)
concepts, and includes information about public health domain usage of these elements. Finally the
document outlines the key limitations, lessons learned, and next steps identified by the PHRI throughout
the process of harmonization. These limitations include the availability of dedicated resources and the
limited scope of the first phase of the PHRI. Next steps include determining maintenance of this
harmonized set of common core data elements, defining implementation guidance and pilots based on
these concepts, and broadening the scope of the public health reporting scenarios in the future.
7
Office of the National Coordinator for Health Information Technology
1. Introduction to Public Health Reporting Initiative – Data
Harmonization Profile
S&I Public Health Reporting Initiative
The S&I Framework Public Health Reporting Initiative (PHRI) is a community-led project focused on
simplifying public health reporting and ensuring Electronic Health Record (EHR) interoperability with
public health information systems. PHRI hopes to create a new public health reporting objective for
Meaningful Use (MU) Stage 3 that is broader than the current program-specific objectives and will lay
the ground work for public health reporting in the future.
The work of this PHRI and contained in this document is based on User Stories and Use Cases that were
submitted by public health (PH) practitioners in the field articulating the business processes used to
achieve their goals across five public health domains: Communicable Disease, Chronic Disease, Child
Health/Newborn Screening, Adverse Events and Infrastructure, Quality and Research (IQR).
By looking across these five domains of public health and identifying specific areas of commonality, this
profile will be helpful as the Public Health Reporting Initiative moves into its next phase of development,
which is focused on a common implementation guide format for public health reporting domains.
Note that user stories from the Infrastructure, Quality, and Research domain were deemed out of scope
for the first phase of the PHRI and as such are not addressed in this document. A full list of user stories
and the domains into which they are classified can be found at
http://wiki.siframework.org/PH+Reporting+User+Stories.
Intent of Public Health Reporting Data Harmonization Profile
The Public Health Reporting Data Harmonization Profile serves as a tool for implementers to use in
defining public health data to be used in support of reporting requirements. This alignment analysis
serves as one building block within the larger Public Health Reporting Initiative technical approach, and
is intended to give implementers a foundation to work from when constructing public health data
reporting guides and specifications. For those specifications that will be developed to support the PHRI,
this profile may enhance the speed of development of these new guides by providing information about
harmonized data elements. For those specifications that have already been created, this profile may
provide additional clarity for structuring those specifications to support structured data.
This tool documents the data needed to support public health reporting in a variety of formats. Working
examples are provided to assist implementers and vendors in structuring source data to support public
health reporting. This Data Harmonization Profile is focused on providing content for the Public Health
Reporting domains, their alignment, and on identifying gaps in public health data representation as
compared to common clinical record data formats (such as HITSP C83 and the EHR-FM (Functional
Model)).
8
Office of the National Coordinator for Health Information Technology
Because the Public Health Reporting harmonization approach intends to support multiple
implementation paths, this “map and model” driven approach allows for common data elements to be
mapped to the underlying implementation representations, and creates models and supporting
documentation to help implementers and vendors ensure alignment to the Public Health Reporting
specifications. This document includes information to support not only the PHRI but also any public
health reporting program, or implementation of activities such as continuity of care communication or
quality reporting, that wishes to leverage these harmonized data elements.
The Public Health Reporting Data Harmonization Profile is not intended to be prescriptive to any public
health reporting program, but rather serve as a resource for programs to help encourage
interoperability and reduce variability in reporting requirements. The document will focus on data
elements that can be used across many public health reporting domains, while acknowledging the need
for more specific data elements to support individual, specific reporting processes) A companion
document, the PHRI Functional Requirements1, describes the business processes associated with public
health reporting.
In Scope
The following activities are in scope for the Data Harmonization Profile document:



Identifying and reviewing public health data needs through user stories and PHRI member input
(i.e., reviewing the “Data Element Spreadsheets”)
Aligning user story needs to public health data elements
Classifying public health data elements as “core common” data elements for public health
reporting and proposing definitions as well as recommending value sets, formats, and standards
to support these data elements and reduce variability
Out of Scope
The PHRI anticipates that generic types of reports (e.g., a tuberculosis report) might contain additional
“report type specific” data elements and specific implementations (e.g., tuberculosis reporting in
California) may require “implementation specific” data elements. The concept of “report type” and
“implementation” specific data elements will be defined below, but the identification of these data
elements is out of scope for this Data Harmonization Profile. Additionally, the alignment of data
elements to any specific content exchange format, for example HL7 Consolidated CDA, is also out of
1
The PHRI Functional Requirements can be found online at
http://wiki.siframework.org/PHRI+Harmonization+and+Standards+Materials
9
Office of the National Coordinator for Health Information Technology
scope for this document.2 However, an indirect mapping to consolidated CDA may be possible as the
CEDD is mapped to consolidated CDA.
Approach to Development
The PHRI collected information from the public health community in the form of reporting programspecific user stories – each representing a specific public health reporting process and set of
requirements. These user stories were harmonized across workflow, functional requirements, and
common processes in the PHRI Use Case and Functional Requirements documents.3 Each user story
submitter was also asked to provide the data elements required to support the reporting process,
including the name, description, format, and value set for each element. The collected elements were
mapped to the S&I Framework Clinical Element Data Dictionary (CEDD) and the Federal Health
Information Model (FHIM) as a framework for analysis and assessment of commonality.
The PHRI categorized data elements into three groups:
 Core Common Data Elements – harmonized data elements that are widely shared across several
report types. Expect EHR systems to be able to produce these data elements but public health
systems may choose to receive these elements at their discretion. The core common data
elements are the primary focus of this Data Harmonization Profile.
 Report Type Specific Data Elements – harmonized data elements (although variance is allowed
where necessary) that are broadly required across public health for a specific report type (e.g., a
communicable disease case report for Tuberculosis (TB), a birth record report, etc.). Special
effort should be taken to harmonize elements between different report types, but this is a
secondary effort of the PHRI at this time. Where possible, report type data elements are
detailed and harmonized within this document, but future companion documents may be
required to cover data elements for various types of reports.
 Implementation Specific Data Elements – additional, relatively unique, or non-harmonized data
elements required by a particular jurisdiction or public health program (e.g., a TB report in
California). Defining these elements is out of scope for the Data Harmonization Profile.
The following figure, Figure 1, describes how core common data elements were derived and the role of
core common, report type and implementation specific data elements in the creation of implementation
guides.
2
The PHRI Implementation specification, currently under development by the PHRI, will include
guidance about a content exchange format as discussed by a select group of public health reporting
programs. More information about the implementation specification can be found here:
http://wiki.siframework.org/PHRI+Implementation+Guide
3
The PHRI Use Case is available here: http://wiki.siframework.org/PH+Reporting+User+Stories and the
functional requirements are available here:
http://wiki.siframework.org/PHRI+Harmonization+and+Standards+Materials
10
Office of the National Coordinator for Health Information Technology
Figure 1 - Data Harmonization Process
For the purposes of Implementation Guides, Report Type Specific and Implementation Specific Data
Elements (defined by specific reporting programs) may be developed to expand the core common set of
data elements into a set that satisfies all of the requirements for a particular public health report type.4
The Data Harmonization Profile will present a set of core common data elements based on collaborative
work across the Public Health Reporting Initiative and guidance from the Data Mapping Subworkgroup.
Data Element Categorization
The categorization approach creates a clearer picture to harmonize public health data elements and to
align them to implementable standards. The core common data elements may simplify the development
and enhancement of implementation guides for eventual inclusion into current regulatory processes,
such as Meaningful Use Stage 3.
In the following table (Table 1), the rules related to defining data elements in the Data Harmonization
Profile are described.
4
For example, a “hearing screening report type” may include objects not presented in this document
which contain report type specific data elements. Defining the full set of report type specific data
elements for each user story is out of scope for this document.
11
Office of the National Coordinator for Health Information Technology
What are they?
Core Common Data
Elements
Report Type Specific
Data Elements
ImplementationSpecific Data Elements
What rules are used to define them?
Core Common Data Elements meet at least
one of the following criteria:
 Exist across at least 2 of the 5
domains defined within PHRI
 Exist across at least 3 user stories
defined as part of PHRI
 Are already included in a published
set of core data elements (e.g., CSTE
and ISDS)
 Were recommended by the Data
Mapping Subworkgroup or Stage 3
Sprint Subworkgroup of the PHRI
Note that section 4 provides an overview of
the user stories that utilize each core
common object.
Report type specific data elements may be
harmonized within particular domains (e.g.,
communicable disease case reporting) and
serve to ‘extend’ or add to the core common
data element to meet the requirements of
specific programs. Report type specific data
elements (which are out of scope for this
document) may pull from harmonized
elements developed in future phases.
Specific only to 1 public health report
How do we test for them?
Conformance (e.g., required or
optional) may vary across
domains or specific types of
PH reports depending on the
standard used to represent
the public health report
An example of a core data
element is “patient name”.
Conformance is specific to
domains and public health
reports. Conformance within a
domain may still vary, but
EHR/HIT vendors are
encouraged to include these
data elements or interfaces in
the first or subsequent
releases of their product(s).
For example, cancer reports
will have tighter constraints on
cancer diagnoses and how
they are coded than an
occupational health report.
Conformance is specific only
to 1 public health report, for
example in a given jurisdiction.
Table 1 – Defining Core, Report Type, and Implementation Specific Data Elements
The following figure, Figure 2, describes how core common, report type, and implementation specific
data elements combine to create a specific public health report.
12
Office of the National Coordinator for Health Information Technology
Figure 2 – Content of Public Health Report (Example)
The example in the figure below (figure 3) uses a specific example around cancer reporting to show how
different levels (core, report type, and implementation specific) can be used to classify data elements;
the classification allows for requirement traceability from a user story to an implementation.
13
Office of the National Coordinator for Health Information Technology
Figure 3 – Core Common, Report Type, and Implementation Specific Data Elements (Cancer Report Example)
One consideration for the Data Harmonization Profile is capturing and representing forms or
questionnaire responses (or question and answer situations in a clinical setting) in implementation
guides. For many user stories, there is an expectation that data elements may be expressed in a clinical
setting as a question and associated answer. The data harmonization profile highlights that the
expected answer would be a coded value, indicating that a diagnosis or condition is present. The only
time this rule does not apply is when a coded value is not available for representation. The following
figure, figure 4, depicts an example of a question and answer situation in a clinical setting, with coded
information distilled from the encounter and sent to a public health agency.
Figure 4 - Example of Creating a Chronic Disease Public Health Report (using survey questions)
14
Office of the National Coordinator for Health Information Technology
Potential Impact of Data Element Categorization
The PHRI recognizes that the classification of data elements into core common, report type, and
implementation specific may affect participants in the public health reporting process, including
regulatory bodies responsible for Meaningful Use, EHR vendors, public health information system
vendors, national, state, local, tribal, and territorial programs, as well as the PHRI membership. The
following table summarizes potential impact to each of these groups:
Community
Core Common Data Elements
Legislative (MU Stage 2 & 3)
EHR vendors
Public Health Information System Vendors
National, State, local, tribal, and territorial public
health programs
S&I PHRI
Potential Impact
Include in MU certification criteria for PH
reporting, updating test procedures and
conformance rules
Products must support these data elements and
interfaces to support PH reporting
Products meet requirements of PH program.
Should be aware of what is available in EHR for
inclusion in PH report, and potentially PH
system.
Harmonization was performed based on
contributed user stories which may differ across
jurisdictions, thus harmonized elements may
differ from those in local use elsewhere.
Serve as primary content for harmonization
across participating PH domains (captured in
this Data Harmonization Profile)
Report Type Specific Data Elements (not included in this Data Harmonization Profile)
Legislative (MU Stage 2 & 3)
Include for domain-specific MU objectives
developed directly by programs (e.g.,
Healthcare Associated Infections (HAI), Cancer),
updating test procedures and conformance
rules
EHR vendors
Support these data elements and/or interfaces
Public Health Information System Vendors
Products meet requirements of PH program.
Should be aware of what is available in EHR for
inclusion in PH report, and potentially PH
system.
National, State, local, tribal, and territorial public
Harmonization out of scope for this Data
health programs
Harmonization Profile, but may be considered in
future phases
S&I PHRI
Harmonization out of scope for this Data
Harmonization Profile, but may be considered in
15
Office of the National Coordinator for Health Information Technology
Community
Potential Impact
future phases
Implementation Specific Data Elements (not included in this Data Harmonization Profile)
Legislative (MU Stage 2 & 3)
May not be part of EHR requirements in MU;
Potential Centers for Medicare and Medicaid
Services (CMS) requirement to accommodate
jurisdictional specificity that should be reflected
in products
EHR vendors
Encouraged to support, but requires continual
monitoring and understanding to determine if
alignment and inclusion is possible.
Public Health Information System Vendors
Products meet requirements of PH program.
Should be aware of what is available in EHR for
inclusion in PH report, and potentially PH
system.
National, State, local, tribal, and territorial public
Harmonization out of scope for this Data
health programs
Harmonization Profile, but may be considered in
future phases
S&I PHRI
Harmonization out of scope for this Data
Harmonization Profile, but may be considered in
future phases
Table 2 – Potential Impact of Data Element Classification
Use of S&I Framework Clinical Element Data Dictionary (CEDD)
To build the Public Health Reporting Data Harmonization Profile, the S&I Framework CEDD5 and its
repository of data elements and their corresponding definitions and attributes were leveraged. The S&I
CEDD lists the data elements and corresponding definitions that are used by a variety of stakeholders
comprising functional and technical experts within the S&I Framework, and includes clinical and
administrative data elements. Wherever possible, the Public Health Reporting Data Harmonization
Profile specifically reuses data elements defined within other S&I Framework initiatives and within
healthcare standards such as the Health Level 7 (HL7) Clinical Care Document (CCD), HL7 Consolidated
CDA, and controlled vocabularies such as Systematized Nomenclature of Medicine – Clinical Terms
(SNOMED-CT®).
5
The CEDD can be found here: http://wiki.siframework.org/file/view/S%26I%20Framework%20%20Clinical%20Element%20Data%20Dictionary%20%28Public Health Domain Data Alignment%29%20%20Value%20Set%20Index%20-%20Version%200.1.docx
16
Office of the National Coordinator for Health Information Technology
Use of Federal Health Information Model (FHIM)
The Federal Health Information Model, part of the Federal Health Architecture (FHA) project, was
utilized to model the common core data elements for public health reporting developed by the Public
Health Reporting Initiative and elaborated in this document. The FHIM Model can be found here:
https://www.fhims.org. The FHIM supports the core common data elements by modeling them as part
of the overall health information model, thereby integrating and harmonizing them with all of the other
content in the model, including content from federal partners representing providers, payers,
researchers, regulatory organizations and public health organizations and content from standards
organizations such as HL7 and HITSP. This harmonized information can then be used to generate health
information exchange standards for public health information by leveraging a model driven architecture
approach.
Data Harmonization Profile Principles
Several principles underlie development of the Public Health Reporting Data Harmonization Profile. They
are listed here to help implementers and vendors understand the context of how this specification was
developed:
 The Public Health Reporting Data Harmonization Profile is designed to support the requirements
outlined in the S&I Framework Public Health Reporting Use Case, with a focus on supporting
multiple public health domains and report types.
 The Public Health Reporting Data Harmonization Profile will reuse existing data types, models,
and data elements wherever possible.
 The Public Health Reporting Data Harmonization Profile is built to be transparent, intuitive, welldocumented, and easily understood by stakeholders. Supporting examples, code, and models
may be provided to assist implementers and vendors in piloting Public Health Reporting
specifications.
 The Public Health Reporting Data Harmonization Profile leverages evolving healthcare coding
standards and maps to existing information modeling efforts, such as the FHIM and the Clinical
Information Modeling Initiative (CIMI).
 Existing implementations should be leveraged as best practices for the Public Health Reporting
Data Harmonization Profile, to minimize any direct implementation-specific modifications or
transitional changes.
To make these principles actionable, the S&I Framework Public Health Reporting initiative focused work
on the Public Health Reporting Data Harmonization Profile in the following areas:
 Examine data elements defined in the S&I Framework Public Health Reporting user stories and
show how they align across multiple domains.
 Leverage the cumulative experience of vendors, implementers and other organizations involved
in public health reporting.
 Rely on existing and standardized coding schemas and ontologies, and be compatible with
existing implementations.
17
Office of the National Coordinator for Health Information Technology
Users Guide
A quick reference to the location of specific sets of data elements, content and mapping to FHIM is
included in Table 3, below:
Data Element
Location
Public Health Reporting Core Common Data Elements – data elements
found across public health reporting user stories, organized into objects,
including location in the FHIM.
References to submitted user stories and their specific data elements
Assessment of gaps, lessons learned, and next steps
Screenshots of FHIM content
Section 3
Section 4
Section 6
Appendix E
Table 3 – Quick Reference Guide
2. Organization of Public Health Data Harmonization Profile Document
The Public Health Reporting Data Harmonization Profile is designed to highlight commonality across the
different domains, as well as showcase commonalities at a domain level. Links to recommended value
sets are also defined within the Public Health Reporting Data Harmonization Profile, where available, to
help with the alignment of data elements.
The use of the word entity in the Data Harmonization Profile means “an object that holds data element”.
The use of the word entity and object is synonymous.
Domain Definition Table
Table 4, below, describes the report types associated with each of the domains that contributed to the
data elements contained in the Data Harmonization Profile.
Domain
Adverse Events
Child Health / Newborn Screening
Chronic Disease
Communicable Disease
User Story Data Elements
Adverse Drug Events (ADE) Spontaneous Triggered
Event Reporting (ASTER) 1
ASTER D
Individual Case Safety Reports (ICSR) R2
Agency for Healthcare Research and Quality
(AHRQ) Common Formats
Immunization
Vital Records
Newborn Hearing Screening
Cancer Genetics
Cancer Reporting
Occupational Health
National Hospital Care Survey (NHCS)
Communicable/Syndromic – Council of State and
Territorial Epidemiologists (CSTE) &
18
Office of the National Coordinator for Health Information Technology
Domain
User Story Data Elements
Infrastructure, Quality, and Research
International Society for Disease Surveillance
(ISDS)
Healthcare Associated Infections (HAI)
Currently out of scope for PHRI
Table 4 – Current Public Health Reporting Domains
The following graphic (Figure 5) shows how the public health reporting domains contribute to and share
a set of core common data elements. Additionally, each domain has specific data elements utilized only
by that domain that remain outside the core common data elements. The information in section 3
describes which domains use which objects. There is also a table in section 5 that describes which user
stories, organized into domains, use which objects, based on submitted data elements.
Figure 5 - Core Common (Overlap across Public Health Reporting Domains)
Object Definition Table
Objects are defined in this Data Harmonization Profile (with details provided in Section 3) as a
foundational building block for future public health reporting standardization. For each object, there is a
core set of data elements (that are defined regardless of domain); the objects can be extended by
adding data elements to meet specific programmatic, report type, or implementation specific
requirements (e.g., adding data elements to the encounter object to characterize a pregnancy visit). The
Core Common Data Elements are categorized into objects; table 5 summarizes how the Object
Definition Table is structured for each object presented in Section 3 of this profile:
References Used
The references used to create this object and the domain alignment
analysis
Public Health Domains
The specific domains that would require this object. This is where
Supported
specific conformance language is also listed, specific to that object.
19
Office of the National Coordinator for Health Information Technology
Implementation Models /
Modules Supported
If the word “Required” is not used, then conformance language is
included for SHOULD or MAY.
The different implementation models / modules that this object is also
represented in. There may be multiple models listed, including:








Alignment to HITSP C83 Content Modules
Alignment to EHR – Functional Model
Hospital-Acquired Infections (HAI) Content Module
ISDS/CSTE Communicable Diseases Content Module
Child Health/Immunization Content Module
Chronic Diseases Content Module
Adverse Events (FDA) Content Module
Federal Health Information Model (FHIM)
Table 5 – Summary of Object Definition Table
Data Element Definition Table
Each object within the Data Harmonization Profile will contain one or more data elements. Each of the
data elements is represented with the following values:
Data Element Name
The name of the data element
Data Element Definition
A definition of the data element – specifically focused on its context of
use within public health
Data Element Format
Identifies if the data element is a coded value, a string, a date/time, an
integer, or a physical quantity. It is important to note that the formats
used may vary depending on context (a format in one domain may
differ from formats in other domains) and data exchange mechanism.
These differences will be noted.
Vocabulary / Value Set
Examples and Guidelines
FHIM Mapping
Data Element Formats in the context of this profile are not prescriptive
but recommended.
A recommended vocabulary is proposed that may be drawn from
existing sources of information on standards-based value sets for this
data element. The Public Health Information Network (PHIN)
Vocabulary Access and Distribution System (VADS) is used as a primary
reference source
Examples and guidelines are provided from both the clinical and
technical perspective to assist with the representation of the data
element (as needed for clarity).
Identifies the location of the data element in the FHIM
Table 6 – Summary of Data Element Definition Table
20
Office of the National Coordinator for Health Information Technology
Use of Additional Information/Data Elements
For many public health report types, additional requirements may exist depending on the context of the
report. For example, a report type may require additional information to be included depending on the
age of the patient/subject, or the specific diagnosis or procedure of the patient/subject. Also, there are
report type specific data elements that cannot be ignored to implement specific reporting requirements
(i.e., Vaccine Information Statement (VIS) Type & Date for Immunization reporting). The Data
Harmonization Profile acknowledges that extensions to the set of common core data elements may be
required by public health reporting programs in the form of report type or implementation specific data
elements.
Public Health Reporting Value Sets and Vocabularies
This Data Harmonization Profile includes multiple vocabularies and value sets defined in current
implementations in use for population health reporting. This includes vocabularies and value sets that
may have already been defined as part of PHIN VADS, Unified Medical Language System (UMLS), and
HITSP, as well as other value sets specific to Standards Development Organizations, such as HL7 and
Integrating the Healthcare Enterprise (IHE). Each of these value sets was identified as part of this domain
alignment analysis, and included in both this analysis and in the CEDD Value Set Index. This index of
value sets allows for potential reuse by other S&I Framework initiatives which have similar functional or
information interchange requirements. Most existing vocabularies for Public Health Domain use are
collected and maintained by the U.S. Centers for Disease Control and Prevention (CDC) through the PHIN
VADS. The Public Health Reporting Initiative has suggested that this process should be continued and
additional data elements and value sets will be added to PHIN VADS as a result of the initiative’s
assessment.
The CEDD Value Set Index is
located at:
The PHIN VADS browser is
located at:
http://wiki.siframework.org/file/view/S%26I%20Framework%20%20Clinical%20Element%20Data%20Dictionary%20%28Public
Health Domain Data Alignment%29%20%20Value%20Set%20Index%20-%20Version%200.1.docx
http://phinvads.cdc.gov/vads/SearchHome.action
Table 7 – Summary of Terminology Sources Used
Public Health Reporting Data in the FHIM
Public Health Reporting data for all the core common data elements described in the next section has
been modeled in the FHIM. Modeling the information (and associated terminologies and value sets) in
the FHIM ensures that the information is harmonized and integrated with data that has already been
modeled to support other types of health organizations at the federal government level such as
providers, payers, research, regulators, and public health. The FHIM leverages PHIN VADS to store its
value sets which is consistent with the approach used by the PHRI. Modeling the Public Health
Reporting information in the FHIM provides an added advantage. The FHIM is integrated with a set of
21
Office of the National Coordinator for Health Information Technology
open source implementation modeling tools called Model Driven Health Tools (MDHT) and leverages
this integration and a model driven architecture (MDA) process to generate standardized health
information exchange (HIE) implementation guides. The models, implementation tools and MDA
processes are all freely available to the PHR Initiative for use in generating their standardized HIE
implementation guides as the PHR Initiative moves forward.
3. Public Health Reporting Data Harmonization Profile: Categorization
of Data Elements
Each of the entities listed below were analyzed as part of the Public Health Reporting initiative, and
further detail was provided based on analysis work done in the Data Mapping Sub-Workgroup. For the
purpose of this analysis, the term “object” is used to group data, and then individual data elements are
defined for each entity. The CSTE core common data elements document, for example, refers to these
specific objects as “categories.” The S&I Framework CEDD uses the word “object” to define entities.
FHIM also uses the term “entity” and “attribute” to describe the data structures it defines in its
model(s).
The following objects organize the core common set of data elements for the Public Health Reporting
Initiative:
 Allergy / Adverse Event
 Employment Information
 Encounter / Patient Visit
 Exposure / Injury
 Facility
 Family History
 Health Problem / Diagnosis
 Immunization
 Medical Devices
 Medication
 Order / Diagnostic Test
 Patient Contact Information
 Patient Information
 Payer Information
 Physical Exam
 Procedure
 Provider Information
 Report Metadata
 Result
 Social History
 Specimen
 Vital Sign Indicator
22
Office of the National Coordinator for Health Information Technology
Note that there is not a PHRI Object for “Risk Factors” because "Risk factors" are condition-dependent
and may be found in the social history, family history, health problem, exposure, and/or other existing
objects. Specific risk factors may be described in report type specific requirements/elements.
The following sections describe in detail data elements associated with these core objects. Each section
includes a discussion of the specific object and includes only those harmonized data elements associated
with that object. For each data element there is information about the location of that element in the
FHIM in the “FHIM Mapping” column from the Section 3 tables (see the table header below). To access
the complete set of reports within the FHIM model, visit:
http://www.fhims.org/content/420A62FD03B6_root.html
The following example describes how to find a specific data element, in this example Allergy/Adverse
Event Reaction, which is contained within a common core object.
Data Element
Name
Allergy /
Adverse Event
Code
Data Element Description
Code describing the
allergy/ adverse event
diagnosed for the subject
of the report (e.g., fever,
headache, rash, etc.)
Data Element
Format
Coded Value
Vocab /
Value Set
Value set
depends on
the “Allergy/
Adverse
Event Type”
Guidelines
FHIM Mapping
As an example:
Vaccination Reactions
(IIS) use a subset of
values found in the IIS
Vaccine Reaction Codes
AdverseReactionR
eportingEvent.Int
oleranceObservat
ion.Reaction.Reac
tion
The rightmost column displays the data element name which can be found in the FHIM model:
AdverseReactionReportingEvent.IntoleranceObservation.Reaction.Reaction. The first part of the data
element name identifies the report where the data element can be found
(AdverseReactionReportingEvent), the second part identifies the table in which data elements
describing the adverse event can be found (IntoleranceObservation) including a field for reactant
category code, the third part identifies the (Reaction) table that links to the reactant category code, and
the fourth part identifies the data element (Reaction) within the Reaction table. To locate this specific
data element requires the following steps:
1. Go to the FHIM model at http://www.fhims.org/content/420A62FD03B6_root.html to see the
complete set of reports available.
23
Office of the National Coordinator for Health Information Technology
2. Select AdverseEventReporting to display data elements within that object. Locate the
IntoleranceObservation table. Note that it is linked to the Reaction table through reactant
category codes.
3. Click on the Reaction field within the Reaction table to see the list of constraints on the element.
24
Office of the National Coordinator for Health Information Technology
4. Click on Observation_Reaction to see the human-friendly version of the Reaction class.
All other data elements referenced in the object tables below can be found in the FHIM model using the
same methodology as described for Adverse Event reaction.
25
Office of the National Coordinator for Health Information Technology
The Public Health Reporting Initiative operates under the following principles concerning the data
elements detailed below:
 Coded Values will always be sent with information to identify the coding system and humanreadable value associated with the code (e.g., coding system name, coding system value, and
coding system human readable description of the code) and the original text
 Addresses include all information pertinent to an address (e.g., address type, street address, zip
code, city, state, etc.) and may be repeated
 Names include all information pertinent to a name (e.g., first name, last name, middle initial,
title, etc.)
 Numeric values / measures will always be sent with the unit of measure (e.g., mL, lbs, inches,
etc.)
26
Office of the National Coordinator for Health Information Technology
Allergy / Adverse Event
The Allergy / Adverse Event object contains elements specific to the reporting of an allergy/ adverse event as part of a public health report. Although not all
allergies are adverse events, and vice versa, the data elements associated with an allergy or an adverse event are similar. Thus, one object includes data
elements relevant for both Allergies and Adverse Events. A summary of the allergy / adverse event object is provided in the table below (Table 8).
References Used
Public Health Reporting Initiative
Recommended Vocabulary
SNOMED-CT
How is the allergy / adverse events object used by each domain?
Communicable Disease
Optional
Chronic Disease
Optional
Child Health/Newborn Screening
Optional
Adverse Events
Required
How does the allergy / adverse events object align with other interoperability initiatives?
HITSP C83
The elements for allergy / adverse event type and date are supported within HITSP
C83
ISDS, Final Recommendation: Core Processes and EHR Requirements
There are no specific recommendations within ISDS regarding allergy / adverse
for Public Health Syndromic Surveillance
events
CSTE, Common Core Data Elements Recommendations
There are no specific recommendations within CSTE regarding allergy / adverse
events
FHIM
Can be modeled in the FHIM
Table 8 – Allergy / Adverse Events Object Summary
The following table (Table 9) describes the core common data elements in the allergy / adverse event object:
Data Element
Name
Data Element Description
Allergy /
Adverse Event
The code associated with the
allergy or adverse event causal
Data
Element
Format
Coded Value
Vocab / Value Set
Medication Brand Name Value
Set (RxNorm), Medication
Guidelines
FHIM Mapping
AdverseReactionReporti
ngEvent.intoleranceObse
27
Office of the National Coordinator for Health Information Technology
Data Element
Name
Data Element Description
Causal Agent
agent (e.g., medication name,
food allergy, etc.)
Allergy /
Adverse Event
Type
The type of allergy/adverse event
(e.g., ) as pertains to the patient.
Allergy/
Adverse Event
Code describing the
allergy/adverse event diagnosed
Data
Element
Format
Coded Value
Coded Value
Vocab / Value Set
Clinical Drug Value Set
(RxNorm), Medication Drug
Class Value Set (NDF-RT ),
Ingradient Value Set (Unique
Ingredient Identifier,UNII),
SNOMED Food Allergy subtype
hierarchy, Environmental
allergies (TBD)
SNOMED CT, Consolidated CDA
Table 48+ environmental allergy
Value Set dependent on the
"Allergy / Adverse Event Type"
Guidelines
FHIM Mapping
rvation.reactant
420134006 SNOMED CT Propensity to
adverse reactions (disorder)
418038007 SNOMED CT Propensity to
adverse reactions to substance (disorder)
419511003 SNOMED CT Propensity to
adverse reactions to drug (disorder)
418471000 SNOMED CT Propensity to
adverse reactions to food (disorder)
419199007 SNOMED CT Allergy to
substance (disorder)
416098002 SNOMED CT Drug allergy
(disorder)
414285001 SNOMED CT Food allergy
(disorder)
59037007 SNOMED CT Drug intolerance
(disorder)
235719002 SNOMED CT Food intolerance
(disorder)
2675004019 Environmental allergy
(disorder)
As an example: Vaccination Reactions (IIS)
use a subset of values - these are found in
AdverseReactionReporti
ngEvent.intoleranceObse
rvation.intoleranceCateg
ory
AdverseReactionReporti
ngEvent.intoleranceObse
28
Office of the National Coordinator for Health Information Technology
Data Element
Name
Data Element Description
Data
Element
Format
Vocab / Value Set
Code
for the subject of the report (e.g.,
fever, headache, rash, etc.)
Allergy/
Adverse Event
Date/Time
Allergy/
Adverse Event
Free Text
Date/time of adverse event
Date/Time
String
Allergy/
Adverse Event
Status
A free text description about the
event. Used to capture reporter
comments or other pertinent
information about the event that
has not been captured in other
sections of the report
The status of the allergy/adverse
event (e.g., active, inactive,
resolved)
Severity Free
Text
Level of severity of reaction to
product
String
Coded Value
Guidelines
FHIM Mapping
the IIS Vaccine Reaction and Adverse
Event6 codes
(https://phinvads.cdc.gov/vads/ViewValue
Set.action?id=CD050AE1-A9B9-DF119BDD-0015173D1785)
rvation.reaction.reaction
AdverseReactionReporti
ngEvent.eventDateTime
HITSPProblemStatus, SNOMED
Any noted intended or unintended effects
of the product. For example: full body
rash, nausea, rash resolved. These are
captured as text.
AdverseReactionReporti
ngEvent.intoleranceObse
rvation.reaction.reaction
.originalText
55561003 SNOMED CT Active
73425007 SNOMED CT Inactive
413322009 SNOMED CT Resolved
AdverseReactionReporti
ngEvent.intoleranceObse
rvation.status
AdverseReactionReporti
ngEvent.intoleranceObse
rvation.reaction.severity.
originalText
Table 9 – Allergy / Adverse Events Data Elements
6
For the purposes of this document, a reaction, side effect or adverse effect to a medication or biologic product is defined as one having a causal relationship to
the product (i.e., exposure to the product caused or contributed to the reaction, side effect or adverse effect). Adverse events, on the other hand, are
characterized as events that occur in temporal association with the product (i.e., exposure to the product preceded the event). Adverse events following a
medication or vaccine may or may not be causally associated. However, unlike a reaction, side effect or adverse effect, in the case of an adverse event no causal
relationship is implied. Due to historical naming conventions, Value Set Codes involving vaccinations contain the term reaction. In this guidance, to specify that
health events occurring after receipt of vaccination may or may not be causally associated with a vaccine, Value Set Name and Value set Description also contain
the term “adverse event” to indicate that no causal association between vaccination and the health outcome should be assumed.
29
Office of the National Coordinator for Health Information Technology
Employment information
The Employment information object allows for the description of employment information within a public health report. Employment information is part of the
recommendations of CSTE and is listed as a distinct object for this domain alignment. A summary of the employment information object is provided in the table
below (Table 10).
References Used
Public Health Reporting Initiative
Recommended Vocabulary
Bureau of Census Industry and Occupation Codes
How is the employment information object used by each domain?
Communicable Disease
Required
Chronic Disease
Required if Known
Child Health/Newborn Screening
Optional
Adverse Events
Optional
How does the employment information object align with other interoperability initiatives?
HITSP C83
There is no information defined for employment in the HITSP C83
Content Modules
ISDS, Final Recommendation: Core Processes and EHR Requirements
Employment Information is not included with the ISDS recommendations
for Public
for Core Processes and EHR requirements for Public Health Syndromic
Health Syndromic Surveillance
Surveillance. The International Society for Disease Surveillance (ISDS)
recommended Industry and Occupation as “future” data elements in
their 2012 recommendations for electronic syndromic surveillance using
hospital inpatient and ambulatory clinical care electronic health record
data
(http://www.syndromic.org/uploads/files/RevisedGuidelinesforSS.pdf).
CSTE, Common Core Data Elements Recommendations
Employment category
FHIM
Can be modeled in the FHIM
Table 10 – Employment information Object Summary
The following table (Table 11) describes the core common data elements in the employment information object:
30
Office of the National Coordinator for Health Information Technology
Data Element
Name
Employer Address
Employer Name
Employer Phone
Employment Status
Industry Type,
Current Code
Industry Type,
Current Free Text
Industry Type,
Current Title
Industry Type,
Usual Code
Industry Type,
Usual Free Text
Industry Type,
Usual Title
Data Element Description
At the time of the report, the
physical address of the of the
subject’s workplace
At the time of the report, the
name of the subject’s current
employer(s)
At the time of the report, the
phone number of the subject’s
current employer(s)
The current status of
employment
At the time of the report, the
industry type(s) of the subject’s
occupation(s) (e.g.,
accommodation and food
services, beer and ale
merchant wholesalers, etc.)
At the time of the report, the
industry type(s) of the subject’s
occupation(s) - text value
Title (text descriptor)
associated with the coded
value.
Industry type of the report
subject’s longest held
occupation (e.g.,
accommodation and food
services, beer and ale
merchant wholesalers, etc.)
Industry type of the report
subject’s longest held
occupation - text value
Title (text descriptor)
associated with the coded
value.
Data Element
Format
Address
Vocab / Value Set
Entity Name
Telephone
Number
String
Coded Value
Bureau of Census
Industry Codes
String
String
Coded Value
Bureau of Census
Industry Codes
Guidelines
FHIM Mapping
NotificationReport.reportSubject.
subject.asEmployee.employer.org
anization.address
NotificationReport.reportSubject.
subject.asEmployee.employer.org
anization.name
NotificationReport.reportSubject.
subject.asEmployee.employer.org
anization.phone
NotificationReport.reportSubject.
subject.asEmployee.employment
Status
NotificationReport.reportSubject.
subject.asEmployee.employer.ind
ustryClassification.code
NotificationReport.reportSubject.
subject.asEmployee.employer.ind
ustryClassification.originalText
NotificationReport.reportSubject.
subject.asEmployee.employer.ind
ustryClassification.text
NotificationReport.reportSubject.
subject.usualIndustry.code
String
NotificationReport.reportSubject.
subject.usualIndustry.originalText
String
NotificationReport.reportSubject.
subject.usualIndustry.text
31
Office of the National Coordinator for Health Information Technology
Data Element
Name
Occupation,
Current Code
Data Element Description
Occupation,
Current, Free Text
At the time of the report, the
subject’s occupation(s) - text
value
Title (text descriptor)
associated with the coded
value.
Report subject’s longest held
occupation (e.g., accountant,
actor, etc.)
Report subject’s longest held
occupation - text value
String
Title (text descriptor)
associated with the coded
value.
Number of years in usual
occupation (i.e., “occupation
held for greatest number of
years)
Number of years in current
occupation
String
Occupation,
Current Title
Occupation, Usual
Code
Occupation, Usual
Free Text
Occupation, Usual
Title
Years of
Employment in
Usual Occupation
Years of
Employment in
Current Occupation
At the time of the report, the
subject’s occupation(s) (e.g.,
accountant, actor, etc.)
Data Element
Format
Coded Value
Vocab / Value Set
Guidelines
FHIM Mapping
Bureau of Census
Occupation Codes
If multiple current occupations,
suggest report type specific data
element to capture which
occupation is the main occupation
(i.e., person works the most hours
per week in that occupation)
NotificationReport.reportSubject.
subject.asEmployee.occupation.c
ode
NotificationReport.reportSubject.
subject.asEmployee.occupation.o
riginalText
NotificationReport.reportSubject.
subject.asEmployee.occupation.t
ext
NotificationReport.reportSubject.
subject.usualOccupation.code
String
Coded Value
Bureau of Census
Occupation Codes
String
NotificationReport.reportSubject.
subject.usualOccupation.originalT
ext
NotificationReport.reportSubject.
subject.usualOccupation.text
Integer
Can be stored as discrete value or
computed
NotificationReport.reportSubject.
subject.yearsInUsualOccupation
Integer
Can be stored as discrete value or
computed
NotificationReport.reportSubject.
subject.yearsInCurrentOccupatio
n
Table 11 – Employment Information Data Elements
Encounter / Patient Visit
Encounter / patient visit information may be included as part of the common core set of data elements for public health reporting. Note that the base set of data
elements for encounters is considered an encounter code (type is included as a possible additional flag to be descriptive). A summary of the encounter / patient
visit object is provided in the table below (Table 12).
32
Office of the National Coordinator for Health Information Technology
References Used
Recommended Vocabulary
Public Health Reporting Initiative
ICD-9
ICD-10
How is the encounter / patient visit object used by each domain?
Communicable Disease
Chronic Disease
Required
Required
Child Health/Newborn Screening
Required
Adverse Events
Required
How does the encounter / patient visit object align with other interoperability initiatives?
HITSP C83
Encounter
ISDS, Final Recommendation: Core Processes and EHR Requirements
Supported through recommendation
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Supported through recommendation
FHIM
Can be modeled in the FHIM
Table 12 – Encounter / Patient Visit Object Summary
The following table (Table 13) describes the core common data elements in the encounter / patient visit object:
Data Element
Name
Admission
Date/Time
Admission Source
Admission Type
Chief Complaint
Discharge
Data Element Description
Date of admission (inpatient only)
The source for the admission (e.g., clinic
referral, transfer from a hospital,
emergency room, etc.)
Type of admission (e.g., accident, labor &
delivery, emergency, routine, urgent,
elective, newborn)
The patient's stated reason for seeking care
(or as stated by the patient's
representative). (i.e., patient's own words)
Date of discharge
Data Element
Format
Date/Time
Vocab / Value Set
Guidelines
FHIM Mapping
Admission Source
(HL7 2.x)
To be updated based on UB04
(PHIN VADS)
NotificationReport.ecounterE
vent.admissionDate
NotificationReport.ecounterE
vent.admissionSource
Coded Value
Coded Value
Admission type
(HL7 2.x)
To be updated based on UB04
(PHIN VADS)
NotificationReport.ecounterE
vent.admissionType
String
NotificationReport.ecounterE
vent.chiefComplaint
Date/Time
NotificationReport.ecounterE
33
Office of the National Coordinator for Health Information Technology
Data Element
Name
Date/Time
Discharge
Disposition
Data Element Description
Data Element
Format
Vocab / Value Set
Guidelines
FHIM Mapping
Information recorded at discharge or end
of visit (can be used for outpatient or
inpatient; e.g., admitted as inpatient to this
hospital, discharged/transferred to a
federal health care facility, etc.)
Coded Value
L7 Discharge
Disposition (HL7
User Defined
Table 112)
To be updated based on UB04
(PHIN VADS)
vent.discharge.date
NotificationReport.ecounterE
vent.discharge.disposition
National Uniform
Billing Committee
(NUBC 04) –
Patient Status
Discharge Facility
Name
Encounter Code
Encounter Type
Patient Visit
Date/Time
Reason for Visit
Name of the facility the patient was
transferred to (if discharge disposition =
transferred)
A procedure code describing the encounter
- in terms of evaluation and management
(e.g., diagnosis or procedure associated
with the encounter)
Type of encounter (e.g., phone call,
outpatient, etc.)
String
Date/Time of the Patient Visit (outpatient,
same day surgery, etc.)
The provider's description of the reason for
the patient's visit. (e.g., entry from
problem list, well care visit, research
monitoring)
Date/Time
Coded Value
CPT-4 (9920099299)
Coded Value
PHRI Encounter
Type: Phone Call,
Outpatient,
Inpatient, Other
Coded Value
May use problem
list
NotificationReport.ecounterE
vent.discharge.dischargeToLo
cation.name
NotificationReport.ecounterE
vent.encounterBillingType
NotificationReport.ecounterE
vent.encounterType
NotificationReport.ecounterE
vent.duration.low
NotificationReport.ecounterE
vent.reasonForVisit
Table 13 – Encounter / Patient Visit Data Elements
Exposure / Injury
This information is derived from occupational health subject matter experts and captures specific information relative to exposure by an individual to a
substance or agent as well as information about an injury. Additional elements were derived from discussions across user stories and the data elements below
may be relevant for other domains. A summary of the exposure / injury object is provided in the table below (Table 14).
34
Office of the National Coordinator for Health Information Technology
References Used
Public Health Reporting Initiative
Recommended Vocabulary
How is the exposure/injury object used by each domain?
Communicable Disease
Chronic Disease
Child Health/Newborn Screening
Adverse Events
How does the object align with other interoperability initiatives?
HITSP C83
ISDS, Final Recommendation: Core Processes and EHR Requirements
for Public
Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
FHIM
No vocabularies could be identified
Optional
Required if Known
Optional
Optional
There is no information defined for exposure/injury within HITSP C83
Not included in recommendations
Not included in recommendations
Can be modeled in the FHIM
Table 14 – Exposure/Injury Object Summary
The following table (Table 15) describes the core common data elements in the exposure / injury object:
Data Element
Name
Activity at time of
Exposure / Injury
Data Element Description
Activity setting at
time of Exposure /
Injury
Exposure / Injury
Agent
Indicates whether the activity was due to
work, both civilian and military,
volunteering, or leisure
The name of the agent the patient was
exposed to
Coded value
Exposure / Injury
Circumstances
Exposure Agent /
Description of the circumstances
surrounding the exposure
The agent the patient was exposed to or the
String
The activity at the time of the exposure or
injury
Data Element
Format
Coded Value
Vocab / Value Set
For Injury: ICD-9-CM E-001
through E030 codes, ICD-10-CM
Y-93 through Y-99 codes.
ICD-9-CM E-000 code, ICD-10-CM
Y-99 code.
String
Coded Value
Guidelines
NotificationReport.expos
ure.activity
NotificationReport.expos
ure.injuryContext
May support coded
value in specific
implementations.
For Injury: ICD-9-CM E-codes,
FHIM Mapping
NotificationReport.expos
ure.agent.originalText
NotificationReport.expos
ure.circumstances
NotificationReport.expos
35
Office of the National Coordinator for Health Information Technology
Data Element
Name
Injury Cause
Exposure Duration
Data Element Description
Exposure Type
The type of exposure (e.g., chemical,
biological, physical, other)
Coded Value
Place of Exposure /
Injury
Indicates the place where the exposure /
injury occurred (e.g., workplace, farm, etc).
Coded value
cause of the injury
Describes a timing effect of exposure (e.g.,
acute, intermediate duration and chronic)
Data Element
Format
Vocab / Value Set
Guidelines
ICD-10-CM V through Y-codes
String
May support coded
value in specific
implementations.
1)chemical,
2)physical, 3)biological and 4)
other agent
For Injury: ICD-9-CM E-849 codes
, ICD-10-CM Y-92 codes
FHIM Mapping
ure.agent.code
NotificationReport.expos
ure.exposureDuration.ori
ginalText
NotificationReport.expos
ure.category
NotificationReport.locati
on
Table 15 – Exposure Data Elements
Facility
A facility can be represented as an organization that serves several roles. The facility can have several states within public health domains, including the sender,
the receiver, or an intermediary. For public health reporting, the facility may also have various “states”, such as the “ordering” facility and the “receiving” facility.
A summary of the facility object is provided in the table below (Table 16).
References Used
Public Health Reporting Initiative
Recommended Vocabulary
There are no recommended vocabularies used to describe a facility.
How is the facility object used by each domain?
Communicable Disease
Required
Chronic Disease
Required
Child Health/Newborn Screening
Required
Adverse Events
Required
How does the facility object align with other interoperability initiatives?
HITSP C83
There is no concept of a facility within HITSP C83
ISDS, Final Recommendation: Core Processes and EHR Requirements Does support the concept of a facility and defines associated data elements
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Ordering Facility - CSTE classifies a facility as “ordering” facility
FHIM
Facility supported through the modeling of several FHIM entities (an
36
Office of the National Coordinator for Health Information Technology
example would be Blood Bank)
Table 16 – Facility Object Summary
The following table (Table 17) describes the core common data elements in the facility object:
Data Element
Name
Facility
Address
Facility ID
Data Element Description
Facility Name
Name of the facility where care was
provided to the subject of the report.
Phone number of the facility where care
was provided to the subject of the report.
Type of facility that the patient visited for
treatment (e.g., hospital, school, clinic, etc.)
Facility Phone
Facility Type
Address of the facility where care was
provided to the subject of the report.
Identifier of the facility where care was
provided to the subject of the report.
Data Element
Format
Address
Vocab / Value Set
Composite ID
National Provider Identifier
(NPI); CLIA number, etc.
(Any unique identifier can
be used here)
Entity Name
Telephone
Number
Coded Value
Guidelines
This section does not exist in
ISDS document. Compared
to ISDS Treatment Facility
Identifiers.
HL7 Table 0440
FHIM Mapping
ServiceDeliveryLocation.addres
s
ServiceDeliveryLocation.id
ServiceDeliveryLocation.name
ServiceDeliveryLocation.phone
Healthcare Service Delivery
Location (HL7)
ServiceDeliveryLocation.locatio
nCategory
Table 17 – Facility Data Elements
Family History
Family history is included in the Data Harmonization Profile to provide a base set of data elements to describe each of the family relationships within a public
health report. A summary of the family history object is provided in the table below (Table 18).
References Used
Recommended Vocabulary
How is the family history object used by each domain?
Communicable Disease
Chronic Disease
Child Health/Newborn Screening
Adverse Events
Public Health Reporting Initiative
HL7 FamilyRelationshipType
HL7 Administrative Gender
CDC Race and Ethnicity
Required
Required
Required
Required
37
Office of the National Coordinator for Health Information Technology
How does the family history object align with other interoperability initiatives?
HITSP C83
Family History
ISDS, Final Recommendation: Core Processes and EHR Requirements
Family History
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Family History
FHIM
Can be modeled in the FHIM
Table 18 – Family History Object Summary
The following table (Table 19) describes the core common data elements in the family history object:
Data Element
Name
Family Member
Date of Birth
Family Member
Ethnicity
Data Element Description
Data Element
Format
Date/Time
Vocab /
Value Set
Detailed ethnicity of the family member (e.g.,
Canadian, Mexican, Cuban, etc.)
Coded Value
Family Member
Ethnicity Group
Ethnicity group of the family member (i.e.,
"Hispanic or Latino", "Not Hispanic or Latino").
Coded Value
CDC Race and
Ethnicity
(Detailed
Ethnicity)
CDC Race and
Ethnicity
(Ethnicity
Group)
Family Member
Name
Family Member
Observation
Family Member
Observation
Duration
Family Member
Observation End
Date/Time
Family Member
Observation
Start Date/Time
Family Member
Name of the family member.
Person Name
Observation about the family member.
Coded Value
Family Member Observation Duration
Date/Time
Family Member Observation End Date/Time
Date/Time
FamilyHistoryConcern.
duration.high
Family Member Observation Start Date/Time
Date/Time
FamilyHistoryConcern.
duration.low
Status of the observation.
Coded Value
Date of birth for the family member.
SNOMED-CT
SNOMED-CT
Guidelines
FHIM Mapping
Can be rolled up into ethnicity
group.
FamilyHistoryConcern.relative.
person.dateOfBirth
FamilyHistoryConcern.relative.
person.ethnicityDetailed
Can be created by rolling up
detailed ethnicity into ethnicity
group.
FamilyHistoryConcern.relative.
person.ethnicityGroup
FamilyHistoryConcern.relative.
person.legalName
FamilyHistoryConcern.
healthConcern
FamilyHistoryConcern. duration
FamilyHistoryConcern.status
38
Office of the National Coordinator for Health Information Technology
Data Element
Name
Observation
Status
Family Member
Race
Data Element Description
Data Element
Format
Vocab /
Value Set
Guidelines
FHIM Mapping
Detailed race information about the family
member (e.g., Alaska Indian, Central American
Indian, Croatan, French, Lebanese).
Coded Value
Can roll up to race category from
detailed race information from
CDC Race and Ethnicity Hierarchy.
FamilyHistoryConcern.relative.
person.raceDetailed
Family Member
Race Category
Race category of the family member (e.g., Asian,
White, Other, etc.)
Coded Value
Can roll up to race category from
detailed race information from
CDC Race and Ethnicity Hierarchy.
FamilyHistoryConcern.relative.
person.raceCategory
Family Member
Sex
Sex of the family member (i.e., female, male,
undifferentiated).
Coded Value
Family
Relationship
Type
Value describing the type of family relationship
(e.g., genetic relationship, in-law, foster child, etc.)
Coded Value
CDC Race and
Ethnicity
(Detailed
Race)
CDC Race and
Ethnicity
(Race
Categories)
HL V3
Administrativ
e Gender
HL7
FamilyRelatio
nshipType
FamilyHistoryConcern.relative.
person.administrativeGender
FamilyHistoryConcern.relative.r
elationshipCategory
Table 19 – Family History Data Elements
Health Problem / Diagnosis
The Health Problem / Diagnosis object includes information related to “diagnosis” and “problem list”. For the purposes of public health reporting, health
problem was utilized to capture commonalities at a higher level. As the following data elements indicate, a “health problem” includes a diagnosis, finding,
complaint, condition, functional limitation, symptom, problem, and/or problem act.
This information is included as part of each of the public health reporting domains and their associated reporting requirements. ISDS also defines the need for a
“diagnosis code” (in the language of PHRI, a “health problem / diagnosis name”) as part of syndromic surveillance reporting requirements. Within the S&I
Framework Public Health Reporting Use Case, 9 user stories make some use of the health problem object, including primary usage of health problem / diagnosis
codes.
The vocabulary to use for all diagnoses is SNOMED-CT, in alignment with the recommendations of the Health IT Standards Committee. Public health reporting
domains MAY also use International Classification of Diseases (ICD) ICD-9 and ICD-10 codes for reporting.
A summary of the health problem / diagnosis object is provided in the table below (Table 20).
39
Office of the National Coordinator for Health Information Technology
References Used
Public Health Reporting Initiative
Recommended Vocabulary
SNOMED-CT (HITSC Recommendation)
ICD-9
ICD-10
How is the health problem / diagnosis object used by each domain?
Communicable Disease
Required
Chronic Disease
Required
Child Health/Newborn Screening
Required
Adverse Events
Required
How does the health problem / diagnosis object align with other interoperability initiatives?
HITSP C83
The concept of health problems is referenced within the HITSP C83 Content
Modules as a Problem/Condition (reference “diagnosis”)
ISDS, Final Recommendation: Core Processes and EHR
The concept of health problems is referenced in this ISDS recommendations
Requirements for Public Health Syndromic Surveillance
(reference “diagnosis”)
CSTE, Common Core Data Elements Recommendations
The concept of health problems is referenced in the CSTE recommendations
(reference “diagnosis”)
FHIM
The concept of health problems can be represented in the FHIM.
Table 20 – Diagnosis Object Summary
The following table (Table 21) describes the core common data elements in the health problem / diagnosis object:
Data Element
Name
Health Problem /
Diagnosis
Date/Time
Health Problem /
Diagnosis Free
Text
Data Element Description
Date and time the health problem was
diagnosed
A free text description about the
diagnosis. Used to capture diagnoses
that are not associated with a specific
Data Element
Format
Date/Time or
Timestamp (TS)
String
Vocab / Value
Set
Guidelines
FHIM Mapping
NotificationReport.healthConce
rn.dateDiagnosed
Note: Contraindications and
precautions free text can be
expressed using the “Health
NotificationReport.healthConce
rn.healthConcern
- or (for contraindications/
40
Office of the National Coordinator for Health Information Technology
Data Element
Name
Data Element Description
Data Element
Format
Vocab / Value
Set
code.
Health Problem /
Diagnosis Onset
Date/Time
Date and time the health problem
began (e.g., onset of symptoms)
Date/Time or
Timestamp (TS)
Health Problem
Status
Current status of this diagnosis (e.g.,
active, inactive, resolved)
Coded Value
Health Problem
Type
Description of the type of health
problem (e.g., finding, complaint,
diagnosis, problem)
Coded Value
Health Problem/
Diagnosis
Certainty
A contextual qualifier for a health
problem / diagnosis to indicate
diagnosis certainty (e.g., definite,
probable)
A contextual qualifier for a health
problem / diagnosis to indicate
diagnosis finality (e.g., working, final,
Coded Value
SNOMED CT
values Active,
Inactive and
Resolved
Finding
Complaint
Diagnosis
Condition
Functional
limitation
Symptom
Problem
Problem Act
(Consolidated
CDA Value Set:
Problem Type
2.16.840.1.1138
83.3.88.12.3221.
7.2 )
SNOMED-CT
Coded Value
SNOMED-CT
Health Problem/
Diagnosis Finality
Guidelines
FHIM Mapping
Problem / Diagnosis Free Text”
element.
precautions) –
MedicationAdministrationEven
t.contraIndication.healthConce
rn.healthConcern.originalText
NotificationReport.healthConce
rn.dateOfOnset
- or (for contraindications /
precautions) –
MedicationAdministrationEven
t.contraIndication.healthConce
rn.dateCreated
NotificationReport.healthConce
rn.status
Note: Contraindications and
precautions date / time can be
expressed using the “Health
Problem / Diagnosis Onset Date /
Time” element.
A Health Problem/Problem
Observation is required to be
wrapped in an act wrapper in
locations such as the Problem
Section, Allergies Section, and
Hospital Discharge Diagnosis
Section, where the type of
Problem needs to be identified or
the condition tracked. A Problem
Observation can be a valid
"standalone" template instance in
cases where a simple Problem
observation is to be sent.
NotificationReport.healthConce
rn.category
Constrain to allow the value set to
apply to all types of health
problems.
NotificationReport.healthConce
rnEntry.healthConcern.certaint
y
Constrain to allow the value set to
apply to all types of health
problems.
NotificationReport.healthConce
rnEntry.priority
41
Office of the National Coordinator for Health Information Technology
Data Element
Name
Health Problem/
Diagnosis
Principality
Health Problem/
Diagnosis Name
Data Element Description
revised, etc.)
A contextual qualifier for a health
problem / diagnosis to indicate
diagnosis principality (e.g., principal,
primary, secondary, etc.)
Indicates a specific disease or problem
(e.g., a history of vaccine preventable
disease, diabetes, injury, etc.)
Data Element
Format
Vocab / Value
Set
Guidelines
FHIM Mapping
Coded Value
SNOMED-CT
Constrain to allow the value set to
apply to all types of health
problems.
NotificationReport.healthConce
rnEntry.ranking
Coded Value
SNOMED-CT
ICD-9 (including
E Codes)
ICD-10
Note: Contraindications and
precautions can be expressed
using the “Health Problem /
Diagnosis Name” element. For
example Immunization program
may use Vaccine
Contraindications, found here:
https://phinvads.cdc.gov/vads/Vie
wValueSetConcept.action?id=89A
1552F-9F75-4CCF-A82AD39D467617A7.
NotificationReport.healthConce
rn.healthConcern
- or (for contraindications/
precautions) MedicationAdministrationEven
t.contraIndication.healthConce
rn.healthConcern
Table 21 – Health Problems Data Elements
Immunization
Immunization information included as part of this document will be closely aligned to the HL7 Immunization Domain Analysis Model (DAM). The intent is to
reuse the work done in modeling the Federal Health Information Model (FHIM) immunization domain, and in analysis of the 3500 form.
Vaccination information is included within this Data Harmonization Profile as part of the Immunization object.
A summary of the immunization object is provided in the table below (Table 22).
References Used
Recommended Vocabulary
Public Health Reporting Initiative
HL7 Immunization Domain Analysis Model (DAM)
Federal Health Information Model (FHIM)
HL7 Version 2.5.1 Implementation Guide: Immunization Messaging
(Release 1.04)
Supported by HL7 Tables
42
Office of the National Coordinator for Health Information Technology
CVX
MVX
How is the vaccination object used by each domain?
Communicable Disease
Required
Chronic Disease
Required if Known
Child Health/Newborn Screening
Required
Adverse Events
Optional
How does the vaccination object align with other interoperability initiatives?
HITSP C83
Represented by HITSP as Immunization
ISDS, Final Recommendation: Core Processes and EHR Requirements
Can be supported by current ISDS recommendations
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Can be supported by current CSTE recommendations
FHIM
Can be modeled in the FHIM
Table 22 – Immunization (Vaccination) Object Summary
The following table (Table 23) describes the core common data elements in the immunization object:
Data Element
Name
Date/Time of
Exemption/Parent
Refusal of Vaccine
Product Type
Administered
Date/Time of
History of Vaccine
Preventable
Disease
Exemption(s)/
Parent Refusal(s)
of Vaccine
Product Type
Administered
Vaccination
Data Element Description
Date of Exemption/Parent Refusal of
Vaccine Product Type Administered
Data Element
Format
Date/Time
Date of History of Vaccine Preventable
Disease
Date/Time
The reason that the patient or
responsible person refuses a particular
vaccine (i.e., parental decision, patient
decision, religious exemption, other)
Coded Value
Vaccination Administration Date
Date/Time
Vocab / Value Set
Guidelines
FHIM Mapping
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.exemption.dateAsserted
Substance Refusal
Reason (IIS)
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.immunityStatus.evidenceOfImm
unity.relevantDate
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.exemption.reason
ImmunizationRegistrySubmission.i
43
Office of the National Coordinator for Health Information Technology
Data Element
Name
Administration
Date/Time
Vaccination Event
Information
Source (admin vs.
history)
Vaccine
Administering
Provider Name
Data Element Description
Data Element
Format
Vocab / Value Set
Guidelines
FHIM Mapping
mmunizationHistory.vaccinationEve
nt.startDateTime
ImmunizationRegistrySubmission.i
mmunizationHistory.informationSo
urce
Historical Vaccination Record (with
source of record specified).
String
Must be able to identify the clinician
administering the vaccine by full name
or ID. If identification is by ID the
Assigning Authority Identifier is
Required.
Vaccine Expiration Date
Person Name
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.administeringProvider.practition
er.asPerson.legalname
Date/Time
Vaccine
Information
Statement (VIS)
Date
Vaccine Information Statement (VIS)
Date
Date/Time
Note that VIS Type and Date
are always grouped
together.
Vaccine
Information
Statement (VIS)
Type
Vaccine Information Statement (VIS)
Type
String
Note that VIS Type and Date
are always grouped
together.
Vaccine
Information
Statements (VIS)
Date given to
patient
Vaccine Lot
Number
Vaccine Information Statements (VIS)
Date given to patient
Date/Time
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.
administeredDrug.productInstance.
manufacturingLot.expirationDate
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.patientDocumentPresentation.va
ccineInformationStatement.dateOf
Publication
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.patientDocumentPresentation.va
ccineInformationStatement.docum
entTitle
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.patientDocumentPresentation.da
teOfPresentation
Vaccine lot number
String
Vaccine
The manufacturer of the vaccine (e.g.,
Coded Value
Vaccine Expiration
Date/Time
Manufacturers of
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.administeredDrug.productInstan
ce.manufacturingLot.lotId
ImmunizationRegistrySubmission.i
44
Office of the National Coordinator for Health Information Technology
Data Element
Name
Manufacture
Name
Data Element Description
Vaccine Ordering
Provider Name
Must be able to identify the clinician
ordering the vaccine by full name or ID.
If identification is by ID the Assigning
Authority Identifier is Required.
The product administered to the
patient (e.g., adenovirus type 4,
anthrax, cholera)
The route the vaccine was
administered, for example:
Intradermal, intramuscular, nasal, etc.
Person Name
The body site where the vaccine was
administered.
Vaccine Product
Type
Administered
Vaccine Route of
Administration
Vaccine Site of
Administration
Data Element
Format
Aviron, Baxter Healthcare Corporation,
etc.)
Vocab / Value Set
Guidelines
vaccines (MVX)
Coded Value
Vaccines administered
(CVX)
Coded Value
Route of
Administration (IIS)
Coded Value
Administrated Site (IIS)
Many programs use their
own codes for approach site
and route of administration
Many programs use their
own codes for approach site
and route of administration
FHIM Mapping
mmunizationHistory.vaccinationEve
nt.administeredDrug.productInstan
ce.packagedMedicinalProduct.man
ufacturer.mvx
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.medicationAdministrationPromis
e.healthcareOrder.author
ImmunizationRegistrySubmission.i
mmunizationHistory.vaccinationEve
nt.administeredDrug.vaccineCode
ImmunizationRegistrySubmission.i
mmunizationHistory.VaccinationEve
nt.bodySite
ImmunizationRegistrySubmission.i
mmunizationHistory.VaccinationEve
nt.route
Table 23 – Immunization Data Elements
Medical Devices
Medical devices is a broad concept used to define any type of medical equipment (durable and non-durable) that is associated with the provision and delivery of
care. A summary of the medical devices object is provided in the table below (Table 24).
References Used
Recommended Vocabulary
How is the medical devices object used by each domain?
Communicable Disease
Chronic Disease
Child Health/Newborn Screening
Allergy / Adverse Events
Public Health Reporting Initiative
FDA
N/A
Optional
Optional
Required
Required
45
Office of the National Coordinator for Health Information Technology
How does the medical devices object align with other interoperability initiatives?
HITSP C83
N/A
ISDS, Final Recommendation: Core Processes and EHR Requirements
N/A
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
N/A
FHIM
Can be modeled in the FHIM
Table 24 – Medical Devices Object Summary
The following table (Table 25) describes the core common data elements in the medical devices object:
Data Element Name
Data Element Description
Device
Brand/Trade/Proprietary
Name
The trade or proprietary name of the
suspect medical device as used in
product labeling or in the catalog (e.g.,
Flo-Easy Catheter, Reliable Heart
Pacemaker, etc.). This information may
1) be on a label attached to a durable
device, 2) be on a package of a
disposable device, or 3) appear in
labeling materials of an implantable
device."
The exact number as it appears in the
manufacturer's catalog, device labeling,
or accompanying packaging
The date the procedure was performed
to remove the device from the patient.
The date the procedure was performed
to implant the device in the patient.
Name of the person or organization who
produced the device
Device catalog number
Device explant date
Device implant date
Device manufacturer
name
Device model number
Device serial number
The exact model number found on the
device label or accompanying packaging
The serial number assigned by the
manufacturer and should be specific to
Data Element
Format
String
String
Date / Time
Date / Time
String
String
String
Vocab / Value
Set
Guidelines
FHIM Mapping
Encounter.patientImplantObservat
ion.deviceInstance.device.name
Encounter.patientImplantObservat
ion.deviceInstance.device.catalogI
d
Encounter.patientImplantObservat
ion.explantDate
Encounter.patientImplantObservat
ion.implantDate
Encounter.patientImplantObservat
ion.deviceInstance.device.manufac
turer.name
Encounter.patientImplantObservat
ion.deviceInstance.device.modelId
Encounter.patientImplantObservat
ion.deviceInstance.id
46
Office of the National Coordinator for Health Information Technology
Data Element Name
Data Element Description
Reprocessed Device
Indicator
Reused Device Indicator
each device
An indicator used to convey that the
device is a reprocessed device
An indicator used to convey that the
device is a reused device
Data Element
Format
Vocab / Value
Set
Coded Value
(Boolean)
Coded Value
(Boolean)
Yes / No
Guidelines
FHIM Mapping
Encounter.patientImplantObservat
ion.isReprocessedDevice
Encounter.patientImplantObservat
ion.isReusedDevice
Yes / No
Table 25 – Medical Devices Data Elements
Medication
This object is used to capture general information about medications in a public health report. A summary of the medication object is provided in the table
below (Table 26).
References Used
Recommended Vocabulary
Public Health Reporting Initiative
RxNORM
HCPCS II
How is the medication object used by each domain?
Communicable Disease
Required
Chronic Disease
Required
Child Health/Newborn Screening
Required
Adverse Events
Required
How does the medication object align with other interoperability initiatives?
HITSP C83
Medication is included in HITSP C83
ISDS, Final Recommendation: Core Processes and EHR Requirements
Not included within the ISDS Recommendations
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Recommendation asks for Test/Result
FHIM
Can be modeled in the FHIM
Table 26 – Medication Object Summary
The following table (Table 27) describes the core common data elements in the medication object:
Data Element Name
Data Element Description
Data Element
Format
Vocab / Value Set
Guidelines
FHIM Mapping
47
Office of the National Coordinator for Health Information Technology
Data Element Name
Data Element Description
Active Ingredient Code
The code for an active ingredient (i.e.,
any component that provides
pharmacological activity or other direct
effect in the diagnosis, cure, mitigation,
treatment, or prevention of disease)
Active Ingredient Code
Description
The text description associated with the
coded value.
String
Active Ingredient Free
Text
A free text field to capture active
ingredients not included in the coded
values.
String
Administration Timing
An abbreviated prescription (Sig)
Component: defines a specific
administration or use time. Can be a
text string (Morning, Evening, Before
Meals, 1 Hour After Meals, 3 Hours
After Meals, Before Bed) or an exact
time.
Data prescription was dispensed
(fulfillment history)
String
The amount of medication to be given,
including unit of measurement.
An abbreviated component of a
prescription (sig) that describes a
medication dose frequency (i.e., how
often the medication is to be
Physical
Quantity
Interval/Timesta
mp
Dispense Date/Time
Dose
Dose Frequency
Data Element
Format
Coded Value
Date/Time
Vocab / Value Set
Unique Ingredient
Value Set, Unique
Ingredient
Identifier (UNII)
Guidelines
FHIM Mapping
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dispensedDrug.productInstanc
e.packagedMedicinalProduct.me
dicinalProduct.ingredient.ingredi
ent.uniqueIngredientIdentifier.c
ode
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dispensedDrug.productInstanc
e.packagedMedicinalProduct.me
dicinalProduct.ingredient.ingredi
ent.uniqueIngredientIdentifier.t
ext
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dispensedDrug.productInstanc
e.packagedMedicinalProduct.me
dicinalProduct.ingredient.ingredi
ent.uniqueIngredientIdentifier.o
riginalText
NotificationReport.medicationHi
story.pharmacyRequest.sig
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dateTimeDispensed
NotificationReport.medicationHi
story.pharmacyRequest.dosage
NotificationReport.medicationHi
story.pharmacyRequest.frequen
cy
48
Office of the National Coordinator for Health Information Technology
Data Element Name
Indication
Lot Number
Data Element Description
administered)
An abbreviated prescription (Sig)
Component: The medical condition or
problem intended to be addressed by
the ordered product (e.g., burn,
abdominal pain, etc.)
An identification number assigned to a
medication by manufacturer
Data Element
Format
Vocab / Value Set
Coded Value
ICD-9 Diagnosis
Guidelines
NotificationReport.medicationHi
story.pharmacyRequest.indicatio
n.indicationCode
String
Manufacturer Name
Name of the manufacturer of the
substance or product as ordered or
supplied (e.g., Aviron, Baxter Healthcare
Corporation, etc.)
Coded Value
Medication Code
A unique drug identifier (code)
Coded Value
Federal
Medications
Terminology
Standards
(accessible
through NCI)
RxNorm
Medication Dosage
A description of a dosage form (e.g.,
Coded Value
FDA Codes -
FHIM Mapping
We expect different value
sets may be used to meet
programmatic needs.
RxNorm incorporates NDC
listings from major data
sources, including
FirstDataBank, FDA
Structured Product Labels,
etc. and represents the most
complete and updated listing
of NDC. Additionally, We
expect different value sets
may be used to meet
programmatic needs. For
example, Cancer Registry
CDA Implementation uses
the Medication Clinical Drug
Name Value Set (from
RxNorm) found here:
https://phinvads.cdc.gov/va
ds/ViewValueSet.action?id=2
39BEF3E-971C-DF11-B3340015173D1785
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dispensedDrug.productInstanc
e.manufacturingLot.lotId
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dispensedDrug.productInstanc
e.packagedMedicinalProduct.ma
nufacturer.name
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dispensedDrug.productInstanc
e.packagedMedicinalProduct.:
ndc
-ormedicinalProduct.code
-ormedicinalProduct.genericMedici
ne.code (RxNorm, NDF-RT)
NotificationReport.medicationHi
49
Office of the National Coordinator for Health Information Technology
Data Element Name
Data Element Description
Form
liquid dosage form, solid dosage form
and semisolid dosage form)
Medication Series
Number
Indicates, which in a series of
administrations a particular
administration represents (e.g.
"hepatitis B vaccine number 2 was
administered on Feb 07, 2004).
Date/time medication was administered
Integer
ImmunizationRegistrySubmissio
n.immunizationHistory.vaccinati
onEvent.evaluation.targetDose.d
oseNumber
Date/Time
Medication Type
Type of Medication (e.g., Prescription,
Over the Counter)
Coded Value
HITSP Medication
Type
Route of Administration
An abbreviated prescription (Sig)
Component: indicates how the
medication is received by the patient
(e.g., by mouth, intravenously, topically,
etc.)
Coded Value
HL7 Route of
Administration
NotificationReport.medicationHi
story.pharmacyRequest.startDat
eTime
NotificationReport.medicationHi
story.pharmacyPromise.dispens
e.dispensedDrug.productInstanc
e.packagedMedicinalProduct.me
dicinalProduct.ingredient.isOver
TheCounter
NotificationReport.medicationHi
story.pharmacyRequest.route
Site
An abbreviated prescription (Sig)
Component: The anatomic site where
the medication is administered (e.g., left
gluteus maximus, right naris, etc.)
Coded Value
SNOMED (Body
Site)
Medication Start
Date/Time
Data Element
Format
Vocab / Value Set
Guidelines
Medication
Product Dosage
Form
FHIM Mapping
story.pharmacyRequest.doseFor
m
Immunization uses a subset
of these codes, found here:
https://phinvads.cdc.gov/va
ds/ViewValueSet.action?id=1
E042B59-15B8-DF11-9BDD0015173D1785
Immunization uses a subset
of codes found in the IIS
Administrative Site list of
values:
https://phinvads.cdc.gov/va
ds/ViewValueSet.action?id=9
8257779-17B8-DF11-9BDD0015173D1785
NotificationReport.medicationHi
story.pharmacyRequest.sig
Table 27 – Medication Data Elements
50
Office of the National Coordinator for Health Information Technology
Order / Diagnostic Test
The order / diagnostic test object is used to capture information about orders that are placed.7 A summary of the order / diagnostic test object is provided in the
table below (Table 28).
References Used
Public Health Reporting Initiative
Recommended Vocabulary
LOINC
How is the order / diagnostic test object used by each domain?
Communicable Disease
Required if Known
Chronic Disease
Required if Known
Child Health/Newborn Screening
Required if Known
Adverse Events
Optional
How does the order / diagnostic test object align with other interoperability initiatives?
HITSP C83
Order / diagnostic test is included in HITSP C83
ISDS, Final Recommendation: Core Processes and EHR Requirements for Order / diagnostic test is not included in the ISDS recommendations
Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Information on an order/ diagnostic test is included in the CSTE
recommendations
FHIM
Can be modeled in the FHIM
Table 28 – Order/ Diagnostic Test Object Summary
The following table (Table 29) describes the core common data elements in the order / diagnostic test object:
Data Element Name
Data Element Description
Order / Diagnostic Test
The order code for the requested observation, test,
Data Element
Format
Coded Value
Vocab / Value
Set
LOINC
Guidelines
FHIM Mapping
ObservationRequest.ordere
7
Note that information about “results” and the “specimen” tested are available in following objects (section 3.19 and 3.21). PHRI includes the data elements in
separate objects as not all information must be captured/ associated for every event. An order / diagnostic test is also related to a facility and/or provider that
performs the test or completes the order.
51
Office of the National Coordinator for Health Information Technology
Data Element Name
Data Element Description
Code
and/or battery. Note: This can be based on local and/or
standardized order codes
The date and time of the order transaction (observation
request)
Order / Diagnostic Test
Date / Time
Data Element
Format
Vocab / Value
Set
CPT
SNOMED
Guidelines
Date/Time
FHIM Mapping
dObservation
ObservationRequest.dateTi
meOrdered
Table 29 – Order / Diagnostic Test Data Elements
Patient Contact Information
Primary contact information is included to outline immediate patient contact information (e.g., an “emergency contact”) for a subject/patient. A summary of
the patient contact information object is provided in the table below (Table 30).
References Used
Public Health Reporting Initiative
Recommended Vocabulary
HL7 Relationship Type
How is the primary contact object used by each domain?
Communicable Disease
Required
Chronic Disease
Required
Child Health/Newborn Screening
Required
Adverse Events
Unknown at this time
How does the primary contact object align with other interoperability initiatives?
HITSP C83
Support
ISDS, Final Recommendation: Core Processes and EHR Requirements
Not listed explicitly as a recommendation
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Patient Contact Information category
FHIM
Can be modeled in the FHIM
Table 30 – Patient Contact Information Object Summary
The following table (Table 31) describes the core common data elements in the patient contact information object:
52
Office of the National Coordinator for Health Information Technology
Data Element
Name
Contact Address
Contact Email
Contact Name
Contact Phone
Contact
Relationship
Data Element Description
Address of the authorized contact(s) for the
subject of the report
Email address of the authorized contact(s) for
the subject of the report.
Name of the authorized contact(s) for the
subject of the report
Phone number of the authorized contact(s) for
the subject of the report
The relationship of the authorized contact(s)
to the subject of the report (Note: this
represents the type of support provided; for
example, immediate emergency contact, next
of kin, family relations, guardians, agents, etc)
Data Element
Format
Address
Vocab / Value
Set
Guidelines
Network/Emai
l address
Person Name
Telephone
Number
Coded Value
Personal
Relationship
(HL7)
This is unique from the
relationship concept in the
family history object.
HL7 2.5 User Table 2
FHIM Mapping
NotificationReport.reportSubject.c
ontactParty.primaryHomeAddress
NotificationReport.reportSubject.c
ontactParty.primaryHomeEmail
NotificationReport.reportSubject.c
ontactParty.legalName
NotificationReport.reportSubject.c
ontactParty.primaryHomePhone
NotificationReport.reportSubject.c
ontactParty.relationshipCategory
-orNotificationReport.reportSubject.c
ontactParty.contactCategory
Table 31 – Patient Contact Information Data Elements
Patient Information
Patient information can be represented in many ways as part of public health reporting activities. A focus of this domain alignment was to look across different
reporting methods for submitting patient information (which may also be referred to as subject information) and determine what core elements would need to
be exchanged for public health reporting regardless of the type of patient/subject being referenced by the public health domain. A summary of the patient
information object is provided in the table below (Table 32).
References Used
Public Health Reporting Initiative
HITSP C83
Recommended Vocabulary
CDC Race and Ethnicity Code Sets
How is the patient information object used by each domain?
Communicable Disease
Required
Chronic Disease
Required
Child Health/Newborn Screening
Required
Adverse Events
Unknown at this time
How does the patient information object align with other interoperability initiatives?
53
Office of the National Coordinator for Health Information Technology
HITSP C83
ISDS, Final Recommendation: Core Processes and EHR Requirements
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
FHIM
Patient Information is a module within HITSP C83
Patient information is captured, including identifying information such as
demographics
Covered in CSTE recommendations as part of “Subject of Report”
Can be modeled in the FHIM
Table 32 – Patient Information Object Summary
The following table (Table 33) describes the core common data elements in the patient information object:
Data Element
Name
Language
Marital Status
Medical Record
Number
Data Element Description
Subject’s primary or spoken language (e.g.,
three-letter identifiers for all known human
languages).
Status of marriage (e.g., single, married,
separated, unknown, unreported, etc.)
Patient medical record number
Data Element
Format
Coded Value
Vocab / Value
Set
ISO 639-2
Coded Value
HL7 Marital
Status
Guidelines
String
Patient Address
Address of the subject of the report,
including Address Type
Address
Patient Age
Age of the subject of the report at the time
of diagnosis (includes units)
Quantity
Patient Date of
Birth
Patient Email
Date of birth (DOB) of the subject of the
report
Email address of the subject of the report
Date/Time
Patient Ethnicity
Detailed ethnicity of the subject of the
report (e.g., Canadian, Mexican, Cuban, etc.)
Coded Value
There may be multiple
addresses associated with an
address type. For example,
work address vs. home address.
Can be a calculated value.
Includes 'age units' (e.g., for
children under 2 years of age,
can include months).
Network/Emai
l address
CDC Race and
Ethnicity
(Detailed
Ethnicity)
Can be rolled up into ethnicity
group.
FHIM Mapping
NotificationReport.reportSubj
ect.subject.languageCapability
.language
NotificationReport.reportSubj
ect.subject.maritalStatus
NotificationReport.reportSubj
ect.patientId
-orNotificationReport.encounter.
accountId
NotificationReport.reportSubj
ect.subject.primaryHomeAddr
ess
NotificationReport.reportSubj
ect.subject.age
NotificationReport.reportSubj
ect.subject.dateOfBirth
NotificationReport.reportSubj
ect.subject.primaryHomeEmai
l
NotificationReport.reportSubj
ect.subject.ethnicityDetailed
54
Office of the National Coordinator for Health Information Technology
Data Element
Name
Patient Ethnicity
Group
Patient ID
Patient Name
Patient Phone
Patient Race
Patient Race
Category
Patient Sex
Data Element Description
Ethnicity group of the subject of the report
(i.e., "Hispanic or Latino", "Not Hispanic or
Latino").
Identifier for the subject of the report (e.g.,
Patient ID)
Name of the subject of the report (including
first, middle, and last)
Phone number of the subject of the report
Data Element
Format
Coded Value
Vocab / Value
Set
CDC Race and
Ethnicity
(Ethnicity Group)
Guidelines
FHIM Mapping
Can be created by rolling up
detailed ethnicity into ethnicity
group.
NotificationReport.reportSubj
ect.subject.ethnicityGroup
Composite ID
Person Name
Telephone
Number
Detailed race information about the subject
of the report (e.g., Alaska Indian, Central
American Indian, Croatan, French,
Lebanese).
Race category of the subject of the report
(e.g., Asian, White, Other, etc.)
Coded Value
CDC Race and
Ethnicity
(Detailed Race)
Coded Value
CDC Race and
Ethnicity (Race
Categories)
Current sex of the subject of the report (i.e.,
female, male, undifferentiated)
Coded Value
HL7
Administrative
Gender
Can roll up to race category
from detailed race information
from CDC Race and Ethnicity
Hierarchy.
Can be created by rolling up
detailed race category from
detailed race information from
CDC Race and Ethnicity
Hierarchy.
NotificationReport.reportSubj
ect.patientId
NotificationReport.reportSubj
ect.subject.legalName
NotificationReport.reportSubj
ect.subject.primaryHomePhon
e
NotificationReport.reportSubj
ect.subject.raceDetailed
NotificationReport.reportSubj
ect.subject.raceCategory
NotificationReport.reportSubj
ect.subject.administrativeGen
der
(HL7 v2 table
001)
Table 33 – Patient Information Data Elements
Payer Information
Payer information is included within the core common specifically to document the insurance type that is applicable to a patient. A summary of the payer
information object is provided in the table below (Table 34).
References Used
Public Health Reporting Initiative
55
Office of the National Coordinator for Health Information Technology
Recommended Vocabulary
Source of Payment Typology or X12 Data Element 1336 Insurance
How is the primary contact object used by each domain?
Communicable Disease
Optional
Chronic Disease
Optional
Child Health/Newborn Screening
Optional
Allergy / Adverse Events
Optional
How does the primary contact object align with other interoperability initiatives?
HITSP C83
Payer Information
ISDS, Final Recommendation: Core Processes and EHR Requirements
N/A
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
N/A
FHIM
Can be modeled in the FHIM
Table 34 – Payer Information Object Summary
The following element (Table 35) is core to exchanging payer information as part of a public health report:
Data Element
Name
Insurance Type
Data Element Description
Type of insurance related to visit (e.g., Auto
Insurance, Managed Care, HMO, Blue Cross
/ Blue Shield, etc.)
Data Element
Format
Coded Value
Vocab / Value Set
Guidelines
Source of Payment Typology
or X12 Data Element 1336
Insurance Type Code
FHIM Mapping
HealthPlan.insuranceType
Table 35 – Payer Information Data Elements
Physical Exam
Physical exam is information that is associated with the specific capture of detailed diagnoses and vital signs through a variety of exams that may be performed
on a patient. A summary of the physical exam object is provided in the table below (Table 36).
References Used
Recommended Vocabulary
How is the physical exam object used by each domain?
Communicable Disease
Public Health Reporting Initiative
CMS Evaluation and Management Guidelines - 1997
Optional
56
Office of the National Coordinator for Health Information Technology
Chronic Disease
Optional
Child Health/Newborn Screening
Optional
Allergy / Adverse Events
Optional
How does the physical exam object align with other interoperability initiatives?
Includes Physical Exam section that is meant to conform to IHE Physical
HITSP C83
Exam
ISDS, Final Recommendation: Core Processes and EHR Requirements
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
FHIM
N/A
N/A
Can be modeled in the FHIM
Table 36 – Physical Exam Object Summary
The following table (Table 37) describes the core common data elements in the physical exam object:
Data Element
Name
Physical Exam
Component/Device
Physical Exam
Narrative
Physical Exam
Observation
Data Element Description
Device used by the clinician to make
observation/assessment (e.g., blood
pressure cuff)
Direct observations made by the clinician
Data Element
Format
Coded Value
Vocab / Value Set
Guidelines
FHIM Mapping
String
Defines a set of observable data (normally
presented as questions/checklist) under
each section according to CMS Evaluation
and Management Guidelines of 1997
Coded Value
Physical Exam
Observation Result
Defines a set of observable data
answers with its qualifiers under each
section according to CMS Evaluation and
Management Guidelines of 1997
Coded Value
Physical Exam
Sections
Defines the system/Body Areas according
to CMS Evaluation and Management
Guidelines of 1997
Coded Value
See appendix PE
according to CMS
Evaluation and
Management
Guidelines of 1997
See appendix PE
according to CMS
Evaluation and
Management
Guidelines of 1997
See appendix PE
according to CMS
Evaluation and
Management
May be a string or an integer
depending on the observation.
57
Office of the National Coordinator for Health Information Technology
Data Element
Name
Data Element Description
Data Element
Format
Vocab / Value Set
Guidelines
FHIM Mapping
Guidelines of 1997
Table 37 – Physical Exam Data Elements
Procedure
The general concept of a procedure is captured in this section. A summary of the procedure object is provided in the table below (Table 38).
References Used
Vocabulary
How is the procedure object used by each domain?
Communicable Disease
Chronic Disease
Child Health/Newborn Screening
Public Health Reporting Initiative
JCIH-EHDI Risk Indicators for Hearing Loss
ICD-9 codes or SNOMED codes for congenital anomalies-clinical disorder
Joint Commission Medical Reason
JCIH-EHDI Procedure Declined
JCIH-EHDI Reason for no Hearing Loss Diagnosis Screening
JCIH-EHDI Newborn Hearing Loss Reason for no Follow-up Patient Reason
Hearing Loss Diagnosis or Screening
Newborn Hearing Loss Referrals
Physical Examination
Review of Systems
Coded Care Plan
JCIH EHDI Hearing Screen Left Value Set
JCIH EHDI Hearing Screen Right Value Set
JCIH EHDI Newborn Hearing Procedure Value Set
Joint Commission Medical Reason Value Set
CPT-4
ICD-9 CM
ICD-10 CM
Required
Required
Required
58
Office of the National Coordinator for Health Information Technology
Adverse Events
Required
How does the procedure object align with other interoperability initiatives?
HITSP C83
Expressed using a Procedure
ISDS, Final Recommendation: Core Processes and EHR Requirements Supported by ISDS recommendations
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Supported by CSTE recommendations
FHIM
Can be modeled in the FHIM
Table 38 – Procedure Object Summary
The following table (Table 39) describes the core common data elements in the procedure object:
Data Element
Name
Data Element Description
Procedure
Code
Code expressing the procedure (this includes, for
example, diagnostic/therapeutic/surgical
interventions or procedures but not laboratory
procedures)
Date/time procedure was performed
Procedure
Date/Time
Procedure Not
Performed
Reason
Procedure
Reason
Data
Element
Format
Coded Value
Vocab / Value Set
Guidelines
Support for
SNOMED-CT, CPT-4,
ICD-9 (volume 3)
and/or ICD-10 (PCS)
FHIM Mapping
Procedure.procedureCode
Date/Time
Procedure.dateTime
Reason procedure was not performed (free text)
String
Procedure.reasonNotPerformed
The reason for the procedure.
Coded value
SNOMED-CT
ICD-9 (volume 1&2)
ICD-10
May link to diagnosis or
problem list.
Procedure.reasonPerformed
Table 39 – Procedure Data Elements
Provider Information
Provider information is included for public health reports in support of identifying the provider(s) who have made a specific diagnosis or performed a procedure
of interest to public health authorities. A core set of elements are required to send provider information within public health reports. A summary of the provider
information object is provided in the table below (Table 40).
References Used
Public Health Reporting Initiative
59
Office of the National Coordinator for Health Information Technology
Recommended Vocabulary
NUCC Provider Taxonomy
How is the provider information object used by each domain?
Communicable Disease
Required
Chronic Disease
Required
Child Health/Newborn Screening
Required
Adverse Events
Required
How does the provider information object align with other interoperability initiatives?
HITSP C83
Healthcare Provider
ISDS, Final Recommendation: Core Processes and EHR Requirements for
Provider
Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Provider
FHIM
Can be modeled in the FHIM
Table 40 – Provider Information Object Summary
The following table (Table 41) describes the core common data elements in the provider object:
Data Element Name
Data Element Description
Provider Address
Address of the person who provided care
for the subject of the report
Provider Email
Email address of the person who provided
care for the subject of the report
Identifier of the person who provided care
for the subject of the report (e.g., National
Provider Identifier or other type of
identifier)
Network/Email
address
Instance
Identifier
Name of the person who provided care for
the subject of the report
Person Name
Provider ID
Provider Name
Data Element
Format
Address
Vocab / Value
Set
Guidelines
FHIM Mapping
Multiple addresses may be
captured. For example, mailing
and/or service address of the
provider.
HealthcareProvider.address
HealthcareProvider.email
National
Provider
Identifier (NPI)
Can be qualified with identifier
type. Able to repeat.
HealthcareProvider.id
-orHealthcareProvider.asNationallyI
dentifiedProvider.nationalProvide
rId
HealthcareProvider.asPerson.lega
lName
-orHealthcareProvider.asOrganizatio
60
Office of the National Coordinator for Health Information Technology
Data Element Name
Data Element Description
Data Element
Format
Provider Organization
Organization that the provider represents
Entity Name
Provider Phone
Phone number of the person who
provided care for the subject of the report
Role played by the person who provided
care for the subject of the report (i.e.,
consulting provider, primary care
provider, referring provider)
Telephone
Number
Coded Value
The type of the provider - may include one
type for an individual and one for an
organization (e.g., Physician, Dentist, etc.)
Coded Value
Provider Role
Provider Type
Vocab / Value
Set
Guidelines
FHIM Mapping
n.name
HealthcareProvider.asOrganizatio
n.name
HealthcareProvider.phone
NUCC Health
Provider Role
HL7 Provider
Role
NUCC Health
Provider
Taxonomy
HealthcareProvider.providerRole
For Vital Records, must record
the attendant at birth.
HealthcareProvider.providerCate
gory
Potentially 2 value sets - one
for individual and one for
organization.
Table 41 – Provider Information Data Elements
Report MetaData
Report MetaData information is akin to Information Source within the HITSP C83 Content Modules. Each public health reporting domain has specific
requirements for the data elements needed for a report. Report MetaData information may be captured as part of the specific transaction and its metadata, or
as part of the payload. This distinction is important because as defined in this Data Harmonization Profile, Report MetaData information is required for all public
health domains. A summary of the report metadata object is provided in the table below (Table 42).
References Used
Recommended Vocabulary
How is the report metadata object used by each domain?
Communicable Disease
Chronic Disease
Child Health/Newborn Screening
Allergy / Adverse Events
Public Health Reporting Initiative
HL7 Date/Time
Required
Required
Required
Required
61
Office of the National Coordinator for Health Information Technology
How does the report metadata object align with other interoperability initiatives?
HITSP C83
There is no concept of a Report MetaData within HITSP C83. This is
covered through other HITSP components.
ISDS, Final Recommendation: Core Processes and EHR
Defines categories of reporting data elements
Requirements for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Defines a Report MetaData category that contains data elements used
within each public health report
FHIM
Can be modeled in the FHIM
Table 42 – Report MetaData Object Summary
The following table (Table 43) describes the core common data elements in the report metadata object:
Data Element Name
Data Element Description
Report Date/Time
Date and time the report is being sent to
public health agencies
The status of the report (i.e., final,
amended, interim)
Report Status
Report Type
Data Element
Format
Date/Time
Vocab / Value
Set
Coded Value
Final,
Amended,
Interim
Describe a type of PH report
(immunization, cancer registry, etc.)
The individual person name of the
reporter
String
Reporter Email
Email of reporter (the person who actually
sends the report)
Network/Email
Address
Reporter Fax
Fax number of reporter (the person who
actually sends the report)
Telephone
Number
Reporter Organization
Address
Reporter Organization
ID
Address of reporter's organization
Address
ID of the reporting organization
ID
Reporter (Person)
Name
Person Name
NPI
Guidelines
FHIM Mapping
This can be used across all
domains within public health
NotificationReport.reportDateTi
me
NotificationReport.status
NotificationReport.reportCatego
ry
NotificationReport.reportSentBy
.asOrganization.pointOfContact.l
egalName
NotificationReport.reportSentBy
.asOrganization.pointOfContact.
email
NotificationReport.reportSentBy
.asOrganization.pointOfContact.f
acsimile
NotificationReport.reportCreate
dBy.address
NotificationReport.reportSentBy
.asOrganization.id
-or62
Office of the National Coordinator for Health Information Technology
Data Element Name
Reporter Organization
Name
Reporter Phone
Reporting System
Sending System
Information
Data Element Description
Data Element
Format
Organization that the reporter represents
String
A contact number for the
person/organization preparing the report
The system used to generate the report
Telephone
Number
Entity Name
Vocab / Value
Set
Information about the sending system.
May be the same as the 'reporting system'
but does not have to be (e.g., HIE)
Guidelines
Sending system information
will be represented differently
in the CDA and 2.5.1 guidance.
FHIM Mapping
NotificationReport.reportSentBy
.asNationallyIdentifiedProvider.n
ationalProviderId
NotificationReport.reportSentBy
.asOrganization.name
NotificationReport.reportCreate
dBy.phone
NotificationReport.reportingSyst
em
NotificationReport.sendingSyste
m
Table 43 – Report MetaData Data Elements
Result
The result object is used to capture information about diagnostic and other types of results, including laboratory results8. A summary of the result object is
provided in the table below (Table 44).
References Used
Public Health Reporting Initiative
Recommended Vocabulary
JCIH-EHDI Evidence of Hearing Screening Performed JCIH-EHDI
Inpatient Screening Results not Performed
Newborn Hearing Screening Method Value Set
How is the result object used by each domain?
Communicable Disease
Chronic Disease
Child Health/Newborn Screening
Adverse Events
How does the result object align with other interoperability initiatives?
8
Required
Required
Required
Required
A result may be associated with an order/diagnostic test (section 3.11) and/or a specimen (section 3.21).
63
Office of the National Coordinator for Health Information Technology
HITSP C83
ISDS, Final Recommendation: Core Processes and EHR Requirements for
Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
FHIM
Result
Not Applicable to ISDS recommendations
Test/Result
Can be modeled in the FHIM
Table 44 – Result Object Summary
The following table (Table 45) describes the core common data elements in the result object:
Data Element Name
Data Element Description
Result Date/Time
Date and time of observation
Data Element
Format
Date/Time
Result ID
Result ID
Identifier
Result Interpretation
Code
Interpretation of the result, such as an
abnormal flag; generally used for
laboratory results (e.g., "abnormal", "above
high normal", "below low normal", etc.)
A text interpretation of the result
interpretation.
Reference range(s) for the observation
Coded Value
Result Interpretation
Free Text
Result Reference
Range
Result Status
Result Type
Result Value
Status for observation (Complete,
preliminary, addendum, etc.)
Code describing the observation (format of
the result) performed or made (e.g., Coded
Entry, Coded with Exception, Date, etc.).
The value of the result, including units of
measure.
Test/Procedure
Performed Code
Coded value for the test/procedure
performed
Test/Procedure Result
Code
Coded value for the test/procedure result
Vocab / Value
Set
Guidelines
LabTestPromise.reportableResult.
dateTimeObserved
LabTestPromise.reportableResult.i
d
LabTestPromise.reportableResult.i
nterpretation.interpretation
Abnormal Flag
(HL70078)
String
Interval/Timest
amp
String
Coded Value
Numeric (or
structured
numeric) Value
Coded Value
Coded Value
Value Type
(HL70125)
FHIM Mapping
Implementations may
support coded values.
This construct is only
needed in HL7 v2 messages.
LabTestPromise.reportableResult.i
nterpretation.interpretationText
LabTestPromise.reportableResult.r
eferenceRange
LabTestPromise.reportableResult.r
eportStatus
n/a
(various)
LOINC
CPT
SNOMED CT
SNOMED-CT
ICD-9 CM
LabTestPromise.reportableResult.l
abTestPerformed
(various)
64
Office of the National Coordinator for Health Information Technology
Data Element Name
Data Element Description
Data Element
Format
Test/Procedure Result
Free Text
Additional text description about a
test/procedure result.
String
Vocab / Value
Set
ICD-10 CM
DSM codes
Guidelines
FHIM Mapping
(various)
Table 45 – Result Data Elements
Social History
Social History information is included in support of those domains needing to support the reporting of additional information such as history of tobacco use, or
other social health factors that may be part of a public health report. A summary of the social history object is provided in the table below (Table 46).
References Used
Recommended Vocabulary
Public Health Reporting Use Case
SNOMED-CT
NAACCR History of Tobacco Use
How is the social history object used by each domain?
Communicable Disease
Optional
Chronic Disease
Required
Child Health/Newborn Screening
Optional
Adverse Events
Optional
How does the social history object align with other interoperability initiatives?
HITSP C83
Represented by Social History
ISDS, Final Recommendation: Core Processes and EHR Requirements
Not included in the ISDS recommendations
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Not included in the CSTE recommendations
FHIM
Can be modeled in the FHIM
Table 46 – Social History Object Summary
The following table (Table 47) describes the core common data elements in the social history object:
65
Office of the National Coordinator for Health Information Technology
Data Element Name
Data Element Description
Data Element
Format
String
Social History Free Text
Social History Duration
Free text description of social
history not associated with a
coded value
Social History Duration
Social History End Date/Time
Social History End Date/Time
Date/Time
Social History Observed Value
Value describing the social history
(e.g. smoking history).
Coded Value
Social History Start Date/Time
Social History Start Date/Time
Date/Time
Social History Type
Value that describes the type of
social history being conveyed by
the observation (smoking status,
employment detail, etc…)
Coded Value
Vocab /
Value Set
Guidelines
FHIM Mapping
NotificationReport.healthCon
cern.details
Date/Time
HITSP C80
HITSP C80
Social
History Type
Code values are same as those used in
Meaningful Use Stage 1, which are the
Centers for Disease Control and
Prevention, National Center for Health
Statistics, National Health Interview
Survey Smoking Status Recodes
(http://www.cdc.gov/nchs/nhis/tobacc
o/tobacco_recodes.htm). This value
set was created because the Smoking
Status Recodes have no registered OID.
e.g., tobacco, alcohol, drug use, sexual
history
NotificationReport.healthCon
cern.timespan
NotificationReport.healthCon
cern.timespan.high
NotificationReport.healthCon
cern.value
NotificationReport.healthCon
cern.timespan.low
NotificationReport.healthCon
cern.healthConcern
Table 47 – Social History Data Elements
Specimen
A summary of the specimen object is provided in the table below (Table 48).
References Used
Recommended Vocabulary
How is the specimen object used by each domain?
Communicable Disease
Chronic Disease
Child Health/Newborn Screening
Public Health Reporting Initiative
Supported by HL7 Tables
Required
Required if Known
Optional
66
Office of the National Coordinator for Health Information Technology
Adverse Events
Unknown at this time
How does the specimen object align with other interoperability initiatives?
HITSP C83
Not expressed as a distinct set of elements in HITSP C83
ISDS, Final Recommendation: Core Processes and EHR Requirements
Specimen information is included in the ISDS recommendations
for Public Health Syndromic Surveillance
CSTE, Common Core Data Elements Recommendations
Specimen information is included in the CSTE recommendations
FHIM
Can be modeled in the FHIM
Table 48 - Specimen Object Summary
The following table (Table 49) describes the core common data elements in the specimen object:
Data Element
Name
Specimen
Collection
Date/Time
Specimen
Collector ID
Specimen
Description
Specimen ID
Specimen Origin
Specimen Parent
ID
Specimen
Received
Date/Time
Specimen Source
Site
Data Element Description
Date and time the specimen was collected
Data Element
Format
DateTime
Vocab / Value Set
Guidelines
FHIM Mapping
LabTestPromise.specimenCollection
Event.dateTime
The person, department, or facility that
collected the specimen (may include both a
name and an identifier)
Any comments associated with the specimen,
order or result
A unique identifier assigned to the specimen
or sample
Domain from which the specimen comes
(e.g., human, animal, environmental).
Unique identifier(s) that provide links to a
laboratory report (e.g., accession number,
order number, specimen identifier, study
identifier)
Time the specimen was received by the
diagnostic service
Entity
Identifier
LabTestPromise.specimenCollection
Event.performer.practitioner.id
String
LabTestPromise.specimenCollection
Event.specimen.description
LabTestPromise.specimenCollection
Event.specimen.id
LabTestPromise.specimenCollection
Event.specimen.specimenOrigin
LabTestPromise.specimenCollection
Event.specimen.specimenProcessin
gEvent.specimen.id
Source from which the specimen was
obtained (e.g., abnormal cell, all extremities,
etc.)
Coded Value
Entity
Identifier
Coded Value
SNOMED-CT
Entity
Identifier
DateTime
LabTestPromise.specimenAssessme
nt.specimenHandling.dateTimeEnd
SNOMED-CT (body site
hierarchy for human/animal;
physical object and
substance hierarchy for
LabTestPromise.specimenCollection
Event.sourceSite
67
Office of the National Coordinator for Health Information Technology
Data Element
Name
Data Element Description
Data Element
Format
Vocab / Value Set
Guidelines
FHIM Mapping
OBX-segment in
v2.5.1, where OBX3 asks the question
and OBX 5 answer
is boolean
N/A
environmental/biologics)
Specimen to PHL
Indicator of whether a specimen relevant to
this condition was submitted to a public
health laboratory.
Coded Value
Specimen Type
Description of the precise nature of the entity
that is the source material for the
observation (e.g., AM specimen, 24 hour
urine specimen, etc.)
Coded Value
HL70488
Yes/No
SNOMED-CT (specimen
hierarchy)
LabTestPromise.specimenCollection
Event.specimen.specimenType
HL70487
Table 49 – Specimen Data Elements
Vital Sign Indicator
Additional reporting data is provided for patient health indicators (categorized in this domain alignment as vital sign indicators). Many of these health indicators
would be information reported with clinical summaries and would be collected through longitudinal coordination of care. A summary of the vital sign indicator
object is provided in the table below (Table 50).
References Used
Public Health Reporting Initiative
Recommended Vocabulary
Supported by HL7 Tables
UCUM
How is the vital sign indicator object used by each domain?
Communicable Disease
Required
Chronic Disease
Required
Child Health/Newborn Screening
Required
Adverse Events
Optional
How does the vital sign indicator object align with other interoperability initiatives?
HITSP C83
Vital Signs
ISDS, Final Recommendation: Core Processes and EHR Requirements for Not specifically listed as a recommendation
Public Health Syndromic Surveillance
68
Office of the National Coordinator for Health Information Technology
CSTE, Common Core Data Elements Recommendations
Can be expressed as individual vital sign observations, such as pulse
oximetry
Can be modeled in the FHIM
FHIM
Table 50 – Vital Sign Indicators Object Summary
The following table (Table 51) describes the core common data elements in the vital sign indicators object:
Data Element Name
Data Element Description
Vital Sign Date/Time
Date of observation
Vital Sign Free Text
Vital Sign Result ID
Text interpretation of the vital sign result
An identifier for this specific vital sign
observation (groups vital signs - similar to
result organizer)
An abbreviated interpretation of the vital
sign observation, e.g., normal, abnormal,
high, etc
The coded representation of the vital sign
observation (e.g., height, weight,
temperature)
String
Integer
The value of the result, including units of
measure (e.g., numeric result for height)
Numeric (or
structured
numeric) Value
Vital Sign Result
Interpretation
Vital Sign Type
Vital Sign Value
Data Element
Format
Date/Time
Vocab / Value
Set
Guidelines
VitalSignObservationEvent.observati
onTime
VitalSignObservationEvent.remarks
VitalSignObservationEvent.id
String
Coded Value
FHIM Mapping
VitalSignObservationEvent.interpreta
tion
LOINC
VitalSignObservationEvent.observed
Characteristic
HITSP Vital
Sign Result
Type Value Set
VitalSignObservationEvent.value
Table 51 – Vital Sign Indicators Data Elements
69
Office of the National Coordinator for Health Information Technology
4. Public Health Data Harmonization Profile – Domain Considerations
In this section, specific recommendations are provided for each of the domains that were analyzed through the data
harmonization process. The intent in using an implementation model-aligned approach is to encourage greater adoption
of the public health data reporting shown in the Public Health Reporting domain alignment analysis, and to support
multiple implementation paths. Since much of the information generated by clinical workflow and usage of clinical data
systems can be captured in clinical data sources, including an EHR, the approach within Public Health Reporting attempts
to harmonize data elements and the overall structure of data being reported, while leaving implementers and vendors
further latitude to define the design most aligned to their current environment. This might include use of the HL7 CDA
R2 document-based approach or the HL7 2.5.1 messaging-based approach.
The following sections detail how each domain and user story includs the public health objects described in section 3. It
is important to note that each domain will likely require additional information that can be captured as report type
specific or implementation specific data elements. This section is meant to describe the relationship of each domain to
the public health reporting harmonized core common data objects. A full record of the specific data elements provided
by each user story is available as an excel spreadsheet on the public health reporting initiative wiki page at
http://wiki.siframework.org/PHRI+-+Data+%26Terminology+Harmonization+Sub-Workgroup. Each data element in the
user story spreadsheets was aligned to a core common data element from the objects described in section 3 or was
considered a potential “report type specific” or “implementation specific” as it did not meet the criteria for inclusion in
the set of core common data elements.9 The spreadsheet tabs also include information about value sets, formats, and
optionality as presented by the data element submitters.
Another key reference to understand the data harmonization profile is the submitted user stories for phase 1 of the
PHRI. A list of these user stories, with references to original submissions, is available in appendix D.
Summary of Selection Criteria by Domain
The domain analysis view (Table 52) shows each object defined in the public health reporting domain alignment and
how it maps across to each public health reporting domain within the Public Health Reporting initiative. The table is
built from the source data from the user stories participating in data harmonization. (Note that some common core data
elements were included based on discussion, but did not originate from submitted user stories requirements - see the
description of selection criteria for core common data elements in section 1.3.1.) This view is meant to identify how
each object defined within the S&I Framework Public Health Reporting Initiative aligns to the domains defined as part of
the initiative.10
9
Note that full harmonization of “report type specific” and “implementation specific” data elements is out of scope for
the data harmonization profile. For specific user story / public health report data elements, reference the excel
spreadsheets and appropriate implementation guides.
10
Although the user story was not formally considered during the use case and functional requirements development in
phase 1 of the PHRI, CDC/NIOSH provided insight into Injury data elements to enhance the completeness of this data
harmonization profile. The minimum “Injury” domain requirements align to the following PHRI Common Core Objects:
Health Problem, Exposure / Injury, Employment Information, and Payer Information.
70
Office of the National Coordinator for Health Information Technology
Adverse Events
Allergy /
Adverse Event
Employment
Information
Encounter /
Patient Visit
Exposure /
Injury
Facility
Family History
Health
Problem /
Diagnosis
Immunization
Medical Device
Medication
Order /
Diagnostic Test
Patient
Contact
Information
Patient
Information
Payer
Information
Physical Exam
Procedure
Provider
Information
Report
Metadata
Result
Social History
Specimen
Vital Sign
Indicator
AHRQ Common
Formats
ASTER 1
ASTER D
x
x
x
ICSR
R2
x
Child Health/Newborn Screening
Newborn Vital
Immunization Hearing
Statistics
Cancer
Genetics
Chronic Disease
Cancer
National Hospital
Reporting
Care Survey
x
x
x
x
X
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
X
X
Occupational
Health
Communicable
Diseases
Communicable
& Syndromic
HAI
X
x
x
x
X
X
x
x
x
x
x
x
x
x
X
X
x
x
x
x
x
x
x
x
x
x
X
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Table 52 – Summary of Selection Criteria by Domain
71
Office of the National Coordinator for Health Information Technology
Adverse Event
The Adverse Event domain includes a set of data elements that span multiple user stories, for example, the FDA 3500
form requirements. A full record of the data elements for the Adverse Event domain is available in the spreadsheet
referenced above on the “FDA” tab (located here: http://wiki.siframework.org/PHRI++Data+%26Terminology+Harmonization+Sub-Workgroup). This tab contains data elements for the following:
 Adverse Drug Event (ADE) Spontaneous Triggered Event Reporting (ASTER 1)
 Adverse Spontaneous Triggered Events Reporting (ASTER-D) for automated reporting from electronic health
records
 Individual Case Safety Report (ICSR) R2
 AHRQ Common Formats
Child Health/ Newborn Screening
The Child Health domain includes data elements for several user stories. A full record of the data elements for the Child
Health domain user stories is available in the spreadsheet referenced above (located here:
http://wiki.siframework.org/PHRI+-+Data+%26Terminology+Harmonization+Sub-Workgroup), using:
 “Immunization” tab - These data elements were provided for the immunization user story
 “Newborn Hearing Screening” tab – These data elements were provided by the newborn hearing screening /
early hearing detection and intervention user stories
 “Vital Statistics” – The data elements were provided by the birth and fetal death (vital statistics) user story
Chronic Disease
The Chronic Disease domain includes data elements for several user stories. A full record of the data elements for the
Chronic Disease domain user stories is available in the spreadsheet referenced above (located here:
http://wiki.siframework.org/PHRI+-+Data+%26Terminology+Harmonization+Sub-Workgroup), using:
 “Cancer Reporting” tab - These data elements were provided for the cancer reporting user story
 “Cancer Genetics” tab – These data elements were provided by the cancer genetics reporting user stories
 “NCHS: National Hospital Care Survey (NHCS)” – The data elements were provided by the National Hospital Care
Survey (NHCS) user story
 “Occupational Health” – These data elements were provided to represent occupational health user stories
Communicable Disease
The communicable disease domain includes data elements for Syndromic Surveillance, as defined by ISDS, and
communicable case reporting, as defined by the CSTE common core data element recommendations as well as data
elements for Healthcare Associated Infection (HAI) reporting. A full record of the data elements for the Communicable
Disease domain is available in the spreadsheet referenced above (located here: http://wiki.siframework.org/PHRI++Data+%26Terminology+Harmonization+Sub-Workgroup):
 “Communicable & Syndromic” tab - These data elements represent a harmonization of the ISDS and CSTE data
elements
 “HAI” tab – These data elements were provided by the HAI user story submitter
72
Office of the National Coordinator for Health Information Technology
Infrastructure, Quality and Research
As Infrastructure, Quality and Research user stories were out of scope for the first phase of the PHRI, no data elements
were submitted from these stories for consideration.
5. Data Harmonization Profile - Implementation Alignment
The content of Section 5 is focused on highlighting how the objects defined in this PHRI Data Harmonization Profile align
to existing recommendations and standards that have been developed within the healthcare community. Clear
alignment is needed to show how the content defined in this profile enables implementation of the recommendations
developed by other interested public health reporting stakeholders. The following alignments are covered in this Data
Harmonization Profile (table 53):
Recommended Alignments
Alignment of the existing public health
reporting domains to the recommendations
of ISDS for syndromic surveillance
Alignment of the existing public health
reporting domains to the recommendations
of the CSTE Workgroup
Alignment with HITSP C83 Content Modules
Alignment with FHIM
Alignment to Consolidated CDA
Why this Alignment is Important
ISDS has released several recommendations for syndromic surveillance
and meaningful use that were considered by this data harmonization
profile. Specific focus is given to the ISDS syndromic surveillance
recommendations in helping to establish a core set of data elements for
consideration.
CSTE is a very influential public health organization that has
recommended a certain set of core common data elements widely
accepted by the public health community. Specific recommendations
within the CSTE workgroup that lay out a set of data elements for public
health reporting have been included in this data harmonization profile.
This alignment ensures that the data elements originally defined by
HITSP within C83 (and referenced within C154) are considered as part of
the data harmonization analysis.
The Federal Health Information Model (FHIM) serves as an important
model for implementation of the data elements defined in the Data
Harmonization Profile.
The Consolidated CDA standard has been adopted as part of Meaningful
Use Stage 2 and is a standard being considered for use in public health
reporting implementation guide development.
Table 53 - Summary of Implementation Alignments
ISDS Syndromic Surveillance Recommendation Alignment
This table will be used to show alignment between ISDS Syndromic Surveillance recommendations and the objects
defined in the Public Health Reporting Data Harmonization Profile (Table 54):
ISDS Syndromic Surveillance Recommendation –
Minimum Data Set
Facility Identifier (Treating)
Facility Name (Treating)
Representation in Data Harmonization Profile – PHRI
Object
FACILITY
FACILITY
73
Office of the National Coordinator for Health Information Technology
ISDS Syndromic Surveillance Recommendation –
Minimum Data Set
Facility
Location (Treating)
Facility / Visit Type
Report Date/Time
Unique Patient Identifier
Medical Record #
Age
Age Units
Gender
City/Town
Zip Code
State
Country
Race
Ethnicity
Unique Visiting ID
Visit Date / Time
Date of onset
Patient Class
Chief Complaint / Reason for visit
Triage Notes
Diagnosis / External Cause of Injury Code
Clinical Impression
Diagnosis Type
Discharge Disposition
Disposition Date/Time
Initial Temperature
Initial Pulse Oximetry
Representation in Data Harmonization Profile – PHRI
Object
FACILITY
FACILITY
FACILITY
REPORT METADATA
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
PATIENT INFORMATION
ENCOUNTER / PATIENT VISIT
ENCOUNTER / PATIENT VISIT
ENCOUNTER / PATIENT VISIT
ENCOUNTER / PATIENT VISIT
HEALTH PROBLEM
HEALTH PROBLEM
HEALTH PROBLEM
HEALTH PROBLEM
HEALTH PROBLEM
HEALTH PROBLEM
HEALTH PROBLEM
VITAL SIGN INDICATOR
VITAL SIGN INDICATOR
Table 54 - ISDS Syndromic Surveillance Recommendations - Alignment to Data Harmonization Profile
CSTE Workgroup Recommendation Alignment
The CSTE workgroup recommendations were used as a basis for formulating many of the Data Harmonization Profile
alignments. These workgroup recommendations formed an initial base of data elements to be represented within the
Communicable Disease/Syndromic Surveillance user story. Table 55 shows the alignment:
CSTE Category
CSTE Data Element
Representation in Data Harmonization Profile
Report
Report Date/Time
REPORT METADATA
Alert creation date/time
Reporting system
Facility
Facility ID
FACILITY
74
Office of the National Coordinator for Health Information Technology
CSTE Category
Employment information
Patient Information
Provider Information
Health Record
Health Problems
CSTE Data Element
Facility Name
Facility Address
Facility Phone
Facility Email
Occupation, current
Occupation, usual
Industry type, current
Industry type, usual
Employer name
Employer
address
Employer phone
Identifier
Name
Address
Phone
Email address
Date of birth
Age
Age units [code]
Gender
Race
Ethnicity
Translator needed
Language spoken
Identifier
Provider ID
Provider Name
Provider Address
Provider Phone
Provider Email Address
Provider Role
Unique Medical Record Number
Diagnosis Code
Date of Onset
Chief Complaint /Reason for visit
Triage notes
Clinical Impression
Diagnosis Type
Discharge Disposition
Representation in Data Harmonization Profile
EMPLOYMENT INFORMATION
PATIENT INFORMATION
PROVIDER INFORMATION
PATIENT INFORMATION
HEALTH PROBLEM
75
Office of the National Coordinator for Health Information Technology
CSTE Category
CSTE Data Element
Disposition Date/Time
Unique Visiting ID
Visit date/time
Date of onset
Encounter ID
Encounter Type
Encounter Facility Identifier
Unique Visiting ID
Visit date/time
Date of onset
Patient class
Encounter
Immunization
Primary Contact
Name
Address
Phone
Family Relationship
Procedure Code
Procedure Type
Procedure
Order
Result
Specimen
Vital Signs (Patient Health
Indicators)
Specimen Collection Date/Time
Specimen Parent ID
Specimen Received Date/Time
Specimen Type
Specimen Source Site
Specimen Origin
Initial Temperature
Initial Pulse Oximetry
Representation in Data Harmonization Profile
ENCOUNTER / PATIENT VISIT
IMMUNIZATION
PATIENT CONTACT INFORMATION
PROCEDURE
ORDER / DIAGNOSTIC TEST
RESULT
SPECIMEN
VITAL SIGN INDICATOR
Table 55 - CSTE Workgroup Recommendations - Alignment to Data Harmonization Profile
HITSP C83 Content Modules Alignment
The following table (Table 56) describes the alignment of Public Health Reporting Initiative objects to the HITSP C83
Content Modules.
Aligned to HITSP C83 Content Module
Not represented in HITSP C83
Personal Information Module
Not represented in HITSP C83
Not represented in HITSP C83
Problem Module
Healthcare Providers Module
Data Harmonization Profile Object
REPORT METADATA
PATIENT INFORMATION
FACILITY
EMPLOYMENT INFORMATION
HEALTH PROBLEM
PROVIDER INFORMATION
76
Office of the National Coordinator for Health Information Technology
Aligned to HITSP C83 Content Module
Encounter Module
Represents elements defined in the Procedure Module
Represents elements defined in the Support Module
Represents elements defined in the Vital Signs Module
Represents elements defined in the Immunization Module
Represents elements defined in the Test Results Module
Not represented in HITSP C83
Not represented in HITSP C83
Not represented in HITSP C83
Data Harmonization Profile Object
ENCOUNTER / PATIENT VISIT
PROCEDURE
PATIENT CONTACT INFORMATION
VITAL SIGN INDICATOR
IMMUNIZATION
RESULT
ORDER / DIAGNOSTIC TEST
SPECIMEN
IMMUNIZATION
Table 56 - HITSP C83 Content Module Alignment View
FHIM Implementation Alignment
An initial alignment of the Federal Health Information Model (FHIM) was conducted to show how the FHIM entities
would align to the objects defined in this Data Harmonization Profile. A separate spreadsheet was also developed
showing how the Federal Health Information Model (FHIM) entities can be used to implement these objects. The results
of that analysis are summarized below. The complete FHIM model can be viewed at
http://www.fhims.org/content/420A62FD03B6_root.html. The FHIM is modeled in an open standard called UML. An
export of the FHIM is available on the web page in an open standard called XMI which can be imported into many UML
modeling tools. Also, all FHIM artifacts are maintained in a GForge repository under the management of the Open
Health Tools (OHT) Initiative. Individuals wishing to access these artifacts may create and account/OHT user name at
https://www.projects.openhealthtools.org/sf/sfmain/do/myPage?cookieCheck=on&detour=https%253A%252F%252Ffhi
ms.projects.openhealthtools.org%252Fservlets%252FProjectHome. Once the user name is created, send an email to
steven.wagner@hhs.gov and access will be provided to the FHIM GForge repository.
Table 57 shows the alignment between FHIM and data harmonization profile objects:
Representation in the FHIM
Can represent elements defined in the ClinicalDocumententity
Can be represented with the Patient Demographics entity
Can be represented in various entities that represent physical
locations
Requires further analysis
Can be represented in various entities that deal with clinical
observations
Represented in the Provider entity
Requires further analysis
Represented in the Encounter entity
Can be represented in various entities that deal with procedures
Can be represented with the Patient Demographics entity
Represented in the Vital Signs entity
Data Harmonization Profile Object
REPORT METADATA
PATIENT INFORMATION
FACILITY
EMPLOYMENT INFORMATION
HEALTH PROBLEM
PROVIDER INFORMATION
EXPOSURE / INJURY
ENCOUNTER / PATIENT VISIT
PROCEDURE
PATIENT CONTACT INFORMATION
VITAL SIGN INDICATOR
77
Office of the National Coordinator for Health Information Technology
Representation in the FHIM
Can be expressed using the ImmunizationandSkinEvent
Can be represented in various entities that produce results, such as
Lab or Radiology
Can be represented in various entities that have elements associated
with orders, such as Lab or Radiology
Can be represented using health concern
Can be represented in the Lab entity
Requires further analysis
Data Harmonization Profile Object
IMMUNIZATION
RESULT
ORDER / DIAGNOSTIC TEST
SOCIAL HISTORY
SPECIMEN
IMMUNIZATION
Table 57 - Federal Health Information Model (FHIM) Alignment
Consolidated CDA Alignment
The following table (table 58) describes the alignment of Public Health Reporting Initiative objects to Consolidated CDA
sections. A more detailed mapping to CDA will be made available in the Core Common Data Element Spreadsheet
available here: http://wiki.siframework.org/PHRI+-+Data+%26Terminology+Harmonization+Sub-Workgroup.
Additionally, the CDA template library (available here: http://wiki.siframework.org/PHRI+Implementation+Guide)
produced by the Public Health Reporting Initiative contains more implementable guidance around CDA sections and
entries.
Aligned to Consolidated CDA
Represents elements defined in the Plan of Care section
Represents elements defined in the Problem section
Not represented in Consolidated CDA11
Represents elements defined in the Encounters section
Represents elements defined in the Allergies section
Represents elements defined in the Encounters section
Represents elements defined in the Informant header element
Represents elements defined in the Immunizations section
Represents elements defined in the Medications section
Represents elements defined in the Plan of Care section
Represents elements defined in the Participant header element
Represents elements defined in the Record Target header element
Represents elements defined in the Procedures section
Represents elements defined in the Documentation Of header element
Not represented in Consolidated CDA
Represents elements defined in the Results section
Represents elements defined in the Social History section
Represents elements defined in the Procedure Specimens Taken section
11
Data Harmonization Profile Object
N/A (Care Plan not included)
HEALTH PROBLEM
EMPLOYMENT INFORMATION
ENCOUNTER / PATIENT VISIT
EXPOSURE / INJURY
FACILITY
PATIENT INFORMATION
IMMUNIZATION
MEDICATION
ORDER / DIAGNOSTIC TEST
PATIENT CONTACT INFORMATION
PATIENT INFORMATION
PROCEDURE
PROVIDER INFORMATION
REPORT METADATA
RESULT
SOCIAL HISTORY
SPECIMEN
Interoperability CDA templates for occupational information are currently being developed by NIOSH.
78
Office of the National Coordinator for Health Information Technology
Aligned to Consolidated CDA
Not represented in Consolidated CDA
Represents elements defined in the Vital Signs section
Data Harmonization Profile Object
IMMUNIZATION
VITAL SIGN INDICATOR
Table 58 - Consolidated CDA Alignment
6. Limitations, Lessons Learned, and Next Steps
The purpose of this section is to describe the gaps, lessons learned and the proposed next steps for subsequent releases
of this Data Harmonization Profile and further PHRI data harmonization tasks. It is expected that this section will aim at
further data harmonization, and that the data harmonization profile will be translated and addressed in subsequent
releases of PHRI data exchange specifications.
Data Harmonization Limitations
The PHRI use case scope is limited to the use of a healthcare provider’s EHR system for reporting patient-level events of
public health interest to a public health agency12 and submitted PHRI user stories. The number of user story
submissions (30) is considered a small representation of the total available PH data exchanges that can be considered.
However, these samples provided a workable cross section of different report types that could be used to form the basis
of an extensible profile over time. The initiative’s goal is to provide an initial set of deliverables that can be used for
pilot testing and analysis against existing and/or new PH data exchange requirements within a specified reporting
domain, e.g., Child Health. Therefore, it is expected that the initial set of data elements, controlled terminologies, and
data exchange format delivered under PHRI will not support all PH reporting requirements.
Another limitation concerned resources and resource availability – the Initiative may not have included all types of
participants or enough dedicated time from existing participants.
Lessons Learned
The PHRI identified several key lessons that should be applied to subsequent phases of data harmonization:
1. We believe that our results demonstrate a successful approach in the development of public health reporting
common core data elements for public health reporting that may serve as a foundation for the development of
new profiles for data exchange, the improvement of existing profiles and further steps in the development of a
Federal Health Architecture (FHA).
12
Use Case and Functional Requirements Development for Interoperability
Public Health Reporting Initiative Consensus Approved Use Case Document:
http://wiki.siframework.org/file/view/PHRI+Use+Case+09252012+Consensus+Approved.pdf/367700864/PHRI%20Use%20Case%2009252012%20Consensus%20Appr
oved.pdf
79
Office of the National Coordinator for Health Information Technology
2. We learned that a data harmonization step should precede the development of data exchange specifications. In
this way, a harmonization of existing data exchange specifications and the development methodology for
consolidated specifications will become systematic and predictable.
3. We learned that there are gaps in existing national policies and procedures which focus on the coordination,
development and maintenance of standardized data elements and value sets. For example, the relationship
between PHIN Vocabulary Access and Distribution System (VADS), AHRQ United States Health Information
Knowledgebase (USHIK) and National Library of Medicine (NLM). Furthermore, a successful implementation of
standardized content will depend on the successful coordination and maintenance of clinical care and public
health vocabularies.
4. Our collaboration with Federal Health Information Modeling (FHIM) leveraged previous work to harmonize and
model common information in the clinical domain with federal partners (DoD, VA, FDA, etc.). The result
demonstrated that public health reporting data elements were successfully modeled to FHIM clinical care
domains. This work can be expanded further to harmonize other public health domains and report types to
FHIM both horizontally (between federal organizations) and vertically, through jurisdictional-level government
agencies and clinical care providers.
5. We learned lessons that apply to specific data harmonization tasks:
 Defining objectives and near term goals.
The overall objective to reduce the healthcare provider reporting burden was widely understood and
accepted by stakeholders; however, a determination of the appropriate near term goals, deliverables
and expectations was less clear. A more balanced set of short-term objectives needs to be agreed upon
quickly because all other activity is dependent upon managing “scope creep” and the purpose and
timeline for completing deliverables. A major challenge was determining the boundaries of the work
effort, which limited available time to focus on technical details given the limited resource commitment
and availability.
 Assessment of existing implementations of standards and current process of information exchange.
The PHRI specification was intended to reduce the reporting burden; thus we tried to create a
specification that covered one or more public health exchanges. As we began to examine reporting
programs, some fit the PHRI paradigm while others did not (or did not completely). There are several
existing PH specifications or other clinically-oriented specifications in use or under development, with
varying levels of adoption. It was difficult to determine early on which data exchanges were similar and
in some cases no automated process exists as reporting is primarily paper-based. More upfront analysis
should have taken place to group similar exchanges or process flows with available standards that could
be immediately adopted, adapted or further developed by a specific reporting domain or report type. A
tremendous amount of time was taken to remodel and reclassify data elements. There were several
existing artifacts that should have been used early on to help direct the business and technical
resources. For example, vocabulary experts could have been tasked with analyzing existing
specifications and could have provided a summary for how to reconcile value sets. Data modelers
should have worked with existing specifications and provided a summary of how the information classes
were reconciled to the appropriate existing artifacts, (e.g., HL7 Reference Implementation Model (RIM),
CDA R2 Refined Message Information Model (RMIM), FHIM, etc.) Background analysis and
harmonization across specifications should have been summarized and presented for decision making
80
Office of the National Coordinator for Health Information Technology


earlier. More transparency around the user story selection criteria would have been helpful in the
articulation of user stories.
Business and technical stakeholder engagement.
Task management should have leveraged earlier co-lead recommendations to form smaller workgroups.
Persons with modeling experience could have started the data harmonization work earlier, while
business users could have focused more on reconciling differences or inconsistencies in current process
flows that did not require technical decisions. Many of the meetings and discussions blended technical
and business discussions which often left one group confused or frustrated. Without clearly defined
roles and responsibilities, it was very difficult to manage input and feedback between technical and
business teams.
Applicability of the scope of common core data elements and limitations of the user story.
The process started with the submission of user stories by participants to represent their program
domain. Those user stories included a set of data elements that were contained in the EHR and that
were deemed necessary to support their workflow. Those data elements became the focus of the
harmonization work to identify the common core versus the program-specific data sets. Data elements
that appeared in only one user story were considered program-specific. However, many of the data
elements that were cited by a single user story were needed by other domains but had not been
included in their set of required data elements (medications were cited by only the Immunization user
story, e.g.). User story authors may have been thinking narrowly about a specific workflow rather than
broadly of all of their data needs from the EHR. Additionally, user story authors may have been unclear
if they needed to describe a current or future process. A more explicit description of what to include
and consider could help guide the process of authoring user stories, but it is likely that the project team
will need to use judgment to determine which data elements belong in the common core.
Next Steps
Future consideration for how to approach the gaps and lessons learned should be assessed using the following general
characterizations:
 Pilot Testing: The number of organizations that expressed interest in using the PHRI specification to support
pilot testing is a critical success criterion for the overall initiative. Pilot testers provide the required feedback
mechanism for evaluating how well the specification supports the objectives of Phase I data exchange
requirements articulated in the original user stories. Pilot testing also helps identify gaps within a domain or
across domains, especially for programs that were not well represented in the Phase I scope, e.g., bi-directional
data exchange and aggregated reporting.
 Data Standards Harmonization: The development of the PHRI CDA specification is largely based upon the
Consolidated CDA Specification; however, templates that could not be directly adopted or easily adapted to
support PH reporting will require enhancement for more explicit and broader PHRI adoption over time. This
includes but is not limited to the addition of data elements within a given template, and addition of terms and
definitions to a referenced value set for a specific template. These are examples of work efforts that need to
take place in parallel with pilot testing to help address current gaps found in any reference artifact (CDA
template or vocabulary code set).
 Assessment and cross-reference to HL7 2.x messaging specifications is needed.
81
Office of the National Coordinator for Health Information Technology



Extensions to the base PHRI Phase I artifacts (Use Case, Functional Requirements, Data Harmonization Profile
and CDA Specification): Stakeholder organizations that did not participate in Phase I activities are encouraged to
assess whether their program requirements map to or can be reconciled against the Data Harmonization Profile
and PHRI Specification. Since it is understood that not all PH reporting requirements are accommodated fully in
the Phase I deliverables, it is expected that additional user story submissions are needed to further extend and
refine the Phase I deliverables for broader adoption over time, as well as subsequent releases of Meaningful Use
Standards harmonization and selection
Communication with ONC and other national partners: Further implementation of harmonized data content
depends on coordination of harmonization efforts on a national level and implementation strategies for
vocabulary development and maintenance in both the clinical and public health realm.
Resource Availability – resources, in terms of both time and people, are essential and need to be supported by
future initiatives to ensure adequate availability to get the job done thoroughly.
82
Office of the National Coordinator for Health Information Technology
Appendix A – Summary of Data Element Optionality
Because what is “required” for a specific public health report may differ substantially depending on what type of public
health report is being exchanged, reporting programs have the flexibility to define optionality for each of the common
core data elements defined in the Data Harmonization Profile.
Initially, user story submitters included recommended optionality for specific reporting scenarios which was taken into
account as the common core data elements were identified and discussed. However this document is not intended to
set a level of optionality across public health reporting programs. Original submissions, including proposed optionality,
are available on the Public Health Reporting Initiative wiki page, here: http://wiki.siframework.org/PHRI++Data+%26Terminology+Harmonization+Sub-Workgroup.
Data Element Optionality
Table 59 lists the 5 possible options defined by the Public Health Reporting Initiative for data element optionality.
1
2
3
4
5
Required and Null Flavor NOT allowed
Required and Null Flavor is allowed
Required data field to be collected, may be empty
Required data field if you collect it, but may be empty
Shall not / not allowed
Table 59 - Summary of Data Element Optionality
When a data element is required, it is listed as Required in the Optionality column of an entity’s data element table in
the companion user story spreadsheets. Required is used for optionality when the element is required to make the
report valid and complete. The definition of “valid and complete” is left to implementation guides and stakeholders to
finalize, but is meant to imply that the report would not be usable, machine-readable, or acceptable without the data
element being provided by the sender.
An additional option is also outlined as part of cancer reporting that focuses on data that MAY be reported and WOULD
allow a NULL flavor to be defined.
Examples of NULL Flavors
A data element may exist that would require a value to be filled in, but does not require a specific value to be defined.
This most commonly occurs when a public health report needs to include elements that the receiving system would
expect on other report types, and thus is designed to accept, but for this particular report’s purpose, is not needed.
Entity Optionality
Within each of the core objects of the Public Health Reporting Data Harmonization Profile Specification there is a coded
value defined, so that all EHR vendors can use coded values as a basis for exchanging public health reports. Where
optionality is less constrained in the Public Health Reporting Data Harmonization Profile specification is for those data
elements that may not have a coded value available (for example, where a CCD does not require a coded value and
where the EHR might not have information stored with a specific controlled vocabulary, but with text).
83
Office of the National Coordinator for Health Information Technology
To fully understand optionality, it is important to consult the corresponding Public Health Reporting domains to
understand their usage of specific data elements. The following table (Table 61) shows how optionality at the entity level
is characterized in this alignment analysis:



SHALL: an absolute requirement for all public health reporting domains
SHALL NOT: an absolute prohibition against inclusion for all public health reporting domains
SHOULD/SHOULD NOT: A best practice or recommendation to be considered by each public health reporting
domain within the context of their requirements; there may be valid reasons to ignore an item, but the full
implications must be understood and carefully weighed before choosing a different course
 MAY/NEED NOT: This is truly optional language for a public health reporting domain; can be included or omitted
as the domain decides with no implications
To support this domain alignment, the Public Health Reporting Initiative used the Consolidated Conformance Verb
Matrix included as part of the HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1.
This matrix is listed below:
RFC 2119
HL7
SHALL
Absolute
requirement of the
specification
SHALL NOT
Absolute prohibition
of the specification
SHOULD
Recommended
There may exist valid
reasons in particular
circumstances to
ignore a particular
item, but the full
implications must be
understood and
carefully weighed
before choosing a
different course.
SHALL
Required/Mandatory
SHOULD NOT
Not Recommended
MAY
Optional
SHOULD NOT
Not Recommended
MAY
Accepted/Permitted
SHALL NOT
Not
Required/Mandatory
SHOULD
Best Practice or
Recommendation
IHE
R (Required)
Element must be present
but can be NULL
-
HITSP
R (Required)
Data elements must
always be sent. A NULL
can be sent.
-
R2 (Required if known)
The sending application
must be able to
demonstrate that it can
send all required if known
elements, unless it does
not in fact gather that
data. If the information
cannot be transmitted, the
data element shall contain
a value indicating the
reason for omission of the
data.
-
R2 (Required if known)
If the sending
application has data for
the data element, it is
REQUIRED to populate
the data element. If the
value is not known, the
data element need not
be sent
O (Optional)
O (Optional)
-
84
Office of the National Coordinator for Health Information Technology
RFC 2119
-
HL7
-
IHE
C (Conditional)
A conditional data element
is one that is required,
required if known or
optional depending upon
other conditions.
HITSP
C (Conditional)
Required to be sent
when the conditions
specified in the HITSP
additional specifications
column are true
Table 60 - Summary of Conformance Criteria
To make the domain alignment more usable, the proposed approach would rely on defining conformance language at
the entity level, and then giving implementers and vendors the flexibility they need to implement at the data element
level the specific reporting options needed.
85
Office of the National Coordinator for Health Information Technology
Appendix B – Acronyms
The following table summarizes the most common terms and acronyms used in this Data Harmonization Profile:
Acronym or Term
Definition/Description
ADE
Adverse Drug Event
AHRQ
Agency for Health Research and Quality
CDA
Clinical Document Architecture
CEDD
Clinical Element Data Dictionary
CIMI
Clinical Information Modeling Initiative
CLIA
Clinical Laboratory Improvement Amendments
CMS
Centers for Medicare and Medicaid Services
CPT
Current Procedural Terminology
CSTE
Council of State and Territorial Epidemiologists
CVX
HL7 Table 0292, Vaccine Administered (CVX)
DAM
Domain Analysis Model
DoD
Department of Defense
DSM
Diagnostic and Statistical Manual
EHDI
Early Hearing Detection and Intervention
EHR
Electronic Health Record
EMR
Electronic Medical Record
ER
Emergency Room
FDA
Food and Drug Administration
FHA
Federal Health Architecture
FHIM
Federal Health Information Model
HAI
Healthcare Associated Infections
HCP
Healthcare Provider
HCPCS
Healthcare Common Procedure Coding System
HIE
Health Information Exchange
HIPAA
Health Insurance Portability and Accountability Act
HIT
Health information technology
HITECH Act
Health Information Technology for Economic and Clinical Health Act of 2009
HITSP
Health Information Technology Standards Panel
HL7
Health Level 7
HMO
Health Maintenance Organization
ICD
International Classification of Diseases
ICSR
Individual Case Safety Reports
IHE
Integrating the Healthcare Enterprise
IIS
Immunization Information System
IQR
Infrastructure, Quality and Research
IS
Information System
ISDS
International Society for Disease Surveillance
JCIH
Joint Committee on Infant Hearing (JCIH)
86
Office of the National Coordinator for Health Information Technology
Acronym or Term
LIS
LOINC
LRI Workgroup
MDA
MDHT
MU
MVX
NAACCR
NCHS
NDF-RT
NHCS
NIOSH
NLM
NPI
NUBC
NUCC
OHT
ONC
PHIN VADS
PHR
PHRI
RIM
RMIM
S&I Framework
TNM
UCUM
UMLS
UNII
USHIK
VA
VIS
XMI
Definition/Description
Laboratory Information System
Logical Observation Identifiers Names and Codes
Laboratory Results Interface Workgroup
Model Driven Architecture
Model Driven Health Tools
Meaningful Use
HL7 Table 0227, Manufacturers of Vaccines (MVX)
North American Association of Central Cancer Registries
National Center for Health Statistics
National Drug File - Reference Terminology
National Hospital Care Survey
National Institute for Occupational Safety and Health
National Library of Medicine
National Provider Identifier
National Uniform Billing Committee
National Uniform Claim Committee
Open Health Tools
Office of the National Coordinator for Health Information Technology
Public Health Information Network Vocabulary Access and Distribution System
Personal Health Record
Public Health Reporting Initiative
Reference Information Model
Refined Message Information Model
Standards & Interoperability Framework
TNM Classification of Malignant Tumours
Unified Code for Units of Measure
Unified Medical Language System
Unique Ingredient Identifier
United States Health Information Knowledgebase
U.S. Department of Veterans Affairs
Vaccine Information Statement
XML Metadata Interchange
Table 61 - Definitions and Acronyms Used in Data Harmonization Profile
87
Office of the National Coordinator for Health Information Technology
Appendix C – References
The following list of references was used as part of this Data Harmonization Profile:
Reference Name
Location
CSTE Recommendation
http://wiki.siframework.org/PHRI++Data+%26Terminology+Harmonization+SubWorkgroup (communicable & syndromic tab on
the “Common Core” spreadsheet)
http://www.syndromic.org/uploads/files/ISDSRec
ommendationPRELIMINARY_EHRDataReq4SS_vFINALerratumr2.pdf
www.wiki.hitsp.org/docs/C83/C83-1.html
ISDS Recommendation
– Syndromic
Surveillance
HITSP C83 Content
Modules
Usage within this Data Harmonization
Profile
The CSTE recommendations were used
to support development of the
Communicable Disease Domain
The ISDS recommendations were used
to support development of the
Communicable Disease Domain
HL7
www.HL7.org
Federal Health
Information Model
(FHIM)
http://www.fhims.org
S&I Framework Public
Health Reporting Use
Case
http://wiki.siframework.org/file/view/PHRI+Use+C
ase.docx
HL7 Version 2.5.1:
Implementation Guide
for Immunization
Messaging, Release 1.4
HL7 Immunization
Domain Analysis Model
(DAM)
IHE Maternal Health
Profiles, including:
http://www.cdc.gov/vaccines/programs/iis/techni
cal-guidance/downloads/hl7guide-1-4-201208.pdf
HITSP C83 CDA Content Modules were
used as a reference source to ensure
alignment of this Data Harmonization
Profile to work done within HITSP in
developing HITSP components in
support of many of the concepts
expressed here.
HL7 provides standards for
interoperability.
The FHIM is the primary mechanism for
implementation alignment of this Data
Harmonization Profile to possible
implementation standards
The S&I Framework Public Health
Reporting Use Case serves as the
primary source of requirements for this
Data Harmonization Profile.
The HL7 2.5.1 Implementation Guide for
Immunization Messaging was used to
help develop the Immunization Domain.
http://wiki.siframework.org/file/view/HL7+Immun
ization+Domain+Analysis+Model.docx
The HL7 Immunization DAM is used to
help develop the immunization Domain
http://wiki.ihe.net/index.php?title=Profiles#IHE_P
atient_Care_Coordination_Profiles
The IHE Maternal Health and Newborn
profiles were used to support
development of the Child Health
Domain.
88
Office of the National Coordinator for Health Information Technology
IHE Immunization
Content Profile
http://wiki.ihe.net/index.php?title=Profiles#IHE_P
atient_Care_Coordination_Profiles
The IHE – Immunization Content Profile
was used to support the development of
the Immunization Domain
Table 62 - Data Harmonization Profile References
89
Office of the National Coordinator for Health Information Technology
Appendix D – Submitted User Stories
User stories were submitted to the PHRI for phase 1 in 2011. These user stories were evaluated, classified into the 5
domains referenced above (adverse event, child health, chronic disease, communicable disease, and infrastructure,
quality and research), and encouraged to participate in the data harmonization work. The included report type data
elements upon which this document is derived are available here http://wiki.siframework.org/PHRI++Data+%26Terminology+Harmonization+Sub-Workgroup). These represent a subset of the initial user stories submitted,
listed below:

Adverse Events
o FDA Spontaneous Triggered Event Reporting
o FDA Spontaneous Triggered Event Reporting #2
o Immunization Information Systems (AIRA)
o Medical Device Reporting (FDA-CDRH)
o Patient Safety Reporting - AHRQ Common Formats

Child Health
o Birth / Fetal Death Registration
o Birth Defects Reporting
o Birth Event Reporting
o Early Hearing Detection and Intervention (EHDI)
o Health Information Exchanges (HIEs) and Immunizations
o Immunization
o Immunization Information Systems (AIRA)
o Maine CDC - Data Research and Vital Statistics
o Newborn Hearing Screening
Chronic Disease
o Cancer Genetics - BRCA
o Cancer
o Cardiovascular Disease (NDHHS)
o Impact of Work on Health
o National Health Care Surveys
o Patient Safety Reporting - AHRQ Common Formats
o Quality Reporting
Communicable Disease
o Syndromic Measure Reporting
o Communicable Disease Case Reporting
o Florida Dept of Health - Enteric Disease Reporting
o Healthcare-Associated Infections
o Michigan Disease Surveillance System - Public Health Communicable Disease Surveillance System
o Minnesota Dept of Health - Communicable Diseases (ASTHO)
o Oregon Health Authority - Mandated Disease Reporting
o Patient Safety Reporting - AHRQ Common Formats
o Public Health Case Reporting
o South Dakota Communicable Disease Reporting



Infrastructure, Quality, and Research
o Admin Use of Health Data
o National Health Care Surveys
o Patient Safety Reporting - AHRQ Common Formats
o PH Reporting User Story Model
90
Office of the National Coordinator for Health Information Technology
o
o
o
o
o
Public Health Data Quality Assurance
Quality Reporting
Registration for Public Health Reporting
UW MED - PHINEX: University of Wisconsin Medical Record - Public Health Information Exchange
Healthcare-Associated Infections
91
Office of the National Coordinator for Health Information Technology
Appendix E – Federal Health Information Model (FHIM)
The Federal Health Information Model contains many concepts and structures that are of interest to Public Health
Reporting. The Public Health Reporting Initiative (PHRI) may therefore benefit from the re-use of the FHIM concepts
rather than undergo a separate effort to identify and document similar concepts. Specific information about the
location of common core data elements is available in Section 3 of this document.
The FHIM is organized into “domains”, which are simply groupings of related concepts. The following pages contain a
diagram from each of the domains which contain Public-Health related information. It is not expected that PHRI will use
all the concepts in every domain shown here, rather these diagrams show the universe of potential elements from which
to choose. The following list includes examples of FHIM domains:
 Person Demographics – contains information about persons as well as other organisms which might be the
subject of health related activity such as animal patients (veterinary), animal research subjects, and diseasecausing organisms. For persons, this domain includes information related to patients to include contact
information
 Birth Certificate – contains information about the birth of a person which may be found on the US Standard
Certificate of Live Birth (Revision 11/2003)
 Death Certificate - contains information about the death of a person which found on the US Standard Certificate
of Death (Revision 11/2003)
 Provider – contains information about healthcare providers and organizations, to include license and specialty
information
 Encounter – contains information related to patient encounters, to include inpatient / long term care stays and
outpatient visits, admissions, discharges, and transfers
 Allergies – contains patient allergy information
 Problem List – contains issues that a clinician may wish to track about a patient
 Orders – contains concepts common to orders and information needed to manage orders (from the clinician’s or
“placer’s” point of view)
 Laboratory – contains laboratory result information
 Pharmacy – contains information regarding pharmacy dispenses and provides a mechanism for patient
medication list
 Immunization – contains information regarding a patient’s immunizations, suitable for reporting to an IIS
 Common Product information – contains concepts regarding medicinal and other products. Based on the HL7
V3 Common Product Model
 Newborn Hearing Screening – contains results of newborn hearing screen
 Common Classes – contains classes that are used in multiple domains
 Data Types – contains classes to be used as data types within the FHIM. All other data types are primitive (e.g.,
string, Boolean, etc.)
Please see www.fhims.org to view the latest model.
Please note that the following diagrams may require that the reader increase the magnification (i.e., “zoom-in”) in order
to be able to fully see the information within. Also please note that during the creation of the diagram, some class
names did not render; we are investigating this abnormality.
92
Office of the National Coordinator for Health Information Technology
Person Demographics:
93
Office of the National Coordinator for Health Information Technology
Birth Certificate:
94
Office of the National Coordinator for Health Information Technology
Death Certificate:
95
Office of the National Coordinator for Health Information Technology
Provider:
96
Office of the National Coordinator for Health Information Technology
Encounter:
97
Office of the National Coordinator for Health Information Technology
Intolerance Condition (aka Allergy):
98
Office of the National Coordinator for Health Information Technology
Health Concern (aka Problem List):
99
Office of the National Coordinator for Health Information Technology
Orders:
100
Office of the National Coordinator for Health Information Technology
Lab:
101
Office of the National Coordinator for Health Information Technology
Pharmacy:
102
Office of the National Coordinator for Health Information Technology
Immunization:
103
Office of the National Coordinator for Health Information Technology
Newborn Hearing Screening:
104
Office of the National Coordinator for Health Information Technology
Common Product Model (Medications and Devices):
105
Office of the National Coordinator for Health Information Technology
Common Classes:
106
Office of the National Coordinator for Health Information Technology
Data Types:
107