ISO/IEEE 11073-20702:2018

INTERNATIONAL ISO/IEEE
STANDARD 11073-
First edition
2018-09
Health informatics — Point-of-care
medical device communication —
Part 20702:
Medical devices communication
profile for web services
Informatique de santé — Communication entre dispositifs médicaux
sur le site des soins —
Reference number
©
IEEE 2017
© IEEE 2017
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from IEEE at the address below.
Institute of Electrical and Electronics Engineers, Inc
3 Park Avenue, New York
NY 10016-5997, USA
Email: stds.ipr@ieee.org
Website: www.ieee.org
Published in Switzerland
ii © IEEE 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national
standards bodies (ISO member bodies). The work of preparing International Standards is normally
carried out through ISO technical committees. Each member body interested in a subject for which a
technical committee has been established has the right to be represented on that committee.
International organizations, governmental and non‐governmental, in liaison with ISO, also take part
in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all
matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for
the different types of ISO documents should be noted (see www.iso.org/directives).
IEEE Standards documents are developed within the IEEE Societies and the Standards
Coordinating Committees of the IEEE Standards Association (IEEE‐SA) Standards Board. The IEEE
develops its standards through a consensus development process, approved by the American
National Standards Institute, which brings together volunteers representing varied viewpoints and
interests to achieve the final product. Volunteers are not necessarily members of the Institute
and serve without compensation. While the IEEE administers the process and establishes rules to
promote fairness in the consensus development process, the IEEE does not independently evaluate,
test, or verify the accuracy of any of the information contained in its standards.
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction
and/or on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does
not constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
ISO/IEEE 11073‐20702 was prepared by the IEEE 11073 Standards Committee of the IEEE
Engineering in Medicine and Biology Society (as IEEE Std 11073‐20702‐2016) and drafted in
accordance with its editorial rules. It was adopted, under the “fast‐track procedure” defined in the
Partner Standards Development Organization cooperation agreement between ISO and IEEE, by
Technical Committee ISO/TC 215, Health informatics.
A list of all parts in the ISO/IEEE 11073 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body.
A complete listing of these bodies can be found at www.iso.org/members.html.
© IEEE 2017 – All rights reserved iii

IEEE Std 11073™-20702-2016
Health informatics—Point-of-care medical device communication

Part 20702: Medical Devices
Communication Profile for
Web Services
Sponsor
IEEE 11073™ Standards Committee
of the
IEEE Engineering in Medicine and Biology Society
Approved 22 September 2016
IEEE-SA Standards Board
Abstract: Within the context of the ISO/IEEE 11073 family of standards for point-of-care (PoC)
medical device communication, a communication protocol specification for a distributed system
of PoC medical devices and medical IT systems that need to exchange data, or safely control
networked PoC medical devices by profiling Web Service specifications, is defined by this standard.
Additional Web Service specifications are part of this standard.
Keywords: Devices Profile for Web Services, DPWS, Efficient XML Interchange, EXI, IEEE 11073-
20702™, ISO/IEEE 11073, MDC, medical device communication, PoC, point-of-care, safety, Simple
Object Access Protocol, SOAP, Streaming Web Services, WS-Discovery
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 26 May 2017. Printed in the United States of America.
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers,
Incorporated.
W3C is trademarks or registered trademarks of the W3C®, (registered in numerous countries) World Wide Web Consortium. Marks of W3C
are registered and held by its host institutions: Massachusetts Institute of Technology (MIT), European Research Consortium for Information
and Mathematics (ERCIM), and Keio University, Japan.
PDF: ISBN 978-1-5044-2324-3 STD21112
Print: ISBN 978-1-5044-2325-0 STDPD21112
IEEE prohibits discrimination, harassment, and bullying.
For more information, visit http:// www .ieee .org/ web/ aboutus/ whatis/ policies/ p9 -26 .html.
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission
of the publisher.
© IEEE 2017 – All rights reserved

Important Notices and Disclaimers Concerning IEEE Standards Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These notices
and disclaimers, or a reference to this page, appear in all standards and may be found under the heading
“Important Notices and Disclaimers Concerning IEEE Standards Documents.” They can also be obtained on
request from IEEE or viewed at http://standards .ieee.or g/ IPR/ disclaimers.html .
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards
Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are
developed within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Asso-
ciation (“IEEE-SA”) Standards Board. IEEE (“the Institute”) develops its standards through a consensus
development process, approved by the American National Standards Institute (“ANSI”), which brings together
volunteers representing varied viewpoints and interests to achieve the final product. IEEE Standards are doc-
uments developed through scientific, academic, and industry-based technical working groups. Volunteers in
IEEE working groups are not necessarily members of the Institute and participate without compensation from
IEEE. While IEEE administers the process and establishes rules to promote fairness in the consensus develop-
ment process, IEEE does not independently evaluate, test, or verify the accuracy of any of the information or
the soundness of any judgments contained in its standards.
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure
against interference with or from other devices or networks. Implementers and users of IEEE Standards doc-
uments are responsible for determining and complying with all appropriate safety, security, environmental,
health, and interference protection practices and all applicable laws and regulations.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and
expressly disclaims all warranties (express, implied and statutory) not included in this or any other document
relating to the standard, including, but not limited to, the warranties of: merchantability; fitness for a particular
purpose; non-infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In
addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort. IEEE standards
documents are supplied “AS IS” and “WITH ALL FAULTS.”
Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there
are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and
issued is subject to change brought about through developments in the state of the art and comments received
from users of the standard.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other
services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any
other person or entity to another. Any person utilizing any IEEE Standards document, should rely upon his or
her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropri-
ate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCURE-
MENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH
DAMAGE WAS FORESEEABLE.
© IEEE 2017 – All rights reserved

Translations
The IEEE consensus development process involves the review of documents in English only. In the event that
an IEEE standard is translated, only the English version published by IEEE should be considered the approved
IEEE standard.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE-SA Standards Board Operations
Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall
not be considered to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or
educational courses, an individual presenting information on IEEE standards shall make it clear that his or her
views should be considered the personal views of that individual rather than the formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless
of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice
pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a
proposed change of text, together with appropriate supporting comments. Since IEEE standards represent a
consensus of concerned interests, it is important that any responses to comments and questions also receive
the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards
Coordinating Committees are not able to provide an instant response to comments or questions except in those
cases where the matter has previously been addressed. For the same reason, IEEE does not respond to interpre-
tation requests. Any person who would like to participate in revisions to an IEEE standard is welcome to join
the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the
provisions of any IEEE Standards document does not imply compliance to any applicable regulatory require-
ments. Implementers of the standard are responsible for observing or referring to the applicable regulatory
requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance
with applicable laws, and these documents may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws.
They are made available by IEEE and are adopted for a wide variety of both public and private uses. These
include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and
the promotion of engineering practices and methods. By making these documents available for use and adop-
tion by public authorities and private users, IEEE does not waive any rights in copyright to the documents.
© IEEE 2017 – All rights reserved

Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy
portions of any individual standard for company or organizational internal use or individual, non-commercial
use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer
Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy
portions of any individual standard for educational classroom use can also be obtained through the Copyright
Clearance Center.
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time
by the issuance of new editions or may be amended from time to time through the issuance of amendments,
corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the doc-
ument together with any amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years
old and has not undergone a revision process, it is reasonable to conclude that its contents, although still of
some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that
they have the latest edition of any IEEE standard.
In order to determine whether a given document is the current edition and whether it has been amended
through the issuance of amendments, corrigenda, or errata, visit the IEEE Xplore at http://ieeexplore .ieee .or g/
or contact IEEE at the address listed previously. For more information about the IEEE-SA or IEEE’s standards
development process, visit the IEEE-SA Website at http://standards .ieee.or g.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL:
http://standards .ieee.or g/ findstds/ errata/index .html. Users are encouraged to check this URL for errata
periodically.
Patents
Attention is called to the possibility that implementation of this standard may require use of subject matter
covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to
the existence or validity of any patent rights in connection therewith. If a patent holder or patent applicant
has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the
IEEE-SA Website at http://standards .ieee.or g/ about/sasb/ patcom/ patents .html. Letters of Assurance may
indicate whether the Submitter is willing or unwilling to grant licenses under patent rights without compensa-
tion or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair
discrimination to applicants desiring to obtain such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not
responsible for identifying Essential Patent Claims for which a license may be required, for conducting inqui-
ries into the legal validity or scope of Patents Claims, or determining whether any licensing terms or conditions
provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are
reasonable or non-discriminatory. Users of this standard are expressly advised that determination of the valid-
ity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further
information may be obtained from the IEEE Standards Association.
© IEEE 2017 – All rights reserved

Participants
At the time this standard was submitted to the IEEE-SA Standards Board for approval, the Point-of-Care
Devices Working Group had the following membership:
Jan Wittenber, Chair
Stefan Schlichting, SubGroup Chair
Bjoern Anderson Kai Hassing Robert Mortonson
Malcolm Clarke John Hatcliff Stephan Poehlsen
Todd Cooper Stefan Karl Tracy Rausch
Chris Courville Martin Kasparick John Rhoads
Gion Durisch Daniel Krahenbuhl Paul Schluter
Michael Faughn Koichiro Matsumoto Janek Schumann
Kenneth Fuchs Joerg-Uwe Meyer Masato Tanaka
John Garguilo Ali Miller Eugene Vasserman
David Gregorczyk Stan Wiley
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Bjoern Andersen Kai Hassing Stephan Poehlsen
Charles Barest John Hatcliff Beth Pumo
Lyle Bullock Werner Hoelzl Bartien Sayogo
Todd Cooper Noriyuki Ikeuchi Stefan Schlichting
Sourav Dutta Atsushi Ito Paul Schluter
Kenneth Fuchs Stefan Karl Eugene Stoudenmire
Joel Goergen Piotr Karocki Walter Struppler
Frank Golatowski Martin Kasparick J. Wiley
Eric W. Gray William Lumpkins Jan Wittenber
David Gregorczyk Joerg-Uwe Meyer Oren Yuen
Randall Groves Daidi Zhong
When the IEEE-SA Standards Board approved this standard on 22 September 2016, it had the following
membership:
Jean-Philippe Faure, Chair
Ted Burse, Vice Chair
John D. Kulick, Past Chair
Konstantinos Karachalios, Secretary
Chuck Adams Ronald W. Hotchkiss Mehmet Ulema
Masayuki Ariyoshi Michael Janezic Yingli Wen
Stephen Dukes Joseph L. Koepfinger* Howard Wolfman
Jianbin Fan Hung Ling Don Wright
J. Travis Griffith Kevin Lu Yu Yuan
Gary Hoffman Annette D. Reilly Daidi Zhong
Gary Robinson
*Member Emeritus
© IEEE 2017 – All rights reserved

Introduction
This introduction is not part of IEEE Std 11073-20702-2016, Health informatics—Point-of-care medical device
communication—Part 20702: Standard for Medical Devices Communication Profile for Web Services.
ISO/IEEE 11073 standards enable communication between medical devices and external computer systems.
They provide automatic and detailed electronic data capture of patient vital signs information and device
operational data. The primary goals are to:
— Provide real-time plug-and-play interoperability for patient-connected medical devices
— Facilitate the efficient exchange of vital signs and medical device data, acquired at the point-of-care
(POC), in all healthcare environments
This standard defines a discovery, messaging, and event propagation method for a distributed POC medi-
cal device communication system. It serves as communication transport layer related to the existing
ISO/IEEE 11073 standards series (ISO/IEEE 11073-10101:2004 [B6], ISO/IEEE 11073-10201:2004 [B7], and
ISO/IEEE 11073-20101:2004 [B8]). Moreover, a set of protocols is defined that allows transmission of
real-time streams (e.g., waveforms) and remote control of a medical device in a safe way. For this purpose,
it introduces implementation constraints and extensions on the Devices Profile for Web Services (DPWS)
standard (OASIS DPWS V1.1) in order to allow the utilization of DPWS in such an environment.
Furthermore, this standard is intended to be compatible with the Integrating the Healthcare Enterprise (IHE)
International’s technical framework specifications for using Web Services for achieving interoperability in
healthcare [e.g., Web Services Basic Profile 2.0 (WS-I Basic Profile V2.0)], which is used by Information
Technology Infrastructure (ITI) Technical Framework Volume 2, Appendix V: Web Services for IHE Trans-
actions, and further referenced for device information exchange in the Patient Care Device (PCD) Technical
Framework Volume 2 [B5].
In the IHE Patient Care Device (PCD) domain, Web Services are used to wrap IHE PCD HL7 messages.
Beyond that, this standard adds the capability of providing a plug-and-play and publish-subscribe supporting
Web Services infrastructure to create a service-oriented architecture in distributed systems of medical devices.
The non-normative name of this standard is “Medical Devices Profile for Web Services” (MDPWS).
The numbers in brackets correspond to those of the bibliography in Annex E.
© IEEE 2017 – All rights reserved

Contents
1. Overview . 10
1.1 Scope . 10
1.2 Purpose . 10
2. Normative references . 10
3. Definitions, terminology, notational conventions, and normative statements . 12
3.1 Definitions . 12
3.2 Terminology . 13
3.3 Notational conventions . 13
3.4 XML namespaces . 16
4. General messaging . 17
4.1 Introduction . 17
4.2 SOAP-over-UDP . 17
4.3 SOAP-over-HTTP . 17
5. Dynamic discovery. 18
6. Service description . 18
6.1 General . 18
6.2 Web Services Description Language (WSDL) . 18
7. Eventing . 19
8. Streaming . 20
8.1 General . 20
8.2 Advertising stream information . 20
8.3 Stream types and stream descriptions . 20
8.4 Retrieving stream descriptions . 22
8.5 SOAP-over-UDP Multicast Stream Binding . 23
9. Safe data transmission . 24
9.1 General . 24
9.2 Advertising safety requirements . 24
9.3 Retrieving safety requirements . 28
9.4 Transmitting safety information . 28
9.5 Qualified Names . 30
10. Security considerations . 32
11. Message serialization . 33
11.1 General . 33
11.2 Advertising compact transmission . 33
12. Conformance . 34
12.1 General . 34
12.2 General format . 35
12.3 ICS tables . 35
Annex A (normative) Constants . 37
Annex B (informative) Scope of streaming specification . 38
Annex C (informative) Streaming and safe data transmission examples . 39
© IEEE 2017 – All rights reserved

Annex D (informative) Discovery and description retrieval sequence diagrams . 44
Annex E (informative) Bibliography . 47
© IEEE 2017 – All rights reserved

Health informatics—Point-of-care medical device communication
Part 20702: Medical Devices
Communication Profile for
Web Services
1. Overview
1.1 Scope
The scope of this standard is a communication protocol specification for a distributed system of point-of-care
(PoC) medical devices and medical IT systems that need to exchange data or safely control networked PoC
medical devices by defining a profile for Web Service specifications and defining additional Web Service
specifications as part of this standard.
1.2 Purpose
Currently, there is no part of the 11073 standard series that allows plug-and-play-enabled communication of
medical devices in an Internet Protocol (IP)-based distributed PoC medical device communication system.
Therefore, this standard defines a discovery, messaging, and event propagation method for a distributed PoC
medical device communication system based on Web Services. Moreover, it proposes a set of protocols that
allow advertisement of STREAMs (e.g., waveforms) as well as provision of remote control in a safe way.
For this purpose, the Devices Profile for Web Services (DPWS) is used as a communication foundation and
tailored to be utilized in a distributed PoC medical device communication system.
This standard can be used for any diagnostic, therapeutic, or monitoring communication needs where PoC
medical devices shall be able to discover communication partners, exchange virtual device descriptions,
provide and consume event-driven data, and enable safe remote control.
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they shall
be understood and used, so each referenced document is cited in text and its relationship to this document is
explained). For dated references, only the edition cited applies. For undated references, the latest edition of the
referenced document (including any amendments or corrigenda) applies.
© IEEE 2017 – All rights reserved

IEEE Std 11073-20702-2016
Health informatics—Point-of-care medical device communication—Part 20702:
Medical Devices Communication Profile for Web Services
IETF RFC 2119, Key Words for Use in RFCs to Indicate Requirement Levels, March 1997. Available at
http://www .ietf .org/ rfc/ rfc2119 .txt.
IETF RFC 2616, Hypertext Transfer Protocol—HTTP/1.1, June 1999. Available at https://tools .ietf .org/ html/
rfc2616.
IETF RFC 3987, Internationalized Resource Identifiers (IRIs), January 2005. Available at https://tools .ietf .org/
html/rfc3987.
OASIS Devices Profile for Web Services (DPWS) Version 1.1, 1 July 2009. Available at http://docs .oasis -
open .org/ ws -dd/ dpws/ 1 .1/ os/ wsdd -dpws -1 .1 -spec -os .html.
OASIS SOAP-over-UDP Version 1.1, 1 July 2009. Available at http://docs .oasis -open .org/ ws -dd/ soapoverudp/
1 .1/ os/ wsdd -soapoverudp -1 .1 -spec -os .html.
OASIS Web Services Dynamic Discovery (WS-Discovery) Version 1.1, 1 July 2009. Available at
http:// docs .oasis -open .org/ ws -dd/ discovery/1 .1/ os/ wsdd -discovery -1 .1 -spec -os .html.
OASIS Web Services Security, SOAP Message Security 1.0 (WS-Security 2004), March 2004. Available at
https://docs .oasis -open .org/ wss/ 2004/ 01/ oasis -200401 -wss -soap -message -security -1 .0 .pdf.
W3C® Web Services Description Language (WSDL) 1.1, Note, 15 March 2001. Available at http://www .w3 .org/
TR/ 2001/ NOTE -wsdl -20010315.
W3C Web Services Eventing (WS-Eventing), Member Submission, 15 March 2006. Available at
http://www .w3 .org/ Submission/ 2006/ SUBM -WS -Eventing-20060315/ .
W3C Web Services Metadata Exchange (WS-MetadataExchange) 1.1, Member Submission, 13 August 2008.
Available at http://www .w3 .org/ Submission/ 2008/ SUBM -WS -MetadataExchange-20080813.
W3C Efficient XML Interchange (EXI) Format 1.0 (Second Edition), Recommendation, 11 February 2014.
Available at http://www .w3 .org/ TR/ 2014/ REC -exi -20140211/ .
W3C Exclusive XML Canonicalization Version 1.0, Recommendation, 18 July 2002. Available at
http://www .w3 .org/ TR/ 2002/ REC -xml -exc -c14n -20020718/ .
W3C Extensible Markup Language (XML) 1.0 (Fifth Edition), Recommendation, 28 November 2008.
Available at https:// www .w3 .org/ TR/ 2008/ REC -xml -20081126/ .
W3C Namespaces in XML 1.0 (Third Edition), Recommendation, 8 December 2009. Available at
http://www .w3 .org/ TR/ REC -xml -names/.
W3C SOAP Version 1.2 Part 1: Messaging Framework, Recommendation, 27 April 2007. Available at
http://www .w3 .org/ TR/ soap12 -part1/.
W3C Web Services Addressing 1.0 (WS-Addressing), Recommendation, 9 May 2006. Available at
http://www .w3 .org/ TR/ ws -addr -core.
W3C Web Services Policy 1.5—Attachment (WS-Policy Attachment), Recommendation, 4 September 2007.
Available at http://www .w3 .org/ TR/ ws -policy -attach.
IETF documents (i.e., RFCs) are available for download at http://www .rfc -archive.or g/ .
W3C is trademarks or registered trademarks of the W3C®, (registered in numerous countries) World Wide Web Consortium. Marks of
W3C are registered and held by its host institutions: Massachusetts Institute of Technology (MIT), European Research Consortium for
Information and Mathematics (ERCIM), and Keio University, Japan.
© IEEE 2017 – All rights reserved

IEEE Std 11073-20702-2016
Health informatics—Point-of-care medical device communication—Part 20702:
Medical Devices Communication Profile for Web Services
W3C Web Services Policy 1.5—Framework (WS-Policy), Recommendation, 4 September 2007. Available at
http://www .w3 .org/ TR/ ws -policy/.
W3C XML Information Set (Second Edition), Recommendation, 4 February 2004. Available at
https://www .w3 .org/ TR/ xml -infoset/.
W3C XML Path Language (XPath) Version 1.0, Recommendation, 7 September 2015. Available at
http://www .w3 .org/ TR/ 1999/ REC -xpath -19991116.
W3C XML Schema 1.1, Recommendation, 28 October 2004. Available at http://www .w3 .org/ TR/
xmlschema-1, http://www .w3 .org/ TR/ xmlschema-2/ .
W3C Web Services Addressing 1.0—Metadata, Working Draft, 16 May 2007. Available at https://
www .w3 .org/ TR/ 2007/ WD -ws -addr -metadata-20070516/ .
WS-I Basic Profile Version 2.0, 9 November 2010. Available at http:// ws -i .org/ profiles/ BasicProfile -
2 .0 -2010 -11 -09 .html.
3. Definitions, terminology, notational conventions, and
normative statements
3.1 Definitions
For the purposes of this document, the following terms and definitions apply. The IEEE Standards Dictionary
Online should be consulted for terms not defined in this clause.
ASSERTION: A WS-Policy assertion. A policy assertion identifies a behavior that is a requirement or
capability of a policy subject. A policy subject is an entity (e.g., an endpoint, message, resource, operation)
with which a policy can be associated. (adapted from W3C WS-Policy 1.5 Framework, Section 3.1)
ATTRIBUTE: References the attribute in a normative outline that is currently described.
NOTE—See normative outlines in 3.3.1.
CLIENT: A network endpoint that sends MESSAGEs to and/or receives MESSAGEs from a SERVICE.
(OASIS DPWS V1.1)
DEVICE: A distinguished type of SERVICE that hosts other SERVICEs and sends and/or receives one or
more specific types of MESSAGEs. (OASIS DPWS V1.1)
ELEMENT: References the element in a normative outline that is currently described.
NOTE—See 3.3.1.
HOSTED SERVICE: A distinguished type of SERVICE that is hosted by another SERVICE. The lifetime of
the HOSTED SERVICE is a subset of the lifetime of its host. The HOSTED SERVICE is visible (not encapsu-
lated) and is addressed separately from its host. Each HOSTED SERVICE has exactly one host. The relation-
ship is not transitive. (OASIS DPWS V1.1)
The IEEE Standards Dictionary Online is available at: http://dictionary .ieee.or g.
Notes in text, tables, and figures of a standard are given for information only and do not contain requirements needed to implement this
standard.
© IEEE 2017 – All rights reserved

IEEE Std 11073-20702-2016
Health informatics—Point-of-care medical device communication—Part 20702:
Medical Devices Communication Profile for Web Services
MESSAGE: Protocol elements that are exchanged, usually over a network, to affect a Web Service. Always
includes a SOAP ENVELOPE. Typically also includes transport framing information such as HTTP headers,
TCP headers, and IP headers. (OASIS DPWS V1.1)
RECEIVER: A CLIENT or SERVICE that receives a MESSAGE. (OASIS DPWS V1.1)
SECURE CHANNEL: A SECURE CHANNEL is a point-to-point transport-level TLS/SSL connection
established between a CLIENT and a SERVICE.
SENDER: A CLIENT or SERVICE that sends a MESSAGE. (OASIS DPWS V1.1)
SERVICE: A software system that exposes its capabilities by receiving and/or sending MESSAGEs on one or
several network endpoints. (OASIS DPWS V1.1)
SOAP ENVELOPE: An XML Infoset that consists of a document information item (W3C XML Information
Set) with exactly one member in its [children] property, which MUST be the SOAP Envelope (W3C SOAP
V1.2 Part 1) element information item. (OASIS DPWS V1.1)
STREAM: A STREAM designates MESSAGEs that are periodically delivered from a networked DEVICE
over an IP-based transmission medium to one or more CLIENTs.
STREAMING: A mechanism to periodically deliver MESSAGEs from networked DEVICEs over an IP-
based transmission medium to one or more CLIENTs.
TEXT SOAP ENVELOPE: A SOAP ENVELOPE serialized as application/soap+xml. (OASIS DPWS V1.1)
3.2 Terminology
The keywords “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,”
“RECOMMENDED,” “MAY,” and “OPTIONAL” in this document are to be interpreted as described in
IETF RFC 2119.
3.3 Notational conventions
3.3.1 Normative outlines
According to OASIS DPWS V1.1, this standard uses the following syntax to define normative outlines:
— The syntax appears as an XML instance, but values in italics indicate data types instead of literal
values.
— Characters are appended to elements and attributes to indicate cardinality:
• “?” (0 or 1)
• “*” (0 or more)
• “+” (1 or more)
• The character “|” is used to indicate a choice between alternatives.
— The characters “(“ and “)” are used to indicate that contained items are to be treated as a group with
respect to cardinality or choice.
— The characters “[“ and “]” are used to call out references and property names.
Information on references can be found in Clause 2.
© IEEE 2017 – All rights reserved

IEEE Std 11073-20702-2016
Health informatics—Point-of-care medical device communication—Part 20702:
Medical Devices Communication Profile for Web Services
— Ellipses (i.e., “.”) indicate points of extensibility. Additional children and/or attributes MAY be added
at the indicated extension points but SHALL NOT contradict the semantics of the parent and/or owner,
respectively. By default, if a receiver does not recognize an extension, the receiver SHOULD ignore
the extension; exceptions to this processing rule, if any, are clearly indicated below.
— XML namespace prefixes (see Table 1) are used to indicate the namespace of the element being defined.
Any normative outline is described in more detail by giving a set of XPath expressions followed by a descrip-
tion. The XPath expressions point to elements or attributes in the foregoing outline.
Example:
(01)
(02) 
(03)   .
(04)  +
(05)
The remainder of this subclause describes additional, normative constraints on the previously listed outline.
/SampleElement
Detailed description of SampleElement. By definition, SampleElement is referenced here by using the key-
word ELEMENT.
/SampleElement/@SampleAttribute
Detailed description of SampleElement’s attribute SampleAttribute. By definition, SampleAttribute is refer-
enced here by using the keyword ATTRIBUTE.
/SampleElement/NestedElement
Detailed description of NestedElement.
3.3.2 Normative statements
According to the notation given in OASIS DPWS V1.1, normative statements of requirements are presented
in the following manner:
Rnnnn: Statement text here.
where “nnnn” is replaced by a number that is unique among the requirements in this standard, thereby forming
a unique requirement identifier.
Requirements can be considered to possess a namespace qualifier, in such a way as to be compatible with
QNames from Namespaces in XML (W3C Namespaces in XML 1.0). If there is no explicit namespace prefix
on a requirement’s identifier (e.g., “R9999” as opposed to “dpws: R9999”), it should be interpreted as being in
the namespace identified for this standard. A prefixed requirement refers to the specification that defines that
prefix. For example, dpws: R9999 refers to requirement R9999 defined in OASIS DPWS V1.1.
3.3.3 Extended Backus-Naur Form
This standard makes use of a simple Extended Backus-Naur Form (EBNF) notation to specify a grammar for
XPath expressions. The simple EBNF notation is cited from W3C XML 1.0. Each rule in the grammar defines
one symbol, in the form:
© IEEE 2017 – All rights reserved

IEEE Std 11073-20702-2016
Health informatics—Point-of-care medical device communication—Part 20702:
Medical Devices Communication Profile for Web Services
symbol ::= expression
Symbols are written with an initial capital letter if they are the start symbol of a regular language, otherwise
with an initial lowercase letter. Literal strings are quoted. Within the expression on the right-hand side of a
rule, the following expressions are used to match strings of one or more characters:
#xN
Where N is a hexadecimal integer, the expression matches the character whose number (code point) in
ISO/IEC 10646 is N. The number of leading zeroes in the #xN form is insignificant.
[a-zA-Z], [#xN-#xN]
Matches any Char with a value in the range(s) indicated (inclusive).
[abc], [#xN#xN#xN]
Matches any Char with a value among the characters enumerated. Enumerations and ranges can be mixed in
one set of brackets.
[^a-z], [^#xN-#xN]
Matches any Char with a value outside the range indicated.
[^abc], [^#xN#xN#xN]
Matches any Char with a value not among the characters given. Enumerations and ranges of forbidden values
can be mixed in one set of brackets.
"string"
Matches a literal string matching that given inside the double quotes.
'string'
Matches a literal string matching that given inside the single quotes.
These symbols may be combined to match more complex patterns as follows, where A and B represent simple
expressions:
(expression)
Expression is treated as a unit and may be combined as described in this list.
A?
Matches A or nothing; optional A.
A B
Matches A followed by B. This operator has higher precedence
...