Service Functional Model
Specification
Unified Communications Service
(UCS)
Version 0.3
12 AUGUST 2013
Project Lead
Emory Fry, MD
Editor
XXXXXXX
Authors
Jerry Goodnough, Emory Fry, MD
Preface
Notes to Readers
This document is the Service Functional Model for the Unified Communication Service (UC),
which is specified under the Service Development Framework process under the auspices of the
Healthcare Services Specification Project (HSSP). Further context is given in the overview
section below, but one key point to note is that the SFM provides a Service Interface
specification, NOT the specification of a Service implementation. This is a critical distinction in
terms of Service Oriented Architecture. There could be many different ways of implementing all
or part of the functionality to support the behavior described in this specification.
Acknowledgements
Important Notes
A. If you are the individual that downloaded or ordered this HL7 Standard,
specification or other work (in each and every instance "Material"), the following
describes the permitted uses of the Material.
B.
If you are NOT such individual, you are not authorized to make any use of the
Material. To obtain an authorized copy of this Material, please visit
http://www.hl7.org/implement/standards/index.cfm.
C.
If you are not an HL7 Organizational Member, the following are your permitted uses
of this Material:
1. Read and Copy License Only. HL7 hereby grants you the right, without charge,
to download and copy (for personal use only) this Material for study purposes only.
This license grant does not include the right to sublicense or modify the Material, or
to implement the Material, either in whole in part, in any product or service.
Please see http://www.hl7.org/legal/ippolicy.cfm for the full license terms governing
the Material.
D.
If you are an HL7 Organizational Member, the following are your permitted uses of
this Material.
1. Implementation License Terms.
1.1 Definitions. As used in this Agreement, the following terms shall have the
following definitions:
"Compliant Product" is a product or service that implements Material that is an
HL7 Specification in whole or in part.
"End User" is a company, entity or individual that is the ultimate purchaser or
licensee from Licensee of a Compliant Product.
1.2 License. In consideration of becoming an Organizational member of HL7 and
continuing to pay the appropriate HL7 Organizational membership fees in full, HL7
hereby grants to you without additional charge, on a perpetual (except as provided for
in the full license terms governing the Material), non- exclusive and worldwide basis,
the right to (a) download, copy (for internal purposes only) and share this Material
with your employees and consultants for study purposes, and (b) utilize the Material
for the purpose of developing, making, having made, using, marketing, importing,
offering to sell or license, and selling or licensing, and to otherwise distribute,
Compliant Products, in all cases subject to the conditions set forth in this Agreement
and any relevant patent and other intellectual property rights of third parties (which
may include members of HL7). No other license, sublicense, or other rights of any
kind are granted under this Agreement.
Please see http://www.hl7.org/legal/ippolicy.cfm for the full license terms governing the
Material.
Table of Contents
1 Overview ....................................................................................................................... 6
1.1 Introduction and Scope ................................................................................................. 6
1.1.1 HL7-OMG Healthcare Services Specification Project (HSSP) .............................. 6
1.1.2 Service Definition Principles .................................................................................. 7
1.2 Overall disclaimers ................................................................................................. 8
1.3 Readers Guide ......................................................................................................... 8
2 Executive Summary ...................................................................................................... 8
2.1 Service Overview .................................................................................................... 8
2.1.1 Service Description and Purpose ............................................................................ 8
2.1.2 Scope ....................................................................................................................... 9
2.2 The Reason Why The Service Is Necessary ........................................................... 9
2.3 Context of this SFM within HSSP Roadmap........................................................ 10
2.4 Structure of the Service ......................................................................................... 10
2.5 Implementation Considerations ............................................................................ 11
2.6 Deployment Scenarios .......................................................................................... 12
2.6.1 Intra-organizational Deployment Model............................................................... 12
3 Business Storyboards .................................................................................................. 13
4 Assumptions and Dependencies ................................................................................. 13
5 Detailed Functional Model for each Interface ............................................................ 14
5.1 Domain Model ...................................................................................................... 14
5.2 Abstract Entities .................................................................................................... 15
5.2.1 Functional Entities ................................................................................................ 15
5.2.2 Addressing-Related Informational Entities........................................................... 16
5.2.3 Message-Related Informational Entities ............................................................... 16
5.2.4 Conversation-Related Informational Entities ....................................................... 18
5.2.5 Exception-Related Informational Entities............................................................. 19
5.2.6 Logging-Related Informational Entities ............................................................... 19
5.2.7 User-Related Informational Entities ..................................................................... 20
5.3 Client Interface...................................................................................................... 20
5.3.1 Addressing and Content Production Functionality ............................................... 20
5.3.2 Communication Channel Setup Functionality ...................................................... 24
5.4 UCS Client Interface ............................................................................................. 26
5.5 Alerting Interface .................................................................................................. 27
5.6 UCS Alerting Interface ......................................................................................... 29
5.7 Adapter Interface .................................................................................................. 30
5.8 UCS Adapter Interface .......................................................................................... 31
5.9 Management Interface .......................................................................................... 33
6 Profiles ........................................................................................................................ 36
6.1 Introduction ........................................................................................................... 36
7 System Interaction Details [Optional] ........................................................................ 37
8 Recommendations for Technical RFP Issuance ......................................................... 38
9 Appendix A - Relevant Standards............................................................................... 38
10 Appendix B - Glossary................................................................................................ 39
11 Appendix C - HL7 EHR Functional Model Traceability............................................ 40
12 Appendix D - Relationship to Information Content ................................................... 40
1 Overview
1.1 Introduction and Scope
The Service Specification Development Framework Methodology is the methodology followed
to define HSSP specifications. The methodology sets out an overall process, and also defines the
responsibilities of the Service Functional Model (SFM). Section 2 sets out the business context
for this particular specification, but firstly it is important to understand the overall context within
which this specification is written, i.e. its purpose from a methodology standpoint.
1.1.1 HL7-OMG Healthcare Services Specification Project (HSSP)
The Healthcare Services Specification Project (HSSP) [http://hssp.wikispaces.com] is a joint
endeavor between Health Level Seven (HL7) [http://www.hl7.org] and the Object Management
Group (OMG) [http://www.omg.org]. The HSSP was chartered at the January 2005 HL7
meeting under the Electronic Health Records Technical Committee, and the project was
subsequently validated by the Board of Directors of both organizations.
The HSSP has several objectives. These objectives include the following:
-
-
To stimulate the adoption and use of standardized “plug-and-play” services by healthcare
software product vendors
To facilitate the development of a set of implementable interface standards supporting
agreed-upon services specifications to form the basis for provider purchasing and
procurement decisions.
To complement and not conflict with existing HL7 work products and activities,
leveraging content and lessons learned from elsewhere within the organization.
Within the process, HL7 has primary responsibility for (1) identifying and prioritizing services as
candidates for standardization; (2) specifying the functional requirements and conformance
criteria for these services in the form of Service Functional Model (SFM) specifications such as
this document; and (3) adopting these SFMs as balloted HL7 standards. These activities are
coordinated by the HL7 Services Oriented Architecture SIG in collaboration with other HL7
committees, which currently include the Vocabulary TC and the Clinical Decision Support TC.
Based on the HL7 SFMs, OMG will develop “Requests for Proposals” (RFPs) that are the basis
of the OMG standardization process. This process allows vendors and other submitters to
propose solutions that satisfy the mandatory and optional requirements expressed in the RFP
while leaving design flexibility to the submitters and implementation flexibility to the users of
the standard. The result of this collaboration is an RFP Submission, which will be referred to in
the HSSP process as a Service Technical Model (STM). HL7 members, content, and concerns
are integral to this process, and will explicitly included in the RFP creation and evaluation
process.
It is important to note that the HL7 SFMs specify the functional requirements of a service, the
OMG RFPs specify the technical requirements of a service, and the STM represents the resulting
technical model, except as specified below. In many cases, SFMs describe an overall coherent
set of functional capabilities and / or define a minimum set of behaviors necessary to guarantee a
minimal level of service in a deployment scenario. These capabilities may be specialized or
subdivided from both functional and informational (semantic) perspectives to provide
conformance “profiles” that may be used as the basis for the OMG RFP process and/or
implemented.
1.1.2 Service Definition Principles
The high level principles regarding service definition that have been adopted by the Services
Specification Project are as follows:
 Service Specifications shall be well defined and clearly scoped and with well understood
requirements and responsibilities.
 Services should have a unity of purpose (e.g., fulfilling one domain or area) but services
themselves may be composable.
 Services will be specified sufficiently to address functional, semantic, and structural
interoperability.
 It must be possible to replace one conformant service implementation with another
meeting the same service specification while maintaining functionality of the system.
A Service at the SFM level is regarded as a system component; the meaning of the term
“(system) component” in this context is consistent with UML usage1.A component is a modular
unit with well-defined interfaces that is replaceable within its environment. A component can
always be considered an autonomous unit within a system or subsystem. It has one or more
provided and/or required interfaces, and its internals are hidden and inaccessible other than as
provided by its interfaces.
Each Service’s Functional Model defines the interfaces that the service exposes to its
environment, and the service’s dependencies on services provided by other components in its
environment. Dependencies in the Functional Model relate to services that have or may in future
have a Functional Model at a similar level; detail dependencies on low-level utility services
should not be included, as that level of design is not in scope for the Functional Model.
The manner in which services and interfaces are deployed, discovered, and so forth is outside the
scope of the Functional Model. However, HSSP Functional Models may reference content from
other areas of HSSP work that deals with architecture, deployment, naming and so forth. Except
where explicitly specified, these references are to be considered informative only. All other
interactions within the scope of the scenarios identified above are in the scope of the Functional
Model.
Reference may be made to other specifications for interface descriptions, for example where an
interface is governed by an existing standard.
1
It is expected that services will be defined, in response to the OMG RFP process, as UML
components, however that level of design is outside the scope of the Functional Model.
1.2
Overall disclaimers
 Examples are illustrative and not normative unless otherwise specified
 The scope of information content of HSSP service specifications is not limited to HL7
content models. At a minimum, however, specifications should provide a semantic profile as
part of its conformance profile to provide support for HL7 content models where applicable.
1.3
Readers Guide
Based upon the nature of your interest, we suggest the following as areas to focus your attention:
AUDIENCE
SECTIONS (IN ORDER OF PRIORITY)
Domain Committees, SME’s
2, 3, 8
Architects, HSSP
6, 5, 8, 7, 4
RFP Submitters
2, 8, 7, 5
2 Executive Summary
2.1
Service Overview
2.1.1 Service Description and Purpose
The Unified Communications Service (UC) is intended to facilitate bi-directional communication
between participants (both SOA services and human participants). It provides for the delivery of
alerts, recommendations, and other notifications using a variety of transport mechanisms to
include, but not limited to, email, SMS, VOIP or Instant Messaging. The service supports
dynamic message routing and/or escalation to ensure that when the intended recipients are not
available, appropriate surrogates can be notified and priority messages can be responded to in a
timely manner.
The field of Communications is undergoing one of the most significant revolutions in its history.
Voice communications have evolved beyond analog POTS phone lines to digital voice-over-IP
(VoIP) systems accessible from a multitude of platforms. New functional capabilities for email,
video conferencing, and instant messaging (IM) are being introduced everyday. Nevertheless,
failure to communicate effectively is a major source of patient dissatisfaction, ineffective
discharge planning, suboptimal transitioning of care, and duplication of services. A service that
automates and unifies human and device communications in a common context promises to help
optimize clinical processes, reduce latency, manage workflows, and eliminating device and
media dependencies that create barriers to effective communication. The implications for cost
avoidance, improved outcomes, and organizational process improvement/change management
are significant.
2.1.2 Scope
The Unified Communication Service will provide for the delivery of alerts, recommendations,
and other notifications using representative transports to include email, SMS, VOIP or other
communication channels. The service will provide for message routing and/or escalation to
ensure that when the intended recipients are not available, appropriate surrogates can be notified
and priority messages can be responded to in a timely manner. In keeping with the approach
used by other HL7 specifications, the Communication Service distinguishes between the
communication modality itself and the payload being communicated. The Service Interface
Specification will provide functional, semantic, and conformance profiles.
The UC Service is focused on communications that originate with, or are consumed by, human
actors, often using hardware devices such as telephones, mobile devices, etc. These payloads can
be clinical or administrative. It is not intended to communicate orders for clinical products or
services, even though healthcare personnel often review these, as these are provided for in the
Ordering Service. Nor does its scope include system messages designed to coordinate or
orchestrate service workflows. Such use cases are clearly within the general domain served by
BPMN, BPEL and other standards.
2.2
The Reason Why The Service Is Necessary
Unified Communications is still an early stage market and technology with vendor products
varying widely in capability and maturity. While standards such as Session Initiation Protocol
(SIP), XMPP and others are beginning to provide consistent and comprehensive functional
capabilities, proprietary vendor-vendor interfaces are still critical in today’s multivendor
environments. As a result, healthcare organizations must pay close attention to interoperability
issues between the different vendor products that are part of their solution set. Despite careful
planning, many will invest in telephony, messaging, presence, and communications-enabled
tools and applications that will rapidly becoming obsolete or limited in their functional impact.
The Unified Communication Service will provide several important benefits. The standard could
expand a vendor’s client base as potential customers will be more inclined to invest in
communication services as they will be provided a degree of insulation from proprietary, vendorspecific interfaces. Given this expansion, a service or tool provider that leverages UCS could
deliver a higher quality service, and lower the price of its services. Because UC can be
implemented as a service wrapper around existing capabilities, a vendor that has an established
client base would be able to continue providing services using existing approaches as well.
Consumers of UC-enabled services will also benefit from a standardized communications service
that effectively integrates the clinical decision support, workflow management, and
administrative systems they will purchase in the future with the end-user devices/tools upon
which their users increasingly depend. UC has emerged as a key tool in the management of
many complex process and workflow challenges. Healthcare technology implementers and
integrators will increasingly focus on improving and monitoring communications when
designing loosely coupled and scalable services. Adopting a standards-based approach to UC,
and utilizing these capabilities in the appropriate context will save resources and help contain
risk in a rapidly emerging market with numerous competing proprietary solutions.
2.3
Context of this SFM within HSSP Roadmap
Describe the context for this specific specification within the overall HSSP roadmap.
2.4
Structure of the Service
The Unified Communications Service facilitates communication between SOA services, human
participants, or any combination thereof, providing for the creation, modification, and delivery of
alerts, recommendations, and other payloads to designated recipients. It also facilitates dynamic
message routing, thereby ensuring that messages, which can be prioritized according to type,
content, sender, or recipient, can be escalated to an alternative recipient or a designated surrogate
if the original recipient is not available.
Figure 1: Structure of the Unified Communication Service
UC Service recognizes two general patterns of communication behavior. In a messaging pattern,
communication events are atomic exchange of specific content and meaning. SMS, error
messages, and CDS notification alerts are representative examples. Messaging events are often
asynchronous, but may be synchronous.
In a conversational pattern, two or more participants engage in a dialog with a common context.
Conversations imply a bidirectional exchange that may need to be suspended, and later resumed,
if the duration is sufficiently long. Typically, conversations are synchronous, for example, as in a
telephone call, but they may also be asynchronous in the case of a threaded exchange in a
bulletin board or forum. The important characteristic is that conversations have a organizing
principle or topic that aggregates atomic events into a coherent collection and communicates
additional meaning.
Communication patterns are separate and distinct dimension from the mechanics of connecting
to a communication device, addressing recipients, creating content, and transmitting payloads.
The UC Service supports all these dimensions with the following core functionality:

Addressing and Content Authoring
All communication events require basic addressing that identifies participants and where an
exchange payload is to be sent. The UC Service provides basic CRUD-like services for the
creation, modification and deletion of both addressing metadata and payload content. The
service enables a “caller” to setup a call, enter a telephone number or addressable handle,
modify the receiver’s address, cancel / delete the communication, or save a record of events.
In a conversational pattern, “content” is often created after a connection has been established;
in a messaging pattern, content is produced before the communication event.

Communication Setup and Content Transmission
In keeping with the general approach used by other HL7 specifications, UC Service
distinguishes between the content being communicated and the communication event itself.
The service provides participants with the functionality required for establishing a
communication connection, dialing a number, accepting a call, transmitting a payload, and
potentially rerouting a communication attempt.

Functional Managers
The Service provides for basic services in which participants and their addressing
information can be obtained from a user directory or some other appropriate source.
Additional services are available for querying/locating individual messages, aggregating the
collection of communication events that constitute a conversation, or for managing the
delivery of communication requests.

Service Administration
The service provides a minimal set of functionality necessary to retrieve communication
service metadata and content, suspend and resume service operations, etc.

Exception Handling
The UCS facilitates dynamic message routing and escalation by providing a simple exception
handling capability. The exception manager provides participating services/actors with a
stable endpoint for reporting transmission errors, etc.
2.5
Implementation Considerations
UC Service makes no assumptions about implementation and is abstracted from the deployment
architecture behind its service contract. It simplifies interoperability between communication
services and components by means of a common and standardized interface independent from an
underlying implementation. Any UC Service deployment should meet the following goals:
2.6

It allows compliance to this standard to be testable and verifiable

It is semantically extensible to meet expanding business needs
Deployment Scenarios
The UC Service is explicitly an interface specification intended to enhance interoperability; it is
not an implementation specification. In addition, there is nothing inherent in the specification
that limits its use to a single organization. Conformance to the specification is asserted against
profiles of the specification rather than against the specification itself. Consequently all scenarios
herein should be considered non-normative with regard to conformance to the UC Service
standard. They are offered for explanatory purposes only and other topologies can be realized on
the basis of the UC Service specification.
2.6.1 Intra-organizational Deployment Model
Figure 1 describes an exemplary intra-organizational deployment scenario where the UC Service
assumes the role of an enterprise resource manager. In this scenario, the Service mediates
between communication participants that consume and transmit content of common interest.
Figure 2: Representative UC Service deployment in a cross-organizational setting (centralized)
3 Business Storyboards
The UC Service is designed to support use cases as diverse and numerous as the communication
modalities available. Typical usage scenarios include, but are not limited to, the following:

Labor and Delivery utilizes a specialized paging service to call for a neonatal resuscitation
team when a crash C-Section is underway. The system takes a basic text description of the
clinical scenario, the Operating Room number, etc. and broadcasts the information by
priority alphanumeric page to all the response team members simultaneously. Insert Activity
Diagram

A CDS system sends a priority alert to a provider’s EMR account informing them of a
potentially dangerous drug-drug interaction. The alert is sent with read recipient enabled.
When the original recipient doesn’t respond within a pre-determined 45min time window, the
system escalates the reminder to a dedicated surrogate and modifies the payload to explain
the reason for the escalation. Insert Activity Diagram

An automated patient notification system notifies a PPD converter that their annual screening
reminder is due using a VOIP “robocall” system. The patient follows the automated
attendant’s instructions and completes a brief symptom survey using the telephone keypad.
Upon completion of the survey, the system thanks the patient, hangs up, and records the
survey results in the appropriate Preventive Health database. Insert Activity Diagram
4 Assumptions and Dependencies
The UC Service is intended to be a buffer between systems and components attempting to
communicate using any number of possible exchange mechanisms. It assumes that devices and
systems that are participants in a communication event have unique identifiers, such as email,
MAC, or IP addresses, are pre-configured to conform to the site’s security policies, and
communicate with the UC Service using exiting protocols via service adaptors.
Another assumption is that the service would not be invoked to “communicate” or update clinical
data in electronic medical records. Orders, documentation, or diagnostic results will be managed
by other more specific services. The UC Service is not required connect directly to medical
record data repositories.
A final assumption is that the quality of service afforded by a particular communication channel
is stable and communications problems unlikely. The UC Service not currently specify behaviors
designed to accommodate significant infrastructure unpredictability, or to ensure dynamic
reconfiguration / rerouting to minimize exposure of other SOA components to uneven quality of
service.
5 Detailed Functional Model for each Interface
5.1
Domain Model
Figure 3: Unified Communication Service Domain Model
5.2
Entities
5.2.1 Functional Entities
Figure 4: Functional Entities

Unified Communication Server (UCS). The UCS represents the primary SOA service.

User Manager. The User Manager provides user addressing and grouping information.

Conversation Manager. The Conversation Manager provides search and retrieval
functionality for conversations.

Message Manager. The Message Manager provides search and retrieval functionality
for atomic communication events.

Message Log. The Message Log persists a serial log of message events.

Delivery Manager. The Delivery Manager manages the delivery of outgoing messages.

Exception Manger. The Exception Manager is responsible for handling exceptions and
notifying clients of specific conditions (e.g. transmission errors or communication
exceptions).

Adaptor Implementation. An instance of the UC Service must be able to interact with
the communication channels (SMS, email, VOIP, etc.) available to the organization. It
does so by using Adaptors that enable UC operations to invoke the corresponding
native API on the specific servers or services used in production.
5.2.2 Addressing-Related Informational Entities
Figure 5: Addressing-Related Informational Entities

Address. The Address class provides bindings identifying the Service ID and the User.

Delivery Group. A Delivery Group class provides a mechanism to group/list users into
convenient cohorts.

Delivery Address. The Delivery Address is a union of Addresses, Delivery Groups, or
User Contact Info.

User Message Directory. The User Message Directory class provides a mechanism for
organizing messages by user.

User Contact Info. The User Contact Info class provides for properties related to user
identification, contact , etc.
5.2.3 Message-Related Informational Entities
In a messaging communication pattern, content is typically textual and communicated in short
lived exchanges. SMS, instant messaging, and CDS alerts are representative examples of
“message communications” that are often asynchronous, but may be synchronous.
Figure 6: Messaging-Related Informational Entities

Alert Message. The Alert Message class provides the properties unique to the Alert
Message Type.

Alert Message Header. The Alert Message Header class provides the properties unique
to the Alert Message Type.

Conversation Message Header. The Conversation Request Message Header class
provides the properties unique to the Conversation Request Message Type.

Conversation Request Message. The Conversation Request Message class provides
the properties unique to the Conversation Request Message Type.

Message. The Message class provides the abstract definition for messages.

Message Body. The Message Body class provides for generic content containment and
type identification by MIME type.

Message Header. The Message Header class provides for all major message metadata.

Notification Message Header. The Notification Message Header class provides the
properties unique to the Notification Message Type.

Notification Message. The Notification Message class provides the properties unique
to the Notification Message Type.

Simple Message. The Simple Message class provides the properties unique to the
Simple Message Type.

Simple Message Header. The Simple Message Header class provides the properties
unique to the Simple Message Type.
5.2.4 Conversation-Related Informational Entities
In a conversational pattern, a participant communicates with one or more participants in a dialog
with a common context. There is the expectation of a bidirectional exchange and the
conversation may be so long lived that it may need to be suspended and later resumed, perhaps
using different communication modalities. Typically such conversations are synchronous, for
example, as in a telephone call, but they may also be asynchronous in the case of a threaded
exchange in a bulletin board or forum.
Figure 7: Conversation-Related Informational Entities

Conversation. The Conversation class provides context for a common ongoing
communication between two or more parties.

Conversation Channel. Conversation Channel is an abstraction describing the
communication stream/channel/mechanism used to conduct a conversation.

Conversation Message Header. The Conversation Message Header class provides the
properties unique to the Conversation Message Type.

Conversation Request Message. The Conversation Request Message class provides
the properties unique to the Conversation Request Message Type.

Monitored Conversation Channel. The Monitored Conversation Channel Class
provides a persistence mechanism for conversation-patterned exchanges.

Unmonitored Conversation Channel. The Unmonitored Conversation Channel Class
provides a mechanism for establishing conversation-patterned exchanges without
maintaining a record.
5.2.5 Exception-Related Informational Entities
Figure 8: Exception-Related Informational Entities

Exception. The Exception class provides for information regarding communication
exceptions and errors in messaging. List potential subclasses.
5.2.6 Logging-Related Informational Entities
Figure 9: Logging-Related Informational Entities

Detailed Log Entry. The Detailed Log Entry class provides log entry information
including the actual message.

Log Entry. The Log Entry class provides log entry information without including the
actual message.

Summary Log Entry. The Summary Log Entry class provides summary log entry
information, e.g. header data.
5.2.7 User-Related Informational Entities
Figure 10: User-Related Informational Entities

User Message Directory. The User Message Directory class provides a mechanism for
organizing messages by user.

User Contact Info. The User Contact Info class provides for properties related to user
identification, contact , etc.
5.3
Client Interface
The Client Interface is the main interface that clients use to call the Unified Communications
Service. It provides a number of methods that conceptually can be organized in to functional
groupings. These collections are described below.
5.3.1 Addressing and Content Production Functionality
Enables clients to create and prepare compliant content for communication events.
Create Message

Story Board(s)
Dr. Jane Doe logs into her EMR to conduct an online VOIP meeting / appointment with a diabetic patient
who has questions regarding recent changes in his insulin sliding scale. She accesses the VOIP tool,
searches for and locates the desired patient, and reviews her notes prior to the call (conversational
pattern). While waiting, she decides to send the patient an email that includes a reference to the latest
research on diabetes. She accesses the email module, addresses a message to the patient, writes a brief
note and pastes the url reference to the research report (messaging pattern).

Description: Enables clients to create communication events using a number of
different channels. For conversation pattern channels, create sets up required
addressing and channel specific metadata. For messaging pattern channels,
create also accepts the content that the communication channel is to transmit.







Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Query Message

Story Board(s)


Description:
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Retrieve Message

Story Board(s)
Later that day, Dr. Doe realizes that the email she had intended to send had not been sent and was still
listed as a draft in her email Outbox. She retrieves the message and quickly reviews the note she had
written earlier in the day.


Description: Enables clients to read previously created communication events
that were prepared, but have yet to be executed.
Pre-Conditions:
o





Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)

Notes
Update Message

Story Board(s)
ACME Medical Center utilizes an advanced Clinical Decision Support system to automatically notify
ordering providers of abnormal laboratory results. One morning a patient CBC is resulted that has a
preliminary platelet count that is critically low. The CDS system, previously configured to send
preliminary results only if critical, sends an alert to the ordering provider Dr. John Smith. At that time,
Dr. Smith is busy examining another patient and is not logged in to the EMR to read the message. A few
minutes later, the pathologist confirms the platelet result and finalizes the lab result. The CDS system,
attempting to reduce alert fatigue and message volume, checks the status of the preliminary result alert,
determines that it had not yet been reviewed, and replaces the message with an updated alert that reflects
the final pathologist interpretation.
Realizing that the email contained a spelling mistake, Dr. Doe makes the required corrections, but
decides to add a second reference. She saves the revised draft until the additional information can be
located.


Description: Enables clients to update previously created communication events
that were prepared, but have yet to be executed.
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Cancel Message

Story Board(s)
After located the second reference, Dr. Doe decides to simply send an SMS message to the patient with
both references. Upon completing her text, she then deletes the draft email communication.






Description: Enables clients to delete previously created communication events
that were prepared, but have yet to be executed.
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)


Reference to Functional Profiles (optional)
Notes
Send Message

Story Board(s)
After the VOIP connection is established, Dr. Doe beings the telemedicine visit by introducing herself and
stating the purpose of her call. The speakerphone application automatically encodes her speech and
transmits her voice data via SIP protocol to the receiver.


Description: Enables authenticated clients to transmit their content payloads to
an appropriate channel. For messaging patterns, the content is a discrete
message, for example a 140 character SMS, and is typically sent asynchronously.
For conversational patterns, a channel is opened with a receiving device and the
connection is maintained while communication data is exchanged. For POTS
calls, this data stream in analog, for VOIP, the transmission is digital.
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Query Users

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Retrieve User

Story Board(s)








Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
5.3.2 Communication Channel Setup Functionality
Enables clients to establish communication channels for conducting conversations.
Connect Conversation

Story Board(s)
At the agreed upon meeting time, Dr. Doe initiates the VOIP call to the diabetic patient. Her
speakerphone application connects to the hospital telecommunications trunk, receives a dial tone, and
automatically dials the patient using the addressing information provided in the initial communication
event setup. When the recipient accepts the call, the client completes the connection (conversational
pattern).


Description: Enables clients to connect to a communication channel and
authenticate.
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Disconnect Conversation

Story Board(s)
Upon completing her business with the diabetic patient, Dr. Doe says goodbye and hangs up.


Description: Enables authenticated clients to gracefully disconnect from a
communication channel.
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Query Conversations

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Retrieve Conversation

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






5.4
UCS Client Interface
Receive Message

Story Board(s)
Dr. Doe’s patient, having picked up his phone, listens to the doctor’s explanation for calling, and then
replies with an appropriate response. The patient’s voice is similarly encoded and transmitted to the
provider’s client, which automatically receives the communication and converts it back into
understandable analog speech.


Description: Enables clients to asynchronously receive new messages, i.e. push.
Pre-Conditions:

Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
o






Call Ready

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Handle Notification

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:






o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Handle Response

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Handle Exception

Story Board(s)

Description: Provides a handler interface for communication end-points to pass
back transmission errors or communication exceptions.
Pre-Conditions:

o






5.5
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Alerting Interface
Receive Alert Message

Story Board(s)


Description:
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Update Alert message

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Cancel Alert Message

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)






5.6
Reference to Functional Profiles (optional)
Notes
UCS Alerting Interface
Cancel Alert Message

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Receive Alert Message

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Update Alert Message

Story Board(s)


Description:
Pre-Conditions:
o






5.7
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Adapter Interface
Conversation Ready

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Conversation Update

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Post Exception

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






5.8
UCS Adapter Interface
Cancel Message

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Send Message

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:






Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Update Message

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Get Service ID

Story Board(s)


Description:
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes






Get Interaction Types

Story Board(s)

Description:







Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
5.9 Management Interface
The Manager interface provides a minimal set of functionality necessary to monitor UCS
activity, control channel services, and provide for the retrieval of communication events.
Get Status

Story Board(s)
The Unified Communications Service allows administrators to determine the status of communication
events, channels, quality of service etc. that were conducted using the service. For example, it allows
administrators to review








Description: Enables clients to inquire about the status of different service
functions or execution events passed as a parameterized list. This API might
support inquires about the status of a channel, whether a previously
communicated message had been read, or whether a VOIP call successfully
connected and for how long. Some inquiries might require the client to be
authenticated first.
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Suspend Channel

Story Board(s)
ACME Medical Center utilizes an older commercial VOIP switch to manage all telephone traffic for the
institution. When it comes time for this switch to be upgraded to a more capable model, the system
administrator access the Unified Communications Service Management Portal and temporarily suspends
the VOIP channel, while allow email, IM, and other non-VOIP channels to continue to operate.


Description: Enables authenticated clients to suspend the operation of one or
more previously configured and functional communication channels.
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Resume Channel

Story Board(s)
Following the hardware upgrade, the administrator again logs in to the Management Portal and resumes
VOIP services for the Unified Communications Service.


Description: Enables authenticated clients to resume the operation of one or
more previously configured and functional communication channels.
Pre-Conditions:
o






Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Discover Channels

Story Board(s)
New Wave Technologies, Inc. has a small team of developers working on a Clinical Decision Support
product for its healthcare customers. The system, when installed at a client site, automatically “pings” the
network for any available Unified Communications Service, and if one is found, queries the service to
discover the specific channels and communication functionality that are being supported.


Description: Enables authenticated clients to discover what communication
channels the Unified Communication Service has been configured to support.
Pre-Conditions:
o

Conceptual Information Objects:
o Inputs:
o





Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Get Event Metadata

Story Board(s)
Business Process Improvement teams often need detailed information about communication events,
patterns of use, fails, etc. to identify where clinical workflow is suboptimal or where there might be
opportunities to improve. The Unified Communications Service can retrieve metadata for a specific
communication event, or an aggregate of events with common metrics.








Description: Retrieves available metadata for a specific communication event or a
set of related events defined by some organizing principle such as a date range, a
recipient, or a communication type. Applicable to both conversational and messaging
patterns.
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified
Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
Get Event Content

Story Board(s)
The Unified Communications Service allows the retrieval of content data for a completed communication
event, typically of the messaging type, where the content payload might be cached or stored for a
reasonable amount of time before being archived.





Description: Retrieves actual payload content for a specific communication
events or set of related events. Applicable typically to messaging patterns.
Pre-Conditions:
o
Conceptual Information Objects:
o Inputs:
o Outputs:
Post-Conditions:
Exception Conditions: None identified



Aspects left for Technical Bindings (optional)
Reference to Functional Profiles (optional)
Notes
6 Profiles
6.1
Introduction
A set of profiles may be defined that cover specific functions, semantic information and overall
conformance. The SSDF explains in detail the meaning of each of these types of profile. In brief,
they are as follows:

Functional Profile: a named list of a subset of the operations defined within this specification
which must be supported in order to claim conformance to the profile.

Semantic Profile: identification of a named set of information descriptions (e.g. semantic
signifiers) that are supported by one or more operations.

Conformance Profile: this is a combination of a set of functional and semantic profiles taken
together to give a complete coherent set of capabilities against which conformance can be
claimed. This may optionally include additional constraints where relevant.
Fully define the profiles being defined by this version of the service.
When appropriate, a minimum profile should be defined. For example, if a service is dataoriented, a minimum semantic profile supporting HL7 data (with the relevant data cited)
should be included.
Each functional profile must identify which interfaces are supported, and where relevant
where specific data groupings are covered etc.
When profiling, consider the use of your service in:

Differing business contexts

Different localizations

Different information models

Partner-to-Partner Interoperability contexts

Product packaging and offerings
7 System Interaction Details [Optional]
Describe the dynamics of the service from a requirement-level architectural view and its
interactions with anticipated (services/components/applications, etc.)
High-level description, illustrating the storyboards, elaborated for each storyboard in
Chapter 3.
May use any well known, reasonable mechanism for communicating the information, (e.g.
UML Activity Diagrams or Sequence Diagrams)
8
Recommendations for Technical RFP Issuance
There should be no impact to this service for internationalization because the service deals in strings of
data that do not need to have any other semantic or syntactic characteristics other than those specified
by the site. The service itself is not designed to discriminate for or against any particular language.
Any required multi-language functionality is assumed to be implemented with the sub-system.
9
Appendix A - Relevant Standards
Review of potentially relevant standards, including a short-list of applicable standards.
For each applicable standard (this may include citations to standards themselves, information
content, portions of standards, etc. Demonstrate that “you are not re-inventing the wheel”):

A short review that explains its intended relationship to this specification

What are the relevant parts that are being re-used, extended, etc.

Include context of how the service relates to the existing standard.

How does this work relate to similar work;

What are the implications if this service is used in an environment that has already
adopted a competing or closely related standard
If there is relevant realm work, a traceability matrix would be useful here {for instance, U.S.
Federal Enterprise Architecture/Service Reference Model}
OASIS: ALert MAnagement Service (ALMAS) Specification Version 1.0
UML Profile and Metamodel for Voice-based Applications Specification Version 1.0
Audio/Video Stream Specification
Notification Service Specification Version 1.1
NETHA: Endpoint Location Service Technical Service Specification Version 1.3
XMPP: XEP-0045: Multi-User Chat
XEP-0166: Jingle
38
IETF: Extensible Messaging and Presence Protocol (XMPP): Core
OASIS: Common Alerting Protocol Version 1.2
Web Services Notification (WSN)
WS – Human Task
3GPP2: Simple Message Service
Pre-existing conceptual and standards-development work in the Communications domain
(Extensible Messaging and Presence Protocol-XMPP, Short Message Service-SMS, Session
Initiation Protocol-SIP, OASIS WS-Human Task, OASIS Web Services Notification-WSN)
will be leveraged to help document the necessary definitions, descriptions, graphics, and
artifacts that are relevant. In keeping with the approach used by other HL7 specifications, the
Communication Service will distinguish between the communication modality itself and the
payload being communicated. The Service Interface Specification will provide functional,
semantic, and conformance profiles.
10 Appendix B - Glossary
Citation of terms specific to this functional specification and not included in the overall HSSP
Glossary
There are a number of acronyms used in this document, and in standards or other documents
related to this specification. The following is a brief list of what the most common ones stand for:
Acronym
ANSI
CDS
CDSS
DRG
DRI
DSS
HITSP
HSSP
IHE
ISO
KM
OMG
PIM
PSM
RIM
RM-ODP
SFM
UML
Full Name
American National Standards Institute (U.S.A.)
Clinical decision support
Clinical Decision Support Service (synonymous with DSS)
Data requirement group
Data requirement item
Decision Support Service
Health Information Technology Standards Panel of ANSI HL7 Health Level 7
Healthcare Services Specification Project
Integrating the Healthcare Enterprise
International Organization for Standardization
Knowledge module
Object Management Group
Platform Independent Model
Platform Specific Model
Reference Information Model defined by HL7
Reference Model of Open Distributed Processing
Service Functional Model
Unified Modeling Language
39
11 Appendix C - HL7 EHR Functional Model Traceability
This section lists the EHR Functions that are related to this service.
Note that in general there will not be a direct correspondence between EHR Functions and HSSP
Services, since Services are specified from a different system viewpoint. The mapping provided
here enables the HSSP Services to be understood in the context of the EHR-S Functional Model
DSTU. The table below references Version ________ of the EHR Functional Model.
EHR
Function
ID
EHR
Name
Function EHR Function Statement
Notes
For every row, explain the rationale for including in t
12 Appendix D - Relationship to Information Content
The following principles shall be followed for specifying the information model to be used by the
services being specified in this Service Functional Model:
1. SFMs shall provide a conformance profile supporting HL7 content where relevant
2. We shall not preclude the use of non-HL7 content
3. SFMs will reuse to the maximum extent possible the content models as defined in other standards
(for example, HL7 RMIMs)
4. Information content representations shall be represented in platform-agnostic formalisms (e.g.,
UML)
5. SFMs may identify content at varying levels of granularity, depending upon the functions being
specified. (For example, the Common Terminology Service will deal with different granularity of
information than the Resource Location and Update Service).
6. Conformance Profiles may be balloted or adopted after the release of the initial SFM to address
specialized business needs. (realm-specific profiles, domain-specific profiles, etc.)
7. Details about semantics specific to this SFM appear in other sections of this document
40