V3_SOA_EPSSRVINT_R1_O1_2014SEP
HL7 Version 3 Specification: Event Publish &
Subscribe Service Interface, Release 1 - US Realm
September 2014
HL7 Draft Ballot
Sponsored by:
Services Oriented Architecture Work Group HL7
Clinical Decision Support Working Group HL7
Copyright © 2014 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 1 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Project Lead
Emory Fry, MD
Editor
Alfred Bustamante
Authors
Emory Fry, MD
Jerry Goodnough
Claude Nanjo
Page 2 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Preface
Notes to Readers
This document is the Service Functional Model (SFM) for the Event Publish and
Subscribe Service (EPS), 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
(SOA). There could be many different ways of implementing all or part of the
functionality to support the behavior described in this specification.
Acknowledgements
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
Page 3
September 2014
© 2014 Health Level Seven International. All rights reserved.
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), nonexclusive 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.
Page 4 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Table of Contents
Overview ............................................................................................................................. 8
1. Introduction ............................................................................................................... 8
1.1.1 HL7-OMG Healthcare Services Specification Project (HSSP) .............................. 8
1.1.2 Service Definition Principles .................................................................................. 9
1.2 Overall disclaimers ............................................................................................... 10
1.3 Readers Guide ....................................................................................................... 10
2 Executive Summary .................................................................................................... 10
2.1 Service Overview .................................................................................................. 10
2.1.1 Service Description and Purpose .......................................................................... 10
2.1.2 Scope ..................................................................................................................... 12
2.1.3 Security ................................................................................................................. 12
2.1.4 The Reason Why the Service Is Necessary........................................................... 13
2.2 Context of this SFM within HSSP Roadmap ........................................................ 14
2.3 Structure of the Service ......................................................................................... 16
2.3.1 Service Architecture.............................................................................................. 18
2.4 Implementation Considerations ............................................................................ 19
2.5 Deployment Scenarios .......................................................................................... 20
2.5.1 Hybrid organizational deployment ....................................................................... 20
3 Business Storyboards .................................................................................................. 21
4 Assumptions and Dependencies ................................................................................. 21
5 Detailed Functional Model ......................................................................................... 22
5.1 Domain Model ...................................................................................................... 22
5.2 Entities .................................................................................................................. 23
5.2.1 Functional Entities ................................................................................................ 23
5.2.2 Informational Entities ........................................................................................... 24
5.2.3 Interface Summary ................................................................................................ 26
5.2.4 Handling Data Collections .................................................................................... 28
5.3 Common Topic & Channel Concepts ................................................................... 29
5.3.1 Retention ............................................................................................................... 29
5.3.2 Durability .............................................................................................................. 30
5.3.3 Delivery Guarantee ............................................................................................... 30
5.3.4 Priority .................................................................................................................. 30
5.3.5 Sequencing ............................................................................................................ 30
5.3.6 Topic Constraints .................................................................................................. 31
5.3.6.1 Content Publication Restrictions..................................................................... 31
5.3.6.2 Minimum Subscriber QOS ............................................................................. 31
5.3.6.3 Maximum Subscriber QOS ............................................................................. 31
5.3.7 Topic Options........................................................................................................ 31
5.3.8 Topic Identity ........................................................................................................ 32
5.3.9 The Topic Tree ...................................................................................................... 32
5.3.10 Message Identity .............................................................................................. 33
5.3.11 Message Lifecycle ........................................................................................... 33
5.3.11.1 Message States .............................................................................................. 34
5.3.12 Common Message Elements ............................................................................ 35
5.3.13 The Message Event Content ............................................................................ 36
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
Page 5
September 2014
© 2014 Health Level Seven International. All rights reserved.
5.3.14 Broker Options ................................................................................................. 36
5.4 The Subscription ................................................................................................... 37
5.5 Event Message Dynamics ..................................................................................... 37
5.5.1 Pull Based Subscriptions....................................................................................... 37
5.5.2 Push Based Subscriptions ..................................................................................... 38
5.5.3 Effects of Presence ................................................................................................ 38
5.5.3.1 Presence State ................................................................................................. 39
5.5.4 Event Replay and Dynamics ................................................................................. 39
5.5.5 Publish-on-Demand Dynamics ............................................................................. 40
5.5.5.1 Base Support ................................................................................................... 40
5.5.5.2 Pull .................................................................................................................. 40
5.5.5.3 Replay Support................................................................................................ 41
5.5.5.4 Dynamic Topics .............................................................................................. 41
5.6 Message Review, Approval, Modification and Filtering ...................................... 41
5.7 Federation ............................................................................................................. 41
5.8 Service Level Security Roles ................................................................................ 42
5.9 Exceptions ............................................................................................................. 42
5.10 Publication Interface ............................................................................................. 43
5.11 Subscription Interface ........................................................................................... 46
5.12 Broker Interface .................................................................................................... 56
5.13 Broker Management Interface .............................................................................. 62
5.14 Topic Management Interface ................................................................................ 71
5.15 Broker Monitoring Interface ................................................................................. 79
5.16 Federation interface .............................................................................................. 81
5.17 PS Federation interface ......................................................................................... 85
5.18 PS Publish-on-demand Interface........................................................................... 88
5.19 PS Subscription Client Interface ........................................................................... 93
5.20 PS Publication Intervention Interface ................................................................... 95
5.21 PS Content Brokering Interface ............................................................................ 96
5.22 PS Delivery Intervention interface........................................................................ 98
6 Examples ................................................................................................................... 101
6.1 Auto Registration ................................................................................................ 101
6.2 Topic Navigation ................................................................................................ 101
6.3 Publication Review ............................................................................................. 102
6.4 Delivery review ................................................................................................... 104
6.4.1 Delivery review – Push Event............................................................................. 104
6.4.2 Delivery Review – Pull Request (List) ............................................................... 105
6.4.3 Delivery review – Pull Request (Detail) ............................................................. 107
6.5 Auto Register a publisher.................................................................................... 107
6.6 Auto Register a Subscriber ................................................................................. 108
6.7 Pull from an On Demand Publisher .................................................................... 110
6.8 On Demand Topic Tree ...................................................................................... 110
6.9 Topic Administration .......................................................................................... 112
6.10 User Administration ............................................................................................ 112
7 Profiles ...................................................................................................................... 113
7.1 Introduction ......................................................................................................... 113
Page 6 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
7.2 Base Conformance Profile .................................................................................. 114
7.3 Push Based Subscriptions Conformance Profile................................................. 115
7.4 Access Request Conformance Profile ................................................................. 116
7.5 Presence Conformance Profile ............................................................................ 116
7.6 Intervention Conformance Profile ...................................................................... 117
7.7 Replay Conformance Profile............................................................................... 117
7.8 Federation Conformance Profile ......................................................................... 117
8 System Interaction Details [Optional] ...................................................................... 118
9 Recommendations for Technical RFP Issuance ....................................................... 119
10 Appendix A - Relevant Standards............................................................................. 120
11 Appendix B - Glossary.............................................................................................. 121
12 Appendix C - HL7 EHR Functional Model Traceability.......................................... 123
13 Appendix D - Relationship to Information Content ................................................. 125
14 Appendix E – Functionality Comparison Matrix...................................................... 127
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
Page 7
September 2014
© 2014 Health Level Seven International. All rights reserved.
Overview
1. Introduction
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 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 Special Interest Group in
collaboration with other HL7 committees, which currently include the Vocabulary
Technical Committee (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.
Page 8 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
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” (see 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 Unified Modeling Language
(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 lowlevel 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.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
Page 9
September 2014
© 2014 Health Level Seven International. All rights reserved.
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
Domain Committees, SMEs
Architects, HSSP
RFP Submitters
Sections (In order of Priority)
2, 3, 8
5, 6, 8, 7, 4
2, 8, 7, 5
2 Executive Summary
2.1
Service Overview
2.1.1 Service Description and Purpose
In many Service Oriented Architecture (SOA) environments, clinical messages generated
by systems or components on the network are sent to individual consumers who must a)
periodically request their data, and b) manage interfaces with numerous producers.
Because exchange participants do not necessarily share common, standardized messaging
formats, requestors are often responsible for the arduous task of collecting, parsing, and
normalizing each message prior to subsequent analysis.
Managing data distribution using polling techniques and non-standard point-to-point
interfaces is inherently inefficient and non-scalable. Costs associated with establishing
and maintaining tightly coupled, custom interfaces can be a significant. There are also
opportunity costs and patient safety concerns when clinical data cannot be consumed and
Page 10 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
acted on in near-real time - inpatient scenarios where acuity and risk are significantly
elevated have little tolerance for latency.
The Event Publish and Subscribe Service (EPS) is a type of notifier/observer service
intended to address these concerns. It does so by consolidating messaging regarding
clinical events, allowing different systems to subscribe and listen to specific types of
events or “topics” of interest, and allowing event publishers to publish events to these
topics when they occur. The service provides a foundation for a wide variety of
responsive, dynamic applications, including new result feeds, content syndication,
subscriber and publisher presence related behavior, and clinical workflow systems.
Indeed, any application that requires event notifications to operate and perform efficiently
stands to benefit. In general, EPS offers event publisher and consumers the following:

Architectural flexibility, enabling event subscribers to be easily added, managed,
and notified of clinical events using standardized messaging and interfaces

Consumer empowerment, allowing stakeholders to manage their own data
requirements and subscriptions (see The Subscription) more efficiently and
dynamically

More efficient resource utilization, resulting from the need to forward messages
only to interested parties with the right privileges to access this information.

Parallel processing to enhance performance and scalability.
The EPS defines two additional capabilities of particular value to the healthcare
enterprise. The first benefit is Content Intervention in which the service actively
intervenes during the publication of event data to the EPS service or during delivery to a
specific subscriber. Interventions can include activities such as data analysis,
rejection/filtering, supplementation, alteration, and redaction. Content intervention has
important implications for security and privacy enforcement. For example, if a patient has
restricted current and future mental health diagnosis from being disclosed to anyone other
than a psychiatrist, a “New Diagnosis” topic published by an EPS service could use
content intervention to selectively redact such information from the data provided to any
subscriber who was not a psychiatrist all the while including such diagnoses for patients
that explicitly authorized more general disclosure.
A second benefit is Content Brokering where the service provides support for deferred
content delivery and negotiation. The EPS service, acting as an intermediary, can manage
content requests from clients in situations where it is not desirable to have the original
material publicly available or when subscribers want to negotiate to receive information
in a preferred form (format, character set, reading level, etc.) For example, a system
might subscribe to a content provider’s topic consisting of free Center for Disease
Control (CDC) Morbidity and Mortality Weekly Reports in English, but occasionally
broker a request for a paid translation into Latvian.
Finally, EPS provides effective architecture to specify, scope, and implement information
exchanges. Whether this interoperability is among departments, systems, or
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 11
September 2014
© 2014 Health Level Seven International. All rights reserved.
organizations, EPS provides a flexible specification for building dynamic, responsive
infrastructure well suited to the distributed, privacy sensitive, and increasingly regulated
information network upon which modern healthcare is dependent.
2.1.2 Scope
The EPS Functional Model specification seeks to define, in general terms, the capabilities
that must be realized by an interface to publish and subscribe to events and information.
For an overview of how this service functional model relates to existing pub/sub
standards, please refer to Appendix E – Functionality Comparison Matrix. The service
focuses on new “events,” not pre-existing data to which a consumer may already have
access. The service should not be used for historical data queries, for example, or for
requesting information from an external source. For this reason, data that is exposed by
the EPS service is always assumed to be “new” to the system for the purposes of analysis.
In addition, the EPS service is not intended to be a front end for adding such new data to
an existing repository.
Although the EPS service defines a protocol for how messages can be distributed to
consuming systems, it does not orchestrate these events. Its role is that of a provider of
information to authenticated and authorized consumers. The EPS service does not
manage state metadata or analyze content to facilitate routing messages to specific topics.
Events are published by the service as pre-defined topics using standardized data
packages. The EPS is stateless without special state-based branching or handling. This
helps minimize resources, maximize throughput, and ensure scalability because no
“decision logic” is necessary in order to manage its subscribers.
Finally, the manner in which services and interfaces are deployed, discovered, etc., is
outside the scope of this functional model. These aspects are left to a conformant Service
Technical Model (STM) and a number of implementation guides that will be made
available over time. All other interactions within the scenarios identified below are
considered to be in scope.
2.1.3 Security
Given the private nature of health information and the central role EPS plays in the
coordination of health information across security boundaries, it is vital that the EPS be
properly secured. EPS provides a number of ways to secure health information as it
transits from content producers to content subscribers:

Compliant EPS implementations will be required to provide a means of
authenticating with the broker. This level of security provides a level of control as
to who is allowed to publish or subscribe to content topics.
Page 12 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014

Compliant EPS implementation will be required to control access to sensitive
topics using appropriate authorization schemes and access control lists (ACLs).
Such authorization may be granted to either publishers or subscribers of content
as dictated by the security policy requirements associated with sensitive content.
This can allow topics to be made available to only those entities that have
sufficient privileges to post or receive potentially sensitive information such as
lab results.

Additional security can be provided on the content’s message envelope itself. In
this case, sensitive content may be associated with metadata which can be filtered
appropriately using publisher or subscriber interventions, depending on the use
case involved. Publisher interventions may filter sensitive content prior to
delivery to all subscribers of the topic. Subscriber interventions allow fine-grained
filtering based on the privileges and characteristics associated with each
individual subscriber. Both are controlled and invoked by the broker.

In addition to content metadata filtering, content may be filtered based on the
nature of content being exchanged. For instance, certain classes of content (e.g.,
an FHIR Diagnostic Result) may be filtered or redacted prior to submission. In
some cases, the filtering may be based on keywords or specific characteristics of
the content itself.
While this SFM acknowledges the importance of security in the exchange of health
information between parties by providing several mechanisms to ensure that the right
content makes it from the right producer to the right consumer, the details of such a
security framework are out-of-scope of this SFM and are rightfully addressed in the
Security Labeling Service SFM.
2.1.4 The Reason Why the Service Is Necessary
A standardized implementation of a clinical EPS offers several advantages. Two in
particular, loose coupling and scalability, are extremely useful in SOA.
Implementing loosely coupled services enables content publishers to be ignorant of
system topologies or even the existence of subscribers. Publishers and subscribers can
operate largely independently of each other. In traditional, tightly coupled architectures,
participants must be online and available. Many pub/sub systems decouple not only the
locations of the publishers and subscribers, but also decouple them temporally. EPS
promises to help implement resilient and flexible networks.
EPS can provide for better scalability than traditional client-server architectures by
offering parallel operation, message caching, tree-based or network-based routing, etc.
This is particularly important in distributed, multi-vendor environments or in scenarios
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 13
September 2014
© 2014 Health Level Seven International. All rights reserved.
where publishers and subscribers must exchange content across organizational
boundaries, for example, on the Nationwide Healthcare Information Network.
EPS can also help ‘extend’ the functionality of existing systems by defining standard
event publishing and listening capabilities. Because EPS can be implemented as a service
wrapper around existing capabilities, a content or data provider that has an established
client base would be able to continue providing services using existing approaches as
well (e.g., via existing application programming interfaces). Entities that may wish to
become EPS publishers include not only commercial companies, but also federal or state
organizations needing more effective ways of distributing their content.
Vendors that utilize data feeds to provide value added services might utilize a
standardized EPS to subscribe to specific messages across the range of topics required to
provide their specific services. They too benefit from reduced costs by not having to
build and maintain non-standard interfaces, by consuming more relevant content feeds,
and by being “pushed” information specific to their interests rather than relying on less
efficient “pull” techniques. They, in turn, can use EPS to publish the results of their
analysis back on the network, creating a marketplace in which data is consumed,
analyzed, and re-exposed dynamically.
Compliance to the EPS functional model provides the fundamentals for implementing an
organization’s business strategies that extend beyond core business components and
organizational boundaries. Interoperability services become an effective means by an
organization to meet the shifting industry or trading requirements that characterize the
healthcare industry. As such, EPS compliant services reduce implementation costs for an
organization while serving to meet the current and evolving interoperability strategies
imposed both from above and below.
Publish and Subscribe has emerged as a key design pattern used to manage many
complex data distribution and integration challenges. Without a commonly agreed upon
standard for the EPS, service consumers need to implement different interfaces when
dealing with different EPS implementations. A commonly accepted standard would make
it more attractive for service clients to invest in the infrastructure required for using EPS,
as they would be able to reuse the same interface to interact with multiple service
vendors. The definition of this service functional model is a first step in this direction.
2.2
Context of this SFM within HSSP Roadmap
The EPS is a logical extension of the Decision Support Service (DSS) 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 “plugand-play” components supplied by any number of healthcare software vendors. The EPS
functional model complements existing HL7 and OMG work products and activities,
leveraging content and lessons learned from elsewhere within both organizations.
Page 14 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 1: The complementary HL7 + OMG relationship
The EPS provides an efficient content distribution mechanism. Producers can publish
their content to any number of topics that consumers can subscribe to in order to have
events and information automatically pushed to them in real time.
To illustrate how an organization might utilize an EPS, consider the increasingly
important application of decision support technologies in the delivery 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 EPS service, which in turn immediately “pushes” the admission event to
topic subscribers. Subscribers might include any number of systems, including a Clinical
Decision Support (CDS) system that subsequently submits an unsigned Pediatric Asthma
Order Set to an attending physician to authorize, a case management system that
automatically assigns a caseworker, and a clinical research management system that
determines that the patient is eligible for a National Institute of Child Health and Human
Development (NICHD) study. This use case is illustrated in the sequence diagram below.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 15
September 2014
© 2014 Health Level Seven International. All rights reserved.
Figure 2: Prototypic use of EPS within an organization’s SOA.
2.3
Structure of the Service
The EPS allows “consumers” to subscribe to clinical events of interest and to be notified
when new data are available, typically receiving only a subset of all the messages
published. The process of selecting messages for reception and processing is called
filtering and can be categorized as topic-based or content-based.
In a topic-based architecture, content is published to "topics" or channels. A topic
subscriber receives all messages published to that topic as a “push” notification. All
subscribers to a topic generally receive the same messages; the topic owner is responsible
for defining the topics that can be subscribed to and for determining security
requirements.
In a content-based system, subscribers receive any message whose attributes or content
match constraints defined by the subscriber. The subscriber is responsible for classifying
the messages once it receives them.
The EPS service supports both content and topic based subscriptions using the following
core functional profiles:

Publication
The service allows a publisher to publish or delete an event in an already defined
topic. The publisher in question must typically have authenticated access to publish
Page 16 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
on the specific topic matter. More than one publisher might have privileges to publish
on a specific topic. A publisher might have privileges to publish a single event to
more than one topic.

Subscription
The service allows a subscriber to select topics with data of interest to them and to
assert some degree of control over the type of data received. The view of the topics
and scope of data provided to subscribers is constrained based on access control
information and content filtering mechanisms.

Topic Management
The service supports user and role management, providing fine gained access control
down to the individual topic level and allowing topic owners to control access to the
information distributed by the topic. Much of this is handled by managing the
affiliations (profiles that define the privileges afforded to a user) to a topic.

Federation
The service supports federation whereby an EPS broker can be a part of a larger
network of brokers, each responsible for publishing topics and information according
to their content provider contracts and individual configurations. Federation allows
multiple EPS systems to form a larger information resource, providing transparent
information sharing across multiple brokers for their user base.

Content Intervention
The service supports active intervention on information that is accepted for
publication. Interventions can include analysis, rejection/filtering, supplementation,
alteration, or redaction steps, and can be chained together to form simple workflows.
Interventions are configurable by broker managers and topic owners—they can be
applied uniformly across all subscriptions, or on a per delivery basis to a specific
subscriber.

Content Brokering
The service provides a facility for the dynamic delivery of content based on a
negotiation between the publisher and the subscriber. An indirect reference to content
can be passed in the body of a message, which can then be used by a consumer to
fetch the actual content in a separate transaction. This allows large artifacts and
multiple presentations of data to be supported efficiently and allows a broker to act as
an intermediary when the original source content is not publicly available to the
subscribers. For example, subscribers might use content brokering to get to
information in a specific, preferred form (format, character set, presentation,
language, etc.) rather than all representations that might be available.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 17
September 2014
© 2014 Health Level Seven International. All rights reserved.

Broker Administration
Administrative functionality includes registering users, creating and managing the
topics that producers can publish to, supporting subscriber consumer subscriptions,
banned users, ownership, whitelist, etc.
The core functionality and interfaces supported by EPS are illustrated in the diagram
below and described in more detail in subsequent sections.
Figure 3: Service Description
2.3.1 Service Architecture
EPS is conceptually aligned with a brokered publication model in which the service acts
as an intermediary managing all content contracts. An alternative model is peer-to-peer,
in which each publisher manages its own contracts with each subscriber. While most
operations relating to the brokered model may also be described in a peer-to-peer fashion,
it is believed that there are enough advantages provided by a dedicated broker model to
Page 18 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
advocate for this behavioral pattern. Some of the potential advantages to the brokered
model are listed below:
 Clients need only implement one simple contract.
 Provides support for multiple subscription forms (e.g., push, pull, or replay)
 Provides a single audit and control point
 Strong base for providing ACID and transactional properties
 Exhibits noninterference at a computational level with mission critical systems
 Provides a single point of implementation to the complex portions of the service
 Brokers may be validated and certified by appropriate bodies.
The broker provides a single business integration point that enables best of breed
capabilities to be developed without undue burden on publishers or subscribers. With a
goal of making the publisher/subscriber roles as lightweight as possible, the broker may
run independently of either.
Event Publish and Subscribe differs from a message bus in that the event stream is not
directed at a particular consumer but rather to a topic. Events are delivered on a basis
specified by individual consumers and may even be delayed for a significant time before
delivery. This temporal disconnect is another major difference from a message bus in that
subscribers may receive messages that existed before the subscription was created
depending on the retention (see Retention) strategy of the topic and the configuration of
the subscription.
2.4
Implementation Considerations
EPS is a service specification and is not intended to replace existing systems or
implementations, but rather to create an interface standard for a service-oriented layer
exposing healthcare assets and resources within an organization, or across organizations,
that meet business and/or clinical needs. EPS provides for low-cost, easily maintainable
components that can be modeled to fit most deployment scenarios.
EPS makes no assumption about implementation and is abstracted from the deployment
architecture behind its service contract. Consequently, any EPS deployment should
achieve the following goals:

Simplifies interoperability between organizations and systems, or departments, by
means of a common and standardized interface independent from an underlying
implementation.

Allows compliance to this standard to be testable and verifiable.

Is semantically extensible to meet expanding business needs.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 19
September 2014
© 2014 Health Level Seven International. All rights reserved.
2.5 Deployment Scenarios
EPS is an interface specification intended to support interoperability and is not an
implementation specification. There is nothing inherent in the specification that limits its
use to a single organization. Consequently, all scenarios herein should be considered nonnormative with regard to conformance to the EPS standard. They are offered for
explanatory purposes only and other topologies can be realized.
EPS can work in multiple different deployment topologies and can be used to support
different types of events. These are all deployment decisions, sensitive to deployment
context, and are valid insofar as they are explicitly profiled.
EPS exposes standardized interfaces that abstract the local implementation
characteristics. This ensures the EPS consumer is decoupled from the internal
applications technology and from the local application topology.
2.5.1 Hybrid organizational deployment
The figure below describes an exemplary organizational deployment scenario where EPS
takes the role of an enterprise resource manager. In this scenario, EPS mediates between
event producers and event subscribers that consume messages of specific interest. To
reiterate, nothing inherent in the specification limits EPS use to a single organization—
cross-organization EPS architecture is equally possible. This example shows a hybrid of
intra-organization and inter-organization deployment.
Figure 4: Representative EPS deployment in a cross-organizational setting (centralized)
Page 20 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
3 Business Storyboards
The following scenarios illustrate applications of the EPS to address a number of
important clinical use-cases:

A CDS system for pharmacy subscribes to those topics utilized by its rule base,
including prescriptions, allergies, and diagnoses. The service does not subscribe to
insurance or psychiatric topics as none of the rules in its knowledge base involve
these fact types. When new clinical data is published, the CDS system receives
pushed notification, resulting in timely analysis and alert generation.

The Information Technology department wishes to insure that postings to public
topics of interest conform to content guidelines, are virus free, and are appropriately
cataloged. The department configures its EPS system to filter and quality check all
inbound data published by its content producers.

A hospital Emergency Response Coordination system publishes granular casualty
case information including clinical acuity, injury type, and prognosis to Federal
subscribers (e.g., FEMA). The system uses content intervention to ensure that all
patient sensitive health information is appropriately redacted before subscribers
receive their topic feeds.

A patient scheduling system consumes a consult request topic and automatically
provides available time slots for a booking clerk to adjudicate. Appointment
availability is brokered/negotiated according to patient category (e.g., in-plan
beneficiaries receive priority access over out-of-plan patient).

A local hospital would like to incorporate a section of the CDC’s educational topics
with their own local topic tree. In order to accomplish this, they establish a federated
subscription with the CDC EPS.
4 Assumptions and Dependencies
Only external messages that are newer than the data contained in available databases will
be captured and received. The service would not be invoked to accommodate additional
historical medical records that may be introduced at a later time or upon initial setup of
the system (or sent erroneously by devices). The EPS module itself is not expected to
connect directly to historical data repositories.
One key assumption to the subscription service is that devices and systems that are
subscribers have unique identifiers—such as email, MAC, or IP addresses—and conform
to the site’s data security policy.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 21
September 2014
© 2014 Health Level Seven International. All rights reserved.
5 Detailed Functional Model
5.1 Domain Model
The following diagram is an overview of the functional model and shows functional
entities (see Functional Entities), informational entities (see Informational Entities), and
interfaces (see Interface Summary). This diagram is a simplified overview of the basic
structure. Certain elements have been excluded from the diagram in the interests of
clarity (e.g., exceptions). Each of the elements in the diagram will be described in greater
detail in following sections.
Page 22 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 5: Domain Model
5.2 Entities
The service functional model breaks entities into two major groups: functional entities
that exhibit behavior and information entities that contain data. Functional entities refer
to a specific role and are used for modeling. An actual functional entity may do
significantly more than is described by this document. Likewise, information entities
define a minimum set of information and, in an implementation, the model may have
significantly more attributes.
5.2.1 Functional Entities
The following diagram show the functional entities used in this document. In terms of
this model they can be regarded as roles or actors that take some action.
Figure 6: Functional Entitles






Broker. The broker is the main intermediary between publishers and subscribers
of information, thus decoupling their interaction. The broker also supports a
number of management options for the proper configuration of an EPS.
Publisher. The publisher is an entity that makes information or events available
by publishing it.
On Demand Publisher. The on demand publisher is a specialized form of
publisher that can offer data when a subscriber is interested in it.
Subscriber. The subscriber is a consumer of information.
Push Subscriber. The push subscriber is a specialized subscriber that can
actively receive information and events.
Content Provider. A content provider is an entity that can fulfill content requests
relating to an event.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 23
September 2014
© 2014 Health Level Seven International. All rights reserved.


Publication Reviewer. The publication reviewer is an entity that can review,
reject and alter publications prior to public publication. This provides a generic
mechanism for the implementation of content intervention during message
publication.
Delivery Reviewer. The delivery reviewer is an entity that can review, alter and
filter events and information on a subscriber level prior to the subscriber receiving
the data. This provides a generic mechanism for the implement of content
intervention on a per subscriber basis.
5.2.2 Informational Entities
The following diagram is a high level summary of the major information entities that the
EPS system handles. Each of the entities in the diagram is described in greater detail
further in this document. The entities described have the minimum set of attributes
defined, and it is expected that the technical specification would supplement the core set.
Page 24 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 7: Information Model
Information entities illustrated in the diagram above can be broken into five major
groups:
Topic related

Topic: A topic provides a convenient mechanism for grouping and organizing
events into cohorts so that they can be more easily managed.
Topic Metadata: Metadata is information that describes a topic, the types of events it
publishes, event durability (see Durability), etc.

Options: An option allows one or more characteristics of a topic to be configured.
For, example, Retention determines how long the service makes a topic event
available for clients to request.

Publication Contract: A contract that enables a publisher to deliver events that
are to be published by the service.

Subscription: A contract that enables a subscriber to receive events that have
been published to the service.
Event and Message related

Message: Messages provide the mechanism for participants to communicate and
exchange information.

Message Header: The message header provides routing and other metadata
required for sending and receiving messages.

Message Body: The message body contains the content of the message.

Management Event: A message that communicates operational information
about the service, its users, and the topics being published.

Management Event Header: The management event header provides routing
and other metadata required for sending and receiving management messages.

Authorship: Authorship identifies the source of the event being published.
Security & Ownership related

User: A user is a person with the authority to access the service, register a source
of events, or subscribe to a topic.

Affiliation: An affiliation is an access profile that defines the privileges afforded
to a user on a specific topic. (See Affiliation Role for more information on
privileges.)
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 25
September 2014
© 2014 Health Level Seven International. All rights reserved.

Access Model: Access model provides default security configuration for a topic,
for example, whether authorization is required for users or not, or if the topic is
not open for registration at all.

Access Request: A request by a publisher/subscriber to be able to be granted
access to the Service.

Affiliation Role: Specifies access privileges afforded to users by their affiliations
with specific topics (e.g., a publisher or a subscriber). A user may have multiple
roles on a topic. The granting of some roles on the topic may grant or revoke
other previous grants.
o Administrator – Allowed perform administrative actions
o Outcast – Prohibited from any actions on the topic
o Owner – Owner of the topic with full access
o Publish Only – May only publish to the topic
o Publisher – May publish to the topic
o Subscribe Only – May only subscribe to the topic
o Subscriber – May subscribe to the topic
o Reviewer – May review and accept or reject events subject to review
Broker related

Capabilities: A service capability communicates the functional abilities of a
particular implementation, for example, whether it can support on-demand
publishing, anonymous subscriptions, or configurable durability.
Communications related

Notification Address: The address (endpoint) at which a publisher or a
subscriber expects to receive communicates.

Channel: A channel is a communication queue related to a topic that manages
specific delivery dynamics. A single topic can have one or more channels
depending on the nature and capabilities of the server and the requested
subscription dynamics. For example a topic might have one channel that provides
ACID delivery of messages and another channel that is fire-and-forget.
5.2.3 Interface Summary
The following diagram is a summary of the interfaces that comprise the EPS System.
They are organized into three main groups: Callable on the broker, Called by the broker,
and those that are both. By convention, any interface starting with the prefix “PS” is an
interface that the broker may call.
Page 26 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 8: Class Interface Summary
Callable on Broker Interfaces

Broker. Provides basic broker information. The broker provides operations that
are common to all classes of users be they publishers and/or subscribers, for
example, getting access to topics.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 27
September 2014
© 2014 Health Level Seven International. All rights reserved.






Broker Management. Provides access to broker-wide operations for
administrations, for example, creating users and topics.
Broker Monitoring. Administrative interface to assess broker health and
operations such monitoring traffic volume.
Federation. Provide information and control of broker federation.
Publication. Used by publishers to publish information and events.
Subscription. Used by subscribers to manage subscription and enquiries into
publications.
Topic Management. Used by topic administrators to control access to
information on the topic.
Implemented by Broker and Called by Broker Interfaces


PS Federation. Implemented and used by brokers to support federated content.
PS Content Brokering. Implemented by broker and selected publishers and used
by brokers to negotiate and mediate content to subscribers.
Called by Broker Interfaces




PS Delivery Intervention. Called by the broker and implemented by delivery
reviewers to filter and redact events on a per subscribers basis.
PS Publish On Demand. Implemented by publishers this interfaces allows the
broker to contact a publisher to dynamically provide events and topics.
PS Publication Intervention. Implemented by the publication reviewer and
invoked by the broker to review content prior to accepting it for publication.
PS Subscription Client. Implemented by subscribers and invoked by the broker
to push events to the subscriber.
5.2.4 Handling Data Collections
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 collections can
contain either all members of the collection or a subset of the members with a link to
fetch the rest. An example might be a paged list of results following a search on a web
site. Moreover, the operation might return full instances of data or some summary form
with a reference where the full detail information may be retrieved. An example might be
a summarized list of results with a link to get the full detail for each instance such as a list
of news articles on a news website. Collections of data represented in tree form may be
returned in a ‘lazy’ manner whereby children dependencies are only fetched when
needed. This is typical in drill-down approaches to hierarchical content—e.g., drilling
down a catalog on Amazon.com or lazy loading of dependencies in an object relational
management framework such as Hibernate. The techniques above ensure that all result
sets are reasonable in size and neither overwhelm computing resources nor result in
slower overall performance.
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
Page 28 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
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
shall be provided, with configurable 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.
5.3 Common Topic & Channel Concepts
Each topic in the topic tree is a possible source for one or more subscription contracts. To
the extent that different subscriptions have varying requirements, a topic may have
multiple channels of communication that meet those minimum contract requirements.
The topic hides channels from the user. All interaction occurs at the topic level. A single
topic may present its events according to the broker’s capabilities and the options enabled
on a specific topic. By default, a topic will support all possible subscription options. The
defaults should be modifiable at broker level. It should also be possible to have a topic
constrain the subscription quality of service (QOS) (See Minimum and Maximum
Subscriber QOS).
Topics exhibit a number of distinct, yet inter-related, characteristics that describe the
general behavior of the messages in the topic. At a high level, these characteristics are
durability, retention, priority, delivery guarantee, sequencing, topic constraints, content
restrictions, minimum and maximum QOS. Each of these characteristics is covered in
more detail in the following section.
5.3.1 Retention
Topic configuration includes the notion of message retention. Retention defines if events
are retained after all subscribers have received them. For example, do they time out
(cease delivery attempts after a fixed time period) and do they expire? Topic may be
configured to provide an expiration time for events posted to it, which may override the
expiration time included on the event. The retention policy will directly interact with the
receipt of messages by subscribers by both push and pull means. A topic that wishes to
support replay must therefore have a compatible retention policy. The following are some
of the possible retention policies:







Permanent
Until Delivered
Not Retained
Fixed Time period
Until Expired
Fixed Period after Delivery
Fixed Period after Expiration
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 29
September 2014
© 2014 Health Level Seven International. All rights reserved.
5.3.2 Durability
Durability is an ACID transaction property that ensures that once a transaction commits,
the committed content will be retained even after a system crash. That is, the content is
no longer transient. Topics may exhibit multiple types of event durability. Durability
interacts with the ability of a topic to receive and deliver a message in a transactional
manner. Durability is explicitly related to the integrity of the event handling. The
spectrum of durability covers topics that are transient in nature to topics where full
transaction message qualities are required.
5.3.3 Delivery Guarantee
Each topic may be configured to provide a delivery guarantee level. For “push”
subscriptions, this has significant implications for ensuring that subscribers receive the
message and to some degree the priority of delivery when a subscriber supports presence
(see Effects of Presence). Delivery guarantee can be included if it is acceptable for a
subscriber to receive duplicate events. For pull-based subscriber, this can directly affect
the retention policy of the topic.
5.3.4 Priority
Both topics and events have a notion of priority, which affects the system resources and
might affect the delivery order events. These two priorities will interact to determine
event delivery scheduling and broker resource consumption. Priorities may be
considered numeric values with the higher priority having a higher number value. The
absolute priority of a message is the combination of the topic priority added to the event
priority. Tied values would be resolved in favor of the topic priority. For example, use of
1 for High, 0 for Normal, and -1 for Low. An event’s score would be its priority
combined with the channel’s priority. With regard to tied values, high priority channels
would process first. Making an order of High/High, High/Normal, Normal/High,
High/Low, Normal/Normal, Low/High, Normal/Low, Low/Normal, and finally
Low/Low.
5.3.5 Sequencing
Topics can be configured to sequence messages in a number of possible ways. Simple
sequencing varieties include the following: unordered, publication time (receipt by
broker), event creation time (user provided) and priority. Sequencing affects the other of
subscription pushes and replays. In addition, sequencing also affect the order of messages
returned for pull-based subscriptions.
Topics may be configured to enforce the sequencing. This enforcement will affect
publishers’ attempting to publish events that are beyond the current time window for the
topic.
Page 30 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
5.3.6 Topic Constraints
Topics may be configured with a number of constraints and requirements that apply both
to what can be published to it and the capabilities of subscribers to the topic. The
following section outlines some of the known constraints.
5.3.6.1 Content Publication Restrictions
Topics may restrict publication of content according to various criteria, including but not
limited to the following: content type/form, content length, censorship, content checking
(e.g., virus scanning) and redaction. Publishers will receive exceptions (see Exceptions)
when events they attempt to publish violate those topics’ content restrictions.
5.3.6.2 Minimum Subscriber QOS
A subscriber to a specific topic must request a minimum quality or service level that
meets the configured QOS. For example a CDS system might request a near real time
subscription to a patient’s observations.
5.3.6.3 Maximum Subscriber QOS
A subscriber to a specific topic must request a maximum quality of service level that does
not exceed the configured QOS. This may be done when the publications are restricted to
a specific maximum QOS. For example, a publish-on-demand publisher or a federation
relationship cannot guarantee a QOS above a particular maximum. This also allows
topics to be configured to restrict the system resources that may be consumed relating to
delivery issues.
5.3.7 Topic Options
Individual topics may be configured with a variety of options based on the capabilities of
the broker. In the following section, each topic option that an individual topic may
support is detailed. Many of the topic options will have a direct analog in the options that
are used to create a subscription.
Topic
Access Model
Approval Required
Audit
Options
The topic’s general security policy. The access model is actually broken into two groups –
publication access and subscription access. The three models are described below.

Open – In the open model, all users are allowed access.

Closed – In the closed model, only those users with an affiliation are allowed access
based on their affiliated roles.

Authorize – In the authorize model, the system supports unaffiliated users of the
topic creating access requests. All affiliated users are granted access based on their
affiliated roles.
Determines if this topic requires that publications be approved by a third party. If present,
this option provides a form of topic moderation in which events acquire a state of “Review
Required” until a manual intervention is made. A topic owner or an affiliated user with the
reviewer role may update the state to either approved or rejected. Systems may notify
owners or reviewers if they have a subscription to the topic associated with the new event
as long as the status of the event clearly identifies that a review is required. Such user shall
receive the message a second time in the event that it is approved for publication.
Publishers that are also reviewers on a topic will automatically approve content they publish.
This entire process is known as manual review.
Determines if this topic is audited, and if so, what level of detail is audited? Some of the
possible auditable events are publication, retraction, subscription, topic change, topic
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 31
September 2014
© 2014 Health Level Seven International. All rights reserved.
Digest
Logging
On Demand Publication
Replayable
Require Secure Transfer
Scheduled Publication
Supports Publication
Usage Consent and
Acknowledgement
access, and message delivery.
Determines if this topic supports digests. Digests can be simple (an aggregate of topic
events delivered in one message), summaries (e.g., topic summarization) or both.
Determines if the topic logs events and at what level of detail.
Determines if this topic supports on demand publication and if so what level of support is
provided. This assumes the broker also supports this ability. The three possible states are
described below.
None – No on demand publication.
Content – Supports calling publishers for on demand content.
Dynamic Tree – Support calling publishers to provide both on demand content and dynamic
topic subtrees.
Determines if the topic is replayable. The replayable option determines if the events on this
topic may be replayed. For example, a subscriber may request that all events from the past
24 hours be resent in the sequence they were originally published in order to recreate the
circumstances of the original clinical situation. It should be noted that the ability is
constrained by the retention policy of the topic. Messages/Events that are replayed are
distinguished by the Replay ID in the message header, with original messages having
empty values while replayed ones will have subscriber provided values. Some
implementations may also support multi-topic replay and a timing rate for modeling.
Determines if a topic may require that all access to its content occur using a secure
message transport protocol, for example TLS or HTTPS.
Determines if a topic delivers events on a scheduled basis. In other words, can an event be
published at a specific time in the future?
Determines if a topic supports publication. Some topic in the tree may be used only for
organizational purposes and publication to them would be meaningless. A common example
of a topic which would not support publication is the root topic.
Determines if the topic requires acknowledgement of a usage consent form before a
subscription is authorized. Such information would generally be a part of the subscription
options. Implementation may provide a detailed listing of the specific requirements that are
needed.
5.3.8 Topic Identity
Every topic on a particular broker has a unique identity. The identity is defined in at least
two manners: a human-readable topic tree path and an object identifier (OID). The OID
of a topic is immutable once the topic has been created, while the topic’s names and path
may change. In addition, a topic may have multiple aliases. This can include, but is not
limited to, alternate topic navigation paths, names, and even HL7 defined standard topic
OIDs. All names given to a topic must be unique with the scope of a particular broker. In
addition, all topic names starting from a root of “HL7” are reserved for assignment by
HL7.
5.3.9 The Topic Tree
Topics on a broker are organized into a directory tree structure with a single common
root. Each node (topic) in the tree will have a name that is unique in terms of its
immediate parent in the tree. The names of the topics in the topic tree are intended to be
human readable. Presentation of the topic tree may well be aliased by the natural
language of the user. In addition, there will exist a canonic tree that is organized by topic
OID. The root level topic “HL7” and its subtree are reserved for use by HL7. There shall
be a similar reserved OID for the HL7 root topic.
The names of topics are constrained to Unicode alphanumeric characters, the space, dash
and period. The slash or backslash character is used as a path separator. All other
punctuation characters are reserved for future use and conforming implementations must
Page 32 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
accept them and ignore all content until the next path separator. An example topic path
might be /HL7/Orders.
The topic tree is considered a hierarchy in which each node (topic) may or may not
support publications. A publication to the topic tree does not cascade down the topic tree.
brokers may support tree-based subscriptions whereby all events in a particular tree are
considered part of the subscription.
Topics in the topic tree might in the future be navigable by inter topic relationship and
specific characteristic such as media form or language. The rationale behind reserving
punctuation characters is to support this use and topic expressions in the future. An
example for a future use name would be /HL7/Orders:(lang:en).
Depending on the capability of the broker, the topic tree may be dynamic in nature. If
dynamic nodes are supported by a broker, an on-demand publisher may provide a
dynamic subtree. Publishers for a specific topic may expose an on demand topic tree.
This tree is exposed as subtree below that topic. This is done by the brokers using calls to
the PS On Demand Publisher Interface implemented on the publisher. This is highly
useful for publishers with large bodies of content to which only a small part may be
subscribed. For example an electronic health record (EHR) system might expose a topic
of patients labs in a tree like “/patientlabs/{patientid}/labs” and only those patients
having active subscriptions would have events published.
The topic tree supports restricted visibility and security options on the level of individual
topics. For example, there may be topic trees that contain protected information, such as
a path containing a Social Security Number.
5.3.10 Message Identity
Each message that is published to a broker will be assigned a unique ID (Message ID) by
the broker. This ID is unique to the broker and can be used to refer directly to a message
without regard to what topic it is published. Absolute unique message identity may be
established by combining the broker’s unique identity as a delimited prefix to the
message ID. Each broker is presumed to have a unique identifier.
5.3.11 Message Lifecycle
The typical message life cycle is illustrated below. The life cycle shows both pull style
message delivery where the subscribers make a request for content and push style
message delivery where the broker will send the message to a subscriber.
1. Publication Rights
a. The broker checks that a producer is authorized to publish to a topic.
2. Publication Acceptance
a. If accepted, the broker iterates over the prepublication message review
chain and provides each publication intervention plug-in an opportunity to
update the message or reject it.
b. Validate that the message is not malformed.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 33
September 2014
© 2014 Health Level Seven International. All rights reserved.
c. Provisionally accept the message.
d. If manual publication review is in effect for the topic
i. If publisher is not allowed to bypass review, then acknowledge to
the publisher that the publication review is pending and notify
reviewers.
ii. Message remains in queue until a reviewer takes action.
e. Message is accepted for publication and the publisher is informed.
3. Message Delivery (Push)
a. For each Push Subscriber
i. Iterate over the delivery intervention chain and allow each delivery
intervention plug-in an opportunity to update the message or reject
delivery to this subscriber.
ii. Attempt message delivery.
iii. Update delivery status.
4. Message Delivery (Pull)
a. For each message in the scope of the pull request
i. Iterate over the delivery filter chain and allow each engine an
opportunity to update the message or reject delivery to this
subscriber
ii. Build the pull response.
iii. Send the pull response.
iv. Update delivery status.
5.3.11.1
Message States
Messages exhibit a number of states as they move through the processes of acceptance
and delivery. The state diagram below shows the various states and their various possible
transitions.
Page 34 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 9: Message State Model
Every message has a state, which describes where it is in the broker’s workflow.








Delivered – Subscribers have received the message.
Expired – Message has expired.
Review Pending – Message requires review.
Rejected – Message rejected from publication.
Initial – Message is new.
Approved – Message is approved for publication.
Deleted – Message has been removed.
Pending – Message is pending delivery to subscribers.
5.3.12 Common Message Elements
All events will have a few common elements as explained below:





Creation Time – the actual time the event was created by the publisher.
Publication Time – the time when the broker should publish an event. If empty,
the broker will assign the current time.
Expiration Time – the time at which the event should expire. If not provided, the
event will expire in accordance with topic and broker policies.
Publisher – the publisher of the event as known by the broker.
Author – authorship information about the creator of the event. Intended for
external consumption.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 35
September 2014
© 2014 Health Level Seven International. All rights reserved.
5.3.13 The Message Event Content
The EPS system is content agnostic with minimum content requirements. Each event may
have one or more bodies of content, each body being tagged as to content type and form.
This is similar to content encoded as mime attachments. Some content types might also
refer to a publicly accessible content broker or provider, rather than including that content
explicitly. The content body mechanism also allows recursive content, thereby providing
support for digest based subscriptions. Topics and brokers may optionally constrain the
size, type and form of event content.
5.3.14 Broker Options
The following are the parameters that a specific broker may optionally support. The list
of options supported by a broker must be returned by the “Inquire into Broker
capabilities (Discover Features)” service provided by the broker interface. It should
return a listing of each option and the level of support for that option. Elements that are
missing must be assumed by clients to be unsupported by the reporting broker. Many of
the concepts found in the following table are covered in greater detail later in the
document
Parameter
Auto Confirmed/ Approved –
Publication
Auto Confirmed/Approved –
Subscription
Auto Register
Content Brokering
Delivery Intervention
Publication Intervention
Engines Supported
Digest
Filtering & Topic Expressions
Leased Subscriptions
Multi-Subscribe
Presence
Publish-on-demand
Publish Only Affiliation
Push Based Subscriptions
Summarization Support
Supports Federation
Topic Bridging
Options
Does the broker support a workflow that automatically allows the owner of a topic to
confirm publications to the topic? This can include unrestricted publishers, individual
publications, and entire sets of pending publications.
Does the broker support a workflow that automatically allows the owner of a topic to
confirm topic subscription requests?
Does the broker support the auto registration concept? If so what level of types are
provided: publication, subscription, user access?
What support does this broker have for content on demand? Possible states are:
none, publisher only, broker only, and broker and publisher.
Does the broker support delivery intervention engines? These engines are linked in
series to provide services such virus checking, redactions, tagging, and censorship.
Does the broker support publications engines? These engines are linked in series to
provide services such virus checking, redactions, tagging, and censorship.
Does the broker support digest mode subscription? Such a subscription aggregates
the content of a topic and sends it to the subscriber on a fixed interval.
Does the broker support topic expressions and what types of expressions are
understood. ?
Does the broker support subscriptions that are leased? The information returned by
this option should specify the nature of the lease types and related constraints. For
example a broker might support leases that are based on a specific period of time or
volume of information. Some of the possible leasing models are; by time period, by
volume, pay as you go, auto renewing, etc.
Does the broker support the same subscriber having more than one subscription to a
specific topic?
Does the broker support presence related behavior?
Does the broker support publish-on-demand publishers?
Does the broker support the publish only affiliation?
Does the broker support push based subscriptions?
Does the broker support topic summarization, whereby select message information
(e.g., author, subject, etc.) is aggregated into a single event and sent to the
subscriber on a fixed interval? This differs from digest based message support in that
only a summary of each event is present.
Does the broker support federation?
Topic bridging is the ability of the broker to delegate a portion of the topic sub-tree to
another broker or publisher in whole or part. An example of this might be an
Page 36 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Transaction Capable
Tree subscriptions
Windowed Subscriptions
advanced use of publish-on-demand extended to include topic map support. An
example use case might be to allow a topic like /vista/labs/patients/… where the subnodes under ../patients/ would be dynamic on demand topics based on the VistA
data. Note this feature requires publish-on-demand. This relates directly to whether
the broker supports the dynamic topic trees fetched using publish on demand.
Is the broker transactions capable? For example are message delivered in a manner
that is compatible with a transactional system.
Does the broker support subscriptions, which are not to a single topic but rather to a
topic tree? This allows a subscriber to create high-level tree subscription and receive
all events in the tree and all its subtrees. Depending on tree path semantics this
subscription might also be a based on a topic pattern match or query.
Does the broker support subscriptions that are active or gated to a specified time
window? For example, a subscription that is only active from 9:00 AM to 5:00 PM
with subscriber messages outside the window being either deferred or perhaps even
ignored.
5.4 The Subscription
A subscription is a relationship between a single consumer (subscriber) and one or more
topics. Subscriptions may exist in many possible configurations with various delivery
dynamics, content requirements, lifespans, filters, qualities of service, and delivery
mechanisms, to name just a few of the possible differentiating factors. Every subscription
is an artifact in the EPS server with a unique subscription ID. A single subscription can
be thought of as message stream for one or more topics directed to a single subscriber.
There are a number of subscription related features that are not yet specified in this
document. It is envisioned that they may be desirable in the future, and every effort has
been made to provide forward compatibility with these features. The following is a brief
list:



Subscriber to Tree: A single subscription can be created that covers an entire
section of the topic tree. Such subscriptions might be by pattern or by tree depth.
Subscriber based event filtering: Subscriber can establish criteria for filtering
the events seen.
Inter-Topic Subscriptions. Internal or interlinked subscription whereby topic
might subscribe and filter other topics.
5.5 Event Message Dynamics
Message event dynamics describe how messages/events are delivered to subscribers.
There are two major dynamic models: event pull and event push. In each case, the
distinguishing factor is which party initiates the action. It should be noted that message
dynamics relate to message delivery and not to specific subscriptions (which will exhibit
dynamic characteristics).
5.5.1 Pull Based Subscriptions
In a pull-based subscription, the subscriber connects to the broker and retrieves the events
they are interested in. With subscriptions of this form, the broker retains information
about what the subscriber has not already retrieved (although the subscriber may also
keep an independent record of their state). Pull based subscriptions will generally receive
events that are still available and active of a specific topic. For topics that have an onHL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 37
September 2014
© 2014 Health Level Seven International. All rights reserved.
demand publisher, the pull request is filled in the normal manner; however, if the
publisher supports the on-demand pull operation, the request is also forwarded to the
publisher and the results are merged with the events still retained by the topic. Publish on
demand is covered in more detail further in the document.
In pull based subscriptions, the subscriber is responsible for communication setup and is
only considered present for the duration of the call. This form of subscription is well
suited to client-server architectures. For pull-based subscriptions, the successful return of
the information to the subscriber is considered successful delivery.
5.5.2 Push Based Subscriptions
In a push-based subscription, the broker connects to a subscriber end point and pushes
events to the subscriber. A clear communications path to the subscriber from the broker
must exist for the event to be delivered. The duration and quality of the communication
path between the subscribers is not assumed and the service must deal with both link
failure and the lack of presence on the part of the subscriber. With push based
subscriptions, the broker attempts to deliver the messages is a timely manner to the
subscribers within the constraints of available resources and the QOS of the subscription.
When the broker fails to deliver a message to a subscriber and the failure is of such a
nature that it might be transient, the broker will retry delivery until such time as either the
message expires or it is determined that the subscriber is not present. It is expected that a
broker that believes a connection is only temporarily unavailable will retry delivery in a
manner that does not cause undue use of resources.
If a subscriber indicates that it is not present, then the broker will not attempt message
delivery until that subscriber once again asserts its presence.
5.5.3 Effects of Presence
Presence refers to the availability of a user to receive messages from a broker. Presence
applies to both publishers (Publish-on-demand [POD] contracts) and subscribers (Push
subscriptions). Presence is a decoupled attribute; it is not advertised by the broker to
other subscribers and publishers in order to help maintain decoupling and role separation
between the publication and the consumption of events. The meaning of presence differs
from that normally found in a direct messaging system (e.g., instant messaging) in that it
is only of direct concern to the broker.
Presence asserted by the user is tracked at two basic levels; the user and the callback
endpoint. Presence is used by the broker to control message delivery. The broker will
only attempt to send message to those users that have not indicated an offline status. This
includes all subscriptions of the user and POD contracts. A user may suspend push events
by asserting an offline status. When a user is offline, push events are deferred until they
expire or the user re-establishes an online status.
Page 38 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Users that are publish-on-demand publishers will have event publication deferred until
they are online. Pull based requests will consider the publisher to be non-existent if it
does not assert presence at the time of the request.
For users that have specific interfaces that fail to respond to the broker, the interface in
question will move to an indeterminate status. In that status, the broker will attempt
connection on a periodic basis for as many attempts as the broker configuration allows.
Once the maximum number of attempts is reached, the broker will consider the interface
to be offline. In order to have the interface leave the offline status, the contract (e.g.,
subscription) requires either a status update or the user to assert an online presence.
5.5.3.1 Presence State
There are three possible presence states in the following diagram. They are described
immediately after.
Figure 10: Presence States



Online – The user is available to receive messages.
Offline – The user is not available to receive messages and will not until such
time as the state changes to online.
Indeterminate – The presence of the user is questionable. Delivery attempts will
be made until either there is a successfully delivery (indicating online state) or
system policy dictates the user or interface be considered offline.
5.5.4 Event Replay and Dynamics
EPS supports the option of replaying events, i.e., the ability to redeliver a series of events
to a specific requesting subscriber. Event replay is only available to push based
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 39
September 2014
© 2014 Health Level Seven International. All rights reserved.
subscriptions. The subscriber makes the replay request including with it an identification
string to distinguish events that are being relayed from normal event delivery. This
identification string is a separate field from the normal event ID. Event replay may occur
at the same time as normal event delivery. Normal topic operation constraints are obeyed
(e.g., if the contract or topic provides temporal ordering, the replay will be in that order).
All replay requests are for a specific time period in the past, thus ensuring there are no
uncertainties as to which messages are included in the replay. Event replay will also be
bounded by two topic management events: one prior to any events being replayed and the
other after all events have been replayed. This will ensure that both the broker and the
subscriber have a mechanism to understand when all data relating to the replay has been
received.
Replay requires that the topic have some notion of retention and/or one or more POD
publishers that also support replay. In the case of POD publishers and topics with
retention, the broker will merge the streams of events and remove duplicates. This may
be done either by an actual merge or by simply ensuring that duplicates are not
transmitted.
5.5.5 Publish-on-Demand Dynamics
POD is an active contract that allows a producer to publish information on topics only
when there is an active subscription present. There are four basic types of POD support:




Base Support
Pull Support
Replay Support
Dynamic Topics
Each of these types is covered in more detail below. A POD publisher may support only a
limited portion of the possible contract. In addition, a particular broker may also be
limited as to what it accepts.
POD requires that a publisher have an active endpoint whereby the broker may inform
the publisher of specific requests. POD publisher therefore exhibits the characteristics of
presence. Generally, exceptions in POD requests are considered non-fatal. The broker is
an aggregator of data. While there is a logical distinction between the publishers on a
topic and the information that a topic provides, it may be a good idea to distinguish
between having no data and being unable to publish data from some publishers.
5.5.5.1 Base Support
The base level of support for POD is simple notification to start publication on a topic
when there are subscribers and to stop publication on a topic when subscribers to a topic
no longer exist.
5.5.5.2 Pull
POD pull support is the ability of a publisher to be able to honor a query and retrieve
events.
Page 40 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
5.5.5.3 Replay Support
POD replay support is the ability of a publisher to honor an event replay request.
5.5.5.4 Dynamic Topics
POD dynamic topic support is the ability of a publisher to offer its own dynamic topic
tree along with, at a minimum, base level support for those topics.
5.6 Message Review, Approval, Modification and Filtering
An event message is subject to a number of potential interventions during its lifespan.
One major intervention point is at the time of publication, at which point the message
might be rejected, held for manual approval, or the content of the message altered or
supplemented. The other major intervention point for a message is prior to delivery to a
subscriber, at which point it might be filtered by subscriber preference, hidden from view
or delivery, or the content of the message altered or supplemented.
5.7 Federation
Federation is the process whereby a group of EPS servers provide shared content. Event
Publication and Subscription systems can support a form of federations simply by
switching roles and acting as subscribers to other servers. While this base level of
federation is still possible, it is believed to be of benefit to treat federation as a separate
area of concern. By doing this, it becomes possible to address additional issues in a
number of realms including security, efficiency, reliability and operational concerns by
creating a specialized contract between federation partners to address these issues
specifically.
In defining federation, there are two major roles: the source and the target. These roles
are analogous to the publisher/subscriber roles. The source is a system that is sharing
information. The target is the consumer of information. The source is always considered
the authoritative partner in the relationship. There are a number of models for federation
behavior:







Real-time – Target synchronizes with source in real-time.
Batch – Target is updated with source content on a periodic basis.
Aggregation – Target pulls from multiple sources.
Delegation – Target acts as a direct delegate.
Transformation – Target imposes a transformation on events.
Store and Forward (Cache) – Target copies source events.
Mirroring – Target can accept publications that are forwarded to the source.
As can be seen from the list above, the nature of a particular federation can be quite
broad. In general, the relationship between the target and the source will fit in one of the
following three groups:



Consumer Only – Data Access
Publisher Only – Data Source
Consumer & Publisher – Data Sharing
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 41
September 2014
© 2014 Health Level Seven International. All rights reserved.
Federation is represented in this model as a tree based map that ties the topics on each
end of the relationship together along with control information about the federation at
that level. Operationally, federation relationships require bilateral setup. Once
established, a specific federation may be modified, terminated, suspended, resumed, and
filtered. Future considerations for federation specification include the following:



Federated user model
Federated policies
Federated security
5.8 Service Level Security Roles
The broker supports administrative and operational roles that are independent of
affiliations. These roles affect operations that span individual topics. A functional
breakdown of these roles is as follows:






User Management – Allows user related operations.
Broker Management – Allows basic broker management activities.
Federation Management – Allows control of the broker federation.
Operations – Allows monitoring and basic operations.
Auditing and Review – Allows monitoring and data enquiry.
Global – Allow full access.
5.9 Exceptions
The EPS system defines a set of standardized exception conditions to facilitate service
interoperability. The diagram below introduces the various exceptions and their
relationship to each other. The interface details section will call out the expected
exceptions for each operation.
Figure 11: Exceptions
Page 42 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
The following table provides brief descriptions of each exception.
Exception
Authentication Required Exception
Conflict Exception
Expired Exception
Feature Not Available Exception
Incomplete Data Exception
Invalid Data Exception
Media Format Not Accepted Exception
No Such Item Exception
No Such Topic Exception
Not Authorized Exception
Pub/Sub Exception
Description
This exception is generated when an action requires a registered user be
authenticated to invoke it.
This exception is generated when the entity already exists.
This exception is generated when either the event or the subscription has
expired. This may also be used to indicate that the topic in question has
not been paid for.
This exception is generated when the requested feature is not supported.
This exception is generated when incomplete data is submitted.
This exception is generated when invalid data is submitted.
This exception is generated when invalid data, in a format not supported by
a topic, is published.
This exception is generated when an item or element does not exist.
This exception is generated when an item or element does not exist.
This exception is generated when an action is prohibited by owner or
administrator.
Root exception for all pub/sub related exceptions.
5.10 Publication Interface
The EPS service enables devices and systems that generate events/data/messages needed
by other consumers to publish those events to an intermediary that is responsible for their
subsequent distribution to interested parties.
Figure 12: Publication Interface
Publish Event to Topic
This operation allows a publisher to publish an event to an already defined topic. The
publisher in question must have legal access to publish on the specific topic matter.
More than one publisher might have privileges to publish on a specific topic.
 Story Board
A Coulter Counter in the Lab has a new result and wants to publish the result to the “New
Laboratory Results” topic.
 Description: Publisher makes an event publically available. This operation is

asynchronous with regard to the subscriber to the topic receiving the event.
Pre-Conditions:
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 43
September 2014
© 2014 Health Level Seven International. All rights reserved.






The User has Owner, Publisher or Publish Only rights to the topic.
Conceptual Information Objects
o Inputs:
 Topic Id or Topic Path
 Message/Event
o Outputs:
 Message Id
Post-Conditions: The message now appears in the topic and subscribers are
notified.
Exception Conditions:
 Not Authorized
 Authentication Required
 No Such Topic
 Incomplete Data
 Invalid Data
 Media Format Not Accepted
Required Affiliation Roles:
 Publisher
 Publish Only
 Owner
Notes
Figure 13: Publish Event to Topic
Delete Event from Topic
This operation allows a publisher to remove a previously published event from a
topic. Depending on the topic configuration, this action may not be allowed.
Subscribers may be notified of the deletion depending on the nature of their
subscription and the configuration of the topic.

Story Board
Page 44 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
The Coulter Counter wants to stop distribution of the result in the “New Laboratory Results” topic
because of a newly discovered QA issue that compromised the test. The EPS service is notified and
the item is removed from the topic.







Description: Removes an event from the topic. Clients with a Push subscription
that includes the notification of management events will be informed. The
removal of the event will cause the topic’s active event stream not to show the
event; however, the event may still be retained by the broker for auditing
purposes. When an event is cross-posted to more than one topic, it is only
removed from the selected topic.
Pre-Conditions:
 The user has the role of publisher, topic owner, or administrator for
this topic.
Conceptual Information Objects
o Inputs:
 Topic Id or Topic Path
 Message Id
o Outputs: None
Post-Conditions:
 Event no longer appears under the topic.
Exception Conditions:
 No Such Item
 No Such Topic
 Expired
 Not Authorized
 Authentication Required
Required Affiliation Roles:
 Owner
 Publisher (Of the specific event)
 Publish Only (Of the specific event)
Notes
Figure 14: Delete Event from Topic
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 45
September 2014
© 2014 Health Level Seven International. All rights reserved.
Assert Presence
Assert presence allows Publish-on-demand publishers to update their presence
statuses.
 Story Board
A publisher that has a publish-on-demand contract is going offline for review and informs the EPS Server it
is not available.







Description: Allows a user to assert its presence
Pre-Conditions:
 Presence must be supported.
Conceptual Information Objects
o Inputs:
 Publisher Id
 Presence (Online, Offline)
o Outputs:
 Success/Fail
Post-Conditions
 For Offline status – Publisher requests and notifications are deferred.
 For Online status – Publisher requests and notifications are resumed.
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
 Incomplete Data
 Invalid Data
Required Affiliation Roles:
 N/A – not topic relevant
Notes
5.11 Subscription Interface
The EPS service enables external devices and systems to subscribe to receive messages,
reporting, and other events from a Producer System, and to control the type of data
received.
Page 46 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 15: Subscription Interface
Subscribe To a Topic
This operation allows a subscriber to subscribe to a specific topic or topics depending
on the capability of the broker. Some brokers may support wildcard and filter based
subscriptions. The nature of the subscription is also specified in this call. This call
may fail for a number of reasons including security, bad addressing, and capabilities
requested that the broker is not capable of honoring. It may automatically make an
access request.

Story Board
Once registered, the Clinical Decision Support System subscribes to the “New Laboratory
Results” topic and subsequently has access to a steady stream of lab results.





Description: Create a subscription to a topic.
Pre-Conditions:

Authenticated User – For Topics that are not "Open"
Conceptual Information Objects
o Inputs:
 Topic(s) – Topic Id, Path or Expression
 Subscription type – Push/Pull
 Subscription Options
 Client Address – Push subscriptions only
o Outputs:
 Subscription Id
Post-Conditions
 Users authorized for subscriptions to this topic are subscribed.
 If the topic requires authorization for access, the request is deferred.
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 47
September 2014
© 2014 Health Level Seven International. All rights reserved.






No Such Topic
Incomplete Data
Invalid Data
Media Format Not Accepted
Required Affiliation Roles:
 Subscriber
 Subscribe Only
 Owner
Notes
Figure 16: Subscribe to Topic
Unsubscribe
This operation allows a subscriber to remove an existing subscription from the EPS
service. The events queue for this subscription is deleted.

Story Board
After several months of receiving event data of interest only to adult patients, the Pediatric
Department Intranet unsubscribes from the “ACME Medical Center Public Events” topic.



Description: Allows a subscriber to terminate a subscription
Pre-Conditions: Subscriber must have a subscription to the topic.
Conceptual Information Objects
o Inputs:
 Topic (s)- Topic Id, Path or Expression
Page 48 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014






Subscriber Id
Subscription Options or Subscription id [Optional]
o Outputs: Success/Fail
Post-Conditions
 Subscription is removed.
 The topic will no longer deliver messages to this subscription.
 Any messages that are pending delivery to the subscription will be
have their delivery canceled.
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Topic
 No Such Item
 Invalid Data
Required Affiliation Roles:
 Subscriber (Their own subscriptions only)
 Subscribe Only (Their own subscriptions only)
 Owner
 Administrator
Notes
If a subscriber has multiple subscriptions to a topic, this operation will remove all
subscriptions to a topic if no options or subscription ID are provided. If options
are provided, they will be used to match against the subscriber’s subscription and
the matches will be removed. If a Subscription ID for this operation is provided,
then only that subscription will be removed.
Retrieve Events
This operation allows a client, who always is responsible for retrieving content in a
pull contract, to request "list" vs. "detail." The service defaults to maintaining each
client’s "history" and delivering content that has not yet been transmitted. Client
should have option of overriding this default and requesting a defined range. By its
very nature, either the topic has to be fully durable or the publisher has to support
temporal on demand publishing.

Story Board
The Clinical Decision Support System, now subscribed to the “New Laboratory Results” topic
needs a few weeks of previously reported data to initialize its service. The system requests both a
list of all labs resulted, and the details of each test for all patients over the past three weeks.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 49
September 2014
© 2014 Health Level Seven International. All rights reserved.
Figure 17: Authenticated Pull of Events
This also allows an anonymous subscriber to pull events from a topic, either as a
simple list or with full detail. The service defaults to a "stock" payload, but client
may request a custom range. There is no anonymous push contract.
The Pediatric Department Intranet, now anonymously subscribed to the “ACME Medical Center
Public Events” topic, regularly begins to pull topic events to populate its departmental calendar.
Figure 18: Anonymous Pull of Events



Description: Allows the events on a topic to be pulled by a subscriber
Pre-Conditions:
 Pull access allowed to current user.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or Expression, Subscription Id
 Pull Type – Full or Summary or Specific
 Pull Range: Recent or Specific
 Start: TimeStamp [Optional]
Page 50 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014






End: TimeStamp [Optional]
Media Forms desired [Optional]
o Outputs:
 List of Events or Event Summaries
Post-Conditions
 Subscriber specific context in topic may be updated.
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
 No Such Topic
 No Such Item
 Media Format Not Excepted
Required Affiliation Roles:
 Subscriber
 Subscribe Only
 Owner
Notes
For implementation the operation might be represented using three
separate operations based on the Pull Type.
Replay Events
Given a time range, all events on a given topic will be redelivered or retrieved based
on the type of subscription and the nature of the topic. This is a specialized form of
retrieval that is most useful in modeling. By its very nature, either the topic has to be
fully durable or the publisher has to support temporal on demand publishing.

Story Board
A clinical modeling group is reviewing a patient’s encounter history with a clinical decision
engine and asks the broker to replay an encounter related topic for a particular patient to observe
the engine’s behavior.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 51
September 2014
© 2014 Health Level Seven International. All rights reserved.
Figure 19: Replay Events




Description: Replays events to a push subscriber
Pre-Conditions:
 Broker and Topic must support replay.
 Topic must be durable or publish-on-demand.
 Subscriber must have a Push subscription.
Conceptual Information Objects
 Inputs:
 Topic(s) – Topic Id, Path or Expression, Subscription Id
 Start: TimeStamp
 End: TimeStamp
 Replay Id
 Media Forms desired [Optional]
 Replay Rate [Optional]
 Outputs:
 Events pushed to subscriber with the replay flag set to the
replay id.
Post-Conditions
 The requesting push subscriber will have the requested events pushed
to them with the replay flag set.
Page 52 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014



Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
 No Such Topic
 Invalid Data
 Media Format Not Accepted
Required Affiliation Roles:
 Subscriber
 Subscribe Only
Notes
The messages that are replayed will be sent with the provided replay ID in
their headers to allow the subscriber endpoints to identify their sources clearly.
The replay rate is included to allow the rate that message are sent to the consumer
to be controlled. This helps prevent consumer saturation. It is envisioned that in
the replay rate might also be a complex timing model in actual implementations.
For example when using an event replay for training or simulation purposes the
replay rate to the same rate as the events were originally received.
There will be a topic management event generated at the start of the replay
and sent to the requesting subscriber before any events are replayed. Once all
events have been replayed a topic management event will sent to indicate that the
replay has concluded.
Get Default Subscription Options
The operation allows a subscriber to get the default subscription options for a topic.
This is most useful when subscribing to a new topic.

Story Board
A new subscriber is planning on subscribing to a topic and would like to know the default options
for that topic to use as a basis for the subscription.





Description: Allows a subscriber to get the default subscription options for a
topic
Pre-Conditions:
 None
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or Expression
o Outputs:
 Options
Post-Conditions
 None
Exception Conditions
 Not Authorized
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 53
September 2014
© 2014 Health Level Seven International. All rights reserved.





Authentication Required
Feature Not Available
No Such Topic
Required Affiliation Roles:
 Subscriber
 Subscribe Only
 Owner
Notes
Configure Subscription Options
This operation allows a subscriber to change the options associated with a specific
subscription.

Story Board
An existing subscriber determines that the topic subscription needs a higher quality of service;
they determine the new options required and invoke this service.







Description: Allows a subscriber to change the options of a specific subscription.
Example uses would include changing subscription state, delivery parameters, etc.
Pre-Conditions:
 An existing subscription must exist
Conceptual Information Objects
 Inputs:
 Topic – Topic Id, Path or Expression, Subscription Id
 Subscriber Id
 Subscription Options
 Outputs: Success/Fail
Post-Conditions
 Updated Options for the subscription.
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 Expired
 Feature Not Available
 No Such Topic
 No Such Item
 Incomplete Data
 Invalid Data
Required Affiliation Roles:
 Subscriber
 Subscribe Only
 Owner
Notes
Page 54 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Get Subscription Options
This operation allows a subscriber to determine their options associated with a
specific subscription.

Story Board
An existing subscriber determines that wants verify that their the topic subscription at a specific
quality of service; they invoke this service and review the results.







Description: Allows a subscriber to determine the options of a specific
subscription.
Pre-Conditions:
 An existing subscription must exist
Conceptual Information Objects
 Inputs:
 Topic – Topic Id, Path or Expression, Subscription Id
 Subscriber Id
 Outputs:
 Subscription Options
Post-Conditions
 Subscription must exist.
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
 No Such Topic
 No Such Item
Required Affiliation Roles:
 Subscriber
 Subscribe Only
 Owner
Notes
Assert Presence
This operation allows subscribers to update their presence statuses.

Story Board
A subscriber is dropping out of service and wishes to suspend event pushes until they are online again. The
subscriber uses Assert Presence to indicate a change in their presence status. Sometime in the future the
subscriber is once again available to receive events and they use Assert presence to indicate that are now
available.



Description: Allows a user to assert its presence
Pre-Conditions:
 Presence must be supported.
Conceptual Information Objects
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 55
September 2014
© 2014 Health Level Seven International. All rights reserved.
o
Inputs:






Subscriber
Presence (Online, Offline, Indeterminate)
o Outputs:
 Success/Fail
Post-Conditions
 For Offline status – Event Push to subscriber is suspended.
 For Online status – Event Push to subscriber is resumed.
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
 Incomplete Data
 Invalid Data
 Media Format Not Excepted
Required Affiliation Roles:
 N/A, not topic relevant
Notes
5.12 Broker Interface
This is an interface for requesting information from the event broker, including its
capabilities, available event topics, and requesting access. This interface is intended for
the general service consumer.
Figure 20: Broker Interface
Discover Capabilities
The services provide information about the general capabilities of the broker. This
includes the type of contracts the broker is capable of and which optional features are
available.
Page 56 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014

Story Board
A new subscriber is interested in establishing a push subscription from the broker. The subscriber
calls this service to find out if event push is supported and what the maximum QOS is for push
subscriptions.







Description: The services provide information about the general capabilities of
the broker.
Pre-Conditions:
 None
Conceptual Information Objects
o Inputs:
 None
o Outputs:
 List of broker Options and their support status. Any feature not
listed is assumed not to be supported.
Post-Conditions
 None
Exception Conditions
 Not Authorized
 Authentication Required
Required Affiliation Roles:
 N/A, not topic relevant
Notes
Discover Topics
This operation is used to search for available topics on the EPS system. In the
simplest case, this operation is used to get the root of the topic tree.

Story Board
A new subscriber is interested in what topics might be accessible from the broker. The subscriber
first starts browsing the available topics from the root context.





Description: Get a collection of Topics. The results of this service are always a
collection of topics that can then be used navigate the topic tree using the Get
Topic Information service. The topics returned may be filtered based on the
caller’s privileges.
Pre-Conditions:
 None
Conceptual Information Objects
 Inputs:
 Query: a Topic Path or Expression (May be empty)
 Outputs:
 List of Topics matching the query
Post-Conditions
 None
Exception Conditions
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 57
September 2014
© 2014 Health Level Seven International. All rights reserved.







Not Authorized
Authentication Required
Expired
No Such Topic
Invalid Data
Required Affiliation Roles:
 N/A, not topic relevant
Notes
If an empty string or the root topic tree prefix is the query, then the Root level
topics are returned. Currently the query sting is constrained to Topic Path or
Expression, section 5.3.9. In the future, the query may be broadened to include
more capabilities.
Get Sub Topics
This operation is used to view the topic tree from a known parent topic. It will return
the direct children of the topic.
 Story Board
A subscriber is browsing the topic tree and has identified a topic listed below the root (e.g.,.
/rawfeeds) and is interested to discover the available subtopics.







Description: Returns zero or more subtopics that may exist using a topic id. This
operation is optimized for tree walking based on current topic location. The
topics returned may be filtered based on the caller’s privileges.
Pre-Conditions:
 None
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or Expression
o Outputs:
 List of Subtopics
Post-Conditions
 None
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 No Such Topic
Required Affiliation Roles:
 N/A, not topic relevant
Notes
Page 58 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Discover Events for Topic
This operation is used to get a “directory” of the events that have been published to a
topic.
 Story Board
A publisher wishes to verify that a specific message was posted to a topic.






Description: This service finds the available events for a specific topic
Pre-Conditions:
 None
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or Expression
 Start Date/Time (Optional)
 End Date/Time (Optional)
o Outputs:
 List of Events Metadata
Post-Conditions
 None
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 No Such Topic
 Invalid Data
Required Affiliation Roles:
 Owner
 Administrator
 Subscriber
 Subscribe Only
Notes
This operation provides a directory-like summary of the events published to topic.
Depending on the retention properties of the topic, the list of events may or may
not be complete for the period in question and not all events may be retrievable in
their entirety.
Get Topic Options
Get the options that are used to configure topics on this broker. One common use of
this service is to prepopulate the configuration of a new topic being defined.

Story Board
A publisher wishes to know if a specific topic it is planning to publish to provides potential
subscribers with a high QOS.

Description: Get the options that are used to configure topics on this broker.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 59
September 2014
© 2014 Health Level Seven International. All rights reserved.






Pre-Conditions:
 Topic must Exist
Conceptual Information Objects
 Inputs:
 Topic – Topic Id, Path or Expression
 Outputs:
 Options
Post-Conditions
 None
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes
Request Access
This operation is used to submit a user profile for the EPS system requesting access.
 Story Board
A new clinical user registers with the EPS service to request access the broker in order to
subscribe to the topics that are needed for many of their rules and guidelines.
Page 60 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 21: Request Service Access





Description: Allows a user to register with the EPS service in order to initiate
Registration
Pre-Conditions:
 Option must be supported.
Conceptual Information Objects
o Inputs:
 User
o Outputs:
 Success/Fail/Pending Approval
Post-Conditions
 If the server is open and the request valid, a new user is created.
 If the request requires authentication, then an authentication request is
made.
 Service may communicate Success/Fail to user depending on user
provided contact info. This may be via a Topic Management event if a
call back has been provided or via a service like Unified
Communications if other contact information is available (e.g. email
address).
Exception Conditions
 Conflict
 Feature Not Available
 Incomplete Data
 Invalid Data
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 61
September 2014
© 2014 Health Level Seven International. All rights reserved.


Required Affiliation Roles:
 N/A, not topic relevant
Notes
5.13 Broker Management Interface
The broker management interface provides the core services for basic broker
management, including topics, users, and access requests.
Figure 22: Broker Management Interface
Create a User
Register a user with the broker. This operation is used to establish a user, the user
configuration information, privileges, and access to topics including role.

Story Board
A new Clinical Decision Support System requires access with the EPS service to gain access to
the “New Laboratory Results” topic that is needed for many of its rules and guidelines. The
administrator creates a user to represents the CDS system and grants the user subscription
access the “New Laboratory Results” topic.


Description: Register a user with the broker.
Pre-Conditions:
 Current user must be authenticated and have an Administrator role on
the EPS system.
Conceptual Information Objects
o Inputs:
 User
o Outputs:
 Success/Fail
Page 62 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014




Post-Conditions
 New user added to system.
 User may now be used to form affiliations.
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 Incomplete Data
 Invalid Data
Required Affiliation Roles:
 N/A, not topic relevant
Notes
Figure 23: Create user and grant them publication rights
Discover a User
This operation is used to find users and all basic information about the users.

Story Board
George the EPS administrator has been asked to find out if Dr. Smith has access to the system.
George uses this operation to discover if Dr. Smith is a registered user.


Description: Finds one or more users and basic information about them.
Pre-Conditions:
 None
Conceptual Information Objects
o Inputs:
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 63
September 2014
© 2014 Health Level Seven International. All rights reserved.





User Id or Query
o Outputs:
 List of Users
Post-Conditions
 None
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Item
 Invalid Data
Required Affiliation Roles:
 N/A, not topic relevant
Notes
Basic user queries should support by search by name or personal identifier.
Delete a User
This operation will remove a user from the system. This operation will also remove
all subscriptions contracts, publish-on-demand contracts, and affiliations for the user.
The effect on content is directly related to the retention policies of topics to which the
user has published content and the Remove Content Flag for this operation.

Story Board
Dr. Smith has left the medical group and the administrator of the EPS system has been directed to
remove all of Dr. Smith’s Access. The decision of the senior partner is to retain all of the event
publications made by Dr. Smith.



Description: Removes publisher or subscriber and all content related to their
contract
Pre-Conditions:
 User must exist.
 Current user must be an EPS administrator.
Conceptual Information Objects
o Inputs:
 User id
 Remove Content Flag (Yes/No/Override)
o Outputs:
 Success/Fail
Post-Conditions
 User is no longer able to authenticate with the system.
 All user affiliations are removed.
 All user subscriptions are removed.
 All user publish-on-demand contracts are removed.
 The public id of the user is available for reuse.
 The user will no longer show up in searches for active users.
 The user record may be retained in a deleted state for auditing.
Page 64 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014




Depending on the Remove Content flag and system policy content
published by the user may be removed.
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Item
Required Affiliation Roles:
 N/A, not topic relevant
Notes
When the remove content flag (RCF) is “yes” or “override,” the events published
by the user will be removed from the EPS system. Topics with strong retention
policies may retain the user’s events if the RCF is “yes,” while “override” should
cause all events to be removed. A system may retain knowledge of what the
public id of a user was for audit purposes and all audit should be keyed to the
internal user identifier, not the public id. For example if Dr. Smith has a Public
user id of JSmith and a user id of 100282, the public id JSmith would become
available for use, while the user id 100282 would never be reused.
Update a User
Update the information associated with a user. This would include privileges, options,
and authentication information for the user.

Story Board
Dr. Jones has married and now has a last name of Jones-Smyth and needs her name updated on
the EPS server. In addition, Dr. Jones-Smyth now has new contact information and would like to
update her password.





Description: Update the information associated with a user
Pre-Conditions:
 Current user is an EPS Administrator or the user in question.
Conceptual Information Objects
o Inputs:
 User Id
 Options
 User Data
o Outputs:
 Success/Fail
Post-Conditions
 User Information updated
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Item
 Incomplete Data
 Invalid Data
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 65
September 2014
© 2014 Health Level Seven International. All rights reserved.



Media Format Not Excepted
Required Affiliation Roles:
 N/A, not topic relevant
Notes
User may be allowed to update their own information; specific EPS systems may
enforce constraints on the data that must be updated only by an administrator.
Create Topic
Create a new topic or subtopic. This operation is independent of a specific publisher
and would include options and metadata relating to topic.

Story Board
A new publishing system has been acquired by the medical group and the administrator of the
EPS systems has been instructed to create a topic tree to which it will publish.






Description: Create a new topic or subtopic.
Pre-Conditions:
 Topic with name must not exist directly under parent topic.
 Current User must have privileges to create a topic below the parent
topic or support for authorization requests must be present.
Conceptual Information Objects
o Inputs:
 Parent Topic – Topic Id, Path
 Topic name
 Topic options
o Outputs:
 Success/Fail/Deferred
Post-Conditions
 If authorized, the new topic is created.
 If not authorized, and support for authorization requests is available
then a request is generated for the topic administrators and the topic
creation is deferred until approved.
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 Expired
 Feature Not Available
 No Such Topic
 Incomplete Data
 Invalid Data
 Media Format Not Excepted
Required Affiliation Roles:
 N/A, not topic relevant
Notes
Page 66 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Configure Topic
Update the configuration and/or metadata relating to a topic. For example, additional
retention policies for the topic might be changed or the topic could be disabled.

Story Board
A topic that exposes abnormal lab results has previously only retained the last 24 hours of data.
This period has been determined too short and needs to be extended to one week.






Description: Update the configuration and/or metadata relating to a topic.
Pre-Conditions:
 Topic must exist.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path
 Topic Configuration/Options
o Outputs:
 Success/Fail
Post-Conditions
 Topic options updated to the extent possible.
 Existing content may be removed.
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 Expired
 Feature Not Available
 No Such Topic
 Incomplete Data
 Invalid Data
 Media Format Not Excepted
Required Affiliation Roles:
 Owner
 Administrator
Notes
The dynamics of this operation depend heavily on the nature of the options
changed. For example, this could include alias creation, disabling the topic,
updating retentions, changing durability, etc.
Delete Topic
This operation allows a topic to be removed from the broker. All events relating to the
topic are also removed. Removing a high level topic will also remove all subtopics.
Depending on the configuration of the topics in question, the subscribers and
publishers may be notified.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 67
September 2014
© 2014 Health Level Seven International. All rights reserved.

Story Board
An existing topic is found to be no longer used and it is desired to prune it from the tree.







Description: Allows a topic to be removed from the broker
Pre-Conditions:
 Topic must exist.
 Current user must have access to entire sub-tree.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
 Force – True/False
o Outputs:
 Success/Fail
Post-Conditions
 Push Subscribers are notified via Topic Management Event.
 On Demand Publishers are notified via Topic Management Event.
 All Subscriptions are removed.
 All Events are removed.
 All Publication contracts are removed.
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes
If a topic has children and the user did not specify the force option as true the
request will be rejected.
Move Topic
This operation allows a topic to be moved to a different location in the topic tree. All
events, subscriptions, and publication contracts remain in place. Depending on the
configuration of the topics in question, the subscribers and publishers may be
notified.

Story Board
An existing topic location in the topic tree is found to be suboptimal and a better location is found.



Description: Allows a topic to be moved to a new location on the topic tree
Pre-Conditions:
 Topic must exist.
 Current user must have access to source and target topics.
 New Topic path must be available.
Conceptual Information Objects
o Inputs:
Page 68 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Source Topic – Topic Id, Path or expression
Destination Topic Path
o Outputs:
 Success/Fail
Post-Conditions
 Topic changes tree location.
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes
When the source target name is an existing topic alias, then just that alias is
changed. All other paths to the topic remain unchanged.






Get Topic Metadata
Get Metadata information about a particular topic. The Metadata returned may
include such information as topic durability, events available in the topic, available
media formats, copyright information, temporal scope, etc.

Story Board
Hospital administration is assembling monthly metrics and needs to determine the usage level of a
particular topic.







Description: Get Metadata information about a particular topic.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
o Outputs:
 Topic Meta Data
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 69
September 2014
© 2014 Health Level Seven International. All rights reserved.
Purge all Topic Events
Remove all events from a topic. Subscribers might be notified of this action based
upon their subscriptions and the configuration of the topic.
 Story Board
It has been decided to change the acceptable publication media formats for a topic. Prior to
making this change all existing messages need to be removed.







Description: Remove all Events from a Topic.
Pre-Conditions:
 Current user must have sufficient access.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
o Outputs:
 Success/Fail
Post-Conditions
 Existing Push subscribers receive a topic management event.
 All events on the topic are removed.
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes
Get Publisher(s) for Topic
This service will retrieve all publishers for a particular topic. Visibility of the
publishers may be limited by the caller’s privileges. At a minimum a publisher will
always see themselves.
 Story Board
In considering if a particular topic should be altered, it is desired to find who is publishing to it so
they may be consulted.





Description: This service will retrieve all publishers for a particular topic.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
o Outputs:
 List of Publishers
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
Page 70 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014




Expired
No Such Topic
Required Affiliation Roles:
 Administrator (Full view)
 Owner (Full view)
 All others but Outcast may have a limited view.
Notes
Get Subscriptions For Topic
This service will retrieve all subscriptions for a particular topic. Visibility of the
subscriptions may be limited by the caller’s privileges. At a minimum, a caller’s own
subscriptions will be included.
 Story Board
Consideration is being given to changing the QOS offered for a topic. Prior to deciding on this
change, the existing subscriptions are examined to determine their need.







Description: This service will retrieve all subscriptions for a particular topic.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
o Outputs:
 List of Subscriptions
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 No Such Topic
Required Affiliation Roles:
 Administrator (Full view)
 Owner (Full view)
 All other but Outcast may have a limited view
Notes
5.14 Topic Management Interface
This is an interface for managing access to topics. It is intended for use by topic owners
and administrators to allow them to control access and privileges granted to users of
topic.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 71
September 2014
© 2014 Health Level Seven International. All rights reserved.
Figure 24: Topic Management Interface
Create Affiliation
This service creates an affiliation between a user and a topic. This affiliation will
grant the user specific privileges on the topic. The granting of an affiliation might
result in the automatic revocation of prior affiliations.
 Story Board
An Ordering system wishes to subscribe to the laboratory notification topic to monitor fulfillment
capabilities available. An administrator grants the user representing the order system the
subscriber affiliation to the topic.





Description: Create an affiliation between a user and a topic.
Pre-Conditions:
 Current user has sufficient privileges.
 User must be authenticated.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
 User
 Role (See notes)
o Outputs:
 Success/Fail
Post-Conditions
 New affiliation created.
 Conflicting affiliations revoked. (See Table 1: Effect of Granting an
Affiliation
 Audit updated.
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Topic
 No Such Item
 Invalid Data
Page 72 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014


Required Affiliation Roles:
 Owner
 Administrator
Notes
Key to effects: X = No change, R = Revoked, I = Implied.
Grant
Existing Affiliations
Publish
Subscribe
Publish
Only
Only
X
X
X
R
R
R
R
R
R
X
R
R
R
X
R
Administrator
Outcast
Owner
Administrator
Outcast
Owner
Publish Only
Publish
X
R
I
X
X
R
X
R
R
R
X
R
X
X
X
Subscribe
Only
Subscriber
Reviewer
X
R
X
R
R
X
X
R
R
X
X
R
X
X
X
Subscriber
Reviewer
X
R
R
R
X
X
R
X
R
X
X
R
R
R
X
X
I
X
X
Table 1: Effect of Granting an Affiliation
The table shows the possible side effects of granting an affiliation to a user with
an existing affiliation to the topic. In some cases the granting of one role may
result in the loss of another existing privilege. For example a Publish Only user
granted the Subscriber role would lose the ability to publish. Such a user would
then be granted the Publish role if desired.
Delete Affiliation
This operation removes an affiliation between a user and a topic.
 Story Board
Dr. Smith has left the medical group and should no longer be allowed to publish the group’s
internal announcements topic.




Description: Removes a user’s affiliation to a topic
Pre-Conditions:
 Affiliation must exist.
 User must be authenticated.
 User must be authorized to remove the affiliation.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
 User
 Role
o Outputs:
 Success/Fail
Post-Conditions
 Affiliation is removed.
 May result is automatic granting to the ownership to the topic to the
current user if the existing owner is deleted.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 73
September 2014
© 2014 Health Level Seven International. All rights reserved.




Audit updated.
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Topic
 Invalid Data
Required Affiliation Roles:
 Administrator
 Owner
 The subject of the affiliation
Notes
Removing an affiliation that does to exist is considered valid and will return
success.
Update Affiliation
Update the affiliations for a specific user on a topic.
 Story Board
Dr. Jones has been designated as the new owner of the infection control topic this operation is
used to change the affiliations that affect the infection control topic.






Description: Updates the affiliation between a user and a topic
Pre-Conditions:
 User must have an affiliation for the topic.
 User must be authenticated.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
 User
 Role(s)
o Outputs:
 Success/Fail
Post-Conditions
 Updated Affiliation
 Conflicting affiliations revoked (See Table 1: Effect of Granting an
Affiliation)
 Audit updated
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 No Such Topic
 Incomplete Data
 Invalid Data
Required Affiliation Roles:
 Owner
Page 74 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014


Administrator
Notes
See Table 1: Effect of Granting an Affiliation for the possible side effects of
granting an affiliation to a user with an existing affiliation to the topic.
Get Affiliations for Topic
Get the affiliations for a topic. Used to determine which users have what access to the
topic. Results may be filtered based on the access level of the calling user.
 Story Board
Nurse Williams would like to publish her department’s scheduled event topic. Nurse Williams first
checks to see if they have an existing "Publisher" affiliation with the topic. She finds they do not
have this level of access, so she identifies the topic administrator so that she can request access.







Description: Retrieves a list of affiliations for a specific topic
Pre-Conditions:
 User must be authenticated.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
o Outputs:
 List of Affiliations
Post-Conditions
Exception Conditions
 Authentication Required
 Expired
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
 Current user’s Affiliations
Notes
This operation works for any user, but only the owners or administrators will see
all users in the return result. All other users will see only their affiliations with the
topic and the affiliations that have an owner or administrator affiliation role. This
insures that a user may always determine who to ask for access.
Get Affiliations for User
Find all the affiliations for a user including the topics to which they relate.
 Story Board
Dr. Hanks has a new assistant to whom he would like to have the same publication privileges
granted. A system administrator uses this operation to determine the scope of Dr. Hanks’s
accesses and grant publication rights to the new assistant.


Description: Finds all of the topic affiliation that a user has
Pre-Conditions:
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 75
September 2014
© 2014 Health Level Seven International. All rights reserved.






Current User must have administrator role or the Current user must be
the user in question.
 User must be authenticated.
Conceptual Information Objects
o Inputs:
 User or User List
o Outputs:
 List of Topic/Affiliations pairs
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 No Such Item
Required Affiliation Roles:
 Current User
 Filtered by Owner or Administrator
 [System Administrator]
Notes
This operation may be used by a user to determine all of his/her own affiliations.
System administrators may use this operation to get an unconstrained list of
results. All other users will get a list of results which is constrained based on the
interaction of the users’ affiliations and the topic’s current configuration.
Get Pending Access Requests
Finds pending subscription access requests for a topic
 Story Board
Assistant Director Niles has established a general policy topic, which is limited to selected
individuals and systems. This topic has been set up with a limited access model. On a periodic
basis he uses this operation to find and view any pending access requests to the topic.





Description: Returns a list of access request
Pre-Conditions:
 Feature must be supported
 Current user must be authenticated
 Current user must be authorized
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or expression
o Outputs:
 List of Pending Access requests for this topic
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
Page 76 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014



No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes
Reject Access request
This is used to mark a pending access request as being denied.
 Story Board
Assistant Director Niles, in reviewing access requests to the policy topic, has noticed a
publication access request from a department manager. Since the intent is only to have policies on
this topic that have been approved by the Assistant Directors or higher, the request is rejected.







Description: Marks an access requested as being rejected
Pre-Conditions:
 Feature must be supported.
 Current user must be authenticated.
 Current user must be authorized.
 Request must still be pending.
Conceptual Information Objects
o Inputs:
 Access request
o Outputs:
 Success/Fail
Post-Conditions
 Request marked as rejected
 Audit updated
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 Feature Not Available
Required Affiliation Roles:
 Owner
 Administrator
Notes
This action will take effect once the Process Pending Access Requests operation
is invoked.
Grant Access Request
This operation marks an access request as granted.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 77
September 2014
© 2014 Health Level Seven International. All rights reserved.

Story Board
Assistant Director Niles, in reviewing access requests to the policy topic, has noticed a
publication access request from the Director of Policy, who is an astute administrator. Niles
marks it as approved.





Description: Marks an access request as being granted
Pre-Conditions:
 Feature must be supported
 Current user must be authenticated
 Current user must be authorized
 Request must still be pending
Conceptual Information Objects
o Inputs:
 Access request
o Outputs:
 Success/Fail
Post-Conditions
 Request marked as accepted.
 Audit updated.
Exception Conditions
 Not Authorized
 Authentication Required
 Conflict
 Feature Not Available



Required Affiliation Roles:
 Owner
 Administrator
Notes
This action will take effect once the Process Pending Access Requests operation
is invoked.
Process Pending Access Requests
This operation causes all access requests for a topic that have been granted or denied
to take effect.
 Story Board
Assistant Director Niles has finished reviewing access requests and granting and rejecting the
most obvious requests. In order to have these actions take effect, he calls this operation.



Description: Makes grants and rejections of access requests on topic take effect
Pre-Conditions:
 Feature must be supported
 Current user must be authenticated
 Current user must be authorized
Conceptual Information Objects
o Inputs:
Page 78 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Topic – Topic Id, Path or expression
o Outputs:
 Success/Fail
Post-Conditions
 Each grant will cause a new affiliation to be formed.
 Each grant/rejection will generate a topic management event to the
requesting user.
 All granted and rejected requests are removed.
 Audit is updated.
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes





5.15 Broker Monitoring Interface
This interface provides basic monitoring of the state and behavior of the broker.
Figure 25: Broker Monitoring Interface
Get Broker Statistics
This operation is used to find basic statistics about the broker. The scope and nature
of the statistics returned is not detailed by this specification.
 Story Board
One department in the hospital complains that they are not receiving events in a timely manner.
System operators check the broker wide statistics to gauge general latency and determine if there
is a high fault rate.



Description: Find basic statistics about the broker.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 79
September 2014
© 2014 Health Level Seven International. All rights reserved.
o




Outputs:
 Statistics
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
Required Affiliation Roles:
Notes
Get Broker Status
This operation determines the current status of the broker. This can be used as a
general health monitoring tool. The scope and nature of the status information
returned is not detailed by this specification.
 Story Board
Operation staff has a Services dashboard to monitor and display overall system health. This
dashboard uses this service to access the broker’s basic health information







Description: Determine broker status.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
o Outputs:
 Status Info
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 N/A - This operation is in the context of Monitoring
Notes
Get Topic Statistics
This operation is used to get basic operational statics about a topic. This would
include information about the message in various states, subscribers, publishers, etc.
The scope and nature of the statistics returned is not detailed by this specification.
 Story Board
Noting a general system slow down, it is decided to review the usage of the EPS system to see
whether additional resources are needed or the configuration of the user population should be
adjusted. To accomplish the analysis, the usage statistics for individual topics are reviewed.


Description: Get statistics about a topic.
Pre-Conditions:
Page 80 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014





Conceptual Information Objects
o Inputs:
 Topic Id, Name, or Expression
o Outputs:
 Status Info
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 Owner
 Administrator
Notes
5.16 Federation interface
This interface provides the services used to control federation on the EPS broker.
Figure 26: Federation Interface
Get Master Federation Map
This operation retrieves a map of all federation relationships for this broker. The map
is detailed to the topic level.
 Story Board
Management is reviewing annual operating procedures and inter-business relationships. One
element of the study is to understand the sources of information provided to the organization. It is
also desired to understand what information is being shared at an institutional level. This is
accomplished by visualizing the information in the master federation map.



Description: Retrieve all Federation related mappings.
Pre-Conditions:
Conceptual Information Objects
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 81
September 2014
© 2014 Health Level Seven International. All rights reserved.
o
o




Inputs:
Outputs:
 Federation Map
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Item
Required Affiliation Roles:
 N/A – This operation is in the context of federation.
Notes
Get Source Map
This operation retrieves a map of all federation relationships from a specific source.
 Story Board
A Major business partner has announced a new change to the topics they support. This operation
is used to pull a tree of all topics provided to the local server for review.







Description: Retrieve federation map for a specific source.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Federation Source Id
o Outputs:
 Federation Map
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Item
Required Affiliation Roles:
 N/A – This operation is in the context of Monitoring
Notes
Get Target Map
This operation retrieves a map of all federation relationships to a specific target.
 Story Board
Concern is raised that a specific business partner may have a broader federation than is dictated
by the organization’s policy. A tree of all information sources provided to the partner is obtained
and visualized.


Description: Retrieves a map of all federation relationship to a specific target
Pre-Conditions:
Page 82 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014





Conceptual Information Objects
o Inputs:
 Federation Target Id
o Outputs:
 Federation Map
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 N/A – This operation is in the context of Monitoring.
Notes
Update Source
This operation allows a particular federation source definition to be modified. The
scope of the update may be constrained by operational constraints and might be
limited to updates such as credentials or state.
 Story Board
A national disease control EPS service is an existing data source for the local system, after a
recent update it can now handle synchronization dynamics. The local system is also
synchronization compatible so the decision is made to update the service to use synchronization.







Description: Update a federation source definition.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Federation Source Id
 Source Information
o Outputs:
 Success/Failure
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Item
Required Affiliation Roles:
 N/A – This operation is in the context of Monitoring.
Notes
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 83
September 2014
© 2014 Health Level Seven International. All rights reserved.
Update Target
This operation allows a particular federation target definition to be modified. The
scope of the update may be constrained by operational constraints and might be
limited to updates such as credentials or state.
 Story Board
A business partner has been acquired by another organization, which has consolidated their EPS
systems. The addressing information of the new target is updated.







Description Update a federation target definition.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Federation Source Id
o Outputs:
 Federation Map
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
Required Affiliation Roles:
 N/A – This operation is in the context of Monitoring.
Notes
Update Source Map
This operation updates the mapping between a particular source and the local and
remote topic trees.
 Story Board
A Local public health department has created a number of new topics the local institution has
decided should be a part of the local federation. The Source map is updated to enable this change.





Description: Updates the mapping between a source and the local and remote
topic trees
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Federation Source Id
o Outputs:
 Federation Map
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Topic
Page 84 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014


Required Affiliation Roles:
 N/A – This operation is in the context of Monitoring.
Notes
Update Target Map
This operation updates the mapping between a particular target and the local and
remote topic trees.
 Story Board
New topics have been configured that are of particular interest to a business partner. To expose
their interfaces for federation, the target map for that partner is updated.







Description: Updates the mapping between a target and the local and remote
topic trees
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 Federation Source Id
o Outputs:
 Federation Map
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 N/A – This operation is in the context of Monitoring.
Notes
5.17 PS Federation interface
This interface provides the interface whereby one federated broker is called by another
broker. The federation interface includes support for both push and pull dynamics and
may include some management information. It may also support synchronization
operations for relationships that are use a store and forward federation pattern.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 85
September 2014
© 2014 Health Level Seven International. All rights reserved.
Figure 27: PS Federation Interface
Receive Events
This operation is used to receive a set of push events from a federated system. It is
called by another broker to deliver events in bulk.
 Story Board
A Federation target receives a bulk push of events on one or more topics.







Description: To receive a set of push events
Pre-Conditions:
 Federation relationship must exist.
Conceptual Information Objects
o Inputs:
 Set of Events
o Outputs:
Post-Conditions
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of federation
Notes
Pull Events
This operation provides a mechanism to pull a set of events.
 Story Board
A federation source is requested to provide a bulk set of events on a set of topics.






Description: Provides a mechanism to pull a set of events
Pre-Conditions:
 Federation relationship must exist.
Conceptual Information Objects
o Inputs:
o Outputs:
 Set of Events
Post-Conditions
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of Federation.
Page 86 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014

Notes
Synchronize
This operation provides a mechanism for a federation partner to receive a
synchronization message. Synchronization messages are exchanged between
federation partners to coordinate their federation state.
 Story Board
A federation partner is informed of a synchronization event so it can ensure that it has the latest
copy of the events.







Description Receive a synchronization message.
Pre-Conditions:
 Federation relationship must exist.
 Servers must both support synchronization.
Conceptual Information Objects
o Inputs:
 Synchronization Message
o Outputs:
 Status
Post-Conditions
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of Federation.
Notes
Link Management Update
This operation is used to inform the federation partner of management information
relating to the link between the partners. For example, this might be used to inform a
partner that information on the link will not be available.
 Story Board
A federation partner is informed of a state change on its communications link with a partner.






Description: Informs the federation partner of management information relating
to the communications link
Pre-Conditions:
 Federation relationship must exist.
Conceptual Information Objects
o Inputs:
 Link Management Message
o Outputs:
 Acknowledgment
Post-Conditions
Exception Conditions
Required Affiliation Roles:
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 87
September 2014
© 2014 Health Level Seven International. All rights reserved.


N/A – This operation is in the context of Federation.
Notes
5.18 PS Publish-on-demand Interface
Interface for publisher that has desire to publish content only when there are subscribers
or for those publishers that provide dynamic topics.
Figure 28: PS Publish on Demand
The following diagram shows the typical publish on demand process:
Figure 29: Publish-on-demand
Page 88 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Start Publishing On Demand Topic
Requests that a publisher start publishing events on a topic
 Story Board
A laboratory system has registered as an on-demand publisher for the hematology results topic. A
CDS system subscribes to hematology results and the laboratory system is called to tell it to start
publishing hematology results.







Description: Allows the EPS broker to request that publisher start publishing on a
topic
Pre-Conditions:
 Publisher must have registered as an on demand publisher on the topic.
 Subscriber must exist for the topic.
 Topic must be enabled.
Conceptual Information Objects
o Inputs:
 Topic
o Outputs:
 Success/Fail
Post-Conditions
 On success, the EPS system will consider the publisher as actively
publishing to the topic.
 Expect that the publisher will start publishing to the topic.
Exception Conditions
 No Such Topic
Required Affiliation Roles:
 N/A – This operation is in the context of a publisher.
Notes
This operation is used by the EPS once a subscriber exists for a topic with an ondemand publisher.
Stop Publishing On Demand Topic
This operation instructs a publisher to stop publishing on a topic.
 Story Board
The CDS system is no longer interested in Hematology results and unsubscribes from the topic.
There are no longer any active subscribers to the topic, so the laboratory system is informed to
stop publishing on the topic.



Description: Used by the EPS system to inform a publisher the publications are
no longer required on a topic.
Pre-Conditions:
 Publisher must have registered as an on demand publisher on the topic.
 No subscribers must exist for the topic or the topic is disabled or
removed.
Conceptual Information Objects
o Inputs:
 Topic
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 89
September 2014
© 2014 Health Level Seven International. All rights reserved.
o




Outputs:
 Success/Fail
Post-Conditions
 On success the EPS system will consider the publisher as not
publishing to the topic.
Exception Conditions
 No Such Topic
Required Affiliation Roles:
 N/A – This operation is in the context of a publisher.
Notes
This operation is called by the EPS broker when the last subscription to the topic
is removed or the topic is disabled or removed.
Discover Topics

Story Board
An on-demand topic is registered as having dynamic subtopics and a user queries this topic. The
broker uses this service on the publisher to determine what additional topics exist for that
publisher.







Description: Returns the available topics for a specific publish-on-demand topic
Pre-Conditions:
 Called by the broker to determine dynamic topics.
Conceptual Information Objects
o Inputs:
 Topic Query
o Outputs:
 Topics
Post-Conditions
Exception Conditions
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 N/A – This operation is in the context of a publisher.
Notes:
Operation is required only for those publishers wishing to support dynamic topics.
The topic tree returned to the final user may actually be deeper then returned by
the publisher so that publisher context information can be presented. For example,
if the topic tree in questions was /notices/departments/…. and there are two
publishers A and B a system might return the following values:
/notices/departments/puba/radiology,
/notices/departments/puba/legal,
and
/notices/departments/pubb/radiology, /notices/departments/pubb/pharmacy. When
multiple publishers have dynamic content in the same topic, their sub trees are
considered disjointed.
Page 90 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Get Sub-Topics

Story Board
An on-demand topic is registered as having dynamic subtopics and a user queries this topic. The
broker uses this service on the publisher to determine what additional subtopics exist for that
publisher.







Description: Returns the available sub topics for a specific publish-on-demand
topic.
Pre-Conditions:
 Called by the broker to determine dynamic topics.
Conceptual Information Objects
o Inputs:
 Topic
o Outputs:
 Child Topics
Post-Conditions
Exception Conditions
 Feature Not Available
 No Such Topic
Required Affiliation Roles:
 N/A – This operation is in the context of a publisher.
Notes:
This operation is required only for those publishers wishing to support dynamic
topics. The topic tree returned to the final user may actually be deeper than that
returned by the publisher, so that publisher context information can be presented.
For example, if the topic tree in questions was “/notices/departments/…” and
there are two publishers A and B, the system might return the following values:
“/notices/departments/puba/radiology”, “/notices/departments/puba/legal”, and
“/notices/departments/pubb/radiology”,”
/notices/departments/pub/pharmacy”.
When multiple publishers have dynamic content for the same topic, their subtrees
are considered disjointed.
Retrieve Events
This operation allows a broker to contact an on-demand-publisher and use a pull
contract to request events. This request may be for a response in a "list" (aka
summary) or. "detail” form (aka list of events).

Story Board
The Clinical Decision Support System, now subscribed to the “New Laboratory Results” topic,
needs a few weeks of previously reported data to initialize its service. The system requests both a
list of all labs resulted, and the details of each test for all patients over the past three weeks.


Description: Allows the events on a topic offered by a on demand publisher to
be pulled by a broker
Pre-Conditions:
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 91
September 2014
© 2014 Health Level Seven International. All rights reserved.






Publisher must support the pull operation.
Conceptual Information Objects
o Inputs:
 Topic – Topic Id, Path or Expression, Subscription Id
 Pull Type – Full or Summary or Specific
 Pull Range: Recent or Specific
 Start: TimeStamp [Optional]
 End: TimeStamp [Optional]
 Media Forms desired [Optional]
o Outputs:
 List of Events or Event Summaries
Post-Conditions
 Subscriber specific context in topic may be updated.
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
 No Such Topic
 No Such Item
 Media Format Not Accepted
Required Affiliation Roles:
 N/A
Notes
For implementation, the operation might be represented using three separate
operations based on the Pull Type.
Replay Events
The operation requests that a publisher, given a time range, will redeliver all events
on a given topic.
 Story Board
A clinical modeling group is reviewing a patient’s encounter history with a clinical decision
engine and asks the broker to replay an encounter related topic for a particular patient to observe
the engine’s behavior.



Description: Replays events from an on demand publisher
Pre-Conditions:
 Publisher must support replay.
Conceptual Information Objects
 Inputs:
 Topic(s) – Topic Id, Path or Expression, Subscription Id
 Start: TimeStamp
 End: TimeStamp
Page 92 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014







Replay Id
Media Forms desired [Optional]
Replay Rate [Optional]
 Outputs:
 Events will be pushed to broker with the replay flag set to the
replay id.
Post-Conditions
 The broker will have the requested events pushed to them with the
replay flag set.
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 Feature Not Available
 No Such Topic
 Invalid Data
 Media Format Not Excepted
Required Affiliation Roles:
 N/A
Notes
The messages that are replayed will be sent with the provided replay id in their
header to allow the broker endpoint to clearly identify their sources.
5.19 PS Subscription Client Interface
Interface used to push events to a subscriber.
Figure 30: PS Subscription Client Interface
Topic Event
Receives an event
 Story Board
The CDS system has a push subscription to the admissions topic and a new admission is
published. The EPS system calls the CDS system with the new event.

Description: Used to receive an event
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 93
September 2014
© 2014 Health Level Seven International. All rights reserved.






Pre-Conditions:
 Push subscription to topic must exist.
Conceptual Information Objects
o Inputs:
 Topic
 Event
o Outputs:
 Success/Fail
Post-Conditions
 Event considered delivered for this subscription.
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of a subscriber.
Notes
Figure 31: Authenticated Push of Events
Topic Management Event
This operation is used by push subscribers to be informed of operational events of a
topic.
Page 94 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014

Story Board








The CDS system has a push subscription to the admissions topic. This topic requires
reconfiguration so the owner disables it. A topic management event is sent to the CDS system
so that it is aware this class of data is not currently being sent to it. When the configuration is
complete, the topic is enabled and another topic management event is sent indicating the new
status.
Description: Called to inform the subscriber of topic management related events
Pre-Conditions:
 Feature must be supported.
Conceptual Information Objects
o Inputs:
 Topic
 Topic Management Event
o Outputs:
 Success/Fail
Post-Conditions
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of a subscriber.
Notes
5.20 PS Publication Intervention Interface
The PS Publication Intervention Interface is used by the EPS broker to allow third parties
Add-in to reject or transform message content prior to publication. This provides an
essential service contract intervention point for such activities as virus scanning,
redaction, content tagging, content modification, message metadata updates, and policy
compliance.
Figure 32: PS Publication Intervention Interface
Review Message
Called to all content reviewers to alter, scan and reject content
 Story Board
A public topic is configured to automatically invoke virus checking when content is submitted. The
virus checker is invoked using an implementation of this service, which runs the check and if the
content is valid, accepts the content; otherwise, the content is rejected.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 95
September 2014
© 2014 Health Level Seven International. All rights reserved.







Description: Used by content reviewers to have an opportunity to scan, alter and
reject content
Pre-Conditions:
 Publication intervention must be configured for the broker or topic.
Conceptual Information Objects
o Inputs:
 Event
o Outputs:
 Event
 Action (Accepted/Rejected/Request Approval/Approved)
 Altered (yes/no)
Post-Conditions
 If “accepted” the content is passed to the next party.
 If “rejected” the publisher may be notified.
 If “request approval” is selected, the message is flagged for manual
approval. Additional accept events will not alter this state.
 “Approved” is a stronger form of “accepted” that overrides the
“request approval.”
 If altered is true, the altered output event is passed to the next party.
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of a review.
Notes
Publication intervention may be viewed as a chain of engines, each of which
might reject or alter the message. When no engines reject the event, then the
updated event is accepted for publication.
5.21 PS Content Brokering Interface
This interface is used by content consumers to negotiate content form with a content
provider. The interface is generally implemented by a content provider. An EPS broker
may also directly implement this interface to either directly provide content or act as an
intermediary between the original content provider and the consumer.
Figure 33: PS Content Brokering
Get Content
Page 96 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Fetch the content in the best matching form based on the requester’s desire.
 Story Board
Dr. Maxwell, a Radiologist, requests an event information as DICOM;TIFF;JPEG. The content
system supports DICOM, and since this is his first preference, the image is returned as DICOM.







Description: Retrieves content in a preferred matching form
Pre-Conditions:
 Caller must have the correct Content Id.
 Content must exist.
Conceptual Information Objects
o Inputs:
 Content Id
 Acceptable forms
o Outputs:
 Content Form
 Content
 Success/Fail
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 No Such Item
 Media Format Not Accepted
Required Affiliation Roles:
 N/A – This operation is in the context of content fetch.
Notes
The operation can fail when there is no common form between the requester and
the forms available on the server.
Supports Content Form
This operation is used to determine if a set of specific content forms is supported on a
content item.
 Story Board
A subscriber is acting as a bridge to an incoming HL7 V2 stream and when an event is received
with content negotiation, it checks to see if the event has a HL7 V2 representation.



Description: Determine the content forms supported by a content item.
Pre-Conditions:
 Caller must have the correct Content Id.
 Content must exist.
Conceptual Information Objects
o Inputs:
 List of desired forms (including any)
o Outputs:
 List of matching content forms
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 97
September 2014
© 2014 Health Level Seven International. All rights reserved.




Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 No Such Item
Required Affiliation Roles:
 N/A – This operation is in the context of content fetch.
Notes
Get Preferred Content
This operation will return the content in the form that is preferred by the content
provider.
 Story Board
A content consumer would like to consume content in a form, which the sender considers the most
relevant form as determined by the publisher.







Description: Returns the content in the form that is preferred by the content
provider
Pre-Conditions:
 Caller must have the correct Content Id.
 Content must exist.
Conceptual Information Objects
o Inputs:
 Content Id
o Outputs:
 Content Type
 Content
Post-Conditions
Exception Conditions
 Not Authorized
 Authentication Required
 Expired
 No Such Item
Required Affiliation Roles:
 N/A – This operation is in the context of content fetch.
Notes
5.22 PS Delivery Intervention interface
This interface is used by the EPS service to provide a point to intervene on message
delivery and topic access based on the consumer (subscriber).
Page 98 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Figure 34: PS Delivery Intervention
Control Topic Access
Allows a plugin engine to accept or reject a subscription to a topic.
 Story Board
Local policy places additional constraints on topic access based on third party approval.







Description: Filter Access to a topic.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 User Id
 Subscription
 Topic
o Outputs:
 Allow/Disallow
Post-Conditions
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of subscription.
Notes
Review Message
This operation provides the ability to alter and filter the messages and content
received by a subscriber.
 Story Board
Specific security tagging of message content is used to determine if a specific user can see specific
events and, if so, what form the content takes.



Description: Alters and/or filters messages or content by subscriber.
Pre-Conditions:
Conceptual Information Objects
o Inputs:
 User Id
 Event
o Outputs:
 Event
 Action: Pass/Updated/Filter
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 99
September 2014
© 2014 Health Level Seven International. All rights reserved.




Post-Conditions
 On a Pass action the event is passed to the next handler.
 On an Update action the new(altered) event is passed to the next
handler
 On a Filter action, no further processing will be done on this event and
it will not be send by the subscriber.
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of content filtering.
Notes
Review Content
This operation provides the ability to alter and filter content as part of the content
negotiation process. This operation is invoked by EPS systems that provides content
negotiation.
 Story Board
An event has been delivered to a subscriber that includes negotiated content, and the user’s view
of the content may need to be restricted.







Description: Alters and/or filters content by subscriber
Pre-Conditions:
 Request for Content via a PS Content Brokering Interface
implemented on the EPS system.
Conceptual Information Objects
o Inputs:
 User Id
 Event
o Outputs:
 Event
 Action: Pass/Updated/Filter
Post-Conditions
 On a Pass action the event is passed to the next handler.
 On an Update action the new (altered) event is passed to the next
handler.
 On a Filter action, no further processing will be done on this event and
it will not be sent by the subscriber.
Exception Conditions
Required Affiliation Roles:
 N/A – This operation is in the context of content filtering.
Notes
Page 100 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
6 Examples
This section is non-normative.
6.1 Auto Registration
The following activity diagram show how auto registration works:
Example 1: Auto Register Service access
6.2 Topic Navigation
Two examples of topic navigation follow.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 101
September 2014
© 2014 Health Level Seven International. All rights reserved.
6.3 Publication Review
The following is an example automatic Publication review.
Page 102 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Example 2: Publication Review
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 103
September 2014
© 2014 Health Level Seven International. All rights reserved.
6.4 Delivery review
The following is an example of Delivery review (Distribution filtering). There are two
dynamic forms of the review depending on whether the distribution is via a push event or
a pull request.
6.4.1 Delivery review – Push Event
The following diagram shows delivery review when an event is being pushed to a
subscriber.
Example 3: Push Event
Page 104 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
6.4.2 Delivery Review – Pull Request (List)
The following diagram shows a pull request by a subscriber for what events are available.
Delivery review filters the list of items returned to the subscriber.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 105
September 2014
© 2014 Health Level Seven International. All rights reserved.
Example 4: Delivery Review – Pull Request (List)
Page 106 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
6.4.3 Delivery review – Pull Request (Detail)
The following diagram shows how a pull request for a specific event is reviewed.
Example 5: Delivery review – Pull Request (Detail)
6.5 Auto Register a publisher
The following example shows how auto registration interacts with the publication.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 107
September 2014
© 2014 Health Level Seven International. All rights reserved.
6.6 Auto Register a Subscriber
The following example shows how auto registration interacts with the subscription.
Page 108 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 109
September 2014
© 2014 Health Level Seven International. All rights reserved.
6.7 Pull from an On Demand Publisher
The following is an example of a Pull from an On demand publisher.
Example 6: Pull from an On Demand Publisher
6.8 On Demand Topic Tree
The following is an example of an On Demand Topic tree
Page 110 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Example 7: On Demand Topic Tree
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 111
September 2014
© 2014 Health Level Seven International. All rights reserved.
6.9 Topic Administration
The following example shows some of the typical interactions that a topic administrator
might have with a topic.
6.10 User Administration
The following examples show three different user registration scenarios.
Page 112 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
7 Profiles
7.1
Introduction
A profile is a named set of cohesive capabilities. A profile enables a service to be
used at different levels and allows implementers to provide different levels of
capabilities in differing contexts. Service-to-service interoperability will be judged
at the profile level and not the service level. Note that through the use of profiles,
there are no “optional” interfaces. Conditions that might otherwise merit this
optionality should be addressed via a dedicated profile.
Include the following boilerplate text:
A set of profiles may be defined that cover specific functions, semantic information and
overall conformance. The SSDF explains in detail the meaning of each of these types of
profile. In brief, they are as follows:

Functional Profile: a named list of a subset of the operations defined within this
specification that 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
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 113
September 2014
© 2014 Health Level Seven International. All rights reserved.
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:
7.2

Differing business contexts

Different localizations

Different information models

Partner-to-Partner
contexts

Product packaging and offerings
Interoperability
Base Conformance Profile
Interface
Broker
Publication
Subscription
PS Subscription Client
Broker Management
Operation
Discover Capabilities
Discover Events For Topic
Discover Topics
Get Sub Topics
Get Topic Options
Request Access
Publish Event
Delete Event
Assert Presence
Configure Subscription Options
Get Default Subscription Options
Replay Events
Retrieve Events
Subscribe
Unsubscribe
Topic Event
Topic Management Event
Configure Topic
Create Topic
Create User
Delete Topic
Delete User
Discover User
Get Access Requests
Get Publishers For Topic
Get Subscriptions For Topic
Get Topic Metadata
Requirement
Yes
Recommended
Yes
Yes
Recommended
No
Yes
Recommended
No
Recommended
Recommended
No
Yes
Yes
Yes
Strongly Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
No
Recommended
Recommended
Recommended
Page 114 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
Interface
Topic Management
7.3
Operation
Grant Access Request
Purge All Topic Events
Reject Access Request
Create Affiliation
Delete Affiliation
Get Affiliations For Topic
Get Affiliation For User
Move Topic
Get Pending Access Requests
Grant Access Request
Process Pending Access Requests
Reject Access Request
Update Affiliation
Requirement
No
Recommended
No
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
Recommended
Push Based Subscriptions Conformance Profile
The push based subscriptions conformance profile requires the base conformance profile
and makes the following modifications:
Interface
Subscription
PS Subscription Client
Operation
Replay Events
Topic Event
Topic Management Event
Requirement
Optional
Yes
Strongly Recommended
Note: Some other features will require honoring specific data fields but should otherwise
fit in the earlier profile.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 115
September 2014
© 2014 Health Level Seven International. All rights reserved.
7.4
Access Request Conformance Profile
The access request conformance profile requires the base conformance profile and makes
the following modifications:
Interface
Broker
Broker Management
PS Subscription Client
Topic Management
Operation
Request Access
Create User
Delete Topic
Delete User
Discover User
Get Access Requests
Grant Access Request
Reject Access Request
Topic Management Event
Create Affiliation
Delete Affiliation
Get Affiliations For Topic
Move Topic
Get Pending Access Requests
Grant Access Request
Process Pending Access Requests
Reject Access Request
Update Affiliation
Requirement
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes – If Push is supported
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Note: Some other features will require honoring specific data fields but should otherwise
fit in the earlier profile.
Publish-on-demand Conformance Profile
The Publish-On-Demand profile requires the base conformance profile. Publish on
demand is made of four main features: base, pull, replay, and dynamic topics. With the
exception of the base features, the other features are optional and may be combined to
offer additional capability. The following show the additional interfaces beyond the base
conformance profile to support Publish-on-demand:
Interface
PS Publishing On Demand
7.5
Operation
Start Publishing
End Publishing
Retrieve Events
Replay Events
Discover Topic
Get Subtopics
Requirement
Yes - Base
Yes - Base
For Pull support
For Replay support
For Dynamic Topics
For Dynamic Topics
Presence Conformance Profile
The presence conformation profile builds the push based subscription profile or the
publish-on-demand profile and makes the following modifications:
Interface
Publication
Subscription
Operation
Assert Presence
Assert Presence
Requirement
If POD is supported.
If Push based subscriptions are
supported.
Page 116 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
7.6
Intervention Conformance Profile
The intervention conformance profile requires the base conformance profile and makes
the following modifications:
Interface
PS Publication Intervention
PS Delivery Intervention
7.7
Operation
Review Message
Review Content
Review Message
Control Topic Access
Requirement
Yes
Yes
Yes
Yes
Replay Conformance Profile
The replay request conformance profile requires the base conformance profile and makes
the following modifications:
Interface
Subscription
PS Publish On Demand
7.8
Operation
Replay Events
Replay Events
Requirement
Yes
Recommended if Publish One
Demand is supported
Federation Conformance Profile
The federation request conformance profile requires the base conformance profile and
makes the following modifications:
Interface
Federation
PS Federation
Operation
Get Master Federation Map
Update Source
Get Source Map
Update Source Map
Get Target
Get Target Map
Update Target Map
Receive Events
Pull Events
Synchronize
Link Management Update
Requirement
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Recommended
Yes
Note: Some other features will require honoring specific data fields but should otherwise
fit in the earlier profile.
HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm Page 117
September 2014
© 2014 Health Level Seven International. All rights reserved.
8 System Interaction Details [Optional]
Describe the dynamics of the service from a requirement-level architectural view
and its interactions with anticipated (services/components/applications, etc.)
High-level description, illustrating the storyboards, elaborated for each storyboard
in Chapter 3.
May use any well known, reasonable mechanism for communicating the
information, (e.g., UML Activity Diagrams or Sequence Diagrams)
Page 118 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
9 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 installed translation dictionaries.
However, a consumer system as a whole will typically be dependent on the analysis of
medical data and metadata in a language that can be parsed in a triple-store paradigm
from different content repositories. Although this would not affect the EPS service as a
module, it would not produce useful data packages for the system without the means to
analyze a repository of data in the same format. Such a system has only been
developed for the English language, although other languages are in development.
Page 119 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
10 Appendix A - Relevant Standards
OMG: Data Distribution Service
ATOM: IETF RFC 4887 and RFC 5023
XMPP: XEP-0060: Publish-Subscribe
OASIS: WS-BaseNotification, WS-BrokeredNotification and WS-Topics
Page 120 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
11 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
ADT
ANSI
CDC
CDS
CDSS
DRG
DRI
DSS
EHR
EPS
HITSP
HL7
HSSP
IHE
ISO
KM
ODP
OID
OMG
PIM
PSM
POD
QOS
RCF
RFP
RIM
Full Name
Admission-Discharge-Transfer
American National Standards Institute (U.S.A.)
Center for Disease Control
Clinical Decision Support
Clinical Decision Support Service (synonymous with DSS)
Data Requirement Group
Data Requirement Item
Decision Support Service
Electronic Health Record
Event Publish and Subscribe Service
Health Information Technology Standards Panel of ANSI
Health Level 7
Healthcare Services Specification Project
Integrating the Healthcare Enterprise
International Organization for Standardization
Knowledge Module
On-Demand Publisher
Object Identifier
Object Management Group
Platform Independent Model
Platform Specific Model
Publish-on-Demand
Quality of Service
Remove Content Flag
Request for Proposal
Reference Information Model defined by HL7
Page 121 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
RM-ODP
SFM
SOA
STM
UML
Reference Model of Open Distributed Processing
Service Functional Model
Service Oriented Architecture
Service Technical Model
Unified Modeling Language
Page 122 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1 - US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
12 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.
Page 123 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
13 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
(e.g., realm-specific profiles, domain-specific profiles, etc.).
7. Details about semantics specific to this SFM appear in other sections of this document.

Consumer viewpoint and the value offered by the work product
Page 125 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
14 Appendix E – Functionality Comparison Matrix
The following table compares available functionality in this EPS to that of other industry
specifications. This section is non-normative.
Function
EPS
XMPP
Push Subscriber is a specialized subscriber that can actively review information and events.
OASIS
OMG
X
A content provider is an entity that can create events and fulfill content requests relating to an
event.
X
Publication Reviewer is an entity that can review, alter and filter publications prior to public
publication.
X
X
X
X
The HistoryCache forms the interface between the DDS Entities and their corresponding
RTPS Entities. both the RTPS entities and their related DDS entities are able to invoke the
operations on their associated HistoryCache.
X
Delivery Reviewer is an entity that can review, alter and filter events and information on a
subscriber level prior to the subscriber receiving the data.
X
Topic provides a convenient mechanism for grouping and organizing events into cohorts so
that they can be more easily managed
X
X
Topic Tree is a hierarchical (parent/child) grouping of Topics.
X
X
Topic Set is the collection of Topics supported by a NotificationProducer.
X
Meta data describes a topic, the types of events it publishes, event durability, etc.
Event Durability interacts with the ability of a topic to receive and deliver a message in a
transactional manner. Durability is explicitly related to the integrity of the event handling. The
spectrum of durability covers topics that are transient in nature to topics where full transaction
message qualities are required.
Retention defines if events are retained after all subscribers have received them. For
example, do they time out (cease delivery attempts after a fixed time period) and do they
expire? The following are the possible retention policies: Permanent, Until Delivered,
Unretained, Fixed Time period, Until Expired, Fix Period after Delivery, Fixed Period after
Expiration
X
X
X
X
Replay for a topic can be supported if the topic has a compatible retention policy.
X
Options allow one or more characteristics of a topic to be configured.
X
Publication Contract enables a Publisher to deliver events that are to be published by the
Service.
Messages provide the mechanism for participants to communicate and exchange information.
X
X
X
X
Messages Module describes the overall structure and logical contents of the messages that
are exchanged between the Writer endpoints and Reader endpoints.
Page 127 HL7 Version 3 Specification: Event Publish & Subscribe Service Interface, Release 1- US Realm
© 2014 Health Level Seven International. All rights reserved.
September 2014
X
X
Message Header provides routing and other metadata required for sending and receiving
messages.
X
X
AckNack submessage indicates acknowledgement state--positive or negative.
X
Gap a type of submessage sent from an RTPS Writer to an RTPS Reader and indicates to
the RTPS Reader that a range of sequence numbers is no longer relevant. The set may be a
contiguous range of sequence numbers or a specific set of sequence numbers.
X
Heartbeat is a message sent from an RTPS Writer to an RTPS Reader to communicate the
sequence numbers of changes that the Writer has available.
X
HeartbeatFrag: When fragmenting data and until all fragments are available, the
HeartbeatFrag Submessage is sent from an RTPS Writer to an RTPS Reader to
communicate which fragments the Writer has available. This enables reliable communication
at the fragment level. Once all fragments are available, a regular Heartbeat message is used.
X
InfoDestination message is sent from an RTPS Writer to an RTPS Reader to modify the
GuidPrefix used to interpret the Reader entityIds appearing in the Submessages that follow it.
X
InfoReplay message is sent from an RTPS Reader to an RTPS Writer. It contains explicit
information on where to send a reply to the Submessages that follow it within the same
message.
X
Message Body contains the content of the message.
X
Management Event communicates operational information about the Service, its users, and
the topics being published.
X
Mgmt Event Header provides routing and other metadata required for sending and receiving
management messages.
X
Authorship identifies the source of the event being published.
X
User is a person with the authority to access the Service, register a source of events, or
subscribe to a topic.
X
X
X
X
X
X
X
X
Participant: Container of all RTPS entities that share common properties and are located in a
single address space.
X
HistoryCache: Container class used to temporarily store and manage sets of changes to
data-objects. On the Writer side it contains the history of the changes to data-objects made
by the Writer. On the Reader side it contains the history of the changes to data-objects made
by the matched RTPS Writer endpoints.
X
An affiliation is an access profile that defines the privileges afforded to a user on a specific
topic. See Affiliation Role for more information on privileges.
X
Access Model provides default security configuration for a Topic, for example, whether
authorization is required for Users or not, or if the Topic is not open for registration at all.
X
Access Request: A request by a Publisher/Subscriber to be able to be granted access to the
Service.
X
Affiliation Role specifies access privileges afforded to users by their affiliations with specific
topics, for example, a Publisher or a Subscriber. A user may have multiple roles on a topic.
The granting of some roles on the topic may grant or revoke other previous grants.
X
Service Capability communicates the functional abilities of a particular implementation, for
example, whether it can support on demand publishing, anonymous subscriptions, or
configurable durability.
X
Notification Address: The address (endpoint) at which a Publisher or a Subscriber expects to
receive communicates.
X
Channel: A communication queue that provides a mechanism for publishers and subscribers
to manage messages pertaining to the topics that are to be published or that have been
subscribed to.
X
Topic Trees are grouped together into the same namespace for administrative purposes. In
order to avoid naming collisions, and to facilitate interoperation between independently
developed NotificationProducers and Subscribers, every WS-Notification Topic is assigned to
an XML Namespace. The set of Topics associated with a given XML Namespace is termed a
Topic Namespace. Any XML Namespace has the potential to scope a collection of Topics.
Event, Situation: Some occurrence known to a NotificationProducer and of potential interest
to third parties. A Situation could be a change of the internal state of a resource or could be
environmental, such as a timer event. It could also be an external event, such as a piece of
news that has been supplied by a news-feed service.
X
X
X
Page 128
Event Publish & Subscribe Service Interface, Release 1
© 2014 Health Level Seven International. All rights reserved.
January 2014
X
Brokered Publication Model acts as an intermediary managing all content contracts. Some of
the potential advantages to the brokered model are listed below:
•
Clients need only implement one simple contract.
•
Support for multiple subscription forms. For example, push, pull, or replay.
•
Provides a single audit and control point
•
Strong base for providing ACID and transactional properties
•
Exhibits noninterference at a computational level with mission critical systems
•
Provides a single point of implementation to the complex portions of the service
•
Brokers may be validated by national processes.
The broker provides a single business integration point enabling best of breed capabilities to
be developed without undue burden on publishers or subscribers. With a goal of making the
publisher/subscriber roles as lightweight as possible, the broker may run independently of
either.
Broker is the main intermediary of published and delivering information and events.
Discover Topics: Inquire into available topics
X
X
X
X
X
SubscriptionManager is an endpoint, represented by an endpoint reference that implements
message exchanges associated with the SubscriptionManager interface. A
SubscriptionManager provides operations that allow a service requestor to query and
manipulate Subscription resources that it manages. A SubscriptionManager is subordinate to
the NotificationProducer, and MAY be implemented by the NotificationProducer service
provider. However WS-Notification permits it to be implemented by a separate service
provider, should an implementer so desire. The SubscriptionManager interface defines
message exchanges to manipulate Subscription resources. A NotificationBroker is an
intermediary Web service that decouples NotificationConsumers from Publishers. A
notification broker can relieve a Publisher from having to implement message exchanges
associated with NotificationProducer; the NotificationBroker takes on the duties of
subscription management and distributing Notifications on behalf of the Publisher. It
implements NotificationProducer interface.
Renew: To modify the current lifetime of a Subscription, a requestor sends a Renew request
message to the SubscriptionManager.
RegisterPublisher: A Publisher sends a Notify message to a NotificationBroker in order to
publish a Notification on a given Topic. As a result of the Publisher sending this message,
Notifications are delivered to all NotificationConsumers subscribed on the given Topic. This is
a PUSH subscription.
A NotificationBroker MAY also support the required message exchanges defined in the WSResourceProperties specification and MAY support the optional message exchanges defined
in the WS-ResourceProperties specification. 5.2 /wsn-br:RequiresRegistration: The value is
“true” if the NotificationBroker requires a publisher to register before sending it a Notify (i.e.
publish) message on a Topic. Publisher registrations.
Get Sub Topics
X
X
X
X
X
X
X
X
X
Get Topic Options: Get the options that are used to configure topics on this broker.
X
Discover Node Metadata
X
X
Discover Events for Topic: This operation is used to get a “directory” of the events that have
been published to a topic.
X
X
Discover Features, DiscoverCapabilities: Inquire into Broker Capabilities. The services
provide information about the general capabilities of the Broker. This includes the type of
contracts the broker is capable of and which optional features are available.
X
X
Request Access: This operation is used to submit a user profile for the EPS system
requesting access.
X
Subscription is a contract that enables a Subscriber to receive events that have been
published to the Service.
X
X
X
X
Subscriber is a consumer of information.
X
X
X
X
Subscribe To A Topic operation allows a subscriber to subscribe to a specific topic or topics
depending on the capability of the broker. Some brokers may support wildcard and filter
based subscriptions. The nature of the subscription is also specified in this call.
X
X
X
Unsubscribe allows a subscriber to remove an existing subscription from the EPS service.
The events queue for this subscription is deleted.
X
X
X
Retrieve Events (PULL) allows a client, who always is responsible for retrieving content in a
pull contract, to request "list" vs. "detail."
X
X
X
X
Event Publish & Subscribe Service Interface, Release 1
Page 129
January 2014
© 2014 Health Level Seven International. All rights reserved.
Requesting the Most Recent Items: A service MAY allow entities to request the most recent N
items by using the ’max_items’ attribute. When max_items is used, implementations
SHOULD return the N most recent (as opposed to the N oldest) items. (Note: A future version
of this specification may recommend the use of XEP-0059 instead of the ’max_items’
attribute.) 6.5.8 The subscriber can request a particular item by specifying the Node ID and
the appropriate ItemID.
Replay Events: Given a time range, all events on a given topic will be redelivered or retrieved
based on the type of subscription and the nature of the topic.
X
Returning Some Items: A node may have a large number of items associated with it, in which
case it may be problem- atic to return all of the items in response to an items request. In this
case, the service SHOULD return some of the items and note that the list of items has been
truncated by including a Result Set Management notation.
X
X
X
X
X
Assert Presence: This operation allows subscribers to update their presence statuses.
X
X
Configure Subscription Options: This operation allows a subscriber to change the options
associated with a specific subscription.
X
X
Filter component: The process of selecting messages for reception and processing is called
filtering and can be categorized as topic-based or content-based.
X
X
Filter component
X
X
X
X
/wsnt:Subscribe/wsnt:SubscriptionPolicy/wsnt:UseRaw: An element whose presence
indicates that the NotificationProducer is to produce Notifications without using the
wsnt:Notify wrapper. This element SHOULD NOT occur more than once in a Subscribe
request message, as only its presence or absence is significant.
X
/wsnt:SubscribeResponse/wsnt:SubscriptionReference: A reference to the Subscription
created as a result of the Subscribe message.
X
Get Default Subscription Options: The operation allows a subscriber to get the default
subscription options for a topic. This is most useful when subscribing to a new topic.
X
Request Default Subscription Configuration Options; part of get default: An entity might want
to request information about the default subscription configuration. Support for this feature is
OPTIONAL.
Notification: Notify subscriber of event.
X
X
X
NotificationConsumer Interface (Notify message): In contrast to the "raw" notification, the
Notify message provides a well-specified mechanism by which the NotificationProducer can
supply additional information (such as the Topic) in addition to the application-specific
Notification content. It also allows the NotificationConsumer to receive a wide range of
Notifications without having to explicitly provide support for each one in its WSDL. This form
of Notification also allows a batch of several Notifications to be combined into a single
physical message.
X
X
Notification Reliability: Depending on the actual delivery mechanism, this transmission might
be reliable or might be done on a best-effort basis. A Notification which is never produced will
definitely never be delivered, but the converse is not necessarily true: a Notification which is
produced may or may not actually be delivered, depending on the delivery mechanism, the
validity of the NotificationConsumer address, the state of the network, and so forth.
Notification Metadata: A combination of the following metadata elements in the Notifications it
produces: Subscription Reference (Endpoint Reference), Topic (Topic Expression),
Topic/@Dialect, Producer Reference.
/wsnt:Subscribe/wsnt:Filter/wsnt:TopicExpression/@Dialect:
X
Topic Expression Dialects: Topics are referred to by TopicExpressions. There are several
places in WS-Notification where these expressions can appear:
• As a component of the Subscribe message request to a NotificationProducer;
• As a component of a Notification message sent to a NotificationConsumer or
NotificationBroker;
• In the TopicExpression Resource Property element(s) associated with the
NotificationProducer role
/
Publication: The service allows a publisher to publish or delete an event in an already defined
topic. The publisher in question must typically have authenticated access to publish on the
specific topic matter. More than one publisher might have privileges to publish on a specific
topic. A publisher might have privileges to publish a single event to more than one topic.
X
Publisher is an entity that makes information or events available by publishing it.
X
X
X
Page 130
Event Publish & Subscribe Service Interface, Release 1
© 2014 Health Level Seven International. All rights reserved.
January 2014
X
Publisher Requirements: NotificationProducers MAY advertise more constrained behavior
through policy assertions or other means. In cases where the wsnt:UseRaw policy component
is not specified, the Web service identified by the endpoint reference SHOULD implement the
Notify message, as the NotificationProducer will by default produce Notifications in this form.
/wsnt:Subscribe/wsnt:Filter: The NotificationProducer MUST respond with an
InvalidFilterFault message if any child expression element is not supported by the
NotificationProducer. A NotificationProducer MAY accept any filters that may be defined.
X
Return Fault: If the subscription request cannot be handled, the NotificationProducer returns a
fault. The production of Notifications may be realized in a number of ways. In one particular
configuration, the NotificationProducer reproduces
Notifications produced by other entities. Alternatively, a NotificationProducer may produce
Notifications itself.
X
Publication: Publish Event to Topic
X
X
Extension Topics: A NotificationProducer MAY support Topics that are marked as Extensions
of other Topics. Support for such Topics is OPTIONAL
X
Delete Event from Topic, Delete an Item from a Node: This operation allows a publisher to
remove a previously published event from a topic.
X
Assert Presence: Assert presence allows Publish-on-demand publishers to update their
presence statuses.
X
Auto Register a Publisher, Auto Register a Subscriber
X
X
Register_type allows an application to communicate to the Service the existence of a data
type.
X
Automatic Node Creation: A pubsub service MAY automatically create a node when it
receives a publish request sent to a node that does not exist.
X
Publishing Options: A pubsub service MAY support the ability to specify options along with a
publish request.
X
Create Affiliation: This service creates an affiliation between a user and a topic. This affiliation
will grant the user specific privileges on the topic.
X
Get Affiliations for Topic: Get the affiliations for a topic. Used to determine which users have
what access to the topic.
X
X
Get Affiliations for User: Find all the affiliations for a user including the topics to which they
relate.
X
X
Update Affiliation
X
X
Delete Affiliation
X
X
Get Pending Access Requests
X
Grant Access Request
X
Reject Access Request
X
Process Pending Access Requests
X
Management: The service supports registering a publisher, updating a directory of publishers,
creating and configuring topics, publishing topic events, managing subscriptions, etc. Service
Administration: Administrative functionality includes registering publishers, managing the
topics that producers can publish to, supporting subscriber consumer subscriptions, or
managing the affiliations to a topic such as related topics, banned users, ownership, whitelist,
etc.
Broker Manager (dupe)
Create Topic/Node or subtopic
X
X
X
X
X
X
X
X
Create a Node With Default Configuration; Request Default Node Configuration Options: The
node creator accepts the default configuration. A service MAY allow entities to determine the
default configuration options for a given node type before creating a node. 8.3 An entity may
want to request information about the default node configuration, e.g. in order to determine
whether to perform create-and-configure as previously described. Support for this feature is
OPTIONAL.
remove_change: This operation indicates that a previously-added CacheChange has become
irrelevant and the details regarding the CacheChange need not be maintained in the
HistoryCache.
Delete Topic
X
X
X
Event Publish & Subscribe Service Interface, Release 1
Page 131
January 2014
© 2014 Health Level Seven International. All rights reserved.
X
delete contained entities: This operation deletes all the entities that were created by means of
the “create” operations on the DomainParticipant.
That is, it deletes all contained Publisher, Subscriber, Topic, ContentFilteredTopic, and
MultiTopic.
Configure Topic: Update the configuration and/or metadata relating to a topic.
X
X
X
Form Submission, Form Processing: After receiving the configuration form, the owner
SHOULD submit a completed configuration form. If the form can be successfully processed,
the service MUST return an IQ-result.
X
Get Topic Metadata
X
Resource limits policy controls the resources that the Service can use in order to meet the
requirements imposed by the application and other QoS settings. If the DataWriter objects are
communicating samples faster than they are ultimately taken by the DataReader objects, the
middleware will eventually hit against some of the QoS-imposed resource limits. Note that this
may occur when just a single DataReader cannot keep up with its corresponding DataWriter.
The behavior in this case depends on the setting for the RELIABILITY QoS. If reliability is
BEST_EFFORT, then the Service is allowed to drop samples. If the reliability is RELIABLE,
the Service will block the DataWriter or discard the sample at the DataReader 28in order not
to lose existing samples.
Get Publisher(s) ForTopic: This service will retrieve all publishers for a particular topic.
X
X
X
X
get default publisher: This operation retrieves the default value of the Publisher QoS, that is,
the QoS policies which will be used for newly
created Publisher entities in the case where the QoS policies are defaulted in the
create_publisher operation.
X
get default publisher QoS: set default publisher QoS: This operation retrieves the default
value of the Publisher QoS, that is, the QoS policies which will be used for newly-created
Publisher entities in the case where the QoS policies are defaulted in the create_publisher
operation. OMG2 7.1.2.2.1.23 set default publisher QoS This operation sets a default value of
the Subscriber QoS policies that will be used for newly created Subscriber entities
in the case where the QoS policies are defaulted in the create_subscriber operation.
get default subscriber QoS: This operation retrieves the default value of the Subscriber QoS,
that is, the QoS policies which will be used for newly created Subscriber entities in the case
where the QoS policies are defaulted in the create_subscriber operation.
X
X
Implementing DDS QoS and advanced DDS features using RTPS: The RTPS protocol and its
extension mechanisms provide the core functionality required to implement DDS.
X
Supported QoS: The Data-Distribution Service (DDS) relies on the use of QoS. A QoS
(Quality of Service) is a set of characteristics that controls some aspect of the behavior of the
DDS Service.
X
Get Subscriptions For Topic
X
X
X
ignore subscription: This operation allows an application to instruct the Service to locally
ignore a remote subscription. After this call, any data received related to that subscription will
be ignored.
X
Purge All Topic Events
X
Create a User: Register a user with the broker. This operation is used to establish a user, the
user configuration information, privileges, and access to topics including role.
X
Delete a User
X
Discover a User: This operation is used to find users and all basic information about that user.
X
X
X
X
Versioning and Extensibility. Implementations of this version of the RTPS protocol should be
able to process RTPS Messages not only with the same major version but possibly higher
minor versions. 8.6.1 Within this major version, future minor versions of the protocol can
augment the protocol in the following ways:
•
Additional Submessages with other submessageIds can be introduced and used
anywhere in an RTPS Message. An implementation should skip over unknown Submessages
using the submessageLength field in the SubmessageHeader.
•
Additional fields can be added to the end of a Submessage that was already defined in
the current minor version. An implementation should skip over additional fields using the
submessageLength field in the SubmessageHeader.
•
Additional built-in Endpoints with new IDs can be added. An implementation should
ignore any unknown built-in Endpoints.
•
Additional parameters with new parameterIds can be added. An implementation should
ignore any unknown parameters.
Page 132
Event Publish & Subscribe Service Interface, Release 1
© 2014 Health Level Seven International. All rights reserved.
January 2014
X
X
X
X
Move Topic: This operation allows a topic to be move to a different location in the topic tree.
All events, subscriptions, and publication contracts remain in place.
X
Update a User: Update the information associated with a user. This would include privileges,
options, and authentication information for the user.
X
Manage Subscription Requests: A service MAY send subscription approval requests to the
node owner(s) at any time.
Grant Access Request: Upon receiving the data form for managing subscription requests, the
owner then MAY request pending subscription approval requests for a given node.
Reject Access Request: This operation allows an application to instruct the Service to locally
ignore a remote domain participant. From that point onwards the Service will locally behave
as if the remote participant did not exist. This means it will ignore any Topic, publication, or
subscription that originates on that domain participant.
X
X
X
Get Broker Status: This operation determines the current status of the broker.
X
Get Broker Statistics: This operation is used to find basic statistics about the broker.
X
Get Topic Statistics: This operation is used to get basic operational statics about a topic.
X
Federation: The service supports a federated operating model whereby an EPS broker can
be a part of a larger network of brokers, each responsible for publishing topics and
information according to their content provider contracts and individual configurations.
Federation allows multiple EPS systems to form a larger information resource, providing
transparent information sharing for their user base.
X
Get Master Federation Map: This operation retrieves a map of all federation relationships for
this broker.
Update Source: This operation allows a particular federation source definition to be modified.
X
X
X
Get Source Map: This operation retrieves a map of all federation relationships for a specific
source.
X
Update Source Map: This operation updates the mapping between a particular source and
the local and remote topic trees.
X
Update Target: This operation allows a particular federation target definition to be modified.
X
Get Target Map: This operation retrieves a map of all federation relationships for a specific
target.
X
Update Target Map: This operation updates the mapping between a particular target and the
local and remote topic trees.
X
Receive Events: This operation is used to receive a set of push events from a federated
system.
Pull Events: This operation provides a mechanism to pull a set of events.
Accumulating Notification Messages: Notification Messages received by the PullPoint through
its NotificationConsumer interface are accumulated by the PullPoint on a best effort basis. If
the PullPoint is no longer capable of accumulating additional Notification Messages, it MAY
ignore Notification Messages sent to its NotificationConsumer interface, or it MAY dispose of
any previously accumulated Notification Messages and continue to accumulate incoming
Notification Messages.
X
X
X
X
X
X
Synchronize: This operation provides a mechanism for a federation partner to receive a
synchronization message.
X
Link Manage Update: This operation is used to inform the federation partner of management
information relating to the link.
X
Get Content: Fetch the content in the best matching form based on the requester’s desire.
X
Get Preferred Content: This operation will return the content in the form that is preferred by
the content provider.
X
Supports Content Form: This operation is used to determine if a set of specific content forms
is supported on a content item. 2.3 Content Brokering: The service has a notion of deferred
content delivery and negotiation whereby an indirect reference to content can be passed to
the broker and subscribers. This allows large artifacts and multiple presentations of data to be
supported efficiently. Content brokering is a general capability that a particular publisher
would support. It is expected the broker may be able to act as a content brokering
intermediary when the origin material is not publicly available to the subscribers. Subscribers
use content brokering to get to information in their preferred form (format, character set,
presentation, language, etc.)
X
On Demand Publisher: The On Demand Publisher is a specialized form of publisher that can
offer data when a subscriber is interested in it.
X
X
Event Publish & Subscribe Service Interface, Release 1
Page 133
January 2014
© 2014 Health Level Seven International. All rights reserved.
Start Publishing On Demand Topic: Requests that a publisher start publishing events on a
topic.
X
X
Stop Publishing On Demand Topic: This operation instructs a publisher to stop publishing on
a topic.
X
X
Retrieve Events: This operation allows a broker contact an on-demand-publisher and use a
pull contract to request events.
X
X
DestroyPullPoint: The PullPoint interface provides a destroy operation, providing a means by
which a requestor can terminate the PullPoint resource. Upon receipt of the DestroyPullPoint
request, the PullPoint MUST attempt to destroy itself. If the DestroyPullPoint request
message is successfully processed, the PullPoint MUST send a response message. If the
PullPoint does not respond to the DestroyPullPoint request message with the
DestroyPullPointResponse message, then it MUST send a fault.
X
X
DestroyPullPoint Faults: If the PullPoint does not respond to the DestroyPullPoint request
message with the DestroyPullPointResponse message, then it MUST send a fault. This
specification defines the following
faults associated with failure to process the DestroyPullPoint request message:
* ResourceUnknownFault: The PullPoint is acting as a WS-Resource, and the resource
identified in the request message is not known to the Web service.
* UnableToDestroyPullPointFault: The PullPoint was unable to destroy the PullPoint resource
for some reason.
Replay Events: The operation requests that a publisher, given a time range, will redeliver all
events on a given topic.
XMPP: Retrieve Items from a Node: Implementations of pubsub that choose to persist items
MAY allow entities to request existing items from a node (e.g., an entity may wish to do this
after successfully subscribing in order to receive all the items in the publishing history for the
node).
X
X
Inquire into available topics (Discover Topics): Returns the available topics for a specific
publish-on-demand topic.
X
Get Subtopics: Returns the available sub topics for a specific publish-on-demand
X
Topic Event: Receives an event.
X
Topic Management Event: This operation is used by push subscribers to be informed of
operational events of a topic.
X
Review Content: This operation provides the ability to alter and filter content as part of the
content negotiation process. 2.3 Content Intervention: The service supports active
intervention on information that is accepted for publication. In addition, intervention is also
allowed on a per delivery basis to a specific subscriber. Intervention can include analysis,
rejection/filtering, supplementation, alteration, and redaction. Intervention can be chained and
are configurable by broker managers and topic owner.
Review Message: This operation provides the ability to alter and filter the messages and
content received by a subscriber.
Control Topic Access: Allows a plug-in engine to accept or reject a subscription to a topic.
X
X
X
X
X
ignore topic: This operation allows an application to instruct the Service to locally ignore a
Topic. This means it will locally ignore any
X
publication or subscription to the Topic.
X
Security Considerations: Baseline security considerations for WS-Notification are discussed
in WS-BaseNotification specification.
X
X
Form Submission: After receiving the configuration form, the requesting entity SHOULD
submit the form in order to update the entity’s subscription options for that node.
X
Form Processing: If the service can successfully process the submission, it MUST respond
with success.
X
IM Account Integration: Publish-subscribe functionality can be integrated into existing instant
messaging and pres- ence services (see RFC 3921), such that each registered account
functions as a virtual pubsub service.
X
Subscription Manager Interface, Base Subscription Manager: broker functionality and
subscription management: The SubscriptionManager interface defines message exchanges
to manipulate Subscription resources. There are two styles of SubscriptionManager interface:
base and pausable. All SubscriptionManagers MUST implement the message exchanges
described in the Base Subscription Manager section. The basic behavior of a
SubscriptionManager is to renew the duration of a Subscription resource and terminate a
Subscription.
X
X
Page 134
Event Publish & Subscribe Service Interface, Release 1
© 2014 Health Level Seven International. All rights reserved.
January 2014
Pausable Subscription Manager, PauseSubscription: A Pausable Subscription Manager
implements all the message exchanges defined in the Base Subscription Manager and
augments this with a set of advanced capabilities to allow third parties to pause and resume
subscriptions. To temporarily suspend the production of Notifications on the given
Subscription, a requestor MAY send a PauseSubscription request message to the
SubscriptionManager.
X
Resume Subscription: If a requestor wishes to resume the production of Notifications on the
given Subscription, it must send a ResumeSubscription request message.
X
Subscriptions as WS-Resources: Either Base Subscription Managers or Pausable
Subscription Managers MAY expose subscriptions as WS-Resources. A Subscription
Manager that exposes Subscriptions as WS- Resources MUST support the required message
exchanges associated with the WS- ResourceProperties specification [WSResourceProperties] and MAY support the OPTIONAL message exchanges defined by WSResourceProperties. If a SubscriptionManager exposes Subscriptions as WS-Resources then
these WS-Resources MUST support the immediate termination interface defined by Web
Services Resource Lifetime [WS-ResourceLifetime] and MAY support the scheduled
termination interface defined by Web Services Resource Lifetime. Such Subscription
Managers MAY support other means of destroying Subscriptions. A Subscription Manager
MUST declare to requestors (for example in a WSDL definition) which means of Subscription
destruction are supported.
PublisherRegistrationManager Interface: The PublisherRegistrationManager interface defines
message exchanges to manipulate PublisherRegistration resources. The
PublisherRegistrationManager MAY expose PublisherRegistrations as WS-Resources, and if
it does then the PublisherRegistrationManager MUST support the immediate termination
interface defined by WS-ResourceLifetime and it MAY support the scheduled termination
interface defined by WS-ResourceLifetime. If the PublisherRegistrationManager does not
respond to a request message with a response message defined in this specification, then it
MUST send a fault. The WS-ResourceProperties and WS-ResourceLifetime specifications
define some of these fault messages.
PublisherRegistration Resource Properties: In addition to the message exchanges described
in this specification, a PublisherRegistrationManager MAY also support the required message
exchanges defined in the WS-ResourceProperties specification and MAY support the optional
message exchanges defined in the WS-ResourceProperties specification.
X
X
X
create_publisher, delete_publisher: A Publisher is an object responsible for data distribution.
It may publish data of different data types. A DataWriter acts as a typed accessor to a
publisher. The Publication Module contains the Publisher and DataWriter classes as well as
the PublisherListener and DataWriterListener interfaces, and more generally, all that is
needed on the publication side.
X
DCPS - Data-Centric Publish-Subscribe
X
Structure of the Service: This operation creates a ContentFilteredTopic. A
ContentFilteredTopic can be used to do content-based subscriptions. The deletion of a
ContentFilteredTopic is not allowed if there are any existing DataReader objects that are
using the ContentFilteredTopic.
X
create_multitopic, delete_multitopic: Call out notion of aggragate topics and their mgmt.
(similar to createtopic & deletetopic)
X
X
get built-in subscriber: This operation allows access to the built-in Subscriber. Each
DomainParticipant contains several built-in Topic objects as well as corresponding
DataReader objects to access them. All these DataReader objects belong to a single built-in
Subscriber [Here, subscriber does not mean consumer, right?]. The built-in Topics are used
to communicate information about other DomainParticipant, Topic, DataReader, and
DataWriter objects.
X
create_participant, delete participant, lookup_participant (See User.)
X
get_instance (too low level (implementation level): This operation returns the
DomainParticipantFactory singleton. The operation is idempotent, that is, it can be called
multiple times without side-effects and it will return the same DomainParticipantFactory
instance.
X
set_qos, get_qos; set default publisher Quality of Service (QoS).: This operation sets a
default value of the Publisher QoS policies which will be used for newly created Publisher
entities in the case where the QoS policies are defaulted in the create_publisher operation.
OMG1 2.2.1 With the Quality-of-Service concept, DDS provides a sophisticated means to
dynamically tailor data distribution according to the application requirements. In particular,
QoS provide the ability to control and limit the use of resources like network bandwidth or
memory as well as reliability, timeliness and persistence of the data transfer.
X
Event Publish & Subscribe Service Interface, Release 1
Page 135
January 2014
© 2014 Health Level Seven International. All rights reserved.
X
Topics Class: The Topic-Definition Module is comprised of the following classes:
• TopicDescription
• Topic
• ContentFilteredTopic
• MultiTopic
• TopicListener
• TypeSupport
X
X
Derived Classes for Each Application Class: The DCPS Publication Module is comprised of
the following classifiers:
• Publisher
• DataWriter
• PublisherListener
• DataWriterListener
X
create_ datawriter, delete_datawriter, READER_DATA_LIFECYCLE
X
Detection of loss in topological connectivity: There are applications that are designed in such
a way that their correct operation requires some minimal topological
connectivity, that is, the writer needs to have a minimum number of readers or alternatively
the reader must have a minimum number of writers.
X
DLRL objects
X
List: It provides the following methods:
• remove - to remove the item with the highest index from the collection.
• added_elements - to get a list that contains the indexes of the added elements.
• removed_elements - to get a list that contains the indexes of the removed elements.
• modified_elements - to get a list that contains the indexes of the modified elements.
• add - to add an item to the end of the list.
X
RTPS Header structure
X
RTPS Receiver, RTPS Message Receiver: For each new Message, the state of the Receiver
is reset and initialized as listed below. OMG1 8.3.4 The interpretation and meaning of a
Submessage within a Message may depend on the previous Submessages contained within
that same Message. Therefore, the receiver of a Message must maintain state from
previously deserialized Submessages in the same Message. This state is modeled as the
state of an RTPS Receiver that is reset each time a new message is processed and provides
context for the interpretation of each Submessage.
X
SubmessageElements (RTPS ). Submessage structure. RTPS Submessages. Purpose: Each
RTPS Message consists of a variable number of RTPS Submessage parts. All Submessages
start with a SubmessageHeader part followed by a concatenation of SubmessageElement
parts. The SubmessageHeader identifies the kind of Submessage and the optional elements
within that Submessage. The SubmessageHeader contains the fields listed in Table 8.15:
submessageId, flags, submessageLength. Submessages are categorized into two groups:
Entity- Submessages and Interpreter-Submessages. Entity Submessages target an RTPS
Entity. Interpreter Submessages modify the RTPS Receiver state and provide context that
helps process subsequent Entity Submessages.
Additional SubmessageElements: In addition to the SubmessageElements introduced by the
PIM, the UDP PSM introduces the additional SubmessageElements.
X
X
User traffic: User traffic is the traffic exchanged between user-defined Endpoints (i.e., non
built-in Endpoints). As such, it pertains to all the traffic that is not related to discovery.
X
OMG 2: 8.4.4 The Behavior of a Writer with respect to each matched Reader: The behavior of
an RTPS Writer with respect to each matched Reader depends on:
• The setting of the reliabilityLevel attribute in the RTPS Writer and RTPS Reader. This
controls whether a best-effort or
a reliable protocol is used.
• The setting of the topicKind attribute in the RTPS Writer and Reader. This controls whether
the data being
communicated corresponds to a DDS Topic for which a Key has been defined.
X
RTPS Writer Attributes. Configuration attributes of the RTPS Entities: Includes pushMODE,
hearbeatPeriod, etc. RTPS entities are configured by a set of attributes. Some of these
attributes map to the QoS policies set on the corresponding DDS entities. Other attributes
represent parameters that allow tuning the behavior of the protocol to specific transport and
deployment situations. Additional attributes encode the state of the RTPS Entity and are not
used to configure the behavior.
X
Large Data: Includes several sections on fragments
X
Page 136
Event Publish & Subscribe Service Interface, Release 1
© 2014 Health Level Seven International. All rights reserved.
January 2014
Simple Endpoint Discovery Protocol. Simple Participant Discovery Protocol. Simple Endpoint
Discovery Protocol: The purpose of a PDP is to discover the presence of other Participants
on the network and their properties. A Participant may support multiple PDPs, but for the
purpose of interoperability, all implementations must support at least the Simple Participant
Discovery Protocol. An Endpoint Discovery Protocol defines the required information
exchange between two Participants in order to discover each other’s Writer and Reader
Endpoints. A Participant may support multiple EDPs, but for the purpose of interoperability, all
implementations must support at least the Simple Endpoint Discovery Protocol.
X
Removal of a previously discovered Participant: Based on the remote Participant’s
leaseDuration, a local Participant ‘local_participant’ concludes that a previously discovered
Participant with GUID_t participant_guid is no longer present. The Participant
‘local_participant’ must reconfigure any local Endpoints that were communicating with
Endpoints in the Participant identified by the GUID_t participant_guid.
X
What cannot change within this major Version: The following items cannot be changed within
the same major version:
• A Submessage cannot be deleted.
• A Submessage cannot be modified except as described in Section 8.6.1.
• The meaning of submessageIds cannot be modfied.
All such changes require an increase in the major version number.
X
Globally Unique Identifier (GUID) is an attribute present in all RTPS Entities that uniquely
identifies them within the DDS domain. The PIM defines the GUID as composed of a
GuidPrefix_t prefix capable of holding 12 bytes, and an EntityId_t entityId capable of holding 4
bytes.
X
Mapping of the RTPS Messages
X
Data Encapsulation
X
DCPS comprises five modules: Domain, Publication, Subscription, Topic, Infrastructure
X
The Infrastructure Module defines the abstract classes and the interfaces that are refined by
the other modules. It also provides support for the two interaction styles (notification- and
wait- based) with the middleware. It comprises the following classifiers: Entity, DomainEntity,
QosPolicy, Listener, Status, WaitSet, Condition, GuardCondition, StatusCondition
X
The Domain Module contains the DomainParticipant class that acts as an entry-point of the
Service and acts as a factory for many of the classes. The DomainParticipant also acts as a
container for the other objects that make up the Service.
X
MultiTopic
X
DataReader
X
Message States: Every message has a state which describes where it is in the broker’s
workflow.
· Delivered – Subscribers have received the message.
· Expired – Message has expired.
· Review Pending – Message requires review.
· Rejected – Message rejected from publication.
· Initial – Message is new.
· Approved – Message is approved for publication.
· Deleted – Message has been removed.
· Pending – Message is pending delivery to subscribers.
Coherent Sets: The DDS specification provides the functionality to define a set of sample
updates as a coherent set. A DataReader is only notified of the arrival of new updates once
all updates in the coherent set have been received.
What constitutes a coherent set is defined on the DataWriter side by using the container
Publisher to denote the beginning and end of the coherent set. A coherent set may span only
the instances written to by a given DataWriter (access scope TOPIC) or may span across
multiple DataWriters belonging to the same Publisher (access scope GROUP). Please refer
to the DDS specification for additional details. In order to support coherent sets, RTPS uses
the in-line QoS parameter extension mechanism to include additional information in-line with
each Data Submessage. The additional information denotes membership to a particular
coherent set.
Directed Write: Direct peer-to-peer communications may be enabled within the publishsubscribe framework of DDS by tagging samples with the handles of the intended
recipient(s). RTPS supports directed writes by using the in-line QoS parameter extension
mechanism. The serialized information denotes the GUIDs of the targeted reader(s). When a
writer sends a directed sample, only recipients with a matching GUID accept the sample; all
other recipients acknowledge but absorb the sample, as if it were a GAP message.
X
Event Publish & Subscribe Service Interface, Release 1
Page 137
January 2014
© 2014 Health Level Seven International. All rights reserved.
X
X
X
Message Elements: All events will have a few common elements which are covered
below:
· Creation Time – The actual time the event was created by the publisher.
· Publication Time – The time at which the broker should publish the event. If empty the
broker will assign the current time.
· Expiration Time – The time at which the event should expire. If not provided, the event will
expire in accordance with topic
and broker policies.
· Publisher – The publisher of the event as known by the broker.
· Author – Authorship information about the creator of the event. Intended for external
consumption.
Look for/discover participants: get_participant
X
Application portability: The DDS specification also includes a platform specific mapping to IDL
and therefore an application using DDS is able to switch among DDS implementations with
only a re-compile.
X
The PIM describes the protocol in terms of a “virtual machine.” The structure of the virtual
machine is built from the classes described in Section 8.2, which include Writer and Reader
endpoints.
X
Platform Specific Model (PSM) : UDP/IP: The goal for this PSM is to provide a mapping with
minimal overhead directly on top of UDP/IP.
X
Behavior Required for Interoperability: The only purpose of introducing the RTPS virtual
machine is to describe the protocol in a complete and un-ambiguous manner. This description
is not intended to constrain the internal implementation in any way. The only criteria for a
compliant implementation is that the externally-observable behavior satisfies the
requirements for interoperability. 8.4.2 This section describes the requirements that all
implementations of the RTPS protocol must satisfy in order to be compliant with the protocol
specification & interoperable with other implementations. 8.4.2.1.1 All communications must
take place using RTPS Messages; 8.4.2.1.2 All implementations must implement the RTPS
Message Receiver; 8.4.2.1.3 The timing characteristics of all implementations must be
tunable; 8.4.2.1.4 Implementations must implement the Simple Participant and Endpoint
Discovery Protocols
RTPS WriterProxy: The RTPS WriterProxy represents the information an RTPS
StatefulReader maintains on each matched RTPS Writer. The association is a consequence
of the matching of the corresponding DDS Entities as defined by the DDS specification, that is
the DDS DataReader matching a DDS DataWriter by Topic, having compatible QoS,
belonging to a common partition, and not being explicitly ignored by the application that uses
DDS.
Page 138
Event Publish & Subscribe Service Interface, Release 1
© 2014 Health Level Seven International. All rights reserved.
January 2014
X
X