This document articulates the minimum functionality and operational processes necessary for PCA-compliant alerting systems, but does not preclude a system from incorporating additional functionality beyond what this document addresses.Definition o f other terms used in this document are provided in Appendix 1: Definition o f Terms.#
1. R esolve inconsistency with EDXLDistribution.distributionType elem ent. Value will a lw a ys be "Report"
for cascad e m essag es and "A c k " for cascad e acknowledgem ent m essag es.
2. Rem oved the EDXLD istribution.distributionReference from Table 6.1.1 (C a sca d e Alert "Container"), the reference attribute will only be sent in C A P payload.

# INTRODUCTION
The CDC Public Health Information Network (PHIN) is a national initiative to improve the capacity o f public health to use and exchange information electronically by promoting the use o f standards, defining functional and technical requirements. PHIN Communication and Alerting (PCA), one component o f PHIN, is a specification o f public health alerting capabilities, with an emphasis on interoperability o f partners' systems. Alerting in this context means the functionality necessary to manage time-critical information about public health events, send it in real time to personnel and organizations that must respond to and mitigate the impact o f these events, and verify and monitor delivery o f this information. Systems that provide PC A functionality support these capabilities, integrate them with the organization' s other public health information systems and processes, and support interoperability with partners' systems.
PC A is not identical to, or a replacement for, the Health Alert Network (HAN). P C A is a technical specification for alerting. H AN is a public health program that performs alerting. M ost organizations with H AN systems are in the process o f moving them toward compliance with the PCA specification.

# Ob j e c t i v e s
The objective o f this PHIN Partner Communication and Alerting Implementation Guide is to provide a comprehensive description o f the functional aspects o f public health alerting.
To perform alerting in a PHIN-compliant manner, systems must process, send, and manage alerts in a manner that conforms to the requirements o f this guide.
This Implementation Guide defines functional and technical specifications for systems that support PHIN Communication and Alerting (PCA).
Among other things, this document defines how the following technical standards have been adopted for use by PCA:
- Emergency Data Exchange Language (E D X L ) V 1.0 Distribution Element - Common Alerting Protocol (CAP) V 1.1
- Simple Object A ccess Protocol (SOAP)
This document is not intended as a tutorial for E D X L , CAP, X M L, or SOAP. The reader is expected to have a basic conceptual understanding o f m essaging and X M L in order to use this document.

# Au d i e n c e
This guide is designed to be used by analysts who require a better understanding o f the business o f PHIN Communication and Alerting, and by developers and implementers o f PHIN-compliant alerting systems. Understanding and using this guide is a key factor in establishing PHIN compatibility.

# Do c u m e n t S t r u c t u r e
This document contains the following major sections.
- Background and Problem Domain: D escribes the underlying business problem o f cross-jurisdictional alerting. Explains the requirement for some uniformity in public health alerting systems.

# PHIN Communication and Alerting Implementation Guide
Version: 1.3
- Application Requirements: Defines the standard functional behaviors and technical standards necessary to public health alerting systems.
- P C A Alert Attributes: Defines the set o f alert attributes with which all PCA alerting systems must be semantically compatible, their vocabulary and semantics, and how alerting systems must populate, use, manage and process each attribute.
- Vocabulary and Valid Value Sets: Defines the vocabulary employed within the PC A domain and the values that P C A alert attributes can take.
- P C A Cascade Alert Message Formats: Defines the cascade alert m essage formats and the mapping o f P C A alert attributes to these formats.
- Appendices: Define further the terminology used in this document and provide expanded examples o f agency identifiers and audience specifications. Standard attributes, attribute names, attribute vocabularies (value sets), and vocabulary semantics for P C A are defined and referenced throughout this document. Public health alerting systems are not required to use these standard attribute names and vocabularies internally; they may use other, preferred local attribute names and vocabularies. However, whenever alerts and information about alerts must be conveyed across jurisdictional boundaries, the standard set o f attributes and vocabularies must be used. Therefore, the alert information that a system manages must semantically correspond to, and be capable o f translation into, the standard attributes and vocabularies. I f the information used internally by an alerting system can be translated in this way, then the alerting system is said to " support" the standard attributes and vocabularies, and meets the PCA requirement for attributes and vocabularies.
Throughout this document, attribute names appear italicized. For example, the name o f the alertIdentifier attribute is italicized in this sentence.

# De f i n i t i o n : Al e r t
For purposes o f this document and for purposes o f discussions about PHIN or PCA, the term " alert" means a real-time, one-way communication sent by a PHIN partner organization for legitimate business purposes, to a collection o f people and organizations with which the partner has a business relationship, in order to notify them o f an event or situation o f some importance. The term is meant to include communications that are urgent as well as those that are routine.
A " health alert" is one category o f the broader term " alerts." "Health alerts" are communications specifically about health events that are proactively distributed in order to mitigate the extent or severity o f the event.

# De f i n i t i o n : Pu b l i c h e a l t h a l e r t i n g s y s t e m
For purposes o f this document and for purposes o f discussions about PHIN or PCA, the terms " public health alerting system" and " alerting system" mean a system, or a collection o f systems and processes, used by a PHIN partner organization to compose and manage alerts and deliver them to designated recipients in a manner consistent with the PCA requirements set forth here.
An alerting system delivers alerts to recipients using whatever methods o f communication can be supported in practice by the system and by the organization, that are sufficient to meet functional and performance requirements, and that are appropriate to the event. The vocabulary and methods for conveying alert information to recipients can vary based upon circumstance, delivery method, and the capabilities o f various communication device types, as will be detailed later in this document.
PC A functionality may be implemented using a combination o f one or more information systems and manual business processes. The terms " public health alerting system" and " alerting system" within this document are intended to mean the combination o f all o f the systems and processes employed by a given PHIN partner to implement the PCA functionality. These terms do not imply any requirement for a single information system that performs all o f the functions defined.
Further, there is no requirement that a PHIN partner organization own or operate its own alerting system. Under many circumstances it may be practical or preferable for organizations to share the use o f a system. For example, a city health department might reasonably make use o f an alerting system operated by the state health department within whose jurisdiction it lies, or a health department may make use o f an alerting system operated by another government department. The requirement is that PHIN partner organizations have an alerting capability, through whatever arrangement, that meets the PC A specifications.
Re q u i r e m e n t f o r u n i f o r m i t y i n p a r t n e r c o m m u n i c a t i o n s a n d a l e r t i n g
A primary objective o f PHIN is to establish the ability for public health organizations to communicate and work effectively with each other, especially during emergencies. It is important that public health alerting systems achieve a basic level o f standardization with respect to functional capability, behavior, and terminology. Because many, i f not most, public health events are cross-jurisdictional in scope, any individual working within any jurisdiction may be subject to receiving alerts originating from many different health departments or public health jurisdictions. In the event o f an emergency or time-critical event, a certain degree o f uniformity o f alert m essage structure, vocabulary, semantics, and process is critical to clarity and accuracy in communications and to reducing the risk o f communications being mismanaged or misunderstood across multiple organizations and jurisdictions. One objective o f PCA, therefore, is that alerting systems be sufficiently consistent in the type o f information sent to recipients, be semantically consistent with a standard set o f attributes and vocabularies, be consistent as to how alerting terminology corresponds to system behaviors and human processes, and be consistent in the type o f information stored for historical reporting and auditing purposes.
This PCA Implementation Guide therefore addresses:
- a common set o f PCA attributes and vocabularies;
- the content o f information in human-readable alerts;
- the correspondence o f PC A attributes to system functionality;
- the requirements for persistent storage o f information about alerting activities; and
- the composition and interpretation o f system-to-system (Cascade) alert m essages.
At the same time, another objective o f PCA and PHIN in general is that each partner has the maximum possible leeway in choosing an alerting solution that works for their particular circumstance and environment.

# PHIN Communication and Alerting Implementation Guide
Version: 1.3

# APPLICATION REQUIREMENTS

# Al e r t i n g
A PHIN partner organization' s alerting system must be able to create and manage alerts and send them to people and organizations that participate in public health activities within the organization' s jurisdiction.
In particular, alerting systems must be able to send alerts on a 24/7/365 basis to those key personnel and organizations that are critical to the jurisdiction' s emergency response plan. The identification o f these " key personnel and organizations" is the responsibility o f the jurisdiction.
Alerting systems must be able to " broadcast" alerts to all recipients within the scope o f the system, but also target alerts to and limit distribution to specific audiences as circumstances require.
Alerting systems must support a variety o f communication device types, in order that real time communications with these people and organizations will be practical and effective, including emergency and after-hours communications.
Alerting systems must support the ability for alert recipients to confirm that they have received and acknowledge an alert. This acknowledgement must involve conscious deliberate action on the part o f the recipient, such as pressing a specific key on a telephone (i.e. the fact that a phone went " off-hook" is not a confirmation that an intended recipient is aware o f an alert). The alerting system must be able to record each recipient' s acknowledgement and report it.
Alerting systems must be able to display or report delivery status information to the operator o f the system, in near-real time, that includes the number o f recipients targeted to receive an alert and the number that have received it, or, when confirmation is required, that have confirmed receipt.

# S e c u r e C o m m u n i c a t i o n
Alerting systems must provide a means o f secure communication for delivery o f alerts containing sensitive content. The term " secure communication." in the context o f PCA, refers to methods used to ensure that the restricted information is delivered to and is available to only the intended recipients; it refers to the fact that a communications method is secured, but does not refer to the technology used to make the method secure. Secure communication involves (1) the ability to restrict distribution o f the alert and restrict access to the sensitive content, (2) the ability to authenticate the identity o f a user before delivering the sensitive content, and (3) a m essage transport that is not easily open to unauthorized access. For example:
- Standard SM TP e-mail should not be used for secure communication because it is travels the public Internet in plain text and is notoriously easy to " sn iff', does not protect against unauthorized access to m essage content, and does not reliably restrict access to only the intended recipients; - Standard SM TP email entirely within a network and email system administered by the partner organization, coupled with security controls governing access to the email system, may be is suitable for secure communication; - Fax transmission is unsuitable for secure communication because there is no recipient authentication or control over who might pick up the fax;
- Delivery by land-line and digital phone networks can be used in conjunction with a recipient authentication method, e.g. requiring entry o f a PIN number.
Alerts with sensitive content must:
- be tagged as sensitive by having the sensitive attribute set to " Sensitive" ;
- be sent using a secure communication method. Sensitive content may be defined as content whose inappropriate distribution or use could compromise the public health organization' s effectiveness or reputation. Alerting systems must be able to distinguish secure versus non-secure methods o f communication.

# Al e r t At t r i b u t e s a n d Vo c a b u l a r i e s
Standard attributes and vocabularies for describing the parameters o f an alert are critically important when exchanging alerting information across jurisdictions. PHIN Communication and Alerting, to the maximum extent possible, makes use o f standard vocabularies and data structures already defined by standards development organizations.
Public health alerting systems must support, not necessarily use, the standard attribute names and vocabularies defined in this document (see section 1.4). The attributes that alerting systems must support are detailed in Table 4.2. The vocabularies that alerting systems must support are detailed in and Table 5.1.

# Al e r t Fo r m a t
A degree o f standardization o f alert format helps to ensure that public health organizations can communicate effectively within their jurisdictions and with other jurisdictions, especially during emergencies.
Each alert should address a single issue or health event, rather than combining multiple issues and events into one alert.
An alerting system should render alert content in a manner appropriate to the characteristics o f the device on which the recipient will receive it. For purposes o f discussion o f PCA, the following content forms are defined:
- long text -content rendered in a form appropriate for email, fax, or web presentation; - short text -content rendered in a form appropriate for SM S and pagers;
- voice text -content rendered in a form appropriate for voice delivery or automated voice delivery by phone.
Alert format requirements vary depending on the content form.
Generally, all alerts must include the following attributes:
- alertIdentifier -a unique m essage identifier;
- agencyName -the official name o f the agency originating the alert; or where text size is constrained, agencyAbbreviation -an abbreviated representation o f agency name;
- sendTime -the date and time the alert was initiated;
- severity -an indication o f the severity o f the event;
- title -the title or " subject line" o f the alert;
- message -the m essage text.
Under some circumstances alerts must also include additional information:
- sensitive -i f the alert contains sensitive content, this fact must be conveyed to recipients.