# PHIN MESSAGING GUIDE FOR SYNDROMIC

SURVEILLANCE

ADT MESSAGES A01 , A03, A04, and A08

HL7 Version 2.5.1

(Version 2.3.1 Compatible)

Document Version ID: 1. 4

Draft for Review

March 2011



## Centers for Disease Control and PreventionPHIN Messaging Guide for Syndromic Surveillance This page intentionally left blankPHIN Messaging Guide for Syndromic Surveillance 

## Copyright and Trademarks

 HL7 Version 2.5.1 IG: Electronic Lab Reporting to Public Health, R1 (US Realm) © 2010

Health Level Seven, International. All rights reserved.

 HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S.

Pat & TM OffPHIN Messaging Guide for Syndromic Surveillance 

## Acknowledg e ments

This guide was produced and developed through the efforts of a project designed to spe cify a messaging guide for the Syndromic Surveillance . A li st of core data elements for Syndromic

Surveillance was developed by the International Society for Disease Surveillance ( ISDS ) in

collaboration with the Centers for Disease Control and Prevention ( CDC )

, Office of Surveillance, Epidemiology and Laboratory Services ( OSELS), Public Health Surveillance Program Office (PHSPO). The BioSense Program in PHSPO has provid ed funding to support these activities.

The CDC , OSELS, Public Health Informatics and Technology Program Office (PH ITPO) have been the principal author in the development of this messaging guide. A draft of the messaging specification was reviewed by many national and state public health organizations, standar d development organizations and vendors, including the Joint Public Health Informatics Taskforce (JPHIT), Public Health Data Standards Consortium (PHDSC), Health Level 7 (HL7), and the American Health Information Management Association (AHIMA)

.

The contributing edito rs would also like to express gratitude to these reviewers for their thoughtful comments and support during development of this guide.

In addition, special t hanks needs to be expressed to the following groups:

ISDS Meaningful Use Workg rou p:

 Michael A. Coletta, MPH (Workgroup Chair), Virginia

 Ryan Gentry, Indiana State Department of Health

 Julia E. Gunn, RN, MPH, Boston Public Health Commission

 Richard S. Hopkins, MD, MSPH, Florida Department of Health

 Amy Ising, MSIS, University of North Carolina Department of Emergency Medicine at Chapel Hill

 Geraldine S. Johnson, MS, New York State Department of Health

 Bryant T. Karras MD, State of Washington, Department of Health

 Karl Soetebier, Georgia Department of Community Health

 David Swenson, MEd, State of New Hampshire, Department of Public Health

Services

ISDS Board of Directors

 David Buckeridge, MD, PhD, ISDS President, McGill University and Montreal Public Health Department

 John S. Brownstein, PhD, ISDS Vice

- President, Harvard Medical School

 Howard Burkom, PhD, Johns Hopkins University Applied Physics Laboratory

 Wendy Chapman, PhD, University of California, San Diego School of Medicine, Division of

Biomedical Informatics

 Jean

- Paul Chretien, MD, PhD, Lieutenant Commander, US Navy

 Julia E. Gunn, RN, MPH, Boston Public Health Commission

 Bill Lober, MD, University of Washington

 Joseph S. Lombardo, PhD, Johns Hopkins Applied Physics Laboratory

 Marc Paladini, MPH, New York City Department of Health and Mental HygienePHIN Messaging Guide for Syndromic Surveillance



### ISDS Staff

 Charlie Ishikawa, MSPH

 Anne Gifford, MPH

 Rachel Viola

 Emily Cain, MPH

 HLN Consulting, LLC: Noam H. Arzt, PhD; Daryl Chertcoff; Maiko Minami

CDC, Office of Surveillance, Epidemiology and Laboratory Services (OSELS)

 Stephen B. Thacker, MD, MSc, USPHS, Director

 Seth Foldy, MD, MPH, Director , PHITPO

 Laura Conn, MPH, Associate Director for Information Science , PHITPO

 Nedra Gar r ett, MS, Dir ector , Division of Informatics Practice, Policy and Coordination,

PHITPO

 Robb Chapman, Sc.D , Acting Director, Division of Informatics Solutions and Operations,

PHITPO

 James W. Buehler, MD, Director

, PHSPO

 Sam uel L. Groseclose, DVM, MPH, Dipl. ACVPM, Acting Director , Division of Healthcare Information, PHSPO

 Taha A. Kass

- Hout, MD, MS, Deputy Director for Information Scienc e and BioSense Program Manager, Division of Healthcare Information, PHSPO and Syndromic

Surveillance sub

- group lead of the CDC Meaningful Use Advisory Group

Editorial Board

 Lead Co

- Editor: Nikolay Lipskiy, MD, DrPH, CDC, PHITPO

 Lead Co

- Editor: W. Ted Klein, MS, HL7

 Lead Co

- E ditor: Donald T. Mon, PhD, AHIMA , Vice

- President

 Edito r: Sondra R. Renly, MS, MLS, International Business Machines

 Editor: Anna Orlova, PhD, PHDSC

Group of Developers

 Adam Browning, Northrop Grumman, Contractor for OSELS

 Sundak Ganesan, MD, MS, Northrop Grumman, Contractor for OSELS

 Mary Hamilton, R.N., Northrop Grumman, Contractor for OSELS

 W. Ted Klein, MS, Klein Consulting, Contractor for OSELS

 Sergey Li, Northrop Grumman, Contractor for OSELS

 Sharon Lytle, MS, Northrop Grumman Contractor for OSELS

For Information about this Guide, contact: PHINtech@cdc.govPHIN Messaging Guide for Syndromic Surveillance 

## Table of Contents

1 BACKGROUND

................................ ................................ ...................... 9

2 INTRODUCTION

................................ ................................ ................. 11

2.1 P URPOSE



### ................................ ................................ ....................... 13

2.2 A UDIENCE



### ................................ ................................ ....................... 13

2.3 S COPE



### ................................ ................................ .......................... 13

2.4 C OMPATIBILITY



### ................................ ................................ ................. 15

2.5 E XTENSIBILITY



### ................................ ................................ .................. 15

2.6 Q UALIFICATIONS AND 

### C AVEATS



### ................................ .............................. 16

3 HL7 MESSAGING FOR SY NDROMIC SURVEILLANCE

............................ 17

3.1 B ASIC 

### HL7 T ERMS



### ................................ ................................ ............. 17

3.2 S UPPORTED 

### D ATA 

### T YPES FOR 

### S YNDROMIC 

### S URVEILLANCE



### .............................. 18

3.3 E NCODING 

### R ULES



### ................................ ................................ .............. 19

3.4 U SE 

### C ASE 

### M ODEL



### ................................ ................................ ............. 20

3.4.1 Message Acknowledgements

................................ ............................ 22

3.4.2 Dynamic Interaction Models

................................ .............................. 23

3.4.3 Interactions

................................ ................................ ................. 24



### 3.5 S TATIC 

### M ODEL



### - M ESSAGE 

### S TRUCTURE



### ................................ .................... 25

3.5.1 HL7 Message Structure Attributes

................................ ...................... 25

3.5.2 Constrained Message Types

................................ ............................ 26

3.5.3 Constrained Message Structure ADT_A01

................................ ............ 27

3.5.4 Constrained Message Structure ADT_A03

................................ ............ 28

3.5.5 Constrained Message Structure ACK

................................ .................. 29



### 3.6 S TATIC 

### M ODEL



### – M ESSAGE 

### S EGMENTS



### ................................ ..................... 30

3.6.1 Segment Profile Attributes

................................ ............................... 30

3.6.2 Message Header (MSH) Segment

................................ ...................... 33

3.6.3 Event Type (EVN) Segment

................................ .............................. 37

3. 6.4 Patient Identification (PID) Segment

................................ .................... 39

3.6.5 Patient Visit (PV1) Segment

................................ ............................. 50PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.6 Patient Visit

– Additional Information (PV2) Segment

................................ 57

3.6.7 Observation/Result (OBX) Segment

................................ .................... 63

3.6.8 Diagnosis (DG1) Segment

................................ ............................... 72

3.6.9 Procedures (PR1) Segment

................................ .............................. 76

3. 6.10 Insurance (IN1) Segment

................................ ................................ 78

3.6.11 Message Acknowledgement (MSA) Segment

................................ ........ 83



### 3.7 HL7 B ATCH 

### P ROTOCOL



### ................................ ................................ ....... 84

3.7.1 HL7 Batch File Structure

................................ ................................ . 84

3.7.2 File Header (FHS) Segment

................................ ............................. 85

3.7.3 File Trailer (FTS) Segment

................................ ............................... 87

3.7.4 Batch Header (BHS) Segment

................................ ........................... 88

3.7.5 Batch Trailer (BTS) Segment

................................ ............................ 90



### 4 DATA ELEMENTS OF INT EREST

................................ ........................... 91

4.1 C OLUMN 

### D EFINITIONS FOR 

### E LEMENTS OF 

### I NTEREST 

### T ABLE



### ............................... 91

4.2 D ATA 

### E LEMENTS OF 

### I NTEREST FOR 

### S YNDROMIC 

### S URVEILLANCE



### ......................... 92

4.2.1 Minimum Data Set

................................ ................................ ......... 92

4.2.2 Extended Data Elements for Further Consideration

................................ 112

4.2.3 Future Data Elements for Further Consideration

................................ .... 115



### 5 EXAMPLES

................................ ................................ ........................ 119

5.1 A04 E MERGENCY 

### D EPARTMENT 

### R EGISTRATION 

### ; NO 

### U PDATES 

### ; A CKNOWLEDGEMENT



### R EQUESTED



### ................................ ................................ ................... 119

5.2 A04 E MERGENCY 

### D EPARTMENT 

### R EGISTRATION FOLLOWED BY 

### A08 U PDATE



### .......... 120

5.3 A04 E MERGENCY 

### D EPARTMENT 

### R EGISTRATION 

### ; A01 I NPATIENT 

### A DMISSION 

### ; A03

D ISCHARGE INCLUDING P ATIENT DEATH



### ................................ .................... 121

5.4 A01 I NPATIENT 

### A DMISSION 

### ; NO 

### U PDATES



### ................................ .................. 124

5.5 B ATCH 

### E XAM PLE



### ................................ ................................ .............. 125

5.6 S AMPLE 

### I NTERNATIONAL 

### A DDRESS 

### F ORMATS 

### : CONVERTED TO 

### PID SEGMENTS



### ....... 126

5.6.1 Countries Bordering The United States

................................ .............. 126



### 6 MISCELLANEOUS

................................ ................................ ............. 126

6.1 PHIN V OCABULARY 

### S ERVICES



### ................................ .............................. 126

6.1.1 PHIN Vocabulary and Distribution System

................................ ........... 127PHIN Messaging Guide for Syndromic Surveillance 

### 6.1.2 PHIN Message Quality Framework

................................ ................... 127Page 9

PHIN Messaging Guide for Syndromic Surveillance 

## 1 BACKGROUND

On February 17, 2009, the President signed the American Recovery and Reinvestment

Act of 2009 (Recovery Act). Title XIII of Division A and Title IV of Division B of the

Recovery Act, together cited as the Health Information Technology for Economic and

Clinical Health Act (HITECH Act), include provisions to promote meaningful use of

health information technology (health IT) to improve the quality and value of American

heal th care. In July 2010, the Center for Medicare and Medicaid Services released the

following: Medicare and Medicaid Programs; Electronic Health Record Incentive

Program; Final Rule, July 28, 2010 ( http://edocket.access.gpo.gov/2010/pdf/2010

-
17207.pdf )

This final rule specifies the initial criteria that eligible providers, eligible hospitals and

critical access hospitals must meet in order to qualify for an incentive payment, e.g.,

demonstrate meaningful use of certified EHR technology. Stage 1 criteria for meaningful

use focus on electronically capturing health information in a coded format, using that

information to track key clinical conditions, communicating that information for care

coordination purposes, and initiating the reporting of clinical quality measures and public

health information.

In addition, The Office of the National Coordinator for Health Information Technology

(ONC) release d a companion regulation that defined st andards, specifications, and

certification criteria to be used to meet the Meaningful Use objectives defined in the rule

above. This rule can be found at Health Information Technology: Initial Set of

Standards, Implementation Specifications, and Certificat ion Criteria for Electronic

Health Record Technology : Final Rule July 28, 2010

( http://edocket.access.gpo.gov/2010/pdf/2010

- 17210.pdf )Page 10

PHIN Messaging Guide for Syndromic Surveillance 

### The ONC final rule initially included an implementation specification for the Syndromic

Surveillance meaningful u se objective that would not support data exchange for

Syndromic Surveillance . Based on public health feedback, ONC agreed to retract the

standard while retaining the objective 1 

### . Although there was not an implementation

specification availa ble as a replacement immediately, public health was encouraged to

develop data recommendations and implementation specification that can be available

to inform the implementation of S yndromic Surveillance in Stage 1. It was therefore

deemed necessary to define EHR requirements that will support the core of

contemporary public health Syndromic Surveillance practice.

In September 2010, the CDC supported the International Society for Dise ase

Surveillance (ISDS) to recommend EHR requirements for core Syndromic Surveillance

business practices. As the prominent resource for current evidence, best practices, and

lessons learned in Syndromic Surveillance , ISDS works to improve population health by

advancing surveillance science and practice to support timely and effective prevention

and response.

ISDS used a community consensus

- driven process to develop its recommendation.

Input from a workgroup of local and state Syndromic Surveillance experts served as the

basis for early recommendation iterations (i.e., Preliminary Recommendation on

9/30/10, and a Provisional Recommendation on 12/1/10). Workgroup members

represented key public health stakeholder professional organizations (e.g., Counc il of

State and Territorial Epidemiologists, Association of State and Territorial Health

1 45 CFR Part 170 RIN 0991

– AB76, II. Discussion of the Interim Final Rule, A. Public Health Surveillance Implementation Specifications: "For all of these reasons, we are revising 45 CFR 170.205(d)(2) to remove these particular adopted implementation specifications. We are also removing from 45 CFR 170.302(l) the text „„(and applicable implementation specifications)‟‟ to provide additional clarity and to remove the unnecessary and unwarranted burden on ONC

– ATCBs and pe rhaps ONC

– ACBs. In addition, we are removing the reference to the implementation specifications in 45 CFR 170.299(g) where it is incorporated by reference.

, 45 CFR 170.205(d)(2)"Page 11

PHIN Messaging Guide for Syndromic Surveillance 

### Officials, National Association of County and City Health Officials, Joint Public Health

Informatics Taskforce). Input from all Meaningful Use stakeholders on the prov isional

recommendation document was collected during a public comment period. Stakeholder

input then informed ISDS‟s, “Final Recommendation: The Core Processes & EHR

Requirements of Public Health Syndromic Surveillance ”, published in January 2011.

As the ISDS workgroup developed recommendations, CDC translated the business

requirement recommendations to technical specifications.

To learn more about ISDS and the ISDS Meaningful Use Syndromic Surveillance

Workgroup activities and documents, refer to http://syndromic.org/projects/meaningful

use

.

In general, CDC is working to facilitate inclusion of Syndromic Surveillance standards in

the national health IT efforts including:

 Harmonization of Syndromic Surveillance standards with standards from other

public health domains (such as laboratory reporting ) ;

 Expansion of existing testing tools for validation of Syndromic Surveillance

messages and participation in nationally recognized HIT testing laboratories

(events), e.g., the Integrating the Healthcare Enterprise (IHE) Connectathon;

 Develop processes and criteria for certifications of public health systems

that support Syndromic Surveillance ;

 Enable technical assistance to local, state, territorial and tribal public health

agencies to deploy standards

- based IT solutions for Syndromic Surveillance

.



## 2 INTRODUCTION

The Public Health Information Network (PHIN) is defined as a national initiative to

increase the capacity of pu blic health to exchange data and information electronically

across organizational and jurisdictional boundaries by promoting the use of standards

and defining functional and technical requirements. A properly implemented PHIN

c ompliant messaging allows for the consistent exchange of response, health, and

disease tracking data between public health and healthcare partners.

Public Health Syndromic Surveillance is the regular and systematic collection andPage 12

PHIN Messaging Guide for Syndromic Surveillance 

### analysis of near "real

- time" patient data for timely assessments of population health. In

conjunction with other core public health functions 2 

### , PHSS assists in event detection,

situation awareness, and response management.

The PHIN Syndromic Surveillance Messaging Guide meets a national need for health

data exchange standards among healthcare providers and U.S. public health

authorities. The Guide provides the HL7 technical specifications necessary for

exchangi ng health data elements that are core to public health Syndromic Surveillance

practice in accordance with the ISDS Final Recommendations: Core Processes and

EHR Requirements for Public Health Syndromic Surveillance

. 3



### By retracting the proposed implementat ion specification for Syndromic Surveillance data

in the ONC final rule

, an urgent need exists for implementation guidance for the

Syndromic Surveillance (SS). To fulfill this need and lay a foundation for future work,

ISDS, a resource for Syndromic Survei llance best practices and lessons learned, with

the support of the CDC, convened a workgroup of public health surveillance experts to

recommend guidelines. Specifically, this Meaningful Use Workgroup (MU WG ) worked

to :

 Describe the core business processes, inputs and critical task sets of

contemporary Syndromic Surveillance practice

 Define the core EHR requirements for a Syndromic Surveillance message to a

local or state public health authority

As ISDS develop ed its reco mmendations, CDC was concurrently developing messaging

guidance to expedite the translation of ISDS‟s recommendations to technical

specifications. This document is a product of that collaboration.

2 Committee for the Study of the Future of Public Health. The Future of Public Health: Summary & Recommendations. (1988) pg. 7

3 International Society for Disease Surveillance. Final Recommendation: Core Processes and EHR Requirements for Public Health Syndromic Surveillance. (2011)Page 13

PHIN Messaging Guide for Syndromic Surveillance 

## 2.1 PURPOSE

This PHIN Messaging G uide for Syndromic Surveillance contains the necessary

specifications for data exchange from healthcare to public health for elements that are

core to Syndromic Surveillance practice. Note that this g uide does not contain

specifications for the collective data ele ments needed to support current practice of

Syndromic Surveillance across all public health jurisdictions. In particular, this guide is

based on Health Level Seven (HL7) version 2.5.1 messaging structures and vocabulary

content and dynamics as described by ISDS in their document titled “ Fi nal

Recommendation: The Core Processes and EHR Requirements of Public Health

Syndromic Surveillance ,” available at: http://syndromic.org/projects/meaningful

- use

.

This m essaging g uide is intended to meet the anticipated ne eds and requirements for

implementation guidance in clinical care entities that will be described in the future

stages of Health I nformation Technology ( HIT) Meaningful Use legislation. In addition

, this document addresses the needs of public health authorities for receiving core data

Syndromic Surveillance data in accordance with the HIT M eaningful Use legislation,

replacing the previous documentation regarding Case Reporting. This g uide does not

replace the need for documentation of the constraints of specific implementations.

2.2 

## AUDIENCE

This g uide is designed for healthcare and public health information systems, data

exchange, and data management staff and public health data analysts, who require

guidance on Syndromic Surveillance data elements and messaging specifications.

Users of this g uide must be familiar with the details of HL7 message construction and

processing. This g uide is NOT intended to be a tutorial on HL7. In addition , this

document is NOT a substitute for the on

- going business process documentation and

requirements development process lead by CDC and ISDS.



## 2.3 SCOPE

Th is g uide covers Syndromic Surveillance data exchange between clinical care

professionals and local and state P ublic H ealth (PH) authorities. The original use case

that was used for th is g uide is as follows:Page 14

PHIN Messaging Guide for Syndromic Surveillance 

### “[T]he transmission of electronic health data from healthcare providers (senders) and

reception by public health authorities (receive r) Health data transmitted are ca ptured in

a health information system during a patient‟s visit to a healthcare facility.

Senders of data include Hospitals, emergency departments, urgent care centers,

hospital corporations, corporate third party operators of information brokers, regional

data centers for hospitals, health information exchanges (HIE), and regional health

information organizations (RHIO).

Receivers are state and local public health authorities, or a designated third party. A

public health authority (PHA) is broadly defined as including agencies or authorities of

the United States, states, territories, political subdivisions of states or territories,

American Indian tribes, or an individual or entity acting under a grant of authority from

such agencies and responsible for pub lic health matters as part of an official mandate.” 4



### The Stage 1 Meaningful Use objectives assume the sending of data by hospitals and

eligible professionals a nd the capability of local or/and state PH authorities for receiving

this information. The current state business processes defined by the ISDS workgroup

are primarily based on point

- to

- point data exchange of Admit Discharge Transfer (ADT)

messages between healthcare and public health. Applicability of candidate HL7

messages in other data ex change scenarios has yet to be determined and may vary by

public health jurisdiction and data exchange partner.

The decision to use ADT message constructs instead of the ORU message construct

was reviewed and approved by ISDS, Public Health Data Standards Consortium

(PHDSC)

, and o ther CDC partners. Compared to ORU structure, the ADT structure

provides more flexibility for message exchange that captures data from emergency

department (ED) and urgent care (UC) patient visits

, by health information system s,

se n ding to a public health authority in the scope of the ISDS recommendation. Health

Information System s (HIS) transmit ADT messages as part of their normal operation

and configuration; they generally lack any function enabling transmission of observation

re lated data via ORU messages. HIS systems typically are recipients of such

4 International Society for D isease Surveillance, Final Recommendation: The Core Processes and

EHRPage 15

PHIN Messaging Guide for Syndromic Surveillance 

### messages. 5



## 2.4 COMPATIBILITY

This guide follows the HL7 Standard rules to ensure backward

- compatibility of

interfaces. As a result, properly implemented version 2.3.1 interfaces for Syndromic

Surveillance reporting should be able to accept and process version 2.5.1 messages

without producing errors. Section 4.2 describes the Minimum Data Elements. The

form a t of this section has been designed to accommodate differences of HL7 versions

2.3.1 and 2.5.1.

For instance, the Facility Identifier data element (Section 4.2.1, element #1) in HL7

version 2.5.1 is best presented as follows the Event Type segment, 7th field. However,

this field was not defined as part of version 2.3.1 for an Event Type segment.

Therefore, this guide provides, in Section 4.2, a separate description of the Facility

Identifier for versions 2.3.1 and 2.5.1. The flexibility of data element location defined in

this guide may be considered to be fully compatible, in both format and dat a, with both

2.3.1 and 2.5 .1 systems.



## 2.5 EXTENSIBILITY

This guide has been developed using the business approach that potentially allows

adding:

 O ptional data elements by state and local public health surveillance systems (see

Section 4.2.2)

 N ew and optional data elements in the future (see Section 4.2.3)

The current data element requirements and data sources, as presented by ISDS, are

best satisfied with the Admission and Discharge Transfer (ADT) messages described in

this guide. F uture versi on s of this message guide will be able accommodate needs of

our partners for adding new and additional data elements (i.e., laboratory orders and

5 Requirements of Public Health Syndromic Surveillance. Page 53, International Society for Disease Surveillance, Brighton, MA (January 2011); http://www.syndromic.org/project/meaningful

usePage 16

PHIN Messaging Guide for Syndromic Surveillance 

### results, additional diagnostic procedures and more detailed demographic information,

etc.)

. Additional require ments gathering will be undertaken to determine the best

strategy for new message types to meet new requirements. As the Meaningful Use

regulations mature and further recommendation s for new requirements emerge, it may

become necessary to include additional data sources, messaging events and structures

that are not currently defined in this release of this guide.



## 2.6 QUALIFICATIONS AND C AVEATS

The guidelines, information flow, and requir ed / recommended data elements for the

Meaningful Use regulations were under active development and revision by ISDS in

parallel with th e development of this guide

.

A number of compromises were made in the determination of the message definition for

this g uide. Although clinical information is of u t most importance for Syndromic

Surveillance

, the majority of outbound messages containing patient demographic and

history information that are currently generated in the healthcare system in the US for

every patient are administr ative messages, sent mostly by h ospital i nformation s ystems

. In order to produce a g uide widely implementable by most systems in the US, without

significant and substantial cost for new development, the most common ADT messages

were co nstrained and enhanced to support the surveillance needs.Page 17

PHIN Messaging Guide for Syndromic Surveillance 

## 3 HL7 MESSAGING FOR SYNDROMIC SURVEILLAN CE

HL7 (Health Level Seven) version 2 is the most widely used standard for computer

communication of patient information in the United States Healthc are industry today.

This guide is based on the HL7 version 2.5.1

- messaging standard, published by Health

Level Seven International, Inc., and approved as an ANSI standard on February 21,

2007, as an update to the version 2.5 standard released in 2003. This sec tion describes

the messages to be used for Syndromic Surveillance reporting, and includes a very brief

introduction to HL7 terms and concepts. The reader is referred to the full HL7 version

2.5.1 Standard for complete information and details of this backgr ound.



## 3.1 BASIC HL7 TERMS

Profile Attributes



### T A B L E 3

- 1 : B A S I C H L 7 T E R M S

TERM D EFINITION

Message A message is the entire unit of data transferred between systems in a single

transmission. It is a series of segments in a defined sequence, with a message type

and a trigger event.

Segment A segment is a logical grouping of data fields. Segments within a defined message

may be required or optional and may occur only once or may be allowed to repeat.

Each segment is named and is identified by a segment ID, a unique 3

- character

code.

Field A field is a string of characters. Each field has an element name . Each field is

identified by the segment it is in and its sequence within the segment. Usage and

cardinality requirements are defined in the Segment Definitions.

Component A component is on e of a logical grouping of items that comprise the contents of a

coded or composite field. Within a field having several components, not all

components are necessarily required to be populated.

Datatype A data type restricts the contents and format of th e data field. Data types are given

a 2

- or 3

- letter code. Some data types are coded or composite types with several

components. The applicable HL7 data type is listed in each field definition.Page 18

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 1 : B A S I C H L 7 T E R M S

TERM D EFINITION

Delimiters The delimiter values are defined in MSH

- 1 and MSH

- 2 and are used throughout the

message. The default delimiters are:

|

- Field Separator

^

- Component Separator

&

- Sub

- Component Separator

~

- Repetition Separator

\

- Escape Character



## 3.2 SUPPORTED DATA TYPES FOR SYNDROMIC SURVEILLAN CE

The HL7 Standards define a large number of datatypes for use in HL7 messaging. Not

all of these datatypes are required for the messages defined in this guide

. Those that

are used in this guide are defined in the table below and specified further below.

T A B L E 3

- 2 : D A

T A T Y P E S U T I L I Z E D I N S Y N D R O M I C S U R V E I L L A N C E

DATA TYPE DATA TYPE NAME

CE Coded Element

CWE Coded with Exceptions

CX Extended Composite ID with check Digit

DTM Date/Time

EI Entity Identifier

FN Family Name

HD Hierarchic Designator

ID Coded Value for HL7

- defined tables

IS Coded Value for user

- defined tables

MSG Message TypePage 19

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 2 : D A

T A T Y P E S U T I L I Z E D I N S Y N D R O M I C S U R V E I L L A N C E

DATA TYPE DATA TYPE NAME

NM Numeric

PL Person Location

PT Processing Type

SI Sequence Identifier

ST String Data

TX 6 Text Data

TS Timestamp

VID Version Identifier

XAD Extended Address

XPN Extended Person Name



## 3.3 ENCODING RULES

The following list details the encoding rules.

 Encode each segment in the order specified in the Message Structure.

 Begin each segment with the 3

- letter segment ID (e.g., PID ).

 End each segment with the carriage return terminator (hex 0D). Note that in the

examples in this guide , this character is illustrated as “<cr>”. This character is a

single ASCII character; the seg ment terminator is NOT the four

- character

sequence.

 Encode the data fields in the sequence given in the corresponding segment

definition tables.

 Encode each data field according to the data type format listed in this guide

.

6 In this message specification, the only allowed escape sequences are those allowed in HL7 Version 2.5.1, Chapter 2, and Section 2.7.4

- Special Characters. These are the escape sequences for the message delimiters (i.e., “|" = \ F \ , “^” = \ S \ , “~” = \ R \ , “&” = \ T \ , and “ \ ” = \ E \ ).Page 20

PHIN Messaging Guide for Syndromic Surveillance 

###  Components, subcomponents or repetitions that are not valued at the end of a

field need not be represented by component separators. Likewise, field separators

are not required for empty fields at the end of a segment.

For example, the data fields and segments below a re equivalent:

|^XXX&YYY&&^| is equal to |^XXX&YYY|

|ABC^DEF^^| is equal to |ABC^DEF|

and

MSH|^~ \ &||Facillity_NPI^0131191934^NPI|||201009221330||ADT^A04|1|P

|2.3.1||||||||<cr>

is equal to

MSH|^~ \ & ||Facility_NPI^0131191934^NPI|||201009221330||ADT^A04|1|P

|2.3.1<cr>

 

### If a data segment is not documented in this guide, the Sender should not send

the segment. However, if the segment is sent and the segment conforms to

HL7 message structure for the message, the Receiver should ignore the

undocumented segment. This “extraneous” data (segment) is best negotiated

prior to transmission between the Sender and Receiver.



## 3.4 USE CASE MODEL

The use case model is derived from the ISDS Final Recomendation, Section 4.1,

Transmission and Reception of Data.Page 21

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 4 : U S E C A S E : E L E C T R O N I C H E A L T H R E C O R D S Y N D R O M I C D A T A T O P U B L I C

H E A L T H

ITEM DETAIL

Description The Public Health Syndromic Surveillance Use Case focuses on the transmission

of electronic health data from healthcare providers (senders) and reception by Public Health authorities (receiver). Health data transmitted are captured in a health information system during a patient‟s visit to a healthcare facility.

Senders of data include, but are not limited to hospitals, emergency d epartments, urgent care centers, clinician networks, hospital corporations, corporate third party operators of information brokers, regional data centers for hospitals, health information exchanges (HIEs), and regional health information organizations (RHI Os).

Receivers are state and local public health authorities, or a designated third party. A public health authority (PHA) is broadly defined as including agencies or authorities of the United States, states, territories, political subdivisions of states o r territories, American Indian tribes, or an individual or entity acting under a grant of authority from such agencies and responsible for public health matters as part of an

official mandate.

The goal of the use case is to provide secure , reliable deliver y of Syndromic

Surveillance data to public health. If PHIN MS is used for transport, then use of the HL7 Acknowledgements may be unnecessary, although PHIN MS does not ensure that the payload conforms to HL7 formatting rules, it does provide safe and relia ble transport. If another transport mechanism is chosen, consideration should be given for acknowledgement of messages, whether single or batch, and/or possible acknowledgement of payload prior to processing or consumption.

Actors Patient

- A person with symptoms of a heal th problem that seeks treatment

Senders of Syndromic Surveillance data include, but are not limited to: hospitals, emergency departments, urgent care centers, clinician networks, hospital corporations, corporate third par ty operators of information brokers, regional data centers for hospitals, health information exchanges (HIEs), and regional health information organizations (RHIOs).

The Syndromic Surveillance receiver perspective is from the state or local jurisdiction point of view. Data transmission to a federal authority is not explicitly addressed. Data transmission between local and state jurisdictions is also out of

scope.

Assumptions The following assumptions are preconditions for the use of this profile:

Syndromic Surveillance data senders are responsible for the setup of their system with the code systems deemed appropriate to its jurisdiction.

Both sender and receiver of S yndromic data must agree to a facility registration process, allowing for transmission of data, prior to message transmission.

Business Rules The following Business Rule applies to the use of this profile:

Batch processing may optionally be used as described in section 3.8.



### The Send Syndromic Surveillance Data Use Case Model has two primary participating

actors, the Syndromic Data Sender and the Syndromic Data Receiver. The patient actorPage 22

PHIN Messaging Guide for Syndromic Surveillance 

### triggers the sending of the data initially from the or iginal provider. See figure 3.4 below

.

Figure 3.4

– Send Syndromic Surveillance Data Use Case Model



### 3.4.1 M ESSAGE 

### A CKNOWLEDGEMENTS



### HL7 messages that are sent from a healthcare setting to Public Health may be

acknowledged. The Acknowledgement type will be solely HL7 Original Mode

– no

E nhanced M ode Acknowledgement s are supported. This means that the receiver at the

p ublic h ealth d epartment must assume responsibility for the Syndromic Surveillance

message before it sends the Acknowledgement message, i.e.

, it must commit the

message to persistent storage and intend to process the message. The only conditions

that are evaluated for the positive acknowledgement or a possible error rejection are

the:

 Message Type contained in MSH

- 9 is one that c an be processed

 Processing ID contained in MSH

- 11 is appropriate for the communications and

can be processed

 Version ID contained in MSH

- 12 is either 2.3.1 or 2.5.1 and can be processed.

Other types of possible errors in the message, especially in content , must result in

downstream action after the acknowledgement message has been sent.

Note: Although the Original Model Acknowledgement is simplest and least costly to

implement, it does not generally support syntactic validation of messages. Messages

that a re accepted with an Acknowledgement message may thus still be missing fields

that are required. To do this more detailed level of Acknowledgement usually requires

En hanced Mode Accept Acknowledgement

.Page 23

PHIN Messaging Guide for Syndromic Surveillance 

### 3.4.2 D YNAMIC 

### I NTERACTION 

### M ODELS

Figure 3.4.2

. 1 Activity Diagram for Send Syndromic Surveillance Data Use Case

- Acknowledgement Required

Figure 3.4.2

. 2 Activity Diagram for Send Syndromic Surveillance Data Use Case

– Without Acknowledgement

Figure 3.4.2

. 3 Activity Diagram for Send Syndromic Surveillance Data Use Case

– BatchPage 24

PHIN Messaging Guide for Syndromic Surveillance 

### 3.4.3 I NTERACTIONS



### T A B L E 3

- 4 A : I N T E R A C T I O N S

- I N D I V I D U A L T R A N S A C T I O N W I T H A C K N O W L E D G E M E N T S

E VENT 

### M ESSAGE 

### T YPE 

### R ECEIVER



### A CTION 

### S ENDER 

### D ATA 

### V ALUES

Patient visits provider/facility ADT^A01^ADT_A01 Accept, Reject,

Error SS Data

Sender MSH

- 9 = “ADT^A01^ADT_A01”

Patient is admitted to provider facility ADT^A01^ADT_A01 Accept, Reject,

Error SS Data

Sender MSH

- 9 = “ADT^A01^ADT_A01”

Provider ends patient‟s visit ADT^A03^ADT_A03 Accept, Reject,

Error SS Data

Sender MSH

- 9 = “ADT^A03^ADT_A03”

Patient is discharged from facility ADT^A03^ADT_A03 Accept, Reject,

Error SS Data

Sender MSH

- 9 = “ADT^A03^ADT_A03”

Patient registers at provider facility ADT^A04^ADT_A01 Accept, Reject,

Error SS Data

Sender MSH

- 9 = “ADT^A04^ADT_A01”

Patient record is updated ADT^A08^ADT_A01 Accept, Reject,

Error SS Data

Sender MSH

- 9 = “ADT^A08^ADT_A01”

Accept message ACK message related to type of message sent None SS Data

Receiver MSA

- 1 = „AA‟

Reject message ACK message related to type of message sent None SS Data

Receiver MSA

- 1 = „AR‟

Error Message ACK message related to type of message sent None SS Data

Receiver MSA

- 1 = „AE‟



### T A B L E 3

- 4 B : I N T E R A C T I O N S

- I N D I V I D U A L T R A N S A C T I O N W I T H O U T

A C K N O W L E D G E M E N T S / B A T C H

E VENT 

### M ESSAGE 

### T YPE 

### R ECEIVER



### A CTION 

### S ENDER 

### D ATA 

### V ALUES

Patient visits provider/facility ADT^A01^ADT_A01 None SS Data

Sender MSH

- 9 = “ADT^A01^ADT_A01”

Patient is admitted to provider facility ADT^A01^ADT_A01 None SS Data

Sender MSH

- 9 = “ADT^A01^ADT_A01”Page 25

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 4 B : I N T E R A C T I O N S

- I N D I V I D U A L T R A N S A C T I O N W I T H O U T

A C K N O W L E D G E M E N T S / B A T C H

E VENT 

### M ESSAGE 

### T YPE 

### R ECEIVER



### A CTION 

### S ENDER 

### D ATA 

### V ALUES

Provider ends patient‟s visit ADT^A03^ADT_A03 None SS Data

Sender MSH

- 9 = “ADT^A03^ADT_A03”

Patient is discharged from facility ADT^A03^ADT_A03 None SS Data

Sender MSH

- 9 = “ADT^A03^ADT_A03”

Patient registers at provider facility ADT^A04^ADT_A01 None SS Data

Sender MSH

- 9 = “ADT^A04^ADT_A01”

Patient record is updated ADT^A08^ADT_A01 None SS Data

Sender MSH

- 9 = “ADT^A08^ADT_A01”



## 3.5 STATIC MODEL

- MESSAGE STRUCTURE

3.5.1 HL7 M ESSAGE 

### S TRUCTURE 

### A TTRIBUTES



### The structure of the supported messages in this guide are described in tabular format

( refer to the following section). The columns of those tables are used as described in

the table below.

T A B L E 3

- 5

. M E S S A G E S T R U C T U R E A T T R I B U T E S

A BBREVIATION 

### D EFINITION

Segment Three

- character code for the segment and the abstract syntax (e.g ., the square and

curly braces) If a segment is not documented in this guide, it should not be sent.

 [ XXX ] Optional

 { XXX } Repeating

 XXX Required

 [{ XXX }] Optional and Repeating

Name Name of the segment

Description Explan ation of the use of the segment

Usage Use of the segment for Syndromic Surveillance

Indicates if the segment is required, option al, or conditional in a messagePage 26

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 5

. M E S S A G E S T R U C T U R E A T T R I B U T E S

A BBREVIATION 

### D EFINITION

Legal values are:

 R

– Required, Must always be populated

 RE

– Required, but may be empty (segment is not sent). If the Sender has
data, it must be sent. T he Receiver must be capable of processing data if sent, and must not raise an error or warning if the data is not sent.

 O

– Optional There is no specified conformance rules for either Sender or Receiver for this segment in this guide. As an implemented int erface must follow known rules for populating segments, a specific interface for a particular Sender or Receiver must constrain this usage to either R, RE, C, CE, or X. This has been deliberately left unconstrained in this guide to support differing and so metimes mutually exclusive statutory requirements in different jurisdictions; this must be determined locally.

Cardinality Minimum and maximum number of times the segment may appear

 [0..1] Segment may be omitted and can have, at most, one occurrence.

 [1 ..1] Segment must have exactly one occurrence.

 [0..*] Segment may be omitted or repeat an unlimited number of times.

 [1..*] Segment must appear at least once, and may repeat unlimited number

of times.



### 3.5.2 C ONSTRAINED 

### M ESSAGE 

### T YPES



### The following HL7 ADT Messages have been identified for Syndromic Surveillance

reporting:

 ADT^A01 Admit / Visit Notification

 ACK^A01 General Acknowledgement

 ADT^A03 Discharge / End Visit

 ACK^A03 General Acknowledgement

 ADT^A04 Register a Patient

 ACK^A04 General Acknowledgement

 ADT^A08 Update Patient Information

 ACK^A08 General Acknowledgement

Message types that are NOT documented in this guide are considered NOT

SUPPORTED. For more information on receiver usage of not supported, please seePage 27

PHIN Messaging Guide for Syndromic Surveillance 

### tabl e 3

- 6

.

The HL7 message formats sent to public health agencies will be constrained versions of

the 2.5.1 abstract message (with backward compatibility to 2.3.1) formats. Only the

segments necessary for carrying the S yndromic data, and certain structural message
segments, are included. Because the message structure for the message types is

similar, one table (Table 3

- 5 A) was used to define the message structure for the ADT

A01, A04, and A08 messages. Another table (Table 3

- 5 B) was used for the A03

message structure , as per the HL7 Standard. All of the General Acknowledgement

(ACK) messages have the same structur e

. All of the General Acknowledgement (ACK)

messages were placed in the final table (Table 3

- 5 C)

.

3.5.3 C ONSTRAINED 

### M ESSAGE 

### S TRUCTURE 

### ADT_A01



### The abbreviated terms and their definitions used to describe the Message Profile are

detailed in the following tables.

T A B L E 3

- 5 A : S I M P L E M E S S A G E S T R U C T U R E : A 0 1

, A 0 4

, A N D A 0 8

S EG 

### N AME 

### D ESCRIPTION 

### U SAGE 

### C ARDINALITY

MSH Message

Header Information explaining how to parse and process

the message Information includes identification of message delimiters, sender, receiver, message type, timestamp, etc. R [1..1]

EVN Event Type Trigger event information for receiving application R [1..1]

PID Patient

Identification Patient identifying and demographic information R [1..1]

PV1 Patient Visit Information related to this visit at this facility including the nature of the visit, critical timing information and a unique visit identifier. R [1..1]

[PV2] Patient Visit

Additional

Information Admit Reason information. RE [0..1]

{OBX} Observation /

Result Information regarding the age, temperature, and

other information R [1..*]

[{DG1}] Diagnosis Admitting Diagnosis and, optionally, Working and Final Diagnosis information RE [0..*]Page 28

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 5 A : S I M P L E M E S S A G E S T R U C T U R E : A 0 1

, A 0 4

, A N D A 0 8

S EG 

### N AME 

### D ESCRIPTION 

### U SAGE 

### C ARDINALITY

[{PR1}] Procedures Information relative to various types of procedures performed O [0..*]

[{IN1}] Insurance Information about insurance policy coverage information O [0..*]



### 3.5.4 C ONSTRAINED 

### M ESSAGE 

### S TRUCTURE 

### ADT_A03

T A B L E 3

- 5 B : S I M P L E M E S S A G E S T R U C T U R E : A 0 3

S EG 

### N AME 

### D ESCRIPTION 

### U SAGE 

### C ARDINALITY

MSH Message

Header Information explaining how to parse and process

the message

This information includes identification of message delimiters, sender, receiver, message type, timestamp, etc. R [1..1]

EVN Event Type Trigger event information for receiving application R [1..1]

PID Patient

Identification Patient identification and demographic information R [1..1]

PV1 Patient Visit Information related to this visit at this facility including the nature of the visit, critical timing information and a unique visit identifier. R [1..1]

[PV2] Patient Visit

Additional

Information Admit Reason information. RE [0..1]

[{DG1}] Diagnosis Admitting Diagnosis and, optionally, Working and Final Diagnosis information RE [0..*]

[{PR1}] Procedures Information relative to various types of procedures performed O [0..*]

{OBX} Observation /

Result Information regarding the age, temp erature, and

other information R [1..*]

[{IN1}] Insurance Information about insurance policy coverage

information O [0..*]Page 29

PHIN Messaging Guide for Syndromic Surveillance 

### 3.5.5 C ONSTRAINED 

### M ESSAGE 

### S TRUCTURE 

### ACK



### Note that the same Message Structure is used for ACK^A01, ACK^A03, ACK^A04, and

ACK^A08

.

T A B L E 3

- 5 C

. S I M P L E M E S S A G E S T R U C T U R E : A C K

S EG 

### N AME 

### D ESCRIPTION 

### U SAGE 

### C ARDINALITY

MSH Message

Header Information explaining how to parse and process

the message. This includes identification of message delimiters, sender, receiver, message type, timestamp, etc. R [1..1]

MSA Message

Acknowledge

ment Acknowledgement information identifying the ability

of a receiver to accept a message transmitted R [1..1]Page 30

PHIN Messaging Guide for Syndromic Surveillance 

## 3.6 STATIC MODEL

– MESSAGE SEGMENTS

3.6.1 S EGMENT 

### P ROFILE 

### A TTRIBUTES



### Fields or components that are NOT documented in this guide are considered NOT

SUPPORTED. Inclusion of any field or component that is not supported should not

result in failure of the entire message by the receiver, as per recommended receiver

behaviors as defined in HL7.

The abbreviated terms and segment definiti ons used in the constrained message

formats are detailed in the following table.

T A B L E 3

- 6 : S E G M E N T P R O F I L E A T T R I B U T E S

A BBREVIATION 

### D EFINITION

Field Name Descriptive name of the data element

Sequence (Seq) Sequence of the elements as they are numbered in the HL7 segment

Datatype (DT) Data type used for HL7 element

Length (Len) Length of an element is calculated using the following rules:

Field length = (Sum of all supported component lengths) + (component

number of the l ast

- supported component)

– 1.

C omponent length = (Sum of all supported sub

- component lengths) + (sub

- component number of the last

- supported component)

– 1.Page 31

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 : S E G M E N T P R O F I L E A T T R I B U T E S

A BBREVIATION 

### D EFINITION

Sender Usage

Receiver Usage Indicator of whether a data element is required, optional, or conditional in a message, set separately for Senders and Receivers. Legal values

are:

 R

- Required. Must always be populated by the Sender, and if not present he Receiver may reject the message.

 RE 7

- Required, but may be empty (no value). If the Sender has
data, the data must be sent. The Receiver must be capable of processing data if sent, and must not raise an error or warning if the data is not sent.

 O

– Optional

- There are no specified conformance rules for either

Sender or Receiver for this field in this guide . As an implemented interface must follow known rules for populated fields and components, a specific interface for a particular Sender or Receiver must constrain this usage to either R, RE, C, CE, or X. This value has been deliberately

left unconstrained in this guide to support differing and sometimes mutually exclusive statutory requirements in different jurisdictions; this must be determined locally.

 C

– Conditional

- When conditionality predicate evaluates to

„ T rue‟, considered the same as „R‟. When condition

evaluates to „ F alse‟, Senders must not populate the field, and Receivers may raise an error if the field is present but must not raise an error if the field is not present.

 Syndromic Surveillance

- When conditionality predicate

evaluates to „ T rue‟, behaves the same as „RE‟. When conditionality predicate evaluates to „ F alse‟, the Sender should not populate the field, and the Receiver may raise an application error if the field is present.

 X

- Not supported

- Senders must not populate. Receivers may ignore the element if it is sent, or may raise an error if field is present.

Note: A required field in an optional segment does not mean the segment must be present in the message. It means that if the segment is present, the required fields within that segment m ust be populated. The same applies to required components of optional fields. If the field is being populated, then the required

7 The element may be missing from the message, but must be sent by sending application if there is relevant

data. A conforming sending application must be capable of providing all „RE‟ elements. If conforming sending applica tion knows required values for the element, it mu s t send that element. If conforming sending application does not know the required values, then that element will be omitted.Page 32

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 : S E G M E N T P R O F I L E A T T R I B U T E S

A BBREVIATION 

### D EFINITION

components must be populated. The same applies to required

sub

- components of optional components. If a component is being popul ated, then the required sub

- components of that component must be populated.

Cardinality Minimum and maximum number of times the field may appear.

 [0..0] Field never present

 [0..1] Field may be omitted and can have, at most, one

occurrence.

 [1..1] Field m ust have exactly one occurrence

 [0..n] Field may be omitted or may repeat up to n times

 [1..n] Field must appear at least once, and may repeat up to n
time.

 [0..*] Field may be omitted or repeat an unlimited number of

times.

 [1..*] Field must appear at lea st once, and may repeat unlimited

number of times.

 [m..n] Field must appear at least m and at most n times.

Values / Value Set Link to value set or literal value of data expected to be populated in the

field. Numbers in this field denote the related vocab ulary in that HL7

Table. Contains the name and/ or the PHIN Value Set (accessible through PHIN VADS) when relevant as well as notes, condition rules (2.5.1 vs. 2.3.1) and recommendations.

 Fields shaded in yellow denote unsupported fields. The usage is also marked „X‟.

 C o mponents and subcomponents of a single field are noted a s a dotted decimal number.Page 33

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.2 M ESSAGE 

### H EADER 

### (MSH) S EGMENT



### The MSH Segment is used to d efine the intent, source, destination, and some specifics of the syntax of the message. This

segment includes identification of message delimiters, sender, receiver, message type, timestamp, etc.

T A B L E 3

- 6 A : M E S S A G E H E A D E R S E G M E N T ( M S H )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Field Separator 1 ST 1 R R [1..1] Default Value “|” (ASCII 124).

Encoding Characters 2 ST 4 R R [1..1] Default Values “^~ \ &” (ASCII 94,126,92, and 38).

Sending Application 3 HD 227 O O [0..1]

Sending Facility 4 HD 227 R R [1..1] Field that uniquely identifies the facility associated with the app lication that sends the message

If Acknowledgement s are in use, this facility will receive any related Acknowledgement message.

Namespace ID 4.1 IS 20 RE RE [0..1] 0362

Universal ID 4.2 ST 199 R R [1..1]

Universal ID Type 4.3 ID 6 R R [1..1] 0301

Receiving Application 5 HD 227 O O [0..1] 0361Page 34

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 A : M E S S A G E H E A D E R S E G M E N T ( M S H )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Receiving Facility 6 HD 227 O O [0..1] 0362

Date/Time Of Message 7 TS 26 R R [1..1] Note: Date/Time the sending system created the message in the following format: YYYYMMDDHHMMSS[.S[S[S[S]]]]] [+/

- ZZZZ]

The minimum acceptable precision is to the nearest
minute; seconds are desirable.

If Coordinated Universal Time (UTC) offset is not sent, it is assumed to be offset of the receiver.

Security 8 ST 40 X X [0..1]

Message Type 9 MSG 15 R R [1..1] Note: All messages will be Admit

- Discharge

Transfer ( ADT) message types. The triggering

event is a real

- world circumstance causing the message to be sent.

Supported trigger events are A01 (Inpatient Admission), A04 (Emergency Department Registration) and A08 (Update).

Message Code 9.1 ID 3 R R [1..1] Literal Value “ADT” or “ACK”Page 35

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 A : M E S S A G E H E A D E R S E G M E N T ( M S H )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Trigger Event 9.2 ID 3 R R [1..1] One of the following literal values: “A01”, “A03”, “A04”, or “A08”.

Message Structure 9.3 ID 7 R R [1..1] One of the following literal values: “ADT_A01” or “ADT_A03”, or “ACK”

Message Control ID 10 ST 199 R R [1..1] Note: This field is a number or other identifier that uniquely identifies the message.

Processing ID 11 PT 3 R R [1..1] Note: Indicates how to process the message as defined in HL7 processing rules

Literal values: “P” for Production, “D” for Debug or

“T” for Training.

Version ID 12 VID 5 R R [1..1] Note: HL7 version number used to interpret format and content of the message.

Literal value: “2.3.1” or “2.5.1”

Sequence Number 13 NM 15 X X [0..1]

Continuation Pointer 14 ST 180 X X [0..1]

Accept Acknowledgement Type 15 ID 2 X X [0..1] 0155Page 36

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 A : M E S S A G E H E A D E R S E G M E N T ( M S H )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Application Acknowledgement Type 16 ID 2 X X [0..1] 0155

Country Code 17 ID 3 X X [0..1] 0399

Character Set 18 ID 16 X X [0..*] 0211

Principal Language Of Message 19 CE 478 X X [0..1]

Alternate Character Set Handling

Scheme 20 ID 20 X X [0..1] 0356

Message Profile Identifier 21 EI 427 O O [0..*]Page 37

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.3 E VENT 

### T YPE 

### (EVN) S EGMENT



### The EVN segment is used to communicate trigger event information to receiving applications.

T A B L E 3

- 6 B : E V E N T T Y P E S E G M E N T ( E V N )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Event Type Code 1 ID 3 X X [0..0] 0003

Recorded Date/Time 2 TS 26 R R [1..1] Note: Most systems default to the system

Date/Time when the transaction was entered. YYYYMMDDHHMM[SS[.S[S[S[S]]]]] [+/

- ZZZZ]

The minimum acceptable precision is to the nearest
minute; seconds and microseconds are desirable;

the Coordinated Universal Time (UTC) offset is not required.

Date/Time Planned Event 3 TS 26 X X [0..1]

Event Reason Code 4 IS 3 X X [0..1] 0062

Operator ID 5 XCN 309 X X [0..*] 0188

Event Occurred 6 TS 26 X X [0..1]Page 38

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 B : E V E N T T Y P E S E G M E N T ( E V N )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Event Facility 7 HD 241 R R [0..1] Required if using HL7 version 2.5.1.

For HL 7 version 2.3.1, use an OBX segment with a HD data type.

If populated, this element would be the facility where the original event occurred. In this case, the treating facility should be populated here.

Namespace ID 7.1 IS 20 RE RE [0..1] Name of originating facility

Universal ID 7.2 ST 199 R R [1..1] National Provider Identifier. (10

- digit identifier )

Universal ID Type 7.3 ID 6 R R [1..1] Expecting Value “NPI”.Page 39

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.4 P ATIENT 

### I DENTIFICATION 

### (PID) S EGMENT



### The PID Segment is used as the primary means of communicating patient identification information. This segment contains

pertinent patient identifying and demographic information.

T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Set ID

- PID 1 SI 4 O RE [0..1] Note: This Set ID n umbers the repetitions of the segments. Only one patient per message is supported.

Literal value: “1”.

Patient ID 2 CX 20 X X [0..0]

Patient Identifier List 3 CX 478 R R [1..*] PID.3 is a repeating field that can accommodate multiple patient identifiers

.

Note: Patient‟s unique identifier(s) from the facility

that is submitting this report to public health officials

Different jurisdict ions use different identifiers and may often use a combination of identifiers to produce a unique patient identifier. Patient identifiers should be strong enough to remain a unique identifier across different data provider
models, such as a networked data provider or StatePage 40

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

HIE.

ID Number 3.1 ST 15 R R [1..1] Note: A Unique Patient Identifier is required (such as Patient Account number or MPI Number). In addition, it is strongly recommended to submit the patient medical record number to facilitate identification of the patient in the event of a required

follow

- up investigation. Without it, the work required

to follow up on the data provider is greatly

increased.

Check Digit 3.2 ST 1 X X [0..1]

Check Digit Scheme 3.3 ID 3 X X [0..1] 0061

Assigning Authority 3.4 HD 227 O RE [0..1] 0363

Identifier Type Code 3.5 ID 5 R R [1..1] Identifier Type ( Syndromic Surveillance )

Note: Use the Identifier Type Code that corresponds to the type of ID Number specified in

PID

- 3.1. For Medical Record Number, use literal

value “MR”.

Assigning Facility 3.6 HD 227 O RE [0..1]Page 41

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Effective Date 3.7 DT 8 X X [0..1]

Expiration Date 3.8 DT 8 X X [0..1]

Assigning Jurisdiction 3.9 CWE 705 X X [0..1]

Assigning Facility 3.10 CWE 705 X X [0..1]

Alternate Patient ID

- PID 4 CX 20 X X [0..0]

Patient Name 5 XPN 294 R R [1..*] Note: Syndromic Surveillance does not require the patient name. The Patient ID number will be used to identify uniquely the patient. HL7 does require the patient name field for a PID segment. The patient name field must still be populated even when reporting de

- identified data.

The first field name contains the primary or legal name of the patient. Therefore, the name type code (PID.5.7) should be “L “( Legal), when populated.

When the name of the patient is known, but not desired to be sent, HL7 recommends the following: |~^^^^^^S|. The "S" for the name type code (PID.5.7) in the second name field indicates that it isPage 42

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

a pseudonym.

When the name of the patient is not known, HL7 recommends the following: |~^^^^^^U|. The "U" for the name type code (PID.5.7) in the second name field indicates that it is unspecified.

Family Name 5.1 FN 194 O RE [0..1]

Given Name 5.2 ST 30 O RE [0..1]

Second Given Name or Initials 5.3 ST 30 O RE [0..1]

Suffix 5.4 ST 20 O RE [0..1]

Prefix 5.5 ST 20 O RE [0..1]

Degree 5.6 IS 6 X X [0..0] 0360

Name Type Code 5.7 ID 1 R R [0..1] 0200

Expected Values:

“L” (Legal)

– used for patient legal name.

“S” (Pseudonym)

– used for de

- identification ofPage 43

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

patient name.

“U” (Unspecified)

– used when patient name is not

known.

Name Representation Code 5.8 ID 1 X X [0..1]

Name Context 5.9 CE 483 X X [0..1]

Name Validity Range 5.10 DR 53 X X [0..0]

Name Assembly Order 5.11 ID 1 X X [0..1] 0444

Effective Date 5.12 TS 26 X X [0..1]

Expiration Date 5.13 TS 26 X X [0..1]

Professional Suffix 5.14 ST 199 X X [0..1]

Mother‟s Maiden Name 6 XPN 294 X X [0..*]

Date/Time of Birth 7 TS 26 O O [0..1]

Administrative Sex 8 IS 1 RE RE [0..1] Gender ( Syndromic Surveillance )Page 44

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Patient Alias 9 XPN 294 X X [0..0]

Race 10 CE 478 RE RE [0..*] Race Category (CDC)

Note: Patient could have more than one race

defined.

Identifier 10.1 ST 20 RE RE [0..1] Note: Standardized code for patient race category

Text 10.2 ST 199 O RE [0..1] Note: Standardized description associated with

code in PID

- 10.1

Name of Coding System 10.3 ID 20 CE C [0..1] Condition R ule: Required if an identifier is provided in component 1.

Alternate Identifier 10.4 ST 20 X X [0..1]

Alternate Text 10.5 ST 199 X X [0..1]

Name of Alternate Coding System 10.6 ID 20 X X [0..1]

Patient Address 11 XAD 513 RE RE [0..1] Note: Expecting only the patient primary (current)

address informat ion in the supported componentsPage 45

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Street Address 11.1 SAD 184 O O [0..1]

Other Designation 11.2 ST 120 O O [0..1]

City 11.3 ST 50 O O [0..1]

State or Province 11.4 ST 50 RE RE [0..1] FIPS 5

- 2

ZIP or Postal Code 11.5 ST 12 RE RE [0..1] USPS

Country 11.6 ID 3 RE RE [0..1] ISO 3166

- 1

Address Type 11.7 ID 3 O O [0..1] 0190

Expecting value: „C‟

Other Geographic Designation 11.8 ST 50 O O [0..1]

County/Parish Code 11.9 IS 20 O O [0..1]

Census Tract 11.10 IS 20 X X [0..1]

Address Representation Code 11.11 ID 1 X X [0..1]Page 46

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Address Validity Range 11.12 DR 53 X X [0..0]

Effective Date 11.13 TS 26 X X [0..1]

Expiration Date 11.14 TS 26 X X [0..1]

County Code 12 IS 4 X X [0..0] 0289

Phone Number

- Home 13 XTN 250 X X [0..*]

Phone Number

- Business 14 XTN 250 X X [0..*]

Primary Language 15 CE 478 X X [0..1] 0296

Marital Status 16 CE 478 X X [0..1] 0002

Religion 17 CE 478 X X [0..1] 0006

Patient Account Number 18 CX 250 O O [0..1]

SSN Number

- Patient 19 ST 16 X X [0..0]Page 47

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Driver's License Number

- Patient 20 DLN 64 X X [0..0]

Mother's Identifier 21 CX 250 X X [0..*]

Ethnic Group 22 CE 478 RE RE [0..*] Ethnicity Group (CDC)

Identifier 22.1 ST 20 RE RE [1..1] Note: Standardized code for patient ethnic group.

Text 22.2 ST 199 O O [0..1] Note: Standardized description associated with

code in PID

- 22.1.

Name of Coding System 22.3 ID 20 CE C [0..1] Condition R ule: Required if an identifier is provided in component 1.

Alternate Identifier 22.4 ST 20 X X [0..1]

Alternate Text 22.5 ST 199 X X [0..1]

Name of Alternate Coding System 22.6 ID 20 X X [0..1]

Birth Place 23 ST 250 X X [0..1]Page 48

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Multiple Birth Indicator 24 ID 1 X X [0..1] 0136

Birth Order 25 NM 2 X X [0..1]

Citizenship 26 CE 478 X X [0..*] 0171

Veterans Military Status 27 CE 478 X X [0..1] 0172

Nationality 28 CE 478 X X [0..0] 0212

Patient Death Date and Time 29 TS 26 CE CE [0..1] If the patient expired, this field should contain the patient death date and time. (PV1

- 36 denotes patient expiration)

The minimum acceptable precision is to the nearest
minute; seconds are desirable. If Coordinated

Universal Time (UTC) offset is not sent, it is

assumed to be offset of the receiver.

Patient Death Indicator 30 ID 1 CE CE [0..1] 0136

If the patient expired, this field should contain the patient death indi cator. (PV1

- 36 denotes patient disposition )Page 49

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 C

. P A

T I E N T I D E N T I F I C A

T I O N S E G M E N T ( P I D )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Identity Unknown Indicator 31 ID 1 X X [0..1] 0136

Identity Reliability Code 32 IS 20 X X [0..*] 0445

Last Update Date/Time 33 TS 26 O O [0..1]

Last Update Facility 34 HD 241 O O [0..1]

Species Code 35 CE 478 X X [0..1] 0446

Breed Code 36 CE 478 X X [0..1] 0447

Strain 37 ST 80 X X [0..1]

Production Class Code 38 CE 478 X X [0..1] 0429

Tribal Citizenship 39 CWE 697 X X [0..*] 0171Page 50

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.5 P ATIENT 

### V ISIT 

### (PV1) S EGMENT



### The PV1 segment is used by Registration/Patient Administration applications to communicate information on a visit

- specific

basis.

T A B L E 3

- 6 D : P A T I E N T V I S I T S E G M E N T ( P V 1 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Set ID

- PV1 1 SI 4 RE RE [0..1] Note: Set ID numbers t he repetitions of the segments Only one patient per message is supported.

Literal value: “1”

Patient Class 2 IS 1 R RE [1..1] Patient Class ( Syndromic Surveillance )

Assigned Patient Location 3 PL 1220 O O [0..1]

Admission Type 4 IS 2 O O [0..1] 0007

Pre

- admit Number 5 CX 250 X X [0..1]

Prior Patient Location 6 PL 1220 X X [0..1]

Attending Doctor 7 XCN 309 X X [0..*] 0010Page 51

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 D : P A

T I E N T V I S I T S E G M E N T ( P V 1 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Referring Doctor 8 XCN 309 X X [0..*] 0010

Consulting Doctor 9 XCN 309 X X [0..0] 0010

Hospital Service 10 IS 3 O O [0..1] 0069

Temporary Location 11 PL 1220 X X [0..1]

Preadmit Test Indicator 12 IS 2 X X [0..1] 0087

Re

- admission Indicator 13 IS 2 X X [0..1] 0092

Admit Source 14 IS 6 O O [0..1] 0023

Ambulatory Status 15 IS 2 O O [0..*] 0009

VIP Indicator 16 IS 2 X X [0..1] 0099

Admitting Doctor 17 XCN 309 X X [0..*] 0010

Patient Type 18 IS 2 X X [0..1] 0018Page 52

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 D : P A

T I E N T V I S I T S E G M E N T ( P V 1 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Visit Number 19 CX 478 R R [1..1]

ID Number 19.1 ST 15 R R [1..1] Note: Unique identifier for a patient visit

Check Digit 19.2 ST 1 X X [0..1]

Check Digit Scheme 19.3 ID 3 X X [0..1] 0061

Assigning Authority 19.4 HD 227 O RE [0..1] 0363

Identifier Type Code 19.5 ID 5 R R [0..1] Identifier Type

Note: Use the Identifier Type Code that corresponds to the type of ID Number specified in

PV1

- 19.1.

Assigning Facility 19.6 HD 227 O RE [0..1]

Effective Date 19.7 DT 8 X X [0..1]

Expiration Date 19.8 DT 8 X X [0..1]

Assigning Jurisdiction 19.9 CWE 705 X X [0..1]Page 53

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 D : P A

T I E N T V I S I T S E G M E N T ( P V 1 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Assigning Facility 19.10 CWE 705 X X [0..1]

Financial Class 20 FC 50 X X [0..*] 0064

Charge Price Indicator 21 IS 2 X X [0..1] 0032

Courtesy Code 22 IS 2 X X [0..1] 0045

Credit Rating 23 IS 2 X X [0..1] 0046

Contract Code 24 IS 2 X X [0..*] 0044

Contract Effective Date 25 DT 8 X X [0..*]

Contract Amount 26 NM 12 X X [0..*]

Contract Period 27 NM 3 X X [0..*]

Interest Code 28 IS 2 X X [0..1] 0073

Transfer to Bad Debt Code 29 IS 4 X X [0..1] 0110Page 54

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 D : P A

T I E N T V I S I T S E G M E N T ( P V 1 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Transfer to Bad Debt Date 30 DT 8 X X [0..1]

Bad Debt Agency Code 31 IS 10 X X [0..1] 0021

Bad Debt Transfer Amount 32 NM 12 X X [0..1]

Bad Debt Recovery Amount 33 NM 12 X X [0..1]

Delete Account Indicator 34 IS 1 X X [0..1] 0111

Delete Account Date 35 DT 8 X X [0..1]

Discharge Disposition 36 IS 3 RE RE [0..1] NUBC

– Patient Status (UB04

- Field 17 Codes)

Discharged to Location 37 DLD 47 X X [0..1] 0113

Diet Type 38 CE 478 X X [0..1] 0114

Servicing Facility 39 IS 2 X X [0..1] 0115

Bed Status 40 IS 1 X X [0..0] 0116Page 55

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 D : P A

T I E N T V I S I T S E G M E N T ( P V 1 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Account Status 41 IS 2 X X [0..1] 0117

Pending Location 42 PL 1220 X X [0..1]

Prior Temporary Location 43 PL 1220 X X [0..1]

Admit Date/Time 44 TS 26 R R [1..1] Note: Date and time of the patient presentation.

YYYYMMDDHHMM[SS[.S[S[S[S]]]]] [+/

- ZZZZ]

The minimum acceptable precision is to the nearest
minute; seconds are desirable. If Coordinated

Universal Time (UTC) offset is not sent, it is

assumed to be offset of the receiver.

Discharge Date/Time 45 TS 26 RE RE [0..*] Note: Date and time of the patient discharge.

YYYYMMDDHHMM[SS[.S[S[S[S]]]]] [+/

- ZZZZ]

The minimum acceptable precision is to the nearest
minute; seconds are desirable. If Coordinated

Universal Time (UTC) offset is not sent, it is

assumed to be offset of the receiver.

Current Patient Balance 46 NM 12 X X [0..1]Page 56

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 D : P A

T I E N T V I S I T S E G M E N T ( P V 1 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Total Charges 47 NM 12 X X [0..1]

Total Adjustments 48 NM 12 X X [0..1]

Total Payments 49 NM 12 X X [0..1]

Alternate Visit ID 50 CX 250 X X [0..1] 0203

Visit Indicator 51 IS 1 X X [0..1] 0326

Other Healthcare Provider 52 XCN 309 X X [0..0] 0010Page 57

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.6 P ATIENT 

### V ISIT



### – A DDITIONAL 

### I NFORMATION 

### (PV2) S EGMENT



### The PV2 segment is a continuation of visit

- specific information and is the segment where the Admit Reason is passed.

T A B L E 3

- 6 E : P A

T I E N T V I S I T

– A D D I T I O N A L I N F O R M A T I O N S E G M E N T ( P V 2 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Prior Pending Location 1 PL 1220 X X [0..1]

Accommodation Code 2 CE 478 X X [0..1] 0129

Admit Reason 3 CE 478 RE RE [0..1] ICD

- 9 Clinical Modification diagnosis code (including E

- codes and V

- codes)

Or

ICD

- 10 Clinical Modification diagnosis code

Or

SNOMED Disorder/ Disease domain

Identifier 3.1 ST 20 RE RE [0..1]

Text 3.2 ST 199 RE RE [0..1] It is strongly recommended that text be sent to accompany any identifier.Page 58

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 E : P A

T I E N T V I S I T

– A D D I T I O N A L I N F O R M A T I O N S E G M E N T ( P V 2 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Name of Coding System 3.3 ID 20 C C [0..1] Condition R ule: Required if an identifier is provided in component 1.

Alternate Identifier 3.4 ST 20 X X [0..1]

Alternate Text 3.5 ST 199 X X [0..1]

Name of Alternate Coding System 3.6 ID 20 X X [0..1]

Transfer Reason 4 CE 478 X X [0..1]

Patient Valuables 5 ST 25 X X [0..*]

Patient Valuables Location 6 ST 25 X X [0..1]

Visit User Code 7 IS 2 X X [0..*] 0130

Expected Admit Date/Time 8 TS 26 X X [0..1]

Expected Discharge Date/Time 9 TS 26 X X [0..1]

Estimated Length of Inpatient Stay 10 NM 3 X X [0..1]Page 59

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 E : P A

T I E N T V I S I T

– A D D I T I O N A L I N F O R M A T I O N S E G M E N T ( P V 2 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Actual Length of Inpatient Stay 11 NM 3 X X [0..1]

Visit Description 12 ST 50 X X [0..1]

Referral Source Code 13 XCN 309 X X [0..*]

Previous Service Date 14 DT 8 X X [0..1]

Employment Illness Related

Indicator 15 ID 1 X X [0..1] 0136

Purge Status Code 16 IS 1 X X [0..1] 0213

Purge Status Date 17 DT 8 X X [0..1]

Special Program Code 18 IS 2 X X [0..1] 0214

Retention Indicator 19 ID 1 X X [0..1] 0136

Expected Number of Insurance

Plans 20 NM 1 X X [0..1]

Visit Publicity Code 21 IS 1 X X [0..1] 0215Page 60

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 E : P A

T I E N T V I S I T

– A D D I T I O N A L I N F O R M A T I O N S E G M E N T ( P V 2 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Visit Protection Indicator 22 ID 1 X X [0..1] 0136

Clinic Organization Name 23 XON 250 X X [0..*]

Patient Status Code 24 IS 2 X X [0..1] 0216

Visit Priority Code 25 IS 1 X X [0..1] 0217

Previous Treatment Date 26 DT 8 X X [0..1]

Expected Discharge Disposition 27 IS 2 X X [0..1] 0112

Signature on File Date 28 DT 8 X X [0..1]

First Similar Illness Date 29 DT 8 X X [0..1]

Patient Charge Adjustment Code 30 CE 478 X X [0..1] 0218

Recurring Service Code 31 IS 2 X X [0..1] 0219

Billing Media Code 32 ID 1 X X [0..1] 0136Page 61

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 E : P A

T I E N T V I S I T

– A D D I T I O N A L I N F O R M A T I O N S E G M E N T ( P V 2 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Expected Surgery Date and Time 33 TS 26 X X [0..1]

Military Partnership Code 34 ID 1 X X [0..1] 0136

Military Non

- Availability Code 35 ID 1 X X [0..1] 0136

Newborn Baby Indicator 36 ID 1 X X [0..1] 0136

Baby Detained Indicator 37 ID 1 X X [0..1] 0136

Mode of Arrival Code 38 CE 478 X X [0..1] 0430

Recreational Drug Use Code 39 CE 478 X X [0..*] 0431

Admission Level of Care Code 40 CE 478 X X [0..1] 0432

Precaution Code 41 CE 478 X X [0..*] 0433

Patient Condition Code 42 CE 478 X X [0..1] 0434

Living Will Code 43 IS 2 X X [0..1] 0315Page 62

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 E : P A

T I E N T V I S I T

– A D D I T I O N A L I N F O R M A T I O N S E G M E N T ( P V 2 )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Organ Donor Code 44 IS 2 X X [0..1] 0316

Advance Directive Code 45 CE 478 X X [0..*] 0435

Patient Status Effective Date 46 DT 8 X X [0..1]

Expected LOA Return Date/Time 47 TS 26 X X [0..1]

Expected Pre

- admission Testing

Date/Time 48 TS 26 X X [0..1]

Notify Clergy Code 49 IS 20 X X [0..*] 0534Page 63

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.7 O BSERVATION 

### /R ESULT 

### (OBX) S EGMENT



### The OBX Segment in the ADT Message is used to transmit observations related to the patient and visit. In Section 4.2.1 if the

data element is carried i n an OBX and usage is „Required‟ , the segment and its field s must be populated.

T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Set ID

- OBX 1 SI 4 O RE [0..1] Note: Set ID n umbers the repetitions of the segments

Value Type 2 ID 3 R R [1 ..1] 0125

Note: Identifies the structure of data in observation value (OBX.5).

Observation Identifier 3 CE 478 R R [1..1] Observation Identifier ( Syndromic Surveillance )

Note : Identifies data to be received in observation value (OBX.5)

Identifier 3.1 ST 20 R R [1..1]

Text 3.2 ST 199 O O [0..1]

Name of Coding System 3.3 ID 20 C C [0..1] Condition R ule: Required if an identifier is provided in component 1.Page 64

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Alternate Identifier 3.4 ST 20 X X [0..1]

Alternate Text 3.5 ST 199 X X [0..1]

Name of Alternate Coding System 3.6 ID 20 X X [0..1]

Observation Sub

- ID 4 ST 20 X X [0..1]

Observation Value 5 varies 99999 RE RE [0..*] Note: Values received in observation value are defined by value type (OBX.2) and observation identifier (OBX.3).

Listed b elow are the supported fields for each of the supported value types.

Beginning of OBX

- 5 O bservation V alue U sage B ased on D ata Type in OBX

- 2

HD Data Type (2.3.1 Messaging Only)

Namespace ID 5.1 IS 20 RE RE [0..1] Name of originating facility.

Universal ID 5.2 ST 199 R R [1..1] National Provider Identifier. (10 digit identifier)Page 65

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Universal ID 5.3 ID 6 R R [1..1] Expecting Value “NPI”.

TS Data Type

Time 5.1 DTM 24 RE RE [0..1] Note: The minimum acceptable precision is to the nearest day.

Degree of Precision 5.2 ST 1 X X [0..0]

TX Data Type

Text Data 5.1 TX 65536 RE RE [0..1] Note: The TX data type is used to carry string data intended for display purposes. It can contain leading blanks (space characters).

NM Data Type

Numeric Value 5.1 ST 16 RE RE [0..1] Note: A numeric data type is a number represented as a series of ASCII numeric characters consisting of an optional leading sign (+ or

- ), the digits and an optional decimal point. In the absence of a sign, the number is assumed to be positive. If there is no decimal point the

number is assumed to be an integer.Page 66

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

CWE Data Type

Identifier 5.1 ST 20 RE RE [0..1] Note: Implementers should check with their local jurisdiction for version of adopted coding system.

Text 5.2 ST 199 RE RE [0..1] It is strongly recommended that text be sent to accompany any identifier.

Name of Coding System 5.3 ID 20 C C [0..1] Condition R ule: Required if an identifier is provided in component 1.

Alternate Identifier 5.4 ST 20 RE RE [0..1]

Alternate Text 5.5 ST 199 RE RE [0..1] It is strongly recommended that text be sent to accompany any identifier.

Name of Alternate Coding System 5.6 ID 20 C C [0..1] Condition R ule: Required if an identifier is provided in component 4.

Coding System Version ID 5.7 ST 10 O O [0..1]Page 67

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Alternate Coding System

Version ID 5.8 ST 10 O O [0..1]

Original Text 5.9 ST 199 RE RE [0..1] Provide the richest text available in this field.

XAD Data Type

Street Address 5.1 SAD 184 O O [0..1]

Street or Mailing Address 5.1.1 ST 120 O O [0..1] Note: This is the first subcomponent of the SAD data type. This has the same effect as being the first component of the field, while limiting the length based on other subcomponents that are not supported.

Street Name 5.1.2 ST 50 O O [0..1]

Dwelling Number 5.1.3 ST 12 O O [0..1]

Other Designation 5.2 ST 120 O O [0..1]

City 5.3 ST 50 O O [0..1]

State or Province 5.4 ST 50 O O [0..1] FIPS 5

- 2Page 68

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

ZIP or Postal Code 5.5 ST 12 O O [0..1] USPS

Country 5.6 ID 3 O O [0..1] ISO 3166

- 1

Address Type 5.7 ID 3 O O [0..1] 0190

Other Geographic Designation 5.8 ST 50 O O [0..1]

County/Parish Code 5.9 IS 20 O O [0..1]

Census Tract 5.10 IS 20 X X [0..1]

Address Representation Code 5.11 ID 1 X X [0..1]

Address Validity Range 5.12 DR 53 X X [0..0]

Effective Date 5.13 TS 26 X X [0..1]

Expiration Date 5.14 TS 26 X X [0..1]

End of OBX

- 5 Observation Value Usage Based on Data Type in OBX

- 2Page 69

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Units 6 CE 62 C C [0..1] Pulse Oximetry Unit

Temperature Unit

Age unit ( Syndromic Surveillance )

Note: Units are a conditional field. If numeric data is
sent, the units field must define the units of the value used in observation value (OBX.5)

Identifier 6.1 ST 20 R R [1..1]

Text 6.2 ST 20 O O [0..1] Standardized description associated with code in OBX

6.1.

Name of Coding System 6.3 ID 20 C C [0..1] C ondition R ule: Required if an identifier is provided in component 1.

Alternate Identifier 6.4 ST 20 X X [0..1]

Alternate Text 6.5 ST 199 X X [0..1]

Name of Alternate Coding System 6.6 ID 20 X X [0..1]Page 70

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

References Range 7 ST 60 X X [0..1]

Abnormal Flags 8 IS 5 X X [0..*] 0078

Probability 9 NM 5 X X [0..1]

Nature of Abnormal Test 10 ID 2 X X [0..*] 0080

Observation Result Status 11 ID 1 R R [1..1] 0085

Expected value : „F‟

Effective Date of Reference Range 12 TS 26 X X [0..1]

User Defined Access Checks 13 ST 20 X X [0..1]

Date/Time of the Observation 14 TS 26 O O [0..1]

Producer's ID 15 CE 478 X X [0..1]

Responsible Observer 16 XCN 309 X X [0..*]Page 71

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 F : O B S E R V A T I O N / R E S U L T S E G M E N T ( O B X )

Field Name Seq D T Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Observation Method 17 CE 478 X X [0..*]

Equipment Instance Identifier 18 EI 424 X X [0..*]

Date/Time of the Analysis 19 TS 26 X X [0..1]Page 72

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.8 D IAGNOSIS 

### (DG1) S EGMENT



### The DG1 segment contains patient diagnosis information of various types. Syndromic Surveillance supports Admitting, Working

and Final Diagnosis types.

T A B L E 3

- 6 G : D I A G N O S I S S E G M E N T ( D G 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Set ID

- DG1 1 SI 4 R R [1..1] Note: Numbers the repetitions of the segments

Diagnosis Coding Method 2 ID 2 X X [0..1] 0053

Diagnosis Code

- DG1 3 CE 478 R R [0..1] ICD

- 9 Clinical Modification diagnosis code (including

E

- codes and V

- codes)

Or

ICD

- 10 Clinical Modification diagnosis code

Or

SNOMED Disorder/ Disease domain

Identifier 3.1 ST 20 R RE [1..1] Note: Standardized code for diagnosis.

Text 3.2 ST 199 RE RE [1..1] Note: Standardized description associated with code

in DG1

- 3.1.Page 73

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 G : D I A G N O S I S S E G M E N T ( D G 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Name of Coding System 3.3 ID 20 C C [1..1] Condition R ule: Required if an identifier is provided in component 1.

Alternate Identifier 3.4 ST 20 X X [0..1]

Alternate Text 3.5 ST 199 X X [0..1]

Name of Alternate Coding System 3.6 ID 20 X X [0..1]

Diagnosis Description 4 ST 40 X X [0..0]

Diagnosis Date/Time 5 TS 26 O O [0..1]

Diagnosis Type 6 IS 2 R R [1..1] Diagnosis Type (HL7)

Note: Identifies the type of diagnosis being sent.

Literal values: “A” for Admitting diagnosis, “W” for Working diagnosis or “F” for Final diagnosis.

Major Diagnostic Category 7 CE 478 X X [0..0] 0118

Diagnostic Related Group 8 CE 478 X X [0..0] 0055Page 74

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 G : D I A G N O S I S S E G M E N T ( D G 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

DRG Approval Indicator 9 ID 1 X X [0..0] 0136

DRG Grouper Review Code 10 IS 2 X X [0..0] 0056

Outlier Type 11 CE 478 X X [0..0] 0083

Outlier Days 12 NM 3 X X [0..0]

Outlier Cost 13 CP 538 X X [0..0]

Grouper Version And Type 14 ST 4 X X [0..0]

Diagnosis Priority 15 ID 2 X X [0..1] 0359

Diagnosing Clinician 16 XCN 309 X X [0..*]

Diagnosis Classification 17 IS 3 X X [0..1] 0228

Confidential Indicator 18 ID 1 X X [0..1] 0136

Attestation Date/Time 19 TS 26 X X [0..1]Page 75

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 G : D I A G N O S I S S E G M E N T ( D G 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Diagnosis Identifier 20 EI 427 X X [0..1]

Diagnosis Action Code 21 ID 1 X X [0..1] 0206Page 76

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.9 P ROCEDURES 

### (PR1) S EGMENT



### The PR1 segment is used to carry i nformation relative to various types of procedures performed.

T A B L E 3

- 6 H

. P R O C E D U R E S S E G M E N T ( P R 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Set ID

– PR1 1 SI 4 R R [1..1] Note: Numbers the repetitions of the segments.

Procedure Coding Method 2 IS 3 X X [0..1] 0089

Procedure Code 3 CE 478 R R [1..1] 0088

Procedure Description 4 ST 40 X X [0..0]

Procedure Date/Time 5 TS 26 R R [1..1]

Procedure Functional Type 6 IS 2 X X [0..1] 0230

Procedure Minutes 7 NM 4 X X [0..1]

Anesthesiologist 8 XCN 309 X X [0..0] 0010

Anesthesia Code 9 IS 2 X X [0..1] 0019Page 77

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 H

. P R O C E D U R E S S E G M E N T ( P R 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Anesthesia Minutes 10 NM 4 X X [0..1]

Surgeon 11 XCN 309 X X [0..0] 0010

Procedure Practitioner 12 XCN 309 X X [0..0] 0010

Consent Code 13 CE 478 X X [0..1] 0059

Procedure Priority 14 ID 2 X X [0..1] 0418

Associated Diagnosis Code 15 CE 478 X X [0..1] 0051

Procedure Code Modifier 16 CE 478 X X [0..*] 0340

Procedure DRG Type 17 IS 20 X X [0..1] 0416

Tissue Type Code 18 CE 478 X X [0..*] 0417

Procedure Identifier 19 EI 427 X X [0..1]

Procedure Action Code 20 ID 1 X X [0..1] 0206Page 78

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.10 I NSURANCE 

### (IN1) S EGMENT



### The IN 1 segment contains insurance policy coverage information necessary to produce properly pro

- rated and patient and

insurance bills

.

T A B L E 3

- 6 I : I N S U R A N C E S E G M E N T ( I N 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Set ID

– PR1 1 SI 4 R R [1..1] Note: SET ID n umbers the repetitions of the segments.

Insurance Plan ID 2 CE 478 R R [1..1] 0072

Insurance Company ID 3 CX 250 R R [1..*]

Insurance Company Name 4 XON 250 X X [0..*]

Insurance Company Address 5 XAD 513 X X [0..*]

Insurance Co Contact Person 6 XPN 294 X X [0..*]

Insurance Co Phone Number 7 XTN 250 X X [0..*]

Group Number 8 ST 12 X X [0..1]

Group Name 9 XON 250 X X [0..*]Page 79

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 I : I N S U R A N C E S E G M E N T ( I N 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Insured_s Group Emp ID 10 CX 250 X X [0..*]

Insured_s Group Emp Name 11 XON 250 X X [0..*]

Plan Effective Date 12 DT 8 X X [0..1]

Plan Expiration Date 13 DT 8 X X [0..1]

Authorization Information 14 AUI 239 X X [0..1]

Plan Type 15 IS 3 O O [0..1] 0086

Name Of Insured 16 XPN 294 X X [0..*]

Insured_ Relationship To Patient 17 CE 478 X X [0..1] 0063

Insured_ Date Of Birth 18 TS 26 X X [0..1]

Insured_ Address 19 XAD 513 X X [0..*]

Assignment Of Benefits 20 IS 2 X X [0..1] 0135Page 80

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 I : I N S U R A N C E S E G M E N T ( I N 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Coordination Of Benefits 21 IS 2 X X [0..1] 0173

Coord Of Ben. Priority 22 ST 2 X X [0..1]

Notice Of Admission Flag 23 ID 1 X X [0..1] 0136

Notice Of Admission Date 24 DT 8 X X [0..1]

Report Of Eligibility Flag 25 ID 1 X X [0..1] 0136

Report Of Eligibility Date 26 DT 8 X X [0..1]

Release Information Code 27 IS 2 X X [0..1] 0093

Pre

- Admit Cert (PAC) 28 ST 15 X X [0..1]

Verification Date/Time 29 TS 26 X X [0..1]

Verification By 30 XCN 309 X X [0..*]

Type Of Agreement Code 31 IS 2 X X [0..1] 0098Page 81

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 I : I N S U R A N C E S E G M E N T ( I N 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Billing Status 32 IS 2 X X [0..1] 0022

Lifetime Reserve Days 33 NM 4 X X [0..1]

Delay Before L.R. Day 34 NM 4 X X [0..1]

Company Plan Code 35 IS 8 X X [0..1] 0042

Policy Number 36 ST 15 X X [0..1]

Policy Deductible 37 CP 538 X X [0..1]

Policy Limit

- Amount 38 CP 538 X X [0..0]

Policy Limit

- Days 39 NM 4 X X [0..1]

Room Rate

- Semi

- Private 40 CP 538 X X [0..0]

Room Rate

- Private 41 CP 538 X X [0..0]

Insured_ Employment Status 42 CE 478 X X [0..1] 0066Page 82

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 6 I : I N S U R A N C E S E G M E N T ( I N 1 )

Field Name Seq DT Len gt

h Sender

Usage Receiver

Usage Cardinality Values / Value Set

Insured_ Administrative Sex 43 IS 1 X X [0..1] 0001

Insured_ Employer_s Address 44 XAD 513 X X [0..*]

Verification Status 45 ST 2 X X [0..1]

Prior Insurance Plan ID 46 IS 8 X X [0..1] 0072

Coverage Type 47 IS 3 X X [0..1] 0309

Handicap 48 IS 2 X X [0..1] 0295

Insured_ ID Number 49 CX 250 X X [0..*]

Signature Code 50 IS 1 X X [0..1] 0535

Signature Code Date 51 DT 8 X X [0..1]

Insured_ Birth Place 52 ST 250 X X [0..1]

VIP Indicator 53 IS 2 X X [0..1] 0099Page 83

PHIN Messaging Guide for Syndromic Surveillance 

### 3.6.11 M ESSAGE 

### A CKNOWLEDG E MENT 

### (MSA) S EGMENT



### The MSA segment is used by message receivers to acknowledge a correct receipt of a message.

T A B L E 3

- 6 J : M E S S A G E A C K N O W L E D G E M E N T S E G M E N T ( M S A )

Field Name Seq DT Len Sender

Usage Receiver

Usage Cardinality Values / Value Set

Acknowledgement Code 1 ID 2 R R [1..1] 0008

Message Control ID 2 ST 20 R R [1..1] Specifies the value in MSH

- 10 of the message being acknowledged

Text Message 3 ST 80 X X [0..1]

Expected Sequence Number 4 NM 15 X X [0..1]

Delayed Acknowledgement Type 5 X X [0..0] Note: The MSA

- 5 was deprecated as of v2.2 and the

detail was withdrawn and removed from the standard

as of v ersion 2.5

.

Error Condition 6 CE 250 RE RE [0..1] 0357Page 84

PHIN Messaging Guide for Syndromic Surveillance 

## 3.7 HL7 BATCH PROTOCOL

The HL7 Batch Protocol can be used to allow for periodic reporting. The HL7 file and batch header and trailer segments are

defined in exactly the same manner as the HL7 message segments; hence, the same HL7 message construction rules used for

individual messages can be used to encode and deco de HL7 batch files. One batch of messages per file is supported.

3.7.1 HL7 B ATCH 

### F ILE 

### S TRUCTURE



### The structure of the batch file is constrained as follows:

T A B L E 3

- 7 : B A

T C H S I M P L E F I L E S T R U C T U R E

S EGMENT 

### N AME 

### D ESCRIPTION 

### U SAGE 

### C ARDINALITY

FHS File Header Segment Information explaining how to parse and process the file.

This information includes identification of file delimiters, sender, receiver, timestamp, etc. R [1..1]

BHS Batch Header Segment Trigger event information for receiving application. One batch per file is supported. R [1..1]

{ HL7 messages } R [1..*]

BTS Batch Trailer Segment R [1..1]

FTS File Trailer Segment R [1..1]Page 85

PHIN Messaging Guide for Syndromic Surveillance 

### 3.7.2 F ILE 

### H EADER 

### (FHS) S EGMENT



### This segment is used as the lead

- in to a file (group of batches).

T A B L E 3

- 7 A : F I L E H E A D E R S E G M E N T ( F H S )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

File Field Separator 1 ST 1 R R [1..1] Default Value “|” (ASCII 124).

File Encoding Characters 2 ST 4 R R [1..1] Default Values “^~ \ &” (ASCII

94 , 126, 92 , and 38).

File Sending Application 3 HD 227 O O [0..1]

File Sending Facility 4 HD 227 O RE [0..1]

File Receiving Application 5 HD 227 O O [0..1]

File Receiving Facility 6 HD 227 O O [0..1]

File Creation Date/Time 7 TS 26 O RE [0..1]

File Security 8 ST 40 X X [0..1]Page 86

PHIN Messaging Guide for Syndromic Surveillance File Name/ID 9 ST 20 O RE [0..1]

File Header Comment 10 ST 80 O O [0..1]

File Control ID 11 ST 199 O RE [0..1]

Reference File Control ID 12 ST 20 O RE [0..1]



### Example: FHS|^~ \ &<cr>Page 87

PHIN Messaging Guide for Syndromic Surveillance 

### 3.7.3 F ILE 

### T RAILER 

### (FTS) S EGMENT



### The FTS segment defines the end of a file (group of batches).

T A B L E 3

- 7 B

. F I L E T R A I L E R S E G M E N T ( F T S )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

File Batch Count 1 NM 10 R RE [0..1] The number of batches

contained in this file. Since

this interface is constrained to one batch per file, this number should always be

„1‟.

File Trailer Comment 2 ST 80 O O [0..1]



### Example: FTS|1<cr>Page 88

PHIN Messaging Guide for Syndromic Surveillance 

### 3.7.4 B ATCH 

### H EADER 

### (BHS) S EGMENT



### The BHS segment is used to head a group of messages that comprise a batch.

T A B L E 3

- 7 C : B A

T C H H E A D E R S E G M E N T ( B H S )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Batch Field Separator 1 ST 1 R R [1..1] Default Value “|” (ASCII 124).

Batch Encoding Characters 2 ST 4 R R [1..1] Default Values “^~ \ &” (ASCII 94,126,92, and 38).

Batch Sending Application 3 HD 227 R R [1..1]

Batch Sending Facility 4 HD 227 R R [1..1]

Batch Receiving Application 5 HD 227 R R [1..1]

Batch Receiving Facility 6 HD 227 R R [1..1]

Batch Creation Date/Time 7 TS 26 R R [1..1]

Batch Security 8 ST 40 X X [0..1]Page 89

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 3

- 7 C : B A

T C H H E A D E R S E G M E N T ( B H S )

Field Name Seq DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Batch Name/ID 9 ST 20 O RE [0..1]

Batch Header Comment 10 ST 80 O RE [0..1]

Batch Control ID 11 ST 20 O RE [0..1]

Reference Batch Control ID 12 ST 20 O RE [0..1]



### Example: BHS|^~ \ &|ER1^2.16.840.1.113883.19.3.1.1^ISO |CITY_GENERAL^2.16.840.1.113883.19.3.1^ISO|SS_APP^2.16.840.1.113883.19.3.2.1^ISO|SPH^2.16.840.1.113883.19.3. 2^ISO|20080723123558

- 0400<cr>Page 90

PHIN Messaging Guide for Syndromic Surveillance 

### 3.7.5 B ATCH 

### T RAILER 

### (BTS) S EGMENT



### The BTS segment defines the end of a batch of messages.

T A B L E 3

- 7 D : B A

T C H T R A I L E R S E G M E N T ( B T S )

Field Name Seq uence DT Len gth Sender

Usage Receiver

Usage Cardinality Values / Value Set

Batch Message Count 1 NM 10 R RE [0..1] The number of messages contained in the preceding batch.

Batch Comment 2 ST 80 O RE [0..1]

Batch Totals 3 NM 100 X X [0..*]



### Example: BTS|100|Facility reporting for 2

- 1

- 2011<cr>Page 91

PHIN Messaging Guide for Syndromic Surveillance 

## 4 DATA ELEMENTS OF INT EREST

4.1 COLUMN DEFINITIONS F OR ELEMENTS OF INTER EST TABLE

Table 4

- 1 contains the preliminary minimum set of data elements commonly used for public health Syndromic Surveillance

.

This section describes the definitions of the table columns in Table 4

- 1.

T A B L E 4

- 1 : S Y N D R O M I C S U R V E I L L A N C E C O L U M N H E A D I N G S

C OLU MN 

### N AME 

### D EFINITION

# Number of the core data set element as provided by ISDS

Data Element Name Name of the core data set element as provided by ISDS

Description of Field Description of the data element

Usage Refers to whether an element must appear in the message. The Usage codes are:

 R

– Required Indicates that the field is a required field. A value must be present in the field in order for the message to be accepted.

 RE

– Required, but can be empty: Indicates that the field is a required field. Howeve r, if there is no data captured in the field due to the setting (e.g. no chief complaint data for a trauma patient) and the field is blank, the message may be sent with the field containing no data.

 O

– Optional: Optional for data to be sent in a message. Local jurisdictions must further constrain these elements for implementation.Page 92

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 1 : S Y N D R O M I C S U R V E I L L A N C E C O L U M N H E A D I N G S

C OLU MN 

### N AME 

### D EFINITION

Cardinality Minimum and maximum number of times the element may appear

Value Set OID / Name Value Set OID and Name of value set containing the values that define the data element. These may be used to populated the tables from which coded message fields are drawn

Notes Describes additional notes that are relevant to the rules and/or processing of the data element field

Recommended HL7 Location Recommended location of Data Element for HL7 message population



## 4.2 DATA ELEMENTS OF INT EREST FOR SYNDROMIC SURVEILLAN CE

The following section is derived from the ISDS Final Recommendation: The Core Processes and EHR Requirements of Public

Health Syndromic Surveillance

, S ection 4, discussing data sets for core EHR requirements

. In the following tables, columns 1

- 5

are define d by the ISDS recommendations and columns 6

- 8 are provided to assist implementers of HL7 messaging.

4.2.1 M INIMUM 

### D ATA 

### S ET



### The following table contains a minimum list of data elements commonly used by public health authorities to conduct Syndromic

Surveillance

. This list does not represent the entire list of data elements needed to support the current practice of Syndromic

Surveillance across al l public health jurisdictions. Therefore, the actual data elements and their specifications are subject to

change in accordance with applicable state and local laws and practices.Page 93

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

Treatment Facility Identifiers

1 Facility

Identifier (Treating) Unique facility

identifier of facility where the patient originally presented (original provider of the data) R [1..1] Recommend the use of the

National Provider Identifier Standard provided by Centers

for Medicare and Medicaid

Services. For more information about NPI, search for, or to apply for a NPI, click here

. Final Rule establishing NPI as standard unique health

identifier for health care providers

NPI Final Rule This number should be specific for each facility location (not a number representing an umbrella business)

It is recommended that

National Provider Identifier (NPI) be used for the Facility Identifier. HL7 Version 2.5.1 :

EVN

- 7.2

Example EVN

- 7:

| OTH_REG_MEDCTR^12 34567890^NPI|

HL7 Version 2.3.1:

OB X Segment (HD Data Type, 2 nd Component of

5 th field ) with

PHINQUESTION Code (SS001) Observation

IdentifierPage 94

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

Example OBX Segment :

OBX|2|HD|SS001^TREATI

NG FACILITY

IDENTIFIER^PHINQUESTI ON|| OTHER_REG_MED C

TR^1234567890^ NPI ||||||F|| |201102171531 <cr>

2 Facility

Name

(Treating) Name of facility

where the patient originally presented (original provider of the data) O [0..1] Recommend the use of the Organization Name Legal

Business Name ( LBN )

associated with the National

Provider Identifier Standard provided by Centers for

Medicare and Medicaid

Services. For more information about NPI, search for, or to apply for a NPI, click here

.

Final Rule establishing NPI as standard unique health

identifier for health care If this data element is captured and maintained as part of the facility registration process, it may not be sent with every message. See ISDS
recommendations, s ection 4.2, on Facility Registration

ISDS. HL7 Version 2.5.1:

EVN

- 7.1

Example EVN

- 7:

| OTH_REG_MEDCTR^12 34567890^NPI|

HL7 Version 2.3.1:

OBX Segment (HD Data Type, 1 st Component, 5 th

field) with

PHINQUESTION CodePage 95

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

providers

NPI Final Rule (SS001) Observation

Identifier

Example OBX Segment:

OBX|2|HD|SS001^TREATI

NG FACILITY

IDENTIFIER^PHINQUESTI ON||OTHER REG MED

CTR^1234567890^NPI |||||| F|||201102171531 <cr>

3 Facility

Location (Treating)

– Street

Address Street address

of treating facility location O [0..1] If this data element is captured and maintained as part of the facility registration process, it may not be sent with every message. See ISDS
recommendations, section

4.2

, on Facility Registration

ISDS. OBX Segment (XAD Data Type) with

PHINQUESTION Code (SS002) Observation

Identifier

The XAD Data Type has specific fields to

accommodate the street address, city, county and state, so only a single OBX is required to pass 4 Facility

Location (Treating) City of treating

facility location O [0..1] The ISDS recommendations

recommend free text City/Town If this data element is captured and maintained as part of the facilityPage 96

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

- City designations. registration process, it may not be sent with every message. See ISDS
recommendations, section 4.2, on Facility Registration

ISDS. the data.

Example OBX segment:

OBX|1|XAD|SS002^TREAT

ING FACILITY

LOCATION^PHINQUESTI ON||^^^ 13 ^30341^USA^C^ ^DEKALB||||||F|||20110209

1114<cr>

This data can also be

accommodated in the Facility Registration

pro cess as defined by

ISDS. 5 Facility

Location (Treating)

– County County of

treating facility

location O [0..1] The ISDS recommendations

allow free text County designations. If this data element is captured and maintained as part of the facility registration process, it may not be sent with every message. See ISDS
recommendations, section 4.2, on Facility Registration

ISDS.

6 Facility

Location (Treating)

– State State of

treating facility

location O [0..1] 2.16.840.1.114222.4.11.830

PHVS_State_FIPS_5

- 2 If this data element is captured and maintained as part of the facility registration process, it may not be sent with every message. See ISDS
recommendations, section 4.2, on Facility RegistrationPage 97

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

ISDS.

7 Facility / Visit Type Type of facility

that the patient

visited for

treatment RE [0..1] 2.16.840.1.114222.4.11.3401

PHVS_FacilityVisitType_Syndromic

Surveillance R elevant facility/visit type

values are defined in value

set.

This data can also be

accommodated in the Facility Registration process as defined by ISDS for facilities where a single facility/visit type is expected. OBX Segment (CWE Data Type) with

PHINQUESTION Code (SS003) Observation

Identifier

Example OBX segment:

OBX|2|CWE|SS003^FACIL

ITY / VISIT TYPE^PHINQUESTION||11

08

- 0^EMERGENCY DEPARTMENT^HSLOC||||| |F|||201102091114<cr>

8 Report

Date/Time Date and time

of report

transmission from original source (from treating facility) R [1..1] If data flows through an intermediary or third party, the intermediary

must keep the original

date/time of transmission.

HL7 Date/Time Format:

YYYYMMDDHHMM[SS[.S[S EVN

- 2

Example Report

Date/Time:

1:01:59 AM EST on July
4, 2011

| 2011 0704010159

- 0500 |Page 98

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

[S[S]]]]] [+/

- ZZZZ]

Patient Demographics

9 Unique

Patient

Identifier Unique

identifier for the patient R [1..*] 2.16.840.1.114222.4.11. 3405

PHVS_IdentifierType_ SyndromicS

urveillance Unique Patient Identifiers

related to individual

identifiers based on HL7

Table 0203. PID

- 3

The Unique Patient

Identifier occurs in the 1 st

component of the CX data type. The 5th component, the Identifier Type Code, defines the type of identifier

used in the 1 st component.

Example PID

- 3 Fields:

Internal Identifier (PI)

|95101100001^^^^PI|

External Identifier (PT)

|E95101100001^^^^PT|

10 Medical

Record # Patient medical

record number O [0..1] 2.16.840.1.114222.4.11.3405

PHVS_IdentifierType_SyndromicS It is recommended that data providers submit the patient

medical record number to PID

- 3

The Medical Record # is aPage 99

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

urveillance facilitate identification of the patient, in the event of a required follow

- up investigation. Without the
medical record number, the work required to follow

- up
on the records of interest greatly increases on the data provider and may cause unacceptable delays in public health response. In
addition, the medical record number may aid in record

de

- duplication efforts and may often aid in the resolution of apparent transcription e rrors. specific instance of a unique patient identifier. It

occurs in the 1 st component of the CX data type. The

fifth component, the Identifier Type Code,

defines the identifi er as the Medical Record # (MR).

Example PID

- 3 Field:

|MR101100001^^^^MR|

11 Age Numeric value

of patient age R [1..1] For OBX

- 3, p lease use :

2.16.840.1.114222.4.11.3589

PHVS_ObservationIdentifier_Syndr

omicSurveillance This element is represented by the LOINC code: 21612

- 7 in the OBX observation

identifier. OBX Segment (NM Data Type, 1 st Component, 5 th

field) with LOINC Code (21612

- 7) Observation

IdentifierPage 100

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

The actual data value

occurs in the 5 th field of the

same OBX segment and is Numeric as defined by the OBX Data Type NM.

Data providers and

receivers should determine specific data restrictions for their jurisdiction. Example OBX Segment:

OBX|4|NM|21612

- 7 ^AGE

TIME PATIENT REPORTED^LN||43|a^YEA R^UCUM|||||F||| 201102171

531< cr>

12 Age units Unit

corresponding

to numeric value of patient age (e.g. Days,

Month or Years) R [1..1] For OBX

- 6 Please use:

2.16.840.1.114222.4.11.3402

PHVS_AgeUnit_SyndromicSurveill

ance Relevant Age Unit values

are defined in value set.

Unknown has been added

to the value set to allow for

instances wher e the patient age may not be obtainable. OBX Segment (CE Data Type, 6 th field)

Example OBX Segment:

OBX|4|NM|21612

- 7 ^AGE

TIME PATIENT REPORTED^LN||43|a^YEA R^UCUM|||||F||| 201102171

531<cr>Page 101

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

13 Gender Gender of

patient RE [0..1] 2.16.840.1.114222.4.11.3403
PHVS_Gender_SyndromicSurveilla

nce Relevant Gender values are

defined in value set. PID

- 8

14 City/Town City/Town of

patient

residence O [0..1] The ISDS recommendations allow free text City/Town designations. PID

- 11.3

15 ZIP Code Z IP Code of

patient

residence RE [0..1] Provide a minimum of 5 digits for domestic ZIP

code s

. Foreign postal codes should be supported. PID

- 11.5

16 State State of patient

residence RE [0..1] 2.16.840.1.114222.4.11.830

PHVS_State_FIPS_5

- 2 It is recommended that the

2

- digit (numeric)

abbreviation be used for State of the patient domestic

home address. PID

- 11.4Page 102

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

17 Country Country of

patient

residence RE [0..1] 2.16.840.1.114222.4.11.828

PHVS_Country_ISO_3166

- 1 It is recommended that the

3

- character country codes be used for Country of the patient home address. PID

- 11.6

18 Race Race of patient RE [0..*] 2.16.840.1.114222.4.11.836

PHVS_RaceCategory_CDC Relevant Race Category

values are defined in value

set. PID

- 10

19 Ethnicity Ethnicity of

patient RE [0..*] 2.16.840.1.114222.4.11.837

PHVS_EthnicityGroup_CDC Relevant Ethnicity values

are defined in value set. PID

- 22

Patient Health Indicators

20 Unique Visiting ID Unique

identifier for a R [1..1] 2.16.840.1.114222.4.11.3405

PHVS_IdentifierType_SyndromicSu A visit is defined as a discrete or unique clinical PV1

- 19

The Unique Visiting IDPage 103

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

patient visit rveillance encounter within a service department or location. 8 occurs in the 1 st component of the CX data type. The 5th component, the Identifier Type Code,

defines the identifier as the Visit Number (VN).

Example PV1

- 19 Field:

|VN101100001^^^^VN|

21 Visit Date /

Time Date/Time of

patient presentation R [1..1] HL7 Date/Time Format:

YYYYMMDDHHMM[SS[.S[S [S[S]]]]] [+/

- ZZZZ] PV1

- 44

Example Visit

Date/Time:

2:06:59 PM EST on April
1, 2011

|20110401140659

- 0500|

8 The definition of a unique visit in this provisional recommendation differs from BioSense. BioSense rolls multiple visits wit hin a 24

- hour period into

one visit.Page 104

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

22 Date of

onset Date that

patient began having symptoms of condition being reported RE [0..1] For PBX

- 3 Please use:

2.16.840.1.114222.4.11.3589

PHVS_ObservationIdentifier_ Syndromic Surveillance This element is repres ented by the LOINC code: 11368

- 8 in the OBX observation

identifier.

The actual data value

occurs in the 5 th field of the same OBX segment and is a Timestamp as defined by the OBX Data Type TS

. OBX Segment ( TS Data Type, 1 st Component, 5 th

field) with LOINC Code (11368

- 8 ) Observation

Identifier

Example OBX Segment :

OBX|7|TS| 11368

- 8^ILLNESS OR INJURY

ONSET DATE AND

TIME:TMSTP:PT:PATIENT :QN^LN||20110215||||||F||| 2

01102171658<cr>

23 Patient

Class Patient

classification within facility RE [0..1] 2.16.840.1.114222.4.11.3404
PHVS_PatientClass_SyndromicSur

veillance Relevant Patient Class

values are defined in value

set. PV1

- 2

24 Chief Complaint

/ Reason

for visit Short

description of

the chief complaint or

reason of RE [0..*] For OBX

- 3 Please use:

2.16.840.1.114222.4.11.3589

PHVS_ObservationIdentifier_Syndr

omicSurveillance T his element is represented by the LOINC code: 8661

- 1

in the OBX observation

identifier. OBX Segment (CWE Data Type, 5 th field) with LOINC Code (8661

- 1)

Observation IdentifierPage 105

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

patient‟s visit,

recorded when seeking care For OBX

- 5 Please use:

Free text

Or

2.16.840.1.114222.4.11.856

PHVS_AdministrativeDiagnosis_C DC_ICD

- 9CM

Or

2.16.840.1.114222.4.11.3593

PHVS_CauseOfDeath_ICD

10_CDC

Or

2.16.840.1.114222.4.11.909

PHVS_Disease_CDC

(SNOMED Based Valueset)

For further guidance refer to the

column

– „Recommended HL7

Location‟ The actual data value

occurs in the 5 th field of the same OBX segment and is Coded with Exception as defined by the OBX Data Type CWE

. Using the CWE allows for the possibility of free text, while also allowing for the

coded values listed.

If data flows through an intermediary or third party, the intermediary

must keep the original text (CWE

- 9) of th e
transm ission.

Note: Implementers should

check with their local jurisdiction for version of adopted coding system. Example OBX Segment (free text) :

OBX|3|CWE|8661

- 1^CHIEF

COMPLAINT:FIND:PT:PAT

IENT:NOM:REPORTED^L N||^^^^^^^^ STOMACH ACHE||||||F|||20110217153

1 <cr>

Example OBX Segment (coded and free text ):

OBX|3|CWE|8661

- 1^CHIEF

COMPLAINT:FIND:PT:PAT

IENT:NOM:REPORTED^L N||7804^Dizziness and giddiness [780.4]^I9CDX^^^^^^ DIZZY ||||||F|||201102171531 <cr >Page 106

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

25 Triage

Notes Triage notes

for the patient

visit O [0..1] For OBX

- 3 Please use:

2.16.840.1.114222.4.11.3589

PHVS_ObservationIdentifier_Syndr

omicSurveillance

For OBX

- 5 Please use:

Free text

For further guidance refer to the

column

– „Recommended HL7

Location‟ This element is represented by the LOINC code: 54094

- 8 in the OBX observation

identifier.

The actual data value

occurs in the 5 th field of the same OBX segment and is Text as defined by the OBX Data Type TX.

Triage Notes should be sent

as free text.

T riage notes may benefit from additional processing (e.g. negation processing, natural language processing, etc.) in order to maximize the utility of the

data. OBX Segment (TX Data Type, 5 th field) with LOINC Code (54094

- 8)

Observation Identifier

Example OBX Segment :

OBX|1 |TX|54094

- 8^ TRIAGE

NOTE:FIND:PT:EMERGEN

CY

DEPARTMENT:DOC^LN || P ain a recurrent cramping

sensation. ||||||F|||20110209

1114<cr>Page 107

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

26 Diagnosis / Injury

Code Diagnosis or

injury code of patient

condition RE [0..*] 2.16.840.1.114222.4.11.856

PHVS_AdministrativeDiagnosis_C DC_ICD

- 9CM

Or

2.16.840.1.114222.4.11.3593

PHVS_CauseOfDeath_ICD

10_CDC

Or

2.16.840.1.114222.4.11.909

PHVS_Disease_CDC

(SNOMED Based Valueset) Data should be sent on a regular schedule and should not be delayed for diagnosis or verification procedures. Regu lar updating of data

should be used to correct any errors or send data

available later.

Include V

- codes and E

codes

This field is a repeatable field; multiple codes may be

sent.

The first diagnosis code should be the primary / diagnosis. DG1

- 3

27 Clinical Impression Clinical

impression (free text) of the diagnosis O [0..1] For OBX

- 3 Please use :

2.16.840.1.114222.4.11.3589

PHVS_ObservationIdentifier_Syndr

omicSurveillance Thi s element is represented by the LOINC code: 44833

- 2 in the OBX observation

identifier. OBX Segment (TX Data Type, 5 th field) with LOINC Code (44833

- 2)

Observation IdentifierPage 108

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

For OBX

- 5 Please use:

Free text

For further guidance refer to the

column

– „Recommended HL7

Location‟ The actual data value

occurs in the 5 th field of the same OBX segment and is Text as defined by the OBX Data Type TX. Example OBX Segment:

OBX|1|TX|44833

- 2^DIAGNOSIS.PRELIMINA

RY:IMP:PT:PATIENT:NOM :^LN|| Pain consist with appendicitis ||||| |F|||2011020

91114<cr>

28 Diagnosis Type Qualifier for

Diagnosis / Injury Code specifying type of diagnosis RE [0..*] 2.16.840.1.114222.4.11.827

PHVS_DiagnosisType_HL7_2x Relevant Ethnicity values

are defined in value set. DG1

- 6

29 Discharge Disposition Patient's

anticipated

location or status following

ED/UC visit RE [0..1] 2.16.840.1.113883.3.88.12.80.3

3

UB

- 04/NUBC Current UB Data Specifications Manual

- UB

- 04

FL17

– Patient Status

This data set is not currently

free ly available due to licensing

issues

. The value set OID is It is expected that t his field will update with multiple

submissions. PV1

- 36Page 109

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

shown for reference. For more information, visit the National Uniform Billing Comm ittee

website located here

.

30 Disposition

Date / Time Date and time

of disposition RE [0..1] HL7 Date/Time Format:

YYYYMMDDHHMM[SS[.S[S [S[S]]]]] [+/

- ZZZZ]

Send this field as empty if the patient has not been discharged. Do not wait to send data until patient is discharged. PV1

- 45

Example Disposition

Date/Time:

4:45:12 PM EST on January 13, 2011

|20110113164512

- 0500|

31 Initial Temp

erature 1 st recorded

temperature, including units RE [0..1] For OBX

- 3 Please use:

2.16.840.1.114222.4.11.3589

PHVS_ObservationIdentifier_Syndr

omicSurveillance

OBX

- 6 Please use: This element is represented by the LOINC code: 11289

- 6 in the OBX observation

identifier.

The actual data value

occurs in the 5 th field of the OB X Segment (NM Data Type, 1 st Component, 5 th

field) with LOINC Code (11289

- 6) Observation

Identifier

Example OBX Segment:Page 110

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

2.16.840.1.114222.4.11.919

PHVS_TemperatureUnit_UCUM same OBX segment and is Numeric as defined by the OBX Data Type NM.

Units of the temperature

must also be included.

Fahrenheit and Celsius units

of measure are included in

the value set. OBX|3|NM| 11289

- 6^BODY

TEMPERATURE:TEMP:EN

CTRFIRST:PATIENT:QN^L N||100.1|[degF]^FARENHE IT^UCUM||A|||F||| 20110217

145139<cr>

Units of measure ( OBX

- 6, (CE Data Type) must be included defining the

numeric value.

32 Initial

Pulse Oximetry 1 st recorded

pulse oximetry

value RE [0..1] For OBX

- 3 Please use:

2.16.840.1.114222.4.11.3589

PHVS_ObservationIdentifier_Syndr

omicSurveillance

For OBX

- 6 Please use:

2.16.840.1.114222.4.11.3590

PHVS_PulseOximetryUnit_UCUM This element is represented by the LOINC code: 59408

- 5 in the OBX observation

identifier.

The actual data value

occurs in the 5 th field of the same OBX segment and is numeric as defined by the OBX Data Type NM. OBX Segment (NM Data Type, 1 st Component, 5 th

field) with LOINC Code ( 59408

- 5 ) Observation

Identifier

Example OBX Segment:

OBX|4|NM|59408

- 5 ^ OXYGEN

SATURATION:MFR:PT:BL

DA:QN:PULSEPage 111

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 1 : M I N I M U M D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

Units of measure must also

be included. Percentage is the only value included in

the value set. OXIMETRY ^LN|| 91|%^PE

RCENT^UCUM ||A|||F||| 201

10217145139<cr>

Units of measure (OBX

- 6, (CE Data Type) must be included defining the

numeric value.Page 112

PHIN Messaging Guide for Syndromic Surveillance 

### 4.2.2 E XTENDED 

### D ATA 

### E LEMENTS FOR 

### F URTHER 

### C ONSIDERATION


### Identified as Appendix A in the ISDS Final Recommendation, t he extended data elements are fields that are recognized as currently in use by some jurisdictions, but not widespread enough to be included as part of the core minimum data set. These data elements are considered an optional extension of the core minimum data set fo r jurisdictions that wish to include them for implementation.

T A B L E 4

- 2

- 2 : E X T E N D E D D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

33 Pregnancy

Status Pregnancy

status of the patient O TBD Pregnancy status helps

determine the risk factor for

certain diseases or
conditions, such as H1N1 influenza, Arboviral, Brucellosis, gastroenteritis, Acute Hepatitis B, Acute Hepatitis C, Hepatitis D &
E, Listeriosis, Lyme disease, Malaria, Q Fever, Relapsing Fever, Rubella,
West Nile Virus, Yellow OBX SegmentPage 113

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 2 : E X T E N D E D D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

Fever

34 Initial ED Acuity

Assess

ment Assessment of

the severity of the patient‟s

condition O TBD This data element helps determine the severity of the patient‟s condition.

The triage nurse assesses the severity of the patient‟s condition and how many resources are required. An example of the assessment may be to use a scale of 1 to 5 to indicate a range of severity. OBX Segment

35 Laboratory

Order data

set Data elements

related to the ordering of laboratory tests for the patient O The individual data

elements related to laboratory orders have not yet been determined. If used, the specific data

elements should be specified and agreed upon by individual jurisdictions and their Recommendation requires further analysis and has not yet been determined.Page 114

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 2 : E X T E N D E D D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

data sharing partners.

Laboratory order data elements help identify possible health conditions of interest to public

health.

Due to the possible high volume of data, jurisdictions may wish to limit the type of laboratory order dat a that is

transmitted.

36 Laboratory

Results

data set Data elements

related to the

results of laboratory tests

conducted on the patient O The individual data

elements related to laboratory results have

not been determined. If used, the specific data

elements should be specified and agreed upon by individual jurisdictions and their data sharing partners.

Laboratory results data elements help determine Recommendation requires further analysis and has not yet been determined.Page 115

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 2 : E X T E N D E D D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

the proportion of positive

res ults (denominator data) and the amount of testing being conducted at a given time. It may help in the ability to

differentiate when a signal is due to procedural change or an

outbreak.

Due to the possible high volume of data, jurisdictions may wish to limi t the type of laboratory results data that is

transmitted.



### 4.2.3 F UTURE 

### D ATA 

### E LEMENTS FOR 

### F URTHER 

### C ONSIDERATION


### Also identified as Appendix A in the ISDS Final Recommendation, t he future data set contains data elements that will be considered for inclusion into the core minimum data set for future iterations. These future data elements may or may not be currently used by jurisdictions.Page 116

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 3 : F U T U R E D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

37 Patient

Street

Address Patient‟s street

address of

residence O PID

- 11.1

38 Patient

Date of Birth (DOB) Patient‟s date

of birth O PID

- 7

39 Insurance Coverage Patient‟s type

of insurance

coverage O TBD This data element is to capture a high

- level description of insurance,
such as Medicare, Medicaid, Private Insurance, and Self

pay. IN1

- 15

40 Diagnosis

Date/Time Date/Time

associated with the Diagnosis / Injury Code O DG1

- 5Page 117

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 3 : F U T U R E D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

41 Vital Sign

related

data

elements Data elements

that are related to the patient‟s vital sign

measurements O TBD Vital sign elements for

consideration are heart rate, respiratory rate, blood pressure (SBP/DBP), BMI, pulse rate, height, and weight. OBX Segment(s)

42 Observation, symptoms,

and clinical findings Data

element(s) describing the
observation, symptoms, and clinical findings for a patient‟s

condition O TBD This data element(s) has the potential to be large since it may be a full nurse / physician dictation.

This may be a group of data

elements rather than a single data element. OBX Segment(s)

43 Severity of

illness

related data

elements Data elements

that are used

to assess the severity of the O TBD Data elements for

consideration include
ventilated indicators,
intubated indicators, and OBX Segment(s)Page 118

PHIN Messaging Guide for Syndromic Surveillance 

### T A B L E 4

- 2

- 3 : F U T U R E D A T A E L E M E N T S

# Data

Element

Name Description of

Field Usage Cardinality 

### Value Set /Value Domain Implementation Notes Recommended HL7

Location

patient‟s illness desaturation.

44 Highest Temperature Highest

recorded temperature, including units O TBD Highest temperature may provide a more accurate value in classifying certain
conditions, such as pandemic flu.

Units of the temperature

should also be included. OBX Segment

Units of measure (in the

OBX

- 6) should be included defining the numeric valu e.

45 Procedure

Code Procedure

code to identify

the health

intervention provided to the patient O TBD Procedure code is useful in distinguishing whether the patient received a

vaccination for a disease or

treatment for the actual

disease.

This is applicable to primary care settings. PR1

- 3Page 119

PHIN Messaging Guide for Syndromic Surveillance 

## 5 EXAMPLES

A minimal amount of data was intentionally used to provide emphasis on the Syndromic

Surveillance data elements of interest.



## 5.1 A04 EMERGENCY DEPART MENT REGISTRATION; N O UPDATES ;

ACKNOWLEDGEMENT REQU ESTED

In the following example, a non

- Hispanic white female, Ann A. Everyperson, 67 years old, visits the Midland Health Center emergency department with an infected abrasion on her

forearm. The Medical Record Number, 20060012168, is sent for the patient identifier. Since this is an Emergency Department visit, PV1

- 44 reflects the time the patient registered in the Emergency Department. The Admit Reason is coded in ICD

- 9. The original provider of the data, Midland Health Center, is captured in the EVN

- 7. The facility location and visit type was provided by Midland Health Center.

Midland Health Center has requested acknowledgement of the mess age by the State

Public Health

. A sample acknowledgement is included.

MSH|^~ \ &|| MIDLAND HLTH

CTR^9876543210^NPI | State_SS | State_Public_Health |201102091114||ADT^ A04^ADT_A01 |201102091114

-

0078|P|2.5.1<cr>

EVN||201102091114|||||MIDLAND HLTH CTR^9876543210^NPI<cr>

PID|1|| 20060012168^^^^MR ^MIDLAND HLTH CTR&9876543210&NPI|| EVERYPERSON^ANN^A ^^^^L ||| F ||2106

-

3^ White ^CDCREC|^^^ 13 ^30341 ^USA^C ||||||||||| 2186

- 5 ^ Not Hispanic ^CDCREC<cr>

PV1||E||E||||||||||1|||||20110209_0064^^^^VN|||||||||||||||||||||||||20110217144208<cr>

PV2|||9131^ABRASION FOREARM

- INFECT^I9CDX<cr>

OBX|1|XAD|SS002^TREATING FACILITY

LOCATION^PHINQUESTION|| ^^^ 13 ^30341^USA^C ||||||F|||201102091114<cr>

OBX|2 |CWE|SS003^FACILITY / VISIT TYPE^PHINQUESTION|| 1108

- 0^EMERGENCY

DEPARTMENT^HSLOC ||||||F|||201102091114<cr>

OBX|3 |NM|21612

- 7 ^AGE TIME PATIENT REPORTED^LN|| 67|a^YEAR^UCUM |||||F|||201102091114<cr>Page 120

PHIN Messaging Guide for Syndromic Surveillance 

### Continuing the example above, State Public Health needs to acknowledge successful receipt (AA

– Application Accept) of the above message (Message ID

- 201102091114

- 0078) from Midland

Health Center

.

MSH|^~ \ &| State_SS|State_Public_Health|| MIDLAND HLTH

CTR^9876543210^NPI |201102091119|| ACK ^ A04^A CK | ACK

- 201102091119

- 0001 |P|2.5.1<cr>

MSA| AA | 201102091114

- 0078 <cr>



## 5.2 A04 EMERGENCY DEPART MENT REGISTRATION FO LLOWED BY A08

UPDATE

In the next example, a non

- Hispanic black male, 52 years old, visits the City General Hospital emergency department with cough and ear pain. City General Hospital does not transmit Medical Record Number, so it uses a unique patient identifier of 95101100001,

in PID

- 3. The chief complaint was sent as free text and an admitting diagnosis was sent in the DG1 segment, coded in ICD

- 9.

MSH|^~ \ &||CITY GENL HOSP^0133195934^NPI|||20110217144317||ADT^ A04^ADT_A01 |E100648329|P|2.5.1<cr>

EVN||20110217144317 |||||CITY GENL HOSP^0133195934^NPI <cr>

PID|1||95101100001^^^^PI||~^^^^^^U|||M||2054

- 5^ Black or African American ^CDCREC|^^^29 ^65101||||||||||| 2186

-

5 ^ Not Hispanic ^CDCREC<cr>

PV1||E||E||||||||||1|||||8399193^^^^VN|||||||||||||||||||||||||20110217144208<cr>

OBX|1|NM|21612

- 7 ^AGE TIME PATIENT REPOR TED^LN||52|a^YEAR^UCUM|||||F|||201102171443 <cr>

OBX|2|CWE|8661

- 1^CHIEF COMPLAINT:FIND:PT:PATIENT:NOM:REPORTED^LN||^^^^^^^^ HEADACHE FOR 2

DAYS <cr>

DG1|1|| 4739^CHRONIC SINUSITIS NOS^I9CDX ||A<cr>



### Continuing the example above, a non

- Hispanic black male, 52 years old, visits the City General Hospital emergency department with cough and ear pain. City General Hospital wants to updatePage 121

PHIN Messaging Guide for Syndromic Surveillance 

### the receiving system with new information about the same patient and the same visit.

The Visit Number and Admit Date/Time hav e not changed; but, the Message Date/Time and Message Control ID have. So, an A08 message is used to transmit the additional information: Temperature, Blood Oxygen Level, and Final Diagnosis.

MSH|^~ \ &||CITY GENL HOSP^0133195934^NPI||| 20110217145139 ||ADT^ A08^ADT_A01 | E100648353 |P|2.5.1<cr>

EVN||20110217144317|||||CITY GENL HOSP^0133195934^NPI<cr>

PID|1||95101100001 ^^^^PI^CITY GENL HOSP&0133195934&NPI || ~^^^^^^U |||M|| 2054

- 5^Black or African

American^CDCREC |^^^ 29 ^65101|| |||||||||2186

- 5 ^ Not Hispanic ^CDCREC<c r>

PV1||E||E||||||||||1|||||8399193 ^^^^VN |||||||||||||||||||||||||20110217144208<cr>

OBX|1|NM|21612

- 7 ^AGE TIME PATIENT REPORTED^LN||52|a^YEAR^UCUM|||||F||| 20110217145139<cr>

OBX|2|CWE|8661

- 1^CHIEF COMPLAINT:FIND:PT:PATIENT:NOM:REPORTED^LN||^^^^^^^^ HEADACHE FOR 2

DAYS <cr>

OBX|3 |NM| 11289

- 6^BODY

TEMPERATURE :TEMP:ENCTRFIRST:PATIENT :QN ^LN||100.1|[degF]^FARENHEIT^UCUM||A|||F||| 201102171451

39<cr>

OBX|4 |NM|59408

- 5 ^ OXYGEN SATURATION:MFR:PT:BLDA:QN:PULSE

OXIMETRY ^LN||91|%^PERCENT^UCUM||A|||F||| 20110217145139 <cr>

DG1|1||4739^CHRONIC SINUSITIS NOS^I9CDX|||A<cr>

DG1|2||04100^STREPTOCOCCUS UNSPECF^I9CDX|||F<cr>



## 5.3 A04 EMERGENCY DEPART MENT REGISTRATION; A 01 INPATIENT

ADMISSION; A03 DISCHARGE INCLUDING PATIENT DE ATH

I 

### n the next example, a non

- Hispanic white female, 43 years old, visits the Other Regular Medical Center emergency department with a chief complaint of a stomachache

. The chief complaint was sent as free text.Page 122

PHIN Messaging Guide for Syndromic Surveillance MSH|^~ \ &||OTHER REG MED

CTR^1234567890^NPI|||201102171531||ADT^ A04 ^ADT_A01 |201102171531956|P|2.3.1<cr>

EVN||201102171531<cr>

PID|1||FL01059711 ^^^^PI || ~^^^^^^U |||F|| 2106

- 3^White^CDCREC |^^^ 12 ^33821|||||||||||2186

- 5 ^ Not

Hispanic ^CDCREC<cr>

PV1||E||E||||||||||7|||||V20220217

- 00274 ^^ ^^VN |||||||||||||||||||||||||201102171522<cr>

PV2||| 78907^ABDOMINAL PAIN, GENERALIZED^I9CDX<cr>

OBX| 1 |HD|SS001^TREATING FACILITY IDENTIFIER^PHINQUESTION||OTHER REG MED

CTR^1234567890^NPI ||||||F|||201102171531 <cr>

OBX|2 |CWE|8661

- 1^CHIEF COMPLAINT :FIND:PT:PATIENT:NOM:REPORTED^LN||^^^^^^^^ STOMACH

ACHE||||||F|||201102171531 <cr>

OBX| 3 |NM|21612

- 7 ^AGE TIME PATIENT REPORTED^LN||43|a^YEAR^UCUM|||||F||| 201102171531 <cr>

DG1|1||78900^ABDMNAL PAIN UNSPCF SITE^I9CDX|||A<cr>



### Continuing the example, the same non

- Hispanic white female, 43 years old, visits the Other Regular Medical Center emergency department with a chief complaint of a

stomach ache. The patient is suspect for appendicitis and is admitted as an inpatient. The patient has also reported that she has had a stomach ache since the 15 th 

### of February. The patient class (PV1.2) is changed to Inpatient. Admit Date/Time (PV1.44) is updated with the admission date and time.

In this particular case, visit number (PV1.19) has remained the same. However, it is recognized that some insurance companies require the visit number to be changed when a patient is admitted from the Emergency Department.

MSH|^~ \ &||OTHER REG MED

CTR^1234 567890^NPI|||201102171658||ADT^ A01 ^ADT_A01 |201102171658076|P|2.3.1<cr>

EVN||201102171658<cr>

PID|1||FL01059711 ^^^^PI || ~^^^^^^U |||F|| 2106

- 3^White^CDCREC |^^^ 12 ^33821|||||||||||2186

- 5 ^Not

Hispanic^CDCREC<cr>Page 123

PHIN Messaging Guide for Syndromic Surveillance PV1|| I ||E||||||||||7||||| V20220217

- 00274 ^^^^VN |||| ||||||||||||| 09 |||||||| 201102171656 <cr>

PV2||| 78907^ABDOMINAL PAIN, GENERALIZED^I9CDX<cr>

OBX| 1 |HD|SS001^TREATING FACILITY IDENTIFIER^PHINQUESTION||OTHER REG MED

CTR^1234567890^NPI ||||||F|||201102171531 <cr>

OBX|2 |CWE|8661

- 1^CHIEF COMPLAINT :FIND:PT:PATIENT:NOM:REPORTED^LN||^^^^^^^^ STOMACH

ACHE||||||F|||201102171531 <cr>

OBX|3 |NM|21612

- 7 ^AGE TIME PATIENT REPORTED^LN||43|a^YEAR^UCUM|||||F||| 201102171531 <cr>

OBX|4 |NM| 11289

- 6^ BODY

TEMPERATURE:TEMP:ENCTRFIRST:PATIENT:QN ^LN||99.1|[degF]^FARENHEIT^UCUM||A|||F||| 201102171658<

cr>

OBX|5 |NM|59408

- 5 ^ OXYGEN SATURATION:MFR:PT:BLDA:QN:PULSE

OXIMETRY ^LN||95|%^PERCENT^UCUM||A|||F||| 201102171658<cr>

OBX|6 |TS| 11368

- 8^ ILLNESS OR INJURY ONSET DATE AND

TIME:TMSTP:PT:PATIENT:QN ^LN||20110215||||||F||| 201102171658<cr>

DG1|1||78900^ABDMNAL PAIN UNSPCF SITE^I9CDX|||A<cr>

DG1|2||5409^ACUTE APPENDICITIS NOS^I9CDX|||W <cr>



### Continuing the example, the same non

- Hispanic white female, 43 years old, visits the Other Regular Medical Cente r emergency department with a chief complaint of a

stomach ache. The patient has expired and this is indicated in PV1.36 (Code=20). A final diagnosis is also sent. It is also indicated by the “Y” in PID

- 30 and the Date and Time of

Death in PID

- 29. The discharge date/time (PV1.45) is sent with the A03 message type.

MSH|^~ \ &| |OTHER REG MED

CTR^1234567890^NPI|||201102172334||ADT^ A03^ADT_A03 |201102172334640|P|2.3.1<cr>

EVN||201102172334

PID|1||FL01059711 ^^^^PI || ~^^^^^^U |||F|| 2106

- 3^White^CDCREC |^^^ 12 ^338 21|||||||||||2186

- 5 ^Not

Hispanic^CDCREC||||||| 201102172334 |Y <cr>Page 124

PHIN Messaging Guide for Syndromic Surveillance PV1||I||E||||||||||7|||||V20220217

- 00274 ^^^^VN ||||||||||||||||| 20 ||||||||201102171656| 201102172334 <cr>

PV2||| 78907^ABDOMINAL PAIN, GENERALIZED^I9CDX<cr>

OBX|1 |HD|SS001^TREATING FACILITY IDENTIFIER^PHINQUESTION||OTHER REG MED

CTR^1234567890^NPI ||||||F|||201102171531 <cr>

OBX|2 |CWE|8661

- 1^CHIEF COMPLAINT:FIND:PT:PATIENT:NOM:REPORTED^LN||^^^^^^^^ STOMACH

ACHE||||||F|||201102171531 <cr>

OBX|3 |NM|21612

- 7 ^AGE TIME PATIENT REPORTED^LN||43|a^YEAR^ UCUM|||||F||| 201102171531 <cr>

OBX|4 |NM| 11289

- 6^ BODY

TEMPERATURE:TEMP:ENCTRFIRST:PATIENT:QN ^LN||99.1|[degF]^FARENHEIT^UCUM||A|||F||| 201102171658<cr>

OBX|5 |NM|59408

- 5 ^ OXYGEN SATURATION:MFR:PT:BLDA:QN:PULSE

OXIMETRY ^LN||95|%^PERCENT^UCUM||A|||F||| 201102171658 <cr>

OBX|6 |TS| 11368

- 8^ILLNESS OR INJURY ONSET DATE AND

TIME:TMSTP:PT:PATIENT:QN^LN||20110215||||||F||| 201102171658<cr>

DG1|1||78900^ABDMNAL PAIN UNSPCF SITE^I9CDX|||A<cr>

DG1|2||5409^ACUTE APPENDICITIS NOS^I9CDX|||W<cr>

DG1|3||5400^AC APPEND W PERITONITIS^I9CDX|||F<cr>



## 5.4 A01 INPATIENT ADMISS ION; NO UPDATES

In the following example, a Hispanic white male, age currently 20 , is admitted as an

inpatient to the Mid

- Co Health Center emergency department after falling down the stairs.

The Medical Record Number is sent for the patient identifier and the patient account

number is sent for the visit number.

MSH|^~ \ &||MID

- CO HLTH CTR^9876543210^NPI|||201110090314||ADT^ A01^ADT_A01 |201110090314

-

0017|P|2.3.1<cr>

EVN||201110090314<cr>Page 125

PHIN Messaging Guide for Syndromic Surveillance PID|1||MD01059711^^ ^ADMITTING^MR^MID

- CO HLTH CTR^9876543210^NPI|| ~^^^^^^U |||M|| 2106

-

3^White^CDCREC |^^^ 24 ^21502|||||||||||2135

- 2 ^ Hispanic or Latino ^CDCREC<cr>

PV1|| I ||E|||||||||| 6 |||||20111009_0034 ^^^^AN^MID

- CO HLTH CTR&9876543210&NPI

|||||||||||||||||||||||||20111009025915< cr>

OBX|1|NM|21612

- 7 ^AGE PATIENT QN REPORTED^LN|| 2 0| a^YEAR^UCUM |||||F||| 201102171531<cr>

OBX|2 |HD|SS001^TREATING FACILITY IDENTIFIER^PHINQUESTION||MID

- CO HLTH

CTR^9876543210^NPI ||||||F|||201102171531 <cr>

DG1|1||E8809^FALL ON STAIR/STEP NEC^I9CDX|||A<cr>



## 5.5 BATCH EXAMPLE

In the following example, Mid

- Co Health Center sends their syndromic data to their state

public health authority. Mid

- Co sends the messages that have gathered over the last 12

hour period in batch message format. There are 240 messages.

FHS |^~ \ &<cr>

BHS|^~ \ &|ER1| MID

CO_HLTH_ CTR^9876543210^NPI |SS_APP^2.16.840.1.113883.19.3.2.1^ISO|SPH^2.16.840.1.113883.19.3.2^ISO|201

10123123558<cr>

MSH|^~ \ &| ER1 |MID

- CO HLTH

CTR^9876543210^NPI| SS_APP^2.16.840.1.113883.19.3.2.1^ISO|SPH^2.16.840.1.113883.19.3.2^ISO

| 20110123003938 ||ADT^ A01^ADT_A01 | ER1

- 20110123

- 001 |P|2.5 .1<cr>

... (Continue 240 messages)...

BTS|240|Mid

- Co reporting 1

- 23

- 2011: 0000

– 1200 hrs<cr>

FTS|1<cr>Page 126

PHIN Messaging Guide for Syndromic Surveillance 

## 5.6 SAMPLE INTERNATIONAL ADDRESS FORMATS: CONVERTED T O PID

SEGMENTS

5.6.1 C OUNTRIES 

### B ORDERING 

### T HE 

### U NITED 

### S TATES



### 5.6.1.1 Mexico

Super Manzana 3

- 403 [street name + building number

- apartment number]

Puerto Juarez [village]

77520 CANCUN, Q. ROO [postcode + locality name, province abbreviation]

MEXICO [country name]

Example PID segment:

PID|1||MX01059711|| ~^^^^^^U |||M|||Super Manzana 3

- 403^Puerto Juarez^CANCUN^Q. ROO^77520^MEX<cr>



### 5.6.1.2 C anada

111 FAIRFORD STREET EAST

MOOSE JAW SK S6H 2X1

CANADA

Example PID Segment :

PID|1||CA01059711|| ~^^^^^^U |||M|||111 FAIRFORD STREET EAST^^MOOSE JAW^SK^S6H 2X1^CAN<cr>



## 6 MISCELLANEOUS

6.1 PHIN VOCABULARY SERV ICES

Public Health Information Network (PHIN) Vocabulary Services seek to promote the use of

standards

- based vocabulary within PHIN systems and foster the use and exchange of

consistent information among public health partners. The PHIN Vocabulary Access and

Di stribution System (VADS) and the PHIN Message Quality Framework (MQF) support these

standards

.

PHIN MQF and PHIN VADS will be integrated to support the real time validation of electronic

messages supporting Syndromic Surveillance Meaningful Use Measures.Page 127

PHIN Messaging Guide for Syndromic Surveillance 

### The vocabulary codes that are carried in CE and CWE fields in the HL7 message have their

terminology indicated by the appropriate HL7 Table 0396 entry, the complete list of which may

be accessed at http://www.hl7.org/Special/committees/vocab/table_0396/index.cfm

. Vocabulary that is carried in fields of datatype IS and ID does not have a code system carried

in the message instance; these codes are intended to be populated in the identified tables. In

order to facilitate the maintenance of these tables, PHIN VADS may be used for the content of

these tables, each of which is associated with a PHIN value set. The names of these value

sets are included in the data element references a bove.

6.1.1 PHIN V OCABULARY AND 

### D ISTRIBUTION 

### S YSTEM



### PHIN VADS is a W eb

- based enterprise vocabulary system for accessing, searching, and

distributing value sets associated with HL7 implementation guides. Vocabulary associated with

Syndromic Surveillance messagin g guide can be downloaded from PHIN VADS at

http://phinvads.cdc.gov

. A link is provided for the Syndromic Surveillance view here: Syndromic Surveillance

6.1.2 PHIN M ESSAGE 

### Q UALITY 

### F RAMEWORK



### The Message Quality Framework (MQF) is a flexible framework of services and utilities

designed to assis t public health partners with preparing and communicating quality, standard

electronic messages as defined by the applicable messaging, vocabulary, and programmatic

standards. PHIN MQF can be accessed at https://phinmqf.cdc.gov/