HL7 Version 3 Specification: Unified Communication …€¦ · Page 2 HL7 Version 3 Specification: Unified Communication Service Interface, Release 1 ... HL7 Version 3 Specification:

V3_SOA_UCSRVINT_R1_O1_2014JAN

HL7 Version 3 Specification: Unified Communication Service Interface, Release 1 - US

Realm January 2014

HL7 Draft Ballot

Sponsored by:

Services Oriented Architecture Work Group HL7 Clinical Decision Support Working Group HL7

Copyright © 2013 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

Use of this material is governed by HL7's IP Compliance Policy.

Page 2 HL7 Version 3 Specification: Unified Communication Service Interface, Release 1 - US Realm © 2013 Health Level Seven International. All rights reserved. January 2014

Project Lead Emory Fry, MD

Editor Alfred Bustamante

Authors Emory Fry, MD Jerry Goodnough Claude Nanjo

HL7 Version 3 Specification: Unified Communication Service Interface, Release 1 - US Realm Page 3 January 2014 © 2013 Health Level Seven International. All rights reserved.

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 ........................................................................................................................7

1.1 Introduction and Scope ............................................................................................7 1.1.1 HL7-OMG Healthcare Services Specification Project (HSSP) ...............................7 1.1.2 Service Definition Principles ...................................................................................8 1.2 Overall disclaimers ..................................................................................................9 1.3 Readers Guide ..........................................................................................................9

2 Executive Summary .......................................................................................................9 2.1 Service Overview .....................................................................................................9 2.1.1 Service Description and Purpose .............................................................................9 2.1.2 Scope ......................................................................................................................11 2.2 The Reason Why the Service Is Necessary ............................................................11 2.3 Context of this SFM within HSSP Roadmap .........................................................12 2.4 Structure of the Service ..........................................................................................14 2.5 Implementation Considerations .............................................................................17 2.6 Deployment Scenarios ...........................................................................................17 2.6.1 Deployment Model ................................................................................................17 2.6.2 Intra-Organizational Deployment ..........................................................................17 2.6.3 Inter-Organizational Deployment ..........................................................................18

3 Business Storyboards ...................................................................................................18 4 Assumptions and Dependencies ..................................................................................18 5 Detailed Functional Model for each Interface .............................................................19

5.1 Domain Model .......................................................................................................19 5.2 Entities ...................................................................................................................21 5.2.1 Functional Entities .................................................................................................21 5.2.2 Informational Entities ............................................................................................22 5.2.3 Addressing-Related Informational Entities ............................................................24 5.2.4 Message-Related Informational Entities ................................................................25 5.2.4.1 Common Message Concepts ...............................................................................29 5.2.4.2 Common Message body ......................................................................................30 5.2.4.3 The Notification Message ...................................................................................31 5.2.4.4 The Alert Message ..............................................................................................31 5.2.4.5 The Conversation Request Message ...................................................................31 5.2.5 Conversation-Related Informational Entities ........................................................31 5.2.6 Exception-Related Informational Entities ..............................................................33 5.2.7 Logging-Related Informational Entities ................................................................34 5.2.8 User Message Management Related Informational Entities ..................................34 5.2.9 Handling Aggregate Data ......................................................................................35 5.3 Client Interface .......................................................................................................35 5.4 Conversation Interface ...........................................................................................44 5.5 UCS Client Interface ..............................................................................................50 5.6 Alerting Interface ...................................................................................................53 5.7 UCS Alerting Interface ..........................................................................................55 5.8 Adapter Interface ...................................................................................................57 5.9 UCS Adapter Interface ...........................................................................................58


5.10 Management Interface ...........................................................................................62 6 Profiles .........................................................................................................................65

6.1 Introduction ............................................................................................................65 6.2 Base Conformance Profile .....................................................................................66 6.3 Conversation Conformance Profile ........................................................................68 6.4 Alert Conformance Profile .....................................................................................69

7 Recommendations for Technical RFP Issuance ..........................................................69 8 Appendix A - Relevant Standards ................................................................................70 9 Appendix B - Glossary .................................................................................................72 10 Appendix C - HL7 EHR Functional Model Traceability .............................................73 11 Appendix D - Relationship to Information Content ....................................................75 12 Appendix E - Examples ...............................................................................................76


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 be 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. 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.


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.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, SMEs 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 (UCS) facilitates effective bi-directional communication between parties, thereby enabling efficient delivery and coordination of patient care. It provides standardized functionality for delivering alerts, recommendations, and other message-based notifications using a variety of transport mechanisms to include, but not limited to, email, Short Message Service (SMS), or Instant Messaging (IM). UCS also provides functionality for managing analog and digital voice communications, for example establishing or transferring voice-over-IP (VoIP) calls. The UCS is at its core a multi-talented electronic “switchboard” that clients can leverage to establish reliable communications with any addressable party contributing to the delivery of care.


Most importantly, the service supports dynamic routing and/or escalation of communication events to ensure that when intended recipients are not available, appropriate surrogates can be notified and priority messages can be responded to in a timely manner. Dynamic routing refers to the system’s ability to redirect messages intended for a participant to alternative delivery channels, for example sending of a drug-drug interaction warning via SMS if the original EMR alert is not acknowledged. Escalation refers to locating alternative addressees (surrogates) who will then receive the original, un-answered message. Extending the drug-drug example used above, if the provider fails to respond to the dynamically re-routed SMS alert, the system might then escalate to a clinical pharmacist or perhaps another physician on the care team.

The Unified Communications Service introduces another significant behavior centered around the notion that communications exchanged between two or more participants might be grouped by a common topic or subject. Such groupings, referred to as “conversations”, are important constructs for documenting that an ongoing collaboration and exchange of information between providers occurred, or what the reasoning was that led up to a treatment decision or intervention. Conversations can span one or more communication channels or include 2 or more parties. For example, a ward attending may start a conversation with a patient’s primary care physician (perhaps to get some undocumented background) as an informal email, continue at some point with a VOIP phone call, and then conclude with a message exchange conducted via SMS. All these communication events have in common the subject of the patient’s care requirements and are important in establishing context for the ward attending when deciding the patient’s care plan. Conversations are designed to potentially collect these communications and manage them as composite events that have documentation value.

Conversations can be unmonitored or monitored. Unmonitored conversations are simply recorded with metadata about the who, how, why, and when of the events that compose the conversation – the content of each communication is not preserved. Monitored conversations take the additional step of recording the actual content, technology allowing, of each exchange – this has significant medical-legal and care transition implications. Imagine a scenario where complex and potentially controversial discharge instructions reference conservations whose metadata documents the participants that may have been involved in discharge planning, or in the case of monitored conversations, point directly to content that justifies the decisions made.

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 every day. 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 provides for the delivery of alerts, recommendations, and other notifications using representative transports to include email, SMS, or VoIP. The service provides 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 UC Service is largely 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 become obsolete or limited in their functional impact.

For the business community, a standard set of service interfaces will facilitate adoption, implementation and knowledge sharing across organizations. By specifying a common unified communications service interface, one can develop a labor market knowledgeable about this service interface and the technologies it supports. The availability of resources skilled in how unified communications might be integrated within an organization’s existing clinical infrastructure is critical to sales and adoption. A UC standard will also provide the necessary common semantics for facilitating the implementation, integration and use of disparate vendor products. A common interface for third party vendors to build against could also allow a community of ‘best-of-breed’ tools to develop that will be critical to reducing implementation cost and risk. Finally, standardization will create


common experiences that can to be shared within the rather conservative medical community in ways that will support the innovators and galvanize the less adventurous.

Clinically, a standard Unified Communication Service Interface is essential to the supporting cross-organization communication important to effect care coordination and transitions. It is economically untenable for healthcare organizations to accommodate all possible proprietary vendor interfaces when communicating across organizations and systems. The advent of the telephony and telegraph standards transformed the way we communicate in modern societies – similar standards for “new” internet technologies created interconnected networks of millions of instant message and chat users. Healthcare is not immune to these trends and will increasingly demand that the current plurality of communication modalities be embraced and integrated. Interoperable, standardized communication is critical to establishing and maintaining the effective communication required for the delivery of effective care in the modern internet-speed era.

Finally, patients will benefit from a standardized communications service that allows a healthcare provider’s clinical decision support, workflow management, and administrative systems to communicate more directly with them via their consumer-grade devices. UC is emerging as a key tool in the management of many complex business process and workflow challenges. Clinical medicine is no different. Healthcare technology implementers and integrators will increasingly focus on improving and monitoring communications with patients when designing loosely coupled and scalable patient centric services. Adopting a standards-based approach to UC and utilizing these capabilities in the appropriate context will save resources, contain risk, and help create an environment unified by patient needs rather than struggling with the idiosyncrasies of a rapidly emerging market replete with competing proprietary interfaces.

2.3 Context of this SFM within HSSP Roadmap

The Unified Communications Service is a logical extension of Decision Support Service identified in the HSSP Roadmap Version 1.0. It contributes to the functionality and behaviors of other SOA services available to an organization and to the development of standardized “plug-and-play” components supplied by any number of healthcare software vendors. The UC Service Functional Model complements existing HL7 and OMG work products and activities, leveraging content and lessons learned from elsewhere within both organizations.


Figure 1: The complementary HL7 + OMG relationship

The Unified Communications Service provides SOA an enhanced ability for systems and users to establish direct communication with other users using a variety of modalities. It also helps ensure that communication events become a part of a clinical infrastructure that can be monitored, orchestrated, and automated as appropriate.

To illustrate how an organization might integrate a Unified Communications Service into a hypothetical HSSP-HL7-OMG compliant infrastructure, consider the increasingly important application of decision support technologies in support of evidence-based clinical practice guidelines. When a pediatric asthmatic patient, for example, is first admitted to a hospital, an Admission-Discharge-Transfer (ADT) message might be published to an Event Publish and Subscribe system that then “pushes” events to topic subscribers. The CDS system receives this event notification and using patient information obtained from a RLUS service, analyses its rule base to select and place an unsigned Pediatric Asthma Admission Order Set into the ward attending’s order queue. The system, using a Unified Communications Service, then sends a time constrained, “read receipt required” alert to the provider EMR encouraging the recipient to review the orderable items within the set. The provider, busy with another admission, is not logged into the EMR and thus does not acknowledge the alert. Upon failing to receive the required “read receipt” in the allotted time, the UCS dynamically reroutes the original message and sends an SMS text, which the provider promptly reads. This use case is illustrated in the sequence diagram below.


Figure 2: Prototypic use of Unified Communications Service within an organization’s SOA.

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. These capabilities are supported by functionality related to the mechanics of connecting to a communication device, addressing recipients, creating content and transmitting payloads as described below:

• Addressing All communication events require basic addressing that identifies participants and specifies where an exchange payload is to be sent. The UC Service provides basic CRUD-like services for the creation, modification and deletion of such addressing metadata. For instance, when setting up a given communication, the caller must specify the addressable handle (e.g., a phone number) and may specify and/or modify the receiver(s) metadata to ensure correct message routing.

• Content Creation In certain types of communications, but not all, the “payload content” is often created before a connection has been established. For example, in a system that produces alert messages, the payload is produced before the communication event is initiated. This is in contrast to analog voice transmission where “content” is created on the fly after a


connection is made. The UCS supports content authoring, editing, etc. as part of its service behavior.

• Delivery After addressing, and potentially content creation, has been completed, the service provides its customers with the ability to actually establish a communication connection (dial a number, accept a call, send a text) and manage the communication transmission or delivery.

• User Management UC provides for basic services by which participants and their addressing information can be obtained from a user directory or some other appropriate source.

• Service Administration The service provides a minimal set of functionality necessary to suspend and resume service operations, etc. Additional services are available for querying/locating individual messages, aggregating communications, or administering message logs.

• Workflow Management

UCS supports critical workflow related functionalities such as dynamic routing and/or escalation to ensure that when intended recipients are not available, appropriate surrogates can be notified and priority messages can be responded to in a timely manner. The service also provides services/actors with a stable endpoint for reporting transmission errors, etc.

The Service recognizes two general patterns of communication behavior, messaging and conversational. In a messaging pattern, communication events are atomic exchanges of specific content and meaning. SMS, error messages, and CDS notification alerts are representative examples. Messaging events, often asynchronous, may be synchronous.

In a conversational pattern, two or more parties engage in a dialog with a common context. Conversations imply a multi-directional 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 an organizing principle or topic that aggregates atomic events into a coherent collection and communicates additional meaning. An appropriate function manager supports this conversational pattern. Finally, the UC service specifies an adaptor interface and corresponding client behavior that vendors can implement to ensure that the plethora of available communication products can integrate with the service. For example, a SMS text provider could map its proprietary API to the core service behavior of “send message” to allow a compliant product to utilize its services.

Page 16 Unified Communication Service Interface, Release 1 © 2013 Health Level Seven International. All rights reserved. January 2014

Figure 3: Structure of the Unified Communication Service


2.5 Implementation Considerations The Unified Communications Service is neutral with regard to specific software architecture. The rationale is that UCS makes no assumptions about implementation and is abstracted from the deployment architecture behind its service contract

2.6 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. 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 Deployment Model The figure below describes an exemplary 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.

2.6.2 Intra-Organizational Deployment

Figure 3: Representative UC Service deployment in an intra-organizational setting (centralized)


2.6.3 Inter-Organizational Deployment *********** To Be Inserted ***********

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 response team members simultaneously.

• 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 receipt enabled. When the original recipient doesn’t respond within a pre-determined 15-minute time window, the system escalates the reminder to a dedicated surrogate and modifies the payload to explain the reason for the escalation.

• 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.

• Over the course of several days, an oncologist consults with several of her colleagues regarding a difficult case. Many of her communications are by email, but she also has several lengthy discussions regarding treatment considerations over the phone and even during a videoconference with an expert in overseas. For documentation purposes, and for justifying her ultimate treatment plan, the oncologist identifies these communication events as a “monitored conversation” to which she then refers to in her electronic documentation.

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 expected to connect directly to medical record data repositories. The UC Service abstracts the delivery service that should allow a variety of other communications agents to be implemented in the future,

A final assumption is that the quality of service afforded by a particular communication channel is stable and communications problems unlikely. The UC Service does 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

The following diagram is the main master domain model for UCS. This model shows all interfaces (in yellow), functional entities (in green), and information entities (in blue and pink). Interfaces come in two forms: those that are implemented by the UCS server and those that are called by the service. (These interfaces all begin with the prefix “UCS”, for example UCS Adapter.) The functional entities are logical components of the service that perform a specific role in the functional model; in actual implementation, they may not actually exist, but the functions they describe will be performed. Finally, the information entities show the information content used by the service. Each of these major groups will be explained in detail later in the document. The artifacts should not be interpreted as information models.


Figure 4: Unified Communication Service Domain Model


5.2 Entities

5.2.1 Functional Entities The functional entities are logical components of the service. They perform a specific role in the functional model. The purpose of the functional entities is to describe behavior in the model and to provide an active agent for roles and responsibilities. In an actual implementation, they may not actually exist, but the functions they describe will be performed.

Figure 5: Functional Entities

• Unified Communication Server (UCS). The UCS represents the primary SOA service. From an external perspective, this is the primary entity that a client would interact with. The UCS Server is composed of all the other functional entities.

• User Manager. The User Manager provides user addressing and grouping and managing information about users known to the UCS system.

• Conversation Manager. The Conversation Manager provides search and retrieval functionality for conversations. Its role is to handle the dynamics around maintaining conversation state and access. It handles the view point of the conversation and deals with the dynamics of call setup and monitoring.

• Message Manager. The Message Manager provides search and retrieval functionality for atomic communication events. This entity is concerned with managing the long-term life of a message independent of its delivery to various recipients. All messages are implicitly the purview of the Message Manager.

• Delivery Manager. The Delivery Manager manages the delivery of outgoing messages. The delivery manager handles the dynamics of handing off messages to the correct adaptors for delivery and managing their delivery states.

• Message Event Log. The Message Event Log provides a serial log of message events. The message event log records the events relating to message updates and flow in the UCS service. The message log deals with the entire scope of the UCS server’s operations.

• Exception Manager. The Exception Manager is responsible for handling exceptions and notifying clients of specific conditions (e.g., transmission errors or


communication exceptions). The functional role of this manager is twofold: first, fault handling and second, relating to message workflow. The Exception manager provides active intervention into the delivery path of a message and in some implementations may also provide direct message re-routing, depending on the nature of the recipients of the message (e.g., using alternate contact info for a recipient) and any workflow associated with a message (e.g., alert escalation lists, embedded workflow in the body, etc.).

• 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 Informational Entities The information entities of the UCS server are the information content and structures that are handled by the service. They may be grouped in to a number of broad categories:

• Address-Related. Provides information to locate and manage the parties of a communication. This includes users, groups, contact data, etc.

• Message-Related. Provides information about messages. This includes types, content and common message-related data.

• Conversation-Related. Provides information for conversations and conversation management.

• Logging-Related. Provides information on logging messages and system events. • User-Related. Provides information on users of the UCS Server. • Exception-Related. Provides an information model of the exceptions that are

known to the UCS service.

The diagram bellow provides an overview of the first five categories. All six categories are detailed in further sections.


Figure 6: Informational Entities


5.2.3 Addressing-Related Informational Entities

Figure 7: Addressing-Related Informational Entities

• Address. The Address class provides physical addressing and routing information for messages. The address has two major components: the service name and an address specific to the conventions of that service. Some potential examples are SMTP: [email protected], telcom: +115555551212, restput: http://someurl.org/rest/info. In the above example, the first segment is the name of the service adapter that can handle the request and is not intended to be a standardized code, but an attribute of the configuration of the adapter on the services. This provides the functional ability for a single configuration to support the multiple adapters for the same modality (e.g., an internal and external mail server).

• Delivery Group. A Delivery Group is a named collection of delivery addresses. This 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 Contact Info. The User Contact Info class lists all addresses for a given user such as, for example, phone numbers, emails, IM, etc. These addresses are grouped by type (What do we mean by ‘Type’ here? The protocol? Whether it is home, business, etc…?). The UserContactInfo class also specifies the preferred address(es) for this user (what is the cardinality? Is it only one or could a user have more than one preferred address). This class essentially groups properties related to user identification, contact, etc.


5.2.4 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.

Message related Entities can be organized into three types:

• Base Message Structure: The core structure for all messages. • Message & Header Types: Individual specialized messages types and headers

for different communications patterns. Message header information that is independent of content.

• Related Entities: Closely related types like recipient and delivery status information.

Figure 8: Messaging-Related Informational Entities

Base Structure The base structure is the core informational structure common to all message types.


Figure 9: Base Structure

• Message. The Message class provides the abstract definition for messages. • Message Header. The Message Header class provides for all major message

metadata. • Message Body. The Message Body class provides for generic content

containment and type identification by MIME type.


Type of Messages & Headers Each type of communications patterns is supported by a set of different core types of messages.

Figure 10: Message Types

• Simple Message. The Simple Message class provides the properties unique to basic simple messages. These messages are a simple communication with no implied expectations. That is not to say that additional communication dynamics may not apply to the message, but rather that the dynamics are not predictive.

• Alert Message. The Alert Message is a message with an expectation of user response or action. An alert message is typically an asynchronous message that warns the recipient about a potential problem that may require an action to be performed. For instance, an alert may warn a physician of a potential drug-drug interaction that should be resolved in order to prevent a never-event


• Notification Message. The Notification Message class provides the properties unique to a message which has the dynamics of a notification. Notifications are message in which the intent is to communicate an event where a response is not expected.

• Conversation Request Message. The Conversation Request Message class provides the properties unique messages that are used to request the establishment of a conversation. This class includes support for messages that attempt immediately to create a conversation as well and conversations that can only be established when the recipients agree to it (e.g., Calendar invite).

• 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.

• Notification Message Header. The Notification Message Header class provides the properties unique to the Notification Message Type.

• Simple Message Header. The Simple Message Header class provides the properties unique to the Simple Message Type.

Related Entities Directly related to a specific message, there are a number of related entities that are used to direct and manage individual messages.

Figure 11: Related Entities

• Recipient. The recipient provides information about who should receive the message and the constraints and options around the particular recipient. This includes such information as the delivery address of the recipient, the visibility of the recipient, role in the message, and message tracking options (e.g., read receipt).

• Delivery Status. The delivery status tracks the state of delivery for a particular recipient.


5.2.4.1 Common Message Concepts

Figure 12: Message Header

• Message Type. The type of messages being sent (e.g., alert, conversation request, etc.)

• Delivery Guarantee. The level of delivery service required for the message. This delivery guarantee is directly affected by the downstream communications quality of service. The inability to deliver that level downstream is not considered a fault by the service. The following list defines the request states so far identified:

o Best Effort. The system will make a reasonable best effort to attempt delivery of the message. Such messages must be durable until the adapter has acknowledged the send request.

o Disposable. The message is of a transient nature and durability is not required.

o Maximum Effort. Delivery of the message should use the highest possible quality of service and engage such measures as to verify the message was actually received by the recipient. Such messages must be durable until such time as the delivery is confirmed.

• Created. Timestamp of when the message was created. • Delivery Status. Collection of delivery status objects that are used to track the

delivery status of each recipient. • Dynamics. Message processing dynamics.

o Synchronous – Message should be delivered to the service in synchronous manner.

o Asynchronous – Message does not require synchronous delivery. o One-Way – Message is not intended for response (even delivery receipt).

• Last Modified. Timestamp of when the message was last changed.


• Message Id. Unique message ID assigned by the service. The structure of the ID should be such that when combined with a UCI instance ID, a universally unique message identifier could be created.

• Priority. The criticality of the message with regard to resource used by the system in attempting delivery of the message.

• Receipt Notification. Indicates if receipt of the message should be tracked. • Timeout. Length of time that message attempts should be performed. May be

unbounded. • Properties. A list of Name/Value pairs that may have meaning to downstream

services. The purpose of the properties list is multifold: first, it provides a mechanism where metadata unknown to the UCS Service may be passed to specialized adaptors (e.g., adapter context info); second, it provides a generalized location for tagging that might be used by supplemental service layers (e.g., security, redaction, etc.); and finally, it provides a mechanism to handle extensibility.

• Retain Fully In Log. True if a detailed logging of this message is required. • Recipients. Receivers of the message. • Related Conversation. Identity to the conversation this message relates to, if any.

5.2.4.2 Common Message body

Figure 13: Message Body

All message types have a common message body structure. The message body consists of the main content of the payload and the content type generally in the form of a MIME type. The content of a particular message may vary widely (hence, the type ANY) and is considered a set of abstract packets with identification and form information associated with them. The message body is, in effect, an identified tagged format. An example of format is identified MIME-encoded data. Some types of messages (e.g., alerts) will require that specific body parts be available. The general body structure should support both attachments and multiple streams in a recursive manner. This will allow complex body structures to be represented in a duplicative manner based on a separate axis, for example the natural language of the content provided.


Each body section would have a unique ID, allowing it to be included in multiple presentation streams. The common body would also define an organizing section which allows various body parts to be linked together. In addition, the body should support a name in the metadata of the part. This provides three basic parts: type, identity, and name. Specific body types may support content by reference. Examples of this include linking technology, content negotiation.

5.2.4.3 The Notification Message The notification message is a message that is intended to notify one or more individuals of some information. The intent of the message is generally one-way communications, although dialog with the sender may be possible. When a notification message is sent to multiple recipients, the default behavior is not to show the other parties receiving the message. The notification message supports an informative section which can expose the identity of selected recipients in three different forms: user Id, delivery address and sender’s alias for the user.

5.2.4.4 The Alert Message The alert message is a message that is tied to a specific clinical event that may or may not require user action and workflow. Alert messages are usually include explicit workflow, the expectation of acknowledgement, visibility of action to all parties, visibility of the parties involved. Alert messages are also special in that they are the only primitive message type that the UCS defines a full delivery and response path for.

5.2.4.5 The Conversation Request Message The conversation request message is a request to form a conversation with a user. The conversation requested could be immediate, dependent on contact or for a specific scheduled time.

5.2.5 Conversation-Related Informational Entities

In a conversational pattern, a number of participants engage in a dialog with a common context. There is the expectation of a multilateral 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. A single conversation may over the course of its’ lifetime span many modes of commination and exhibit both synchronous and asynchronous elements.


Figure 14: Conversation-Related Informational Entities

• Conversation. The Conversation class provides context for a common ongoing communication between two or more parties. It specifies a unique identifier and a conversation channel.

• Conversation Channel. Conversation Channel is an abstraction describing the communication stream/channel/mechanism used to conduct a conversation. An example of this might be a voice over IP stream.

• Conversation Message Header. The Conversation 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.

• 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.6 Exception-Related Informational Entities

Figure 15: Exception-Related Informational Entities

• Exception. The Exception class provides for information regarding communication

exceptions and errors in messaging. It is ancestor of all other exception classes. Exceptions are considered checked conditions.

• Bad Body Type. The content body type is invalid. • Delivery. There was a delivery failure. For example invalid SMTP address, bad

phone number, etc. • Feature Not Supported. The feature requested is not supported on this server. • Invalid Address. The address of the message is invalid. • Invalid Content. The content is missing or invalid. • Invalid Conversation. The conversation ID used is invalid or unknown. • Invalid Message. The message is malformed. • Invalid Query. The query is not valid. • Message Delivery Timeout. The message could not be delivered before it timed out. • Missing Body Type. The body type element is missing or empty. • Not Connected. The call/conversation is not connected. • Read Only. Attempt to modify a read only item. • Service Adapter Fault. Service adapter specific fault – Details nested within. • Service Offline. The service is currently suspended. • Undeliverable Message. The Message cannot be delivered. • Unknown Service. No such service exists. • Unknown User. No such user exists. • Update. Error updating entity.


5.2.7 Logging-Related Informational Entities In certain cases, communication messages need to be logged for auditing purposes or for clinical decision-making purposes. Log entries may either be detailed or summary entries.

Figure 16: Logging-Related Informational Entities

• Log Entry. The Log Entry abstract class provides summary log entry information, e.g., header data.

• Summary Log Entry. The Summary Log Entry class provides log entry information without including the actual message.

• Detailed Log Entry. The Detailed Log Entry class provides log entry information including the ability to see the state of the actual message at the time the event occurred.

5.2.8 User Message Management Related Informational Entities

Figure 17: User Message Management Informational Entities


• User Message Directory. The User Message Directory class provides a mechanism for organizing messages by user.

5.2.9 Handling Aggregate Data Many of the operations on this service return collections of data. The data collections can be grouped into two broad forms lists/sets and trees. In general such collective entities can contain either full instances of data or some summary form with a reference where full detail may be retrieved. All operations that return aggregate data can be viewed as either returning a complete set of information or a partial/sparse representation. It is expected that actual implementations of the operations will support both full and sparse behaviors in their query semantics. In the case of list and sets it is expected that paged access to the data would be provided, with variable page sizes. For those operations that return a tree structure support for sparse trees and paging should be provided. In a sparse tree only the tree to a specified depth is returned with the deepest level providing metadata suitable for continued drill down. Paging is used on sparse trees to limit the number of child nodes returned on a single node and to allow additional queries to be used to find the additional child nodes. ************************************************************************The Reminder of this document is incomplete and under active development ************************************************************************

5.3 Client Interface The Client Interface is the main interface that clients use to call the Unified Communications Service. It enables clients to create, prepare and send 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 her UCS-aware email client, 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: • Conceptual Information Objects:

o Inputs: § Message


o Outputs: § Success/Fail § Message

• Post-Conditions: o New Message created at service level without any delivery attempt

being made. o Message is assigned a unique message ID.

• Exception Conditions: o None

• Notes

Figure 18: Create and Send Messages


Figure 19: Create Conversation with Messages

Created messages need not be valid. They are considered a work in progress and will not be validated until sent.


Query Message Finds messages stored on the UCS system. This will include messages that have not been sent yet and messages delivered specifically to the User at the UCS service. In addition, this may include messages that have been sent or that are a part of ongoing conversations, depending on the retention policies in place on the server.

• Story Board(s) During her conversation with the diabetic patient, Dr. Doe wants to confirm that she had sent a lab report. She then accesses the “sent” folder in her UCS-aware email client and searches for all emails where the recipient was the patient in question. • Description: The operation allows messages to be retrieved from the service. • Pre-Conditions: • Conceptual Information Objects:

o Inputs: § Message Query String

o Outputs: § List of Message IDs § List of Message Metadata

• Post-Conditions: • Exception Conditions:

o Invalid Message • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes Retrieve Message This operation allows a message that exists on the server to be retrieved. • 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. • Pre-Conditions:

o Message must exist. o Message must be accessible to the user.

• Conceptual Information Objects: o Inputs:

§ Message Id o Outputs:

§ Message • Post-Conditions:


• Exception Conditions: o Invalid Query

• Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes Cancel Message This operation allows a message to be retracted or removed. • Story Board(s) After locating the second reference, Dr. Doe decides simply to 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 delivered. In the case of messages that have been delivered, provides a mechanism to invoke retraction if the delivery services support the mechanism.

• Pre-Conditions: o Message must exist


§ Message Id § Require retraction

o Outputs: § Success/Failure

• Post-Conditions: o If no delivery attempt has been made, the message is deleted. o If delivery is pending, the UCS attempts to cancel delivery. o If delivery has occurred, the UCS attempts retraction. o Messages that have been delivered will be retained as cancelled. o If the required retraction option is true and the message has been

delivered via a service that does not support retraction, a Feature Not Supported exception will be generated and the message state left unchanged.

• Exception Conditions: o Invalid Message o Feature Not Supported o Service Offline

• Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

The operation is also used in the role of cancelling a conversation request.

Send Message


This operation sends a message. The message may have already been created or the entire message must be provided. Sending the message will initiate validity checking of the message. • Story Board(s) After the VoIP connection is established, Dr. Doe begins 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 To send by Message ID, the message must have been created first.


§ Message (Fully formed) or Message ID (Created) o Outputs:

§ Success/Fail § Message ID

• Post-Conditions: o Message is assigned a Message ID if it does not already have one. o Invalid messages are not sent to the service adapter but are retained. o Valid messages are delivered to the service adapters as indicated by

their address and protocol type. For example, “[email protected]” goes to the email adaptor because of its MIME type.

• Exception Conditions: o Invalid Message o Invalid Content o Missing Body Type o Bad Body o Invalid Address o Unknown Service o Delivery o Message Delivery Timeout o Service Adapter Fault o Undeliverable Message o Feature Not Supported o Service Offline o Update o Read Only

• Notes


Figure 20: Send Message Fully Formed

The exceptions that might be generated by this operation may be immediate or deferred, depending on the synchronicity of the message and the implementing service adapter. The effect of sending a message that was not already created is identical to first creating the message and then sending by ID.

Update Message This operation is used to modify a message. Unsent messages are considered fully mutable except for the message ID and creation information. Once a message is sent, the message is immutable. • 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 Message must exist. o Message must not have been sent


§ Message id § Message § Check Update (True/False)


• Post-Conditions: o Varies based on update.

• Exception Conditions: o Invalid Message o Invalid Content o Missing Body Type o Bad Body o Invalid Address o Unknown Service o Feature Not Supported o Update o Read Only o Service offline


The check update option allows the user to request that the message be validated as sendable.

Query Users This operation allows the UCS user directory to be searched. • 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 and uses the built-in patient directory to search for and locate the desired patient using first and last name. Three possibilities are returned.

• Pre-Conditions: None. • Conceptual Information Objects:

o Inputs: § Query

o Outputs: § List on Matching Users


• Post-Conditions: None. • Exception Conditions:

o Invalid Query • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

Retrieve User

This operation allows information about a specific user to be retrieved. • 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 and uses the built-in patient directory to search for and locate the desired patient using first and last name. Three possibilities are returned. She identifies that only the second option listed is of the correct age and sex. Selecting this entry returns the full directory entry including the patient’s VoIP handle. • Description: Retrieves information about a specific user • Pre-Conditions: None. • Conceptual Information Objects:

o Inputs: § User Id

o Outputs: § User Info


o Unknown User • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

Assert Presence This operation allows a client (user) to update their presence status. • Story Board(s) Dr. Jones has just signed off the clinical system which asserts that Dr. Jones is not available for direct application alerts. UCS notes this and will reprioritize the contact information for Dr. Jones and now use a pager to reach him. • Description: Updates presence status. • Pre-Conditions: None. • Conceptual Information Objects:

o Inputs: § User Id § Presence Status (Present/Absent/Undetermined) § Context

o Outputs: § Success/Fail



o Unknown User • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

Update Communications Preferences The update communications preferences provide users the ability to change their communications preferences. This includes the priority and routing of various messages types and the actual physical contact details. • Story Board(s) Dr. Bombay has acquired a new smartphone. This phone not only has a new phone number but also includes an alert application. She updates her preferences with the new number and adds the alert provider to her profile. • Description: Allows a user to update their communications profile. • Pre-Conditions: None. • Conceptual Information Objects:

o Inputs: § User id § New Preferences


• Post-Conditions: o All messages pending to the user will use the new preferences. o Outstanding messages to providers no longer supported by the user are

retracted. • Exception Conditions:

o Unknown User o Update


5.4 Conversation Interface The conversation interfaces allows clients to establish communication channels for conducting conversations.


Figure 21: Conversation with Response

Create Conversation This operation is used to create a conversation. • Story Board(s) Dr. Pennington would like to set up a discussion with a number of colleagues regarding Jane Doe’s current treatment. Dr. Pennington creates a conversation to track the dialog between him and the consulting specialists. A durable conversation is created to establish a narrative record and to allow additional specialists to be consulted as needed. • Description: Enables clients to create a conversation. • Pre-Conditions: • Conceptual Information Objects:

o Inputs: § Conversation

o Outputs: § Conversation Id § Success/Fail


o Invalid Message o Invalid Content o Missing Body Type o Bad Body o Invalid Address o Service Adapter Fault o Undeliverable Message o Feature Not Supported

• Notes


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 Conversation must exist. • Conceptual Information Objects:

o Inputs: § Conversation Id

o Outputs: § Success/Failure § Conversation handle?

• Post-Conditions: o Conversation should be connected if possible

• Exception Conditions: o Invalid Conversation o Invalid Address o Unknown Service o Service Adapter Fault o Undeliverable Message o Feature Not Supported o Read Only

• Notes


Figure 22: Conversation Request and Acceptance

The actual effect of connecting the conversation is dependent on the nature of the service providing the capability. For example, a connect on a VoIP connection might establish the call, while a text service might assert presence and fetch recent content.

Disconnect Conversation This operation disconnects an active conversation. • Story Board(s) Upon completing her business with the diabetic patient, Dr. Doe says goodbye and hangs up.


• Description: Enables authenticated clients to disconnect gracefully from a communication channel.

• Pre-Conditions: o Conversation Must Exist o Conversation must be connected


§ Conversation Id o Outputs:

§ Success/Fail • Post-Conditions:

o Conversation should be disconnected o Transient conversations are removed.

• Exception Conditions: o Not Connected o Invalid Conversation o Unknown Service o Delivery o Service Adapter Fault o Feature Not Supported o Read Only


The actual effect of disconnecting the conversation is dependent on the nature of the service providing the capability. For example, a disconnect on a VoIP connection might hang up the call, while a text service might assert presence lost.

Query Conversations Search for existing conversations. This search may include active and discontinued conversations depending on the nature of the query. • Story Board(s) Nurse Tanaka needs is part of an ongoing conversation about new clinical hygiene standards and has new information gained from his research which he would like to share with the work group. He uses this operation to look up the existing conversation so the new information can be posted to it. • Description: Search for conversations. • Pre-Conditions:

o Query must be valid • Conceptual Information Objects:

o Inputs: § Conversation Query § Query Filters

o Outputs:


§ List of matching conversation metadata. • Post-Conditions: None. • Exception Conditions:

o Invalid Query o Feature Not Supported


Retrieve Conversation This operation retrieves a conversation and references to the messages relating to

it. • Story Board(s) Nurse Tanaka, having discovered the correct conversation, pulls it up to make sure that no one else has already posted the information he discovered. • Description: Retrieves a conversation by Id • Pre-Conditions:


o Inputs: § Conversation Id

o Outputs: § Conversation § List of Messages in the conversation.


o Invalid Conversation o Feature Not Supported


In actual implementation, this operation might be split into two parts: one for the conversation metadata and another to query or retrieve the actual conversation content such as the messages relating to it.

Update Conversation • Story Board(s) Nurse Tanaka discovered that by oversight Dr. Jones was not a part of the Hygiene discussion. He updates the conversation to include Dr. Jones as a participant. • Description: • Pre-Conditions:


o Inputs:


§ Conversation Id § Conversation



o Invalid Address o Unknown Service o Service Adapter Fault o Feature Not Supported o Update o Read Only

• Notes

5.5 UCS Client Interface The UCS Client interface is implemented by client communications systems to provide an asynchronous call back point. The UCS server will uses this interface to inform the client of communications events. Receive Message This operation is called on a client system when a message is received. • 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:

o Interface must be the user’s profile on the UCS server. o The endpoint of the interface must be accessible to the UCS server.


§ User(s) § Message

o Outputs: § Acknowledgement

• Post-Conditions: o Delivery of the message to the client is tracked.

• Exception Conditions: • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

Call Ready This operation is called on a client system when a call is ready.


• Story Board(s) Dr. Doe needs to speak directly with a patient. He has set up a call request for a window of time reserved for handling patient calls. When the call is successfully connected to the patient, Dr. Doe’s phone automatically rings and connects with the patient on answer. • Description: Provides a call back point to client systems to indicate that a call

(conversation) is ready. • Pre-Conditions:

o Call request must exist and connect. • Conceptual Information Objects:

o Inputs: § Conversation § Call Handle


• Post-Conditions: o Call Ready notification is tracked.

• Exception Conditions: None. • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

Handle Notification This operation is used to notify the client of communications events. • Story Board(s) A message was sent requesting delivery acknowledgment. When the message is delivered, the client system is notified. • Description: Notify the client of communications events. • Pre-Conditions:

o Communications Event relevant to the client must exist. • Conceptual Information Objects:



• Post-Conditions: o Delivery of Notification is tracked.


Handle Response This operation is used to notify the client of a communications event that requires a response.


• Story Board(s) A CDS sends an alert that requires the receiver to choose an action. When an action is returned by the receiver, the client application is informed. • Description: Notify the client of a communications event that requires a

response. • Pre-Conditions:

o UCS Server has received a response message. • Conceptual Information Objects:


o Outputs: § Response Message

• Post-Conditions: o Delivery of the Handle Response is tracked.

• Exception Conditions: o Invalid Message o Invalid Content o Missing Body Type o Bad Body o Service Adapter Fault o Undeliverable Message o Feature Not Supported


Handle Exception This operation is called to notify the client of a message processing exception. • Story Board(s) A message is sent to a physical mail address that does not exist, causing a delivery exception. . The sender client system is notified of the error.

• Description: Provides a handler interface for communication end points to pass back transmission errors or communication exceptions. Exceptions are generally passed back to the sender and possibly registered workflow engines.

• Pre-Conditions: o New Exception is present on the UCS server. o UCS Client Interface is registered for sender. o UCS Client Interface may be registered for Workflow handling


§ Message § User § Exception

o Outputs:


§ Acknowledgement • Post-Conditions:

o Exception is tracked as delivered. o Exception may be retained for auditing purposes.

• Exception Conditions: • Notes

Figure 23: Undeliverable Message

5.6 Alerting Interface The alerting interface provides a mechanism whereby alert clients can update the state of an alert with the UCS server.


Figure 24: Alert with Acknowledgement

Update Alert message This operation provides the ability for an alert client to update an alert they have received. For example, a client might update the status of the alert to “acknowledged.” • Story Board(s) Dr. Jones has received an alert from a CPOE system which he then reviews and acknowledges as received. The CPOE system calls the UCS server and updates the alert to an acknowledged status. • Description: Allows alert client to update an alert. • Pre-Conditions:

o Client must have been sent the alert in question. • Conceptual Information Objects:

o Inputs: § Alert


• Post-Conditions:


o An update message is not sent to the originating client. • Exception Conditions:

o Invalid Message o Invalid Content o Unknown Service o Service Adapter Fault o Feature Not Supported o Update o Read Only


5.7 UCS Alerting Interface The UCS Alerting interfaces provides a client side interface to receive alerts from the UCS server.

Cancel Alert Message This operation is called when an alert is cancelled. • Story Board(s) An automated wide area alert about a public health issue has been sent to a number of concerned systems. The conditions causing this alert have passed and a cancellation message is sent out. • Description: Informs an alert client that a specific alert was cancelled. • Pre-Conditions:

o Alert is cancelled or client is no longer in the receipt list. • Conceptual Information Objects:

o Inputs: § Alert Message.


• Post-Conditions: o The alert should now be considered final and no further action taken

with it. • Exception Conditions: • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

The entire old alert message is provided for stateless clients.

Receive Alert Message This operation is called to inform an alert client of a new alert message. • Story Board(s) A patient’s lab results are analyzed by a CDS system and a number of the results raise specific concerns. The CDS system determines the primary care team for the patient and generates an


alert message. This message is then delivered to the client system associated be each user in the care team. • Description: Informs the alert client of a new alert message directed to it. • Pre-Conditions:

o Alert Message is received by UCS. • Conceptual Information Objects:

o Inputs: § Alert Message


• Post-Conditions: o Alert delivery to client is tracked as complete.

• Exception Conditions: None • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

Update Alert Message This operation is called to inform an alert client of a change to an alert it has received. • Story Board(s) Both Dr. Smith and Dr. Jones are alerted to a change in the patient’s condition that requires the acknowledgement from a care provider. Dr. Jones views and acknowledges the alert. An update message is sent to Dr. Smith’s system, allowing it to indicate that the alert has been acknowledged. • Description: Informs the alert client of a change in an alert. • Pre-Conditions:

o Change does not originate from the client in question. • Conceptual Information Objects:

o Inputs: § New Alert Message § Old Alert Message


• Post-Conditions: o Alert update to client is tracked as complete.


The old message is included for reference. We might also consider a change transaction type (e.g., content, status, etc.).


5.8 Adapter Interface The Adapter interface is used by service adapters to communicate with the UCS server. It is considered a privileged interface with regard to messages relating to the specific adapter. In actual implementation it is expected that many Adapter implementations might share resources directly with the server.

Conversation Ready This operation is used to inform the UCS server that a conversation is ready. • Story Board(s) A Service adapter receives a request to set up a call. When the call is ready, the adapter informs the UCS Server. • Description: Informs the UCS server that a conversation is ready. • Pre-Conditions:

o Conversation must exist or be created. • Conceptual Information Objects:

o Inputs: § Conversation



o Invalid Conversation. o Undeliverable Message o Feature Not Supported o Read Only


A service adapter may accept unsolicited conversations, in which event it may use the Conversation interface to create the new conversation.

Conversation Update This operation allows a service adapter to update the characteristic of a conversation it is a part of. • Story Board(s) A multiparty conversation is started and only three out of six participants are in the call. A connection to one of the missing participants is established and the characteristics of the conversation are updated to indicate the presence of the fourth member. • Description: Updates a conversation associated with service adapter. • Pre-Conditions:


o Inputs: § Conversation Id § Conversation



• Post-Conditions: o Conversation is updated.

• Exception Conditions: o Invalid Conversation o Unknown Service o Feature Not Supported o Update o Read Only


Post Exception This operation allows a service adapter to asynchronously inform the UCS server of an exception. • Story Board(s) A secure mail adapter is requested to send a message to a specific provider. The provider’s secure credentials are expired and the message may not be delivered. The adapter informs the UCS server of the delivery exception. • Description: Informs the UCS server of an exception. • Pre-Conditions:

o Exception condition must exist at the adapter level. • Conceptual Information Objects:

o Inputs: § Exception § Type (message/conversation) § Id (message/conversation)


• Post-Conditions: o UCS Server handles exception.

• Exception Conditions: o Invalid Message o Invalid Conversation


5.9 UCS Adapter Interface The UCS Adapter Interface is the essential contract that a service adapter implements to allow the UCS server to use it.

Cancel Message


This operation allows the UCS server to inform the service adapter that a specific message should be cancelled. • Story Board(s) Dr. Jones has initiated a call request to a patient. . An emergency presents and Dr. Jones cancels the call request. The UCS server forwards a cancellation on the service adapter. • Description: Cancels a message with the Service Adapter. • Pre-Conditions:

o Message must have been sent to the adapter before. • Conceptual Information Objects:

o Inputs: § Message § Message Id

o Outputs: § Success state (uncancellable, retracted, cancelled)

• Post-Conditions: o Message may be retracted. o Message/Conversation may be terminated. o Message may be removed. o Varies based on the service implementation

• Exception Conditions: o Invalid Message o Delivery o Message Delivery Timeout o Service Adapter Fault o Feature Not Supported o Read Only


The actual effect is dependent on the nature of the service implementation. The intent of the operation is the cancel/retract the message.

Send Message This operation is used to initiate the sending of a message. • Story Board(s) A CDS system detects that an alert should be sent. This alert message is forwarded by the UCS Server to the adapter to deliver the alert. • Description: Delivers a message to the service adapter requesting delivery. • Pre-Conditions:

o Message must be well formed. • Conceptual Information Objects:


o Outputs:


§ Success/Failure • Post-Conditions:

o Attempt is made to deliver the message. o Varies based on the service implementation

• Exception Conditions: o Invalid Message o Invalid Content o Missing Body Type o Bad Body o Invalid Address o Unknown Service o Delivery o Message Delivery Timeout o Service Adapter Fault o Undeliverable Message o Feature Not Supported


The actual effect is dependent on the nature of the service implementation. The intent of the operation is to act on the message to create the communication.

Update Message This operation is used to inform the service adapter that a message has been updated. How the adapter treats this message is relative to its service implementation. For example, an Alert Adapter would call the UCS Alert Update of the related consumer, while a Publication adapter would change the published message. A VoIP Adapter might add or remove a participant. • Story Board(s) Dr. Jones adds Dr. Smith to a VoIP call he is engaged in. The UCS Adapter forwards his request to the associated service adapter. • Description: Signals a change in a message to the adapter. • Pre-Conditions:

o Message must have been sent to the adapter. • Conceptual Information Objects:

o Inputs: § Message § Old Message

o Outputs: § Accept/Reject

• Post-Conditions: o Varies based on the service implementation

• Exception Conditions:


o Invalid Message o Invalid Content o Missing Body Type o Bad Body o Invalid Address o Unknown Service o Delivery o Message Delivery Timeout o Service Adapter Fault o Undeliverable Message o Feature Not Supported o Update o Read Only


Get Service ID This operation returns the ID associated with an instance of an adapter. The identity is instance specific, rather than adapter specific, to allow an adapter to be reused in multiple contexts. • Story Board(s) The UCS Server checks with each adapter instance to build a run-time service ID registry so it can route messages to the correct adapter instances. • Description: Get the Adapter Instance Id. • Pre-Conditions: • Conceptual Information Objects:

o Inputs: § None

o Outputs: § Adapter Instance Id


o None • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

Get Interaction Types This operation will return a list of the interaction types supported by a particular adapter instance. • Story Board(s) An update to a service adapter is installed and the UCS server checks with the updated adapter to see if there are any changes to the service contract. • Description: Returns the interaction types supported by the instance.


• Pre-Conditions: • Conceptual Information Objects:

o Inputs: § None

o Outputs: § List of Supported Interaction types.

• Post-Conditions: • Exception Conditions: • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

5.10 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 the number of pending VoIP calls. • Description: Enables clients to inquire about the status of different service

functions or execution events passed as a parameterized list. This API might support inquiries 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.


o Inputs: § Capability Type (e.g., general, message, event, etc.) § Capability Id(s)

o Outputs: § Status(s)


o Invalid Message o Invalid Content o Invalid Conversation o Unknown Service o Service Adapter Fault o Feature Not Supported



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 allowing 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 Service must be active.


§ Service Adapter Id(s) o Outputs:

§ Success/Failure • Post-Conditions:

o Traffic to the service is deferred o Critical messages may receive a service offline exception. o Non time critical connections will be deferred.

• Exception Conditions: o Unknown Service o Service Adapter Fault o Feature Not Supported


Resume Channel This operation allows a suspended channel to be resumed. • 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 Service must be suspended • Conceptual Information Objects:

o Inputs: § Service Adapter Id(s)


• Post-Conditions:


o Service resumes normal operations. • Exception Conditions:

o Unknown Service o Service Adapter Fault o Feature Not Supported


Discover Channels This operation provides a mechanism to find what communications channels are available on a particular UCS Server. • 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: None. • Conceptual Information Objects:

o Inputs: § None

o Outputs: § List of Available channel metadata


o Feature Not Supported • 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.



o Inputs: § Conversation/Message/Event Id(s) § Query

o Outputs: § List of Event Metadata


o Invalid Message o Invalid Conversation o Invalid Query o Feature Not Supported


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 event or set of related events. Applicable typically to messaging patterns.

• Pre-Conditions: o Messages must exist


§ List of Message Ids o Outputs:

§ List of Content • Post-Conditions: None. • Exception Conditions:

o Invalid Message • Aspects left for Technical Bindings (optional) • Reference to Functional Profiles (optional) • Notes

6 Profiles

6.1 Introduction A set of profiles is to be defined that covers 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 data-‐oriented, 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

6.2 Base Conformance Profile The following are the operations that must be implemented to support a base configuration profile. This profile is a bare minimum base which other profiles build on.

Interface Operation Requirement

Client Create Message Yes

Send Message Yes



Update Messages Yes

Retrieve Message Yes

Cancel Message Recommended

Query Messages Yes

Assert Presence No

Query Users Recommended

Retrieve User Recommended

Update Communications Preferences

No

Adapter Conversation Ready No

Conversation Update No

Post Exception Yes

UCS Adapter Send Message Yes

Update Message Recommended

Cancel Message Recommended

Get Service Id Yes



Get Interaction Types Yes

6.3 Conversation Conformance Profile The following are the operations that must be implemented to support conversations. This profile builds on the base conformance profile.


Conversation Create Conversation Yes

Connect Conversation Yes

Disconnect Conversation Yes

Query Conversations Yes

Retrieve Conversation Update Conversation

Adapter Conversation Ready Yes

Conversation Update Yes

Post Exception Yes

UCS Client Call Ready Yes

Receive Message Recommended

Handle Exception Recommended



Handle Notification Recommended

Handle Response Recommended

6.4 Alert Conformance Profile The following are the operations that must be implemented to support Alerts. This profile builds on the base conformance profile.


UCS Alerting (Via Service Adapter)

Receive Alert Message Yes

Update Alert Message Yes

Cancel Alert Message Yes

Alerting Update Alert Status Yes

UCS Client Handle Notification Yes

Handle Exception Yes

7 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.


8 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 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.


9 Appendix B - 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 Full Name ANSI American National Standards Institute (U.S.A.) CDS Clinical decision support CDSS Clinical Decision Support Service (synonymous with DSS) DRG Data requirement group DRI Data requirement item DSS Decision Support Service HITSP Health Information Technology Standards Panel HSSP Healthcare Services Specification Project IHE Integrating the Healthcare Enterprise ISO International Organization for Standardization KM Knowledge Module OMG Object Management Group PIM Platform Independent Model PSM Platform Specific Model RIM Reference Information Model defined by HL7 RM-ODP Reference Model of Open Distributed Processing SFM Service Functional Model UML Unified Modeling Language


10 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 Function Name EHR Function Statement Notes For every row, explain the rationale for including in this specification.


11 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.


12 Appendix E - Examples TODO: Alerts

Email

Voice

Conversation

On going conversation

Documents

HL7 Version 3 Specification: Unified Communication …€¦ · Page 2 HL7 Version 3 Specification: Unified Communication Service Interface, Release 1 ... HL7 Version 3 Specification: