Health informatics - Personal health device communication - Part 10408: Device specialization - Thermometer

ISO/IEEE 11073-10408:2010 establishes a normative definition of communication between personal telehealth thermometer devices and computer engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards, including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviours in telehealth environments restricting optionality in base frameworks in favour of interoperability. This International Standard defines a common core of communication functionality for personal telehealth thermometers. ISO/IEEE 11073-10408:2010 addresses a need for an openly defined, independent standard for controlling information exchange to and from personal health devices and computer engines.

Informatique de santé — Communication entre dispositifs de santé personnels — Partie 10408: Spécialisation des dispositifs — Thermomètre

L'ISO/IEEE 11073-10408:2010 établit une définition normative de la communication entre des dispositifs thermométriques personnels de télésanté et des moteurs informatiques (par exemple des téléphones cellulaires, des ordinateurs personnels, des équipements personnels de santé et des boîtiers décodeurs) d'une manière qui permet une interopérabilité du type prêt à l'emploi. Elle s'appuie sur les parties appropriées de normes existantes, y compris la terminologie, des modèles d'informations, des normes de profils d'applications et des normes de transport de l'ISO/IEEE 11073. Elle spécifie l'utilisation de codes, de formats et de comportements en termes spécifiques dans les environnements de télésanté, en limitant les choix à des cadres de travail de base en faveur de l'interopérabilité. Elle définit un noyau commun de fonctionnalités de communication pour les thermomètres personnels de télésanté. L'ISO/IEEE 11073-10408:2010 répond au besoin d'une norme indépendante définie de manière ouverte portant sur la commande de l'échange d'informations entre des dispositifs personnels de santé et des moteurs informatiques.

General Information

Status
Withdrawn
Publication Date
18-Apr-2010
Current Stage
9599 - Withdrawal of International Standard
Start Date
15-Dec-2022
Completion Date
30-Oct-2025
Ref Project

Relations

Standard
ISO/IEEE 11073-10408:2010 - Health informatics -- Personal health device communication
English language
38 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEEE 11073-10408:2010 - Health informatics -- Personal health device communication
English language
38 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO/IEEE 11073-10408:2010 - Informatique de santé -- Communication entre dispositifs de santé personnels
French language
39 pages
sale 15% off
Preview
sale 15% off
Preview

Frequently Asked Questions

ISO/IEEE 11073-10408:2010 is a standard published by the International Organization for Standardization (ISO). Its full title is "Health informatics - Personal health device communication - Part 10408: Device specialization - Thermometer". This standard covers: ISO/IEEE 11073-10408:2010 establishes a normative definition of communication between personal telehealth thermometer devices and computer engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards, including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviours in telehealth environments restricting optionality in base frameworks in favour of interoperability. This International Standard defines a common core of communication functionality for personal telehealth thermometers. ISO/IEEE 11073-10408:2010 addresses a need for an openly defined, independent standard for controlling information exchange to and from personal health devices and computer engines.

ISO/IEEE 11073-10408:2010 establishes a normative definition of communication between personal telehealth thermometer devices and computer engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards, including ISO/IEEE 11073 terminology, information models, application profile standards, and transport standards. It specifies the use of specific term codes, formats, and behaviours in telehealth environments restricting optionality in base frameworks in favour of interoperability. This International Standard defines a common core of communication functionality for personal telehealth thermometers. ISO/IEEE 11073-10408:2010 addresses a need for an openly defined, independent standard for controlling information exchange to and from personal health devices and computer engines.

ISO/IEEE 11073-10408:2010 is classified under the following ICS (International Classification for Standards) categories: 35.240.80 - IT applications in health care technology. The ICS classification helps identify the subject area and facilitates finding related standards.

ISO/IEEE 11073-10408:2010 has the following relationships with other standards: It is inter standard links to ISO/IEEE 11073-10408:2022. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

You can purchase ISO/IEEE 11073-10408:2010 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.

Standards Content (Sample)


INTERNATIONAL ISO/IEEE
STANDARD 11073-10408
First edition
2010-05-01
Health informatics — Point-of-care
medical device communication —
Part 10408:
Device specialization — Thermometer
Informatique de santé — Communication entre dispositifs médicaux
sur le site des soins —
Partie 10408: Spécialisation des dispositifs — Thermomètre

Reference number
©
ISO 2010
©
IEEE 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. Neither the ISO Central
Secretariat nor IEEE accepts any liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies
and IEEE members. In the unlikely event that a problem relating to it is found, please inform the ISO Central Secretariat or IEEE at the
address given below.
©  ISO 2010
©  IEEE 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO or IEEE at the respective
address below.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc.
Case postale 56 • CH-1211 Geneva 20 3 Park Avenue, New York • NY 10016-5997, USA
Tel. + 41 22 749 01 11 E-mail stds.ipr@ieee.org
Fax + 41 22 749 09 47 Web www.ieee.org
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © IEEE 2010 – All rights reserved

Contents Page
Foreword.v
Introduction.vii
1. Overview.1
1.1 Scope.1
1.2 Purpose.1
1.3 Context.2
2. Normative references .2
3. Definitions, acronyms, and abbreviations.2
3.1 Definitions.2
3.2 Acronyms and abbreviations.3
4. Introduction to ISO/IEEE 11073 personal health devices.3
4.1 General.3
4.2 Introduction to IEEE 11073-20601 modeling constructs.4
5. Thermometer device concepts and modalities .4
5.1 General.4
5.2 Body temperature.5
6. Thermometer domain information model .5
6.1 Overview.5
6.2 Class extensions .5
6.3 Object instance diagram.5
6.4 Types of configuration .6
6.5 Medical device system object .7
6.6 Numeric objects .10
6.7 Real-time sample array objects .12
6.8 Enumeration objects.12
6.9 PM store objects.12
6.10 Scanner objects .12
6.11 Class extension objects .12
6.12 Thermometer information model extensibility rules.13
7. Thermometer service model.13
7.1 General.13
7.2 Object access services.13
7.3 Object access event report services.14
8. Thermometer communication model .15
8.1 Overview.15
8.2 Communications characteristics.15
8.3 Association procedure.15
8.4 Configuring procedure .17
8.5 Operating procedure.18
8.6 Time synchronization.19
© IEEE 2010 – All rights reserved iii

9. Test associations .19
9.1 Behavior with standard configuration .19
9.2 Behavior with extended configurations.19
10. Conformance.19
10.1 Applicability.19
10.2 Conformance specification.20
10.3 Levels of conformance.20
10.4 Implementation conformance statements.21
Annex A (informative) Bibliography.26
Annex B (normative) Any additional ASN.1 definitions.27
Annex C (normative) Allocation of identifiers .28
Annex D (informative) Message sequence examples .29
Annex E (informative) Protocol data unit examples.31

iv © IEEE 2010 – 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.
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.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
Attention is called to the possibility that implementation of this standard may require the use of
subject matter covered by patent rights. By publication of this standard, no position is taken with
respect to the existence or validity of any patent rights in connection therewith. ISO/IEEE is not
responsible for identifying essential patents or patent claims for which a license may be required,
for conducting inquiries into the legal validity or scope of patents or patent claims or determining
whether any licensing terms or conditions provided in connection with submission of a Letter of
Assurance or a Patent Statement and Licensing Declaration Form, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is
entirely their own responsibility. Further information may be obtained from ISO or the IEEE
Standards Association.
ISO/IEEE 11073-10408 was prepared by the 11073 Committee of the Engineering in Medicine
and Biology Society of the IEEE (as IEEE Std 11073-10408-2008). It was adopted by Technical
Committee ISO/TC 215, Health informatics, in parallel with its approval by the ISO member
bodies, under the “fast-track procedure” defined in the Partner Standards Development
Organization cooperation agreement between ISO and IEEE. Both parties are responsible for the
maintenance of this document.
ISO/IEEE 11073 consists of the following parts, under the general title Health informatics —
Personal health device communication (text in parentheses gives a variant of subtitle):
— Part 10101: (Point-of-care medical device communication) Nomenclature
— Part 10201: Domain information model
— Part 10404: Device specialization — Pulse oximeter
© IEEE 2010 – All rights reserved v

— Part 10407: Device specialization — Blood pressure monitor
— Part 10408: (Point-of-care medical device communication) Device specialization —
Thermometer
— Part 10415: (Point-of-care medical device communication) Device specialization — Weighing
scale
— Part 10417: Device specialization — Glucose meter
— Part 10471: (Point-of-care medical device communication) Device specialization —
Independant living activity hub
— Part 20101: (Point-of-care medical device communication) Application profiles — Base
standard
— Part 20601: (Point-of-care medical device communication) Application profile — Optimized
exchange protocol
— Part 30200: (Point-of-care medical device communication) Transport profile — Cable
connected
— Part 30300: (Point-of-care medical device communication) Transport profile — Infrared
wireless
vi © IEEE 2010 – All rights reserved

Introduction
ISO/IEEE 11073 standards enable communication between medical devices and external computer systems. This
a
document uses the optimized framework created in IEEE Std 11073-20601 and describes a specific, interoperable
communication approach for weighing scales. These standards align with, and draw upon, the existing clinically
focused standards to provide support for communication of data from clinical or personal health devices.

a
For information on references, see Clause 2.
© IEEE 2010 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEEE 11073-10408:2010(E)

Health informatics — Point-of-care medical device
communication —
Part 10408:
Device specialization — Thermometer
IMPORTANT NOTICE: This standard is not intended to assure safety, security, health, or
environmental protection in all circumstances. Implementers of the standard are responsible for
determining appropriate safety, security, environmental, and health practices or regulatory
requirements.
This IEEE document is made available for use subject to important notices and legal disclaimers. These
notices and disclaimers appear in all publications containing this document and may be found under the
heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.”
They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.
1. Overview
1.1 Scope
Within the context of the ISO/IEEE 11073 family of standards for device communication, this standard
establishes a normative definition of communication between personal telehealth thermometer devices and
compute engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a
manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards,
including ISO/IEEE 11073 terminology, information models, application profile standards, and transport
standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments
restricting optionality in base frameworks in favor of interoperability. This standard defines a common core
of communication functionality for personal telehealth thermometers.
1.2 Purpose
This standard addresses a need for an openly defined, independent standard for controlling information
exchange to and from personal health devices and compute engines (e.g., cell phones, personal computers,
personal health appliances, and set top boxes). Interoperability is the key to growing the potential market
for these devices and to enabling people to be better informed participants in the management of their
health.
© IEEE 2010 – All rights reserved

1.3 Context
TM
See IEEE Std 11073-20601 for an overview of the environment within which this standard is written.

This document, IEEE Std 11073-10408, defines the device specialization for the thermometer, being a
specific agent type, and it provides a description of the device concepts, its capabilities, and its
implementation according to this standard.

This standard is based on IEEE Std 11073-20601, which in turn draws information from both ISO/IEEE
11073-10201:2004 [B3] and ISO/IEEE 11073-20101:2004 [B4]. The medical device encoding rules
(MDERs) used within this standard are fully described in IEEE Std 11073-20601.

This standard reproduces relevant portions of the nomenclature found in ISO/IEEE 11073-10101:2004 [B2]
and adds new nomenclature codes for the purposes of this standard. Between this standard and
IEEE Std 11073-20601, all required nomenclature codes for implementation are documented.
NOTE—In this standard, IEEE Std 11073-104zz is used to refer to the collection of device specialization standards that
utilize IEEE Std 11073-20601, where zz can be any number from 01 to 99, inclusive.
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so that 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.

TM
IEEE Std 11073-20601 -2008, Health informatics—Personal health device communication—Part 20601:
3, 4
Application profile—Optimized Exchange Protocol.
3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this standard, the following terms and definitions apply. The Authoritative Dictionary of
IEEE Standards [B1] should be referenced for terms not defined in this clause.
3.1.1 agent: A node that collects and transmits personal health data to an associated manager.
3.1.2 body temperature: The measurement of the core body temperature of the person.
3.1.3 class: In object-oriented modeling, it describes the attributes, methods, and events that objects
instantiated from the class utilize.
3.1.4 compute engine: See: manager.
3.1.5 device: A term used to refer to a physical apparatus implementing either an agent or a manager role.

The numbers in brackets correspond to those of the bibliography in Annex A.
Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.
The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.
IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854,
USA (http://standards.ieee.org/).

© IEEE 2010 – All rights reserved

3.1.6 extremity body temperature: The measurement of the temperature at the extremities of the body of
the person, such as finger or toe.
3.1.7 handle: An unsigned 16-bit number that is locally unique and identifies one of the object instances
within an agent.
3.1.8 manager: A node receiving data from one or more agent systems. Some examples of managers
include a cellular phone, health appliance, set top box, or a computer system.
3.1.9 obj-handle: See: handle.
3.1.10 object: In object-oriented modeling, a particular instantiation of a class. The instantiation realizes
attributes, methods, and events from the class.
3.1.11 personal health device: A device used in personal health applications.
3.1.12 personal telehealth device: See: personal health device.
3.2 Acronyms and abbreviations
APDU application protocol data unit
ASN.1 Abstract Syntax Notation One
DIM domain information model
EUI-64 extended unique identifier (64 bits)
ICS implementation conformance statement
MDC medical device communication
MDER medical device encoding rules
MDS medical device system
MOC managed object class
PDU protocol data unit
PHD personal health device
RT-SA real-time sample array
VMO virtual medical object
VMS virtual medical system
4. Introduction to ISO/IEEE 11073 personal health devices
4.1 General
This standard and the remainder of the series of ISO/IEEE 11073 personal health device (PHD) standards
fit in the larger context of the ISO/IEEE 11073 series of standards. The full suite of standards enables
agents to interconnect and interoperate with managers and with computerized health-care information
systems. See IEEE Std 11073-20601 for a description of the guiding principles for this series of ISO/IEEE
11073 Personal Health Device standards.

IEEE Std 11073-20601 supports the modeling and implementation of an extensive set of personal health
devices. This standard defines aspects of the thermometer device. It describes all aspects necessary to
implement the application layer services and data exchange protocol between an ISO/IEEE 11073 PHD
thermometer agent and a manager. This standard utilizes a subset of the classes and functionality defined in
IEEE Std 11073-20601, defines the objects needed to model a thermometer, and adds new modeling
definitions where appropriate. All new definitions are given in Annex B in Abstract Syntax Notation One
(ASN.1) [B5]. Nomenclature codes referenced in this standard, which are not defined in IEEE Std 11073-
20601, are normatively defined in Annex C.
© IEEE 2010 – All rights reserved

4.2 Introduction to IEEE 11073-20601 modeling constructs
4.2.1 General
The ISO/IEEE 11073 series of standards, and in particular IEEE Std 11073-20601, is based on an object-
oriented systems management paradigm. The overall system model is divided into three principal
components: the domain information model (DIM), the service model, and the communication model. See
IEEE Std 11073-20601 for a detailed description of the modeling constructs.
4.2.2 Domain information model
The DIM is a hierarchical model that describes an agent as a set of objects. These objects and their
attributes represent the elements that control behavior and report on the status of the agent and data that an
agent can communicate to a manager. Communication between the agent and the manager is defined by the
application protocol in IEEE Std 11073-20601.
4.2.3 Service model
The service model defines the conceptual mechanisms for the data exchange services. Such services are
mapped to messages that are exchanged between the agent and the manager. Protocol messages within the
ISO/IEEE 11073 series of standards are defined in ASN.1. The messages defined in IEEE Std 11073-20601
can coexist with messages defined in other standard application profiles defined in the ISO/IEEE 11073
series of standards.
4.2.4 Communication model
In general, the communication model supports the topology of one or more agents communicating over
logical point-to-point connections to a single manager. For each logical point-to-point connection, the
dynamic system behavior is defined by a connection state machine as specified in IEEE Std 11073-20601.
4.2.5 Implementing the models
An agent implementing this standard shall implement all mandatory elements of the information, service,
and communication models as well as all conditional elements where the condition is met. The agent should
implement the recommended elements, and it may implement any combination of the optional elements. A
manager implementing this standard shall utilize at least one of the mandatory, conditional, recommended,
or optional elements. In this context, “utilize” means to use the element as part of the primary function of
the manager device. For example, a manager whose primary function is to display data would need to
display a piece of data in the element in order to utilize it.
5. Thermometer device concepts and modalities
5.1 General
This clause presents the general concepts of thermometer devices. In the context of personal health devices
in this family of standards, a thermometer is a device that measures the temperature at some point on the
body of a person. In general, the thermometer will be taking a measurement representative of the core
temperature of the body, and traditionally oral or rectal measurements are used for spot checks or attached
under the armpit (axillary) for extended monitoring. Band thermometers are placed on exposed areas of
skin, often the forehead, but these are not considered as accurate. Typically, the thermometer is placed at
the measurement site for sufficient time for the measuring probe to reach the same temperature as the body
site, and when stable, a direct digital reading of the probe temperature is taken.

© IEEE 2010 – All rights reserved

Methods to determine the temperature of the probe vary, but common methods include change in the
properties of materials with heat such as resistance or semiconductor bandgap voltage. Tympanic
thermometers measure the temperature of the tympanum by infrared measurement, which is noncontact and
immediate. Unless relevant, the method used to determine temperature is ignored in this standard.

Thermometers may be designed for specialist monitoring purposes. For example, thermometers embedded
in capsules may be swallowed and their data transmitted for monitoring during periods of high physical
activity for signs of overheating.

Measurements may be taken at the extremities of the body (fingers, toes) and would typically be used to
monitor for signs of problems due to circulation or hypothermia.
5.2 Body temperature
This standard assumes that a temperature measurement is normally taken as representative of the core body
temperature, and therefore, the actual site of its measurement is not relevant. For this reason, the type
attribute for the temperature object in the standard configuration is set to generic body temperature.

When the site or the method is significant, this will be indicated by use of a separate type for the
temperature in an extended configuration.

The main units used in medicine are the Celsius and the Fahrenheit scales.
6. Thermometer domain information model
6.1 Overview
This clause describes the domain information model of the thermometer.
6.2 Class extensions
In this standard, no class extensions are defined with respect to IEEE Std 11073-20601.
6.3 Object instance diagram
The object instance diagram of the thermometer domain information model, defined for the purposes of this
standard, is shown in Figure 1.

The objects of the DIM, as shown in Figure 1, are described in 6.4 to 6.12. This includes the medical device
system (MDS) object (see 6.5) and the numeric objects (see 6.6). There are no real-time sample array (RT-
SA) objects (see 6.7), enumeration objects (see 6.8), PM-store objects (see 6.9), or scanner objects (see
6.10) in the thermometer. See 6.11 for rules for extending the thermometer information model beyond
elements as described in this standard. Each clause that describes an object of the thermometer contains the
following information:
⎯ The nomenclature code used to identify the class of the object. One example of where this code
is used is the configuration event, where the object class is reported for each object. This allows
the manager to determine whether the class of the object being specified is a numeric, real-time
sample array, enumeration, scanner, or PM-store class.
© IEEE 2010 – All rights reserved

⎯ The attributes of the object. Each object has attributes that represent and convey information on
the physical device and its data sources. Each object has a Handle attribute that identifies the
object instance within an agent. Attribute values are accessed and modified using methods such
as GET and SET. Attributes types are defined using ASN.1. The ASN.1 definitions for new
attribute types specific to this standard are in Annex B, and the ASN.1 definitions for existing
attribute types referenced in this standard are in IEEE Std 11073-20601.
⎯ The methods available on the object.
⎯ The potential events generated by the object. Data are sent to the manager using events.
⎯ The available services such as getting or setting attributes.

The attributes for each class are defined in tables that specify the name of the attribute, its value, and its
qualifier. The qualifiers mean M — Attribute is Mandatory, C — Attribute is Conditional and depends on
the condition stated in the Remark or Value column (if IEEE Std 11073-20601 is referenced, then it
contains the conditions), R — Attribute is Recommended, NR — Attribute is Not Recommended, and O —
Attribute is Optional. Mandatory attributes shall be implemented by the agent. Conditional attributes shall
be implemented if the condition applies and may be implemented otherwise. Recommended attributes
should be implemented by the agent. Not recommended attributes should not be implemented by the agent.
Optional attributes may be implemented by the agent.
The attributes can be either static, meaning that they shall remain unchanged after the configuration is
agreed upon, or dynamic, meaning that the attribute may change at some point after configuration.
PHD-Thermometer object instances
MDS
Thermometer
Numeric
Body Temperature
Figure 1—Thermometer—domain information model
6.4 Types of configuration
6.4.1 General
As specified in IEEE Std 11073-20601, there are two styles of configuration available. Subclauses 6.4.2
and 6.4.3 briefly introduce standard and extended configurations.
© IEEE 2010 – All rights reserved

6.4.2 Standard configuration
Standard configurations are defined in the IEEE 11073-104zz specializations (such as this standard) and are
assigned a well-known identifier (Dev-Configuration-Id). The usage of a standard configuration is
negotiated at association time between the agent and the manager. If the manager recognizes and selects to
operate using the configuration, then the agent can send measurements immediately. If the manager does
not recognize the configuration, the agent provides the configuration prior to transmitting measurement
information.
6.4.3 Extended configuration
In extended configurations, the agent’s configuration is not predefined in a standard. The agent determines
the objects, attributes, and values that will be used in a configuration and assigns a configuration identifier.
When the agent associates with a manager, an acceptable configuration is negotiated. Typically, the
manager does not recognize the agent’s configuration on the first connection, so the manager responds that
the agent must send its configuration information as a configuration event report. If, however, the manager
recognizes the configuration, either because it was preloaded in some way or the agent had previously
associated with the manager, then the manager responds that the configuration is known and no further
configuration information needs to be sent.
6.5 Medical device system object
6.5.1 MDS object attributes
Table 1 summarizes the attributes of the thermometer MDS object. The nomenclature code to identify the
MDS class is MDC_MOC_VMS_MDS_SIMP.
Table 1 —MDS object attributes
Attribute name Value Qual.
Handle 0 M
System-Type Attribute not present. See IEEE Std 11073-20601. C
System-Model {“Manufacturer”,”Model”}. M
System-Id Extended unique identifier (64 bits) (EUI-64). M
Dev-Configuration-Id Standard config: 0x0320 (800) M
Extended configs: 0x4000-0x7FFF.
Attribute-Value-Map See IEEE Std 11073-20601. C
Production-Specification See IEEE Std 11073-20601. O
Mds-Time-Info See IEEE Std 11073-20601. C
Date-and-Time See IEEE Std 11073-20601. C
Relative-Time See IEEE Std 11073-20601. C
HiRes-Relative-Time See IEEE Std 11073-20601. C
Date-and-Time-Adjustment See IEEE Std 11073-20601. C
Power-Status onBattery or onMains. R
Battery-Level See IEEE Std 11073-20601. R
Remaining-Battery-Time See IEEE Std 11073-20601. R
Reg-Cert-Data-List See IEEE Std 11073-20601. O
System-Type-Spec-List {MDC_DEV_SPEC_PROFILE_TEMP, 1}. M
Confirm-Timeout See IEEE Std 11073-20601. O
NOTE—See IEEE Std 11073-20601 for information on whether an attribute is static or dynamic.

In the response to a Get MDS object command, only implemented attributes and their corresponding values
are returned.
© IEEE 2010 – All rights reserved

See IEEE Std 11073-20601 for descriptive explanations of the individual attributes as well as for
information on attribute ID and attribute type.

The Dev-Configuration-Id attribute holds a locally unique 16-bit identifier that identifies the device
configuration instance. For a thermometer agent with extended configuration, this identifier is chosen in the
range of extended-config-start to extended-config-end (see IEEE Std 11073-20601) as shown in Table 1.

The agent sends the Dev-Configuration-Id during the Associating state (see 8.3) to identify its configuration
for the duration of the association. If the manager already holds the configuration information relating to
the Dev-Configuration-Id, it recognizes the Dev-Configuration-Id and the Configuring state (see 8.4) is
skipped; the agent and manager then enter the Operating state. If the manager does not recognize the Dev-
Configuration-Id, the agent and manager enter the Configuring state.

If an agent implements multiple IEEE 11073-104zz specializations, System-Type-Spec-List is a list of
type/version pairs, each referencing the respective device specialization and version of that specialization.
6.5.2 MDS object methods
Table 2 defines the methods (actions) of the MDS object. These methods are invoked using the Action
service. In Table 2, the Subservice type name column defines the name of the method; the Mode column
defines whether the method is invoked as an unconfirmed action (i.e., roiv-cmip-action from
IEEE Std 11073-20601) or a confirmed action (i.e., roiv-cmip-confirmed-action); the Subservice type
(action-type) column defines the nomenclature code to use in the action-type field of an action request and
response (see IEEE Std 11073-20601); the Parameters (action-info-args) column defines the associated
ASN.1 data structure (see IEEE Std 11073-20601 for ASN.1 definitions) to use in the action message for the
action-info-args field of the request; and the Results (action-info-args) column defines the structure to use
in the action-info-args of the response.
Table 2 —MDS object methods
Service Subservice Mode Subservice type Parameters Results
type name (action-type) (action-info- (action-info-
args) args)
ACTION Set-Time Confirmed MDC_ACT_SET_TIME SetTimeInvoke —

Set-Time
This method allows the manager to set a real-time clock in the agent with the absolute time. The agent
indicates whether the Set-Time command is valid using the mds-time-capab-set-clock bit in the Mds-Time-
Info attribute (see IEEE Std 11073-20601). Agents with an internal real-time clock (RTC) shall indicate
this capability by also setting the mds-time-capab-real-time-clock bit in the Mds-Time-Info attribute.
6.5.3 MDS object events
Agents following only this device specialization and no others shall send event reports using agent-initiated
measurement data transmission. During the association procedure (see 8.3), DataReqModeCapab shall be
set to the appropriate value for the event report style (set to data-req-supp-init-agent). The manager shall
assume the thermometer agent does not support any of the MDS-Data-Request features (see IEEE Std
11073-20601 for additional information). The data-req-init-manager-count shall be set to zero, and the data-
req-init-agent-count shall be set to 1.

Agents following this device specialization as well as others shall send event reports in the appropriate
fashion. During the association procedure (see 8.3), DataReqModeCapab shall be set to the appropriate
value for the event report style.

Table 3 defines the events that can be sent by the thermometer MDS object.
© IEEE 2010 – All rights reserved

Table 3 —Thermometer MDS object events
Service Subservice type Mode Subservice type Parameters Results
name (event-type) (event-info) (event-
reply-info)
MDS- Confirmed MDC_NOTI_CONFIG ConfigReport ConfigRepor
Configuration- tRsp
Event
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPOScanReportInfoVar —
Data-Update-Var RT_VAR
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPOScanReportInfoFixed —
EVENT
Data-Update-Fixed RT_FIXED
REPORT
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPO ScanReportInfoMPVar —
Data-Update-MP- RT_MP_VAR
Var
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPO ScanReportInfoMPFixed —
Data-Update-MP- RT_MP_FIXED
Fixed
⎯ MDS-Configuration-Event:
This event is sent by the thermometer agent during the configuring procedure if the manager
does not already know the thermometer agent’s configuration from past associations or because
the manager has not been implemented to recognize the configuration according to the
thermometer device specialization. The event provides static information about the supported
measurement capabilities of the thermometer agent.
⎯ MDS-Dynamic-Data-Update-Var:
This event provides dynamic measurement data from the thermometer agent for the body
temperature numeric object. These data are reported using a generic attribute list variable
format. The event is sent as an unsolicited message by the agent (i.e., an agent-initiated
measurement data transmission). See 8.5.3 for more information on unsolicited event reporting.
MDS events for temperature readings shall be sent no faster than once per second.
⎯ MDS-Dynamic-Data-Update-Fixed:
This event provides dynamic measurement data from the thermometer agent for the body
temperature numeric object. These data are reported in the fixed format defined by the Attribute-
Value-Map attribute of the object. The event is sent as an unsolicited message by the agent (i.e.,
an agent-initiated measurement data transmission). See 8.5.3 for more information on
unsolicited event reporting.
⎯ MDS-Dynamic-Data-Update-MP-Var:
This is the same as MDS-Dynamic-Data-Update-Var but allows inclusion of data from multiple
people.
⎯ MDS-Dynamic-Data-Update-MP-Fixed:
This is the same as MDS-Dynamic-Data-Update-Fixed but allows inclusion of data from
multiple people.
NOTE—IEEE Std 11073-20601 requires that managers support all of the MDS object events listed above.
6.5.4 Other MDS services
6.5.4.1 GET service
A thermometer agent shall support the GET service, which is provided by the MDS object to retrieve the
values of all implemented MDS object attributes. The GET service can be invoked as soon as the
thermometer agent receives the Association Response and moves to the Associated state, including the
Operating and Configuring substates.

© IEEE 2010 – All rights reserved

The manager may request the MDS object attributes of the thermometer agent; in which case, the manager
shall send the “Remote Operation Invoke | Get” message (see roiv-cmip-get in IEEE Std 11073-20601) with
the reserved MDS handle value of 0. The thermometer agent shall report its MDS object attributes to the
manager using the “Remote Operation Response | Get” message (see rors-cmip-get in IEEE Std 11073-
20601). See Table 4 for a summary of the GET service including some message fields.
Table 4 —Thermometer MDS object GET service
Service Subservice Mode Subservice Parameters Results
type name type
GET GetArgumentSimple GetResultSimple
confirmed> = (obj-handle = 0), = (obj-handle = 0), attribute-
attribute-id-list list

See 8.5.2 for details on the procedure for getting the MDS object attributes.
6.5.4.2 SET service
The thermometer specialization does not require an implementation to support the MDS object SET
service.
6.6 Numeric objects
6.6.1 General
The thermometer DIM (see Figure 1) contains one required object for body temperature, which is described
in 6.6.2.
Sometimes, the interpretation of one attribute value in an object depends on other attribute values in the
same object. For example, Unit-Code and Unit-LabelString provide context for the observed values.
Whenever a contextual attribute changes, the agent shall report these changes to the manager using an MDS
object event (see 6.5.3) prior to reporting any of the dependent values.
6.6.2 Temperature
Table 5 summarizes the attributes of the body temperature numeric object. The nomenclature code to
identify the numeric class is MDC_MOC_VMO_METRIC_NU. The body temperature numeric object
shall be supported by a thermometer agent.

© IEEE 2010 – All rights reserved

Table 5 —Body temperature numeric object attributes
Attribute name Extended configuration Standard configuration
(Dev-Configuration-Id = 0x0320)
Value Qual. Value Qual.
Handle See IEEE Std 11073-20601. M 1 M
Type {MDC_PART_SCADA, M {MDC_PART_SCADA, M
MDC_TEMP_zzz}. MDC_TEMP_BODY}.
Supplemental-Types See IEEE Std 11073-20601. NR Attribute not initially present. If present NR
follow IEEE Std 11073-20601.
Metric-Spec-Small mss-avail-intermittent, mss- M mss-avail-intermittent, mss-avail-stored-data, M
avail-stored-data, mss-msmt- mss-upd-aperiodic, mss-msmt-aperiodic, mss-
aperiodic, mss-acc
...


INTERNATIONAL ISO/IEEE
STANDARD 11073-10408
First edition
2010-05-01
Health informatics — Personal health
device communication —
Part 10408:
Device specialization — Thermometer
Informatique de santé — Communication entre dispositifs de santé
personnels —
Partie 10408: Spécialisation des dispositifs — Thermomètre

Reference number
©
ISO 2010
©
IEEE 2010
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. Neither the ISO Central
Secretariat nor IEEE accepts any liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies
and IEEE members. In the unlikely event that a problem relating to it is found, please inform the ISO Central Secretariat or IEEE at the
address given below.
©  ISO 2010
©  IEEE 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO or IEEE at the respective
address below.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc.
Case postale 56 • CH-1211 Geneva 20 3 Park Avenue, New York • NY 10016-5997, USA
Tel. + 41 22 749 01 11 E-mail stds.ipr@ieee.org
Fax + 41 22 749 09 47 Web www.ieee.org
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © IEEE 2010 – All rights reserved

Contents Page
Foreword.v
Introduction.vii
1. Overview.1
1.1 Scope.1
1.2 Purpose.1
1.3 Context.2
2. Normative references .2
3. Definitions, acronyms, and abbreviations.2
3.1 Definitions.2
3.2 Acronyms and abbreviations.3
4. Introduction to ISO/IEEE 11073 personal health devices.3
4.1 General.3
4.2 Introduction to IEEE 11073-20601 modeling constructs.4
5. Thermometer device concepts and modalities .4
5.1 General.4
5.2 Body temperature.5
6. Thermometer domain information model .5
6.1 Overview.5
6.2 Class extensions .5
6.3 Object instance diagram.5
6.4 Types of configuration .6
6.5 Medical device system object .7
6.6 Numeric objects .10
6.7 Real-time sample array objects .12
6.8 Enumeration objects.12
6.9 PM store objects.12
6.10 Scanner objects .12
6.11 Class extension objects .12
6.12 Thermometer information model extensibility rules.13
7. Thermometer service model.13
7.1 General.13
7.2 Object access services.13
7.3 Object access event report services.14
8. Thermometer communication model .15
8.1 Overview.15
8.2 Communications characteristics.15
8.3 Association procedure.15
8.4 Configuring procedure .17
8.5 Operating procedure.18
8.6 Time synchronization.19
© IEEE 2010 – All rights reserved iii

9. Test associations .19
9.1 Behavior with standard configuration .19
9.2 Behavior with extended configurations.19
10. Conformance.19
10.1 Applicability.19
10.2 Conformance specification.20
10.3 Levels of conformance.20
10.4 Implementation conformance statements.21
Annex A (informative) Bibliography.26
Annex B (normative) Any additional ASN.1 definitions.27
Annex C (normative) Allocation of identifiers .28
Annex D (informative) Message sequence examples .29
Annex E (informative) Protocol data unit examples.31

iv © IEEE 2010 – 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.
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.
The main task of technical committees is to prepare International Standards. Draft International
Standards adopted by the technical committees are circulated to the member bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the member bodies
casting a vote.
Attention is called to the possibility that implementation of this standard may require the use of
subject matter covered by patent rights. By publication of this standard, no position is taken with
respect to the existence or validity of any patent rights in connection therewith. ISO/IEEE is not
responsible for identifying essential patents or patent claims for which a license may be required,
for conducting inquiries into the legal validity or scope of patents or patent claims or determining
whether any licensing terms or conditions provided in connection with submission of a Letter of
Assurance or a Patent Statement and Licensing Declaration Form, if any, or in any licensing
agreements are reasonable or non-discriminatory. Users of this standard are expressly advised that
determination of the validity of any patent rights, and the risk of infringement of such rights, is
entirely their own responsibility. Further information may be obtained from ISO or the IEEE
Standards Association.
ISO/IEEE 11073-10408 was prepared by the 11073 Committee of the Engineering in Medicine
and Biology Society of the IEEE (as IEEE Std 11073-10408-2008). It was adopted by Technical
Committee ISO/TC 215, Health informatics, in parallel with its approval by the ISO member
bodies, under the “fast-track procedure” defined in the Partner Standards Development
Organization cooperation agreement between ISO and IEEE. Both parties are responsible for the
maintenance of this document.
ISO/IEEE 11073 consists of the following parts, under the general title Health informatics —
Personal health device communication (text in parentheses gives a variant of subtitle):
— Part 10101: (Point-of-care medical device communication) Nomenclature
— Part 10201: Domain information model
— Part 10404: Device specialization — Pulse oximeter
© IEEE 2010 – All rights reserved v

— Part 10407: Device specialization — Blood pressure monitor
— Part 10408: (Point-of-care medical device communication) Device specialization —
Thermometer
— Part 10415: (Point-of-care medical device communication) Device specialization — Weighing
scale
— Part 10417: Device specialization — Glucose meter
— Part 10471: (Point-of-care medical device communication) Device specialization —
Independant living activity hub
— Part 20101: (Point-of-care medical device communication) Application profiles — Base
standard
— Part 20601: (Point-of-care medical device communication) Application profile — Optimized
exchange protocol
— Part 30200: (Point-of-care medical device communication) Transport profile — Cable
connected
— Part 30300: (Point-of-care medical device communication) Transport profile — Infrared
wireless
vi © IEEE 2010 – All rights reserved

Introduction
ISO/IEEE 11073 standards enable communication between medical devices and external computer systems. This
a
document uses the optimized framework created in IEEE Std 11073-20601 and describes a specific, interoperable
communication approach for weighing scales. These standards align with, and draw upon, the existing clinically
focused standards to provide support for communication of data from clinical or personal health devices.

a
For information on references, see Clause 2.
© IEEE 2010 – All rights reserved vii

INTERNATIONAL STANDARD ISO/IEEE 11073-10408:2010(E)

Health informatics — Personal health device
communication —
Part 10408:
Device specialization — Thermometer
IMPORTANT NOTICE: This standard is not intended to assure safety, security, health, or
environmental protection in all circumstances. Implementers of the standard are responsible for
determining appropriate safety, security, environmental, and health practices or regulatory
requirements.
This IEEE document is made available for use subject to important notices and legal disclaimers. These
notices and disclaimers appear in all publications containing this document and may be found under the
heading “Important Notice” or “Important Notices and Disclaimers Concerning IEEE Documents.”
They can also be obtained on request from IEEE or viewed at http://standards.ieee.org/IPR/disclaimers.html.
1. Overview
1.1 Scope
Within the context of the ISO/IEEE 11073 family of standards for device communication, this standard
establishes a normative definition of communication between personal telehealth thermometer devices and
compute engines (e.g., cell phones, personal computers, personal health appliances, and set top boxes) in a
manner that enables plug-and-play interoperability. It leverages appropriate portions of existing standards,
including ISO/IEEE 11073 terminology, information models, application profile standards, and transport
standards. It specifies the use of specific term codes, formats, and behaviors in telehealth environments
restricting optionality in base frameworks in favor of interoperability. This standard defines a common core
of communication functionality for personal telehealth thermometers.
1.2 Purpose
This standard addresses a need for an openly defined, independent standard for controlling information
exchange to and from personal health devices and compute engines (e.g., cell phones, personal computers,
personal health appliances, and set top boxes). Interoperability is the key to growing the potential market
for these devices and to enabling people to be better informed participants in the management of their
health.
© IEEE 2010 – All rights reserved

1.3 Context
TM
See IEEE Std 11073-20601 for an overview of the environment within which this standard is written.

This document, IEEE Std 11073-10408, defines the device specialization for the thermometer, being a
specific agent type, and it provides a description of the device concepts, its capabilities, and its
implementation according to this standard.

This standard is based on IEEE Std 11073-20601, which in turn draws information from both ISO/IEEE
11073-10201:2004 [B3] and ISO/IEEE 11073-20101:2004 [B4]. The medical device encoding rules
(MDERs) used within this standard are fully described in IEEE Std 11073-20601.

This standard reproduces relevant portions of the nomenclature found in ISO/IEEE 11073-10101:2004 [B2]
and adds new nomenclature codes for the purposes of this standard. Between this standard and
IEEE Std 11073-20601, all required nomenclature codes for implementation are documented.
NOTE—In this standard, IEEE Std 11073-104zz is used to refer to the collection of device specialization standards that
utilize IEEE Std 11073-20601, where zz can be any number from 01 to 99, inclusive.
2. Normative references
The following referenced documents are indispensable for the application of this document (i.e., they must
be understood and used, so that 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.

TM
IEEE Std 11073-20601 -2008, Health informatics—Personal health device communication—Part 20601:
3, 4
Application profile—Optimized Exchange Protocol.
3. Definitions, acronyms, and abbreviations
3.1 Definitions
For the purposes of this standard, the following terms and definitions apply. The Authoritative Dictionary of
IEEE Standards [B1] should be referenced for terms not defined in this clause.
3.1.1 agent: A node that collects and transmits personal health data to an associated manager.
3.1.2 body temperature: The measurement of the core body temperature of the person.
3.1.3 class: In object-oriented modeling, it describes the attributes, methods, and events that objects
instantiated from the class utilize.
3.1.4 compute engine: See: manager.
3.1.5 device: A term used to refer to a physical apparatus implementing either an agent or a manager role.

The numbers in brackets correspond to those of the bibliography in Annex A.
Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.
The IEEE standards or products referred to in this clause are trademarks of the Institute of Electrical and Electronics Engineers, Inc.
IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, Piscataway, NJ 08854,
USA (http://standards.ieee.org/).

© IEEE 2010 – All rights reserved

3.1.6 extremity body temperature: The measurement of the temperature at the extremities of the body of
the person, such as finger or toe.
3.1.7 handle: An unsigned 16-bit number that is locally unique and identifies one of the object instances
within an agent.
3.1.8 manager: A node receiving data from one or more agent systems. Some examples of managers
include a cellular phone, health appliance, set top box, or a computer system.
3.1.9 obj-handle: See: handle.
3.1.10 object: In object-oriented modeling, a particular instantiation of a class. The instantiation realizes
attributes, methods, and events from the class.
3.1.11 personal health device: A device used in personal health applications.
3.1.12 personal telehealth device: See: personal health device.
3.2 Acronyms and abbreviations
APDU application protocol data unit
ASN.1 Abstract Syntax Notation One
DIM domain information model
EUI-64 extended unique identifier (64 bits)
ICS implementation conformance statement
MDC medical device communication
MDER medical device encoding rules
MDS medical device system
MOC managed object class
PDU protocol data unit
PHD personal health device
RT-SA real-time sample array
VMO virtual medical object
VMS virtual medical system
4. Introduction to ISO/IEEE 11073 personal health devices
4.1 General
This standard and the remainder of the series of ISO/IEEE 11073 personal health device (PHD) standards
fit in the larger context of the ISO/IEEE 11073 series of standards. The full suite of standards enables
agents to interconnect and interoperate with managers and with computerized health-care information
systems. See IEEE Std 11073-20601 for a description of the guiding principles for this series of ISO/IEEE
11073 Personal Health Device standards.

IEEE Std 11073-20601 supports the modeling and implementation of an extensive set of personal health
devices. This standard defines aspects of the thermometer device. It describes all aspects necessary to
implement the application layer services and data exchange protocol between an ISO/IEEE 11073 PHD
thermometer agent and a manager. This standard utilizes a subset of the classes and functionality defined in
IEEE Std 11073-20601, defines the objects needed to model a thermometer, and adds new modeling
definitions where appropriate. All new definitions are given in Annex B in Abstract Syntax Notation One
(ASN.1) [B5]. Nomenclature codes referenced in this standard, which are not defined in IEEE Std 11073-
20601, are normatively defined in Annex C.
© IEEE 2010 – All rights reserved

4.2 Introduction to IEEE 11073-20601 modeling constructs
4.2.1 General
The ISO/IEEE 11073 series of standards, and in particular IEEE Std 11073-20601, is based on an object-
oriented systems management paradigm. The overall system model is divided into three principal
components: the domain information model (DIM), the service model, and the communication model. See
IEEE Std 11073-20601 for a detailed description of the modeling constructs.
4.2.2 Domain information model
The DIM is a hierarchical model that describes an agent as a set of objects. These objects and their
attributes represent the elements that control behavior and report on the status of the agent and data that an
agent can communicate to a manager. Communication between the agent and the manager is defined by the
application protocol in IEEE Std 11073-20601.
4.2.3 Service model
The service model defines the conceptual mechanisms for the data exchange services. Such services are
mapped to messages that are exchanged between the agent and the manager. Protocol messages within the
ISO/IEEE 11073 series of standards are defined in ASN.1. The messages defined in IEEE Std 11073-20601
can coexist with messages defined in other standard application profiles defined in the ISO/IEEE 11073
series of standards.
4.2.4 Communication model
In general, the communication model supports the topology of one or more agents communicating over
logical point-to-point connections to a single manager. For each logical point-to-point connection, the
dynamic system behavior is defined by a connection state machine as specified in IEEE Std 11073-20601.
4.2.5 Implementing the models
An agent implementing this standard shall implement all mandatory elements of the information, service,
and communication models as well as all conditional elements where the condition is met. The agent should
implement the recommended elements, and it may implement any combination of the optional elements. A
manager implementing this standard shall utilize at least one of the mandatory, conditional, recommended,
or optional elements. In this context, “utilize” means to use the element as part of the primary function of
the manager device. For example, a manager whose primary function is to display data would need to
display a piece of data in the element in order to utilize it.
5. Thermometer device concepts and modalities
5.1 General
This clause presents the general concepts of thermometer devices. In the context of personal health devices
in this family of standards, a thermometer is a device that measures the temperature at some point on the
body of a person. In general, the thermometer will be taking a measurement representative of the core
temperature of the body, and traditionally oral or rectal measurements are used for spot checks or attached
under the armpit (axillary) for extended monitoring. Band thermometers are placed on exposed areas of
skin, often the forehead, but these are not considered as accurate. Typically, the thermometer is placed at
the measurement site for sufficient time for the measuring probe to reach the same temperature as the body
site, and when stable, a direct digital reading of the probe temperature is taken.

© IEEE 2010 – All rights reserved

Methods to determine the temperature of the probe vary, but common methods include change in the
properties of materials with heat such as resistance or semiconductor bandgap voltage. Tympanic
thermometers measure the temperature of the tympanum by infrared measurement, which is noncontact and
immediate. Unless relevant, the method used to determine temperature is ignored in this standard.

Thermometers may be designed for specialist monitoring purposes. For example, thermometers embedded
in capsules may be swallowed and their data transmitted for monitoring during periods of high physical
activity for signs of overheating.

Measurements may be taken at the extremities of the body (fingers, toes) and would typically be used to
monitor for signs of problems due to circulation or hypothermia.
5.2 Body temperature
This standard assumes that a temperature measurement is normally taken as representative of the core body
temperature, and therefore, the actual site of its measurement is not relevant. For this reason, the type
attribute for the temperature object in the standard configuration is set to generic body temperature.

When the site or the method is significant, this will be indicated by use of a separate type for the
temperature in an extended configuration.

The main units used in medicine are the Celsius and the Fahrenheit scales.
6. Thermometer domain information model
6.1 Overview
This clause describes the domain information model of the thermometer.
6.2 Class extensions
In this standard, no class extensions are defined with respect to IEEE Std 11073-20601.
6.3 Object instance diagram
The object instance diagram of the thermometer domain information model, defined for the purposes of this
standard, is shown in Figure 1.

The objects of the DIM, as shown in Figure 1, are described in 6.4 to 6.12. This includes the medical device
system (MDS) object (see 6.5) and the numeric objects (see 6.6). There are no real-time sample array (RT-
SA) objects (see 6.7), enumeration objects (see 6.8), PM-store objects (see 6.9), or scanner objects (see
6.10) in the thermometer. See 6.11 for rules for extending the thermometer information model beyond
elements as described in this standard. Each clause that describes an object of the thermometer contains the
following information:
⎯ The nomenclature code used to identify the class of the object. One example of where this code
is used is the configuration event, where the object class is reported for each object. This allows
the manager to determine whether the class of the object being specified is a numeric, real-time
sample array, enumeration, scanner, or PM-store class.
© IEEE 2010 – All rights reserved

⎯ The attributes of the object. Each object has attributes that represent and convey information on
the physical device and its data sources. Each object has a Handle attribute that identifies the
object instance within an agent. Attribute values are accessed and modified using methods such
as GET and SET. Attributes types are defined using ASN.1. The ASN.1 definitions for new
attribute types specific to this standard are in Annex B, and the ASN.1 definitions for existing
attribute types referenced in this standard are in IEEE Std 11073-20601.
⎯ The methods available on the object.
⎯ The potential events generated by the object. Data are sent to the manager using events.
⎯ The available services such as getting or setting attributes.

The attributes for each class are defined in tables that specify the name of the attribute, its value, and its
qualifier. The qualifiers mean M — Attribute is Mandatory, C — Attribute is Conditional and depends on
the condition stated in the Remark or Value column (if IEEE Std 11073-20601 is referenced, then it
contains the conditions), R — Attribute is Recommended, NR — Attribute is Not Recommended, and O —
Attribute is Optional. Mandatory attributes shall be implemented by the agent. Conditional attributes shall
be implemented if the condition applies and may be implemented otherwise. Recommended attributes
should be implemented by the agent. Not recommended attributes should not be implemented by the agent.
Optional attributes may be implemented by the agent.
The attributes can be either static, meaning that they shall remain unchanged after the configuration is
agreed upon, or dynamic, meaning that the attribute may change at some point after configuration.
PHD-Thermometer object instances
MDS
Thermometer
Numeric
Body Temperature
Figure 1—Thermometer—domain information model
6.4 Types of configuration
6.4.1 General
As specified in IEEE Std 11073-20601, there are two styles of configuration available. Subclauses 6.4.2
and 6.4.3 briefly introduce standard and extended configurations.
© IEEE 2010 – All rights reserved

6.4.2 Standard configuration
Standard configurations are defined in the IEEE 11073-104zz specializations (such as this standard) and are
assigned a well-known identifier (Dev-Configuration-Id). The usage of a standard configuration is
negotiated at association time between the agent and the manager. If the manager recognizes and selects to
operate using the configuration, then the agent can send measurements immediately. If the manager does
not recognize the configuration, the agent provides the configuration prior to transmitting measurement
information.
6.4.3 Extended configuration
In extended configurations, the agent’s configuration is not predefined in a standard. The agent determines
the objects, attributes, and values that will be used in a configuration and assigns a configuration identifier.
When the agent associates with a manager, an acceptable configuration is negotiated. Typically, the
manager does not recognize the agent’s configuration on the first connection, so the manager responds that
the agent must send its configuration information as a configuration event report. If, however, the manager
recognizes the configuration, either because it was preloaded in some way or the agent had previously
associated with the manager, then the manager responds that the configuration is known and no further
configuration information needs to be sent.
6.5 Medical device system object
6.5.1 MDS object attributes
Table 1 summarizes the attributes of the thermometer MDS object. The nomenclature code to identify the
MDS class is MDC_MOC_VMS_MDS_SIMP.
Table 1 —MDS object attributes
Attribute name Value Qual.
Handle 0 M
System-Type Attribute not present. See IEEE Std 11073-20601. C
System-Model {“Manufacturer”,”Model”}. M
System-Id Extended unique identifier (64 bits) (EUI-64). M
Dev-Configuration-Id Standard config: 0x0320 (800) M
Extended configs: 0x4000-0x7FFF.
Attribute-Value-Map See IEEE Std 11073-20601. C
Production-Specification See IEEE Std 11073-20601. O
Mds-Time-Info See IEEE Std 11073-20601. C
Date-and-Time See IEEE Std 11073-20601. C
Relative-Time See IEEE Std 11073-20601. C
HiRes-Relative-Time See IEEE Std 11073-20601. C
Date-and-Time-Adjustment See IEEE Std 11073-20601. C
Power-Status onBattery or onMains. R
Battery-Level See IEEE Std 11073-20601. R
Remaining-Battery-Time See IEEE Std 11073-20601. R
Reg-Cert-Data-List See IEEE Std 11073-20601. O
System-Type-Spec-List {MDC_DEV_SPEC_PROFILE_TEMP, 1}. M
Confirm-Timeout See IEEE Std 11073-20601. O
NOTE—See IEEE Std 11073-20601 for information on whether an attribute is static or dynamic.

In the response to a Get MDS object command, only implemented attributes and their corresponding values
are returned.
© IEEE 2010 – All rights reserved

See IEEE Std 11073-20601 for descriptive explanations of the individual attributes as well as for
information on attribute ID and attribute type.

The Dev-Configuration-Id attribute holds a locally unique 16-bit identifier that identifies the device
configuration instance. For a thermometer agent with extended configuration, this identifier is chosen in the
range of extended-config-start to extended-config-end (see IEEE Std 11073-20601) as shown in Table 1.

The agent sends the Dev-Configuration-Id during the Associating state (see 8.3) to identify its configuration
for the duration of the association. If the manager already holds the configuration information relating to
the Dev-Configuration-Id, it recognizes the Dev-Configuration-Id and the Configuring state (see 8.4) is
skipped; the agent and manager then enter the Operating state. If the manager does not recognize the Dev-
Configuration-Id, the agent and manager enter the Configuring state.

If an agent implements multiple IEEE 11073-104zz specializations, System-Type-Spec-List is a list of
type/version pairs, each referencing the respective device specialization and version of that specialization.
6.5.2 MDS object methods
Table 2 defines the methods (actions) of the MDS object. These methods are invoked using the Action
service. In Table 2, the Subservice type name column defines the name of the method; the Mode column
defines whether the method is invoked as an unconfirmed action (i.e., roiv-cmip-action from
IEEE Std 11073-20601) or a confirmed action (i.e., roiv-cmip-confirmed-action); the Subservice type
(action-type) column defines the nomenclature code to use in the action-type field of an action request and
response (see IEEE Std 11073-20601); the Parameters (action-info-args) column defines the associated
ASN.1 data structure (see IEEE Std 11073-20601 for ASN.1 definitions) to use in the action message for the
action-info-args field of the request; and the Results (action-info-args) column defines the structure to use
in the action-info-args of the response.
Table 2 —MDS object methods
Service Subservice Mode Subservice type Parameters Results
type name (action-type) (action-info- (action-info-
args) args)
ACTION Set-Time Confirmed MDC_ACT_SET_TIME SetTimeInvoke —

Set-Time
This method allows the manager to set a real-time clock in the agent with the absolute time. The agent
indicates whether the Set-Time command is valid using the mds-time-capab-set-clock bit in the Mds-Time-
Info attribute (see IEEE Std 11073-20601). Agents with an internal real-time clock (RTC) shall indicate
this capability by also setting the mds-time-capab-real-time-clock bit in the Mds-Time-Info attribute.
6.5.3 MDS object events
Agents following only this device specialization and no others shall send event reports using agent-initiated
measurement data transmission. During the association procedure (see 8.3), DataReqModeCapab shall be
set to the appropriate value for the event report style (set to data-req-supp-init-agent). The manager shall
assume the thermometer agent does not support any of the MDS-Data-Request features (see IEEE Std
11073-20601 for additional information). The data-req-init-manager-count shall be set to zero, and the data-
req-init-agent-count shall be set to 1.

Agents following this device specialization as well as others shall send event reports in the appropriate
fashion. During the association procedure (see 8.3), DataReqModeCapab shall be set to the appropriate
value for the event report style.

Table 3 defines the events that can be sent by the thermometer MDS object.
© IEEE 2010 – All rights reserved

Table 3 —Thermometer MDS object events
Service Subservice type Mode Subservice type Parameters Results
name (event-type) (event-info) (event-
reply-info)
MDS- Confirmed MDC_NOTI_CONFIG ConfigReport ConfigRepor
Configuration- tRsp
Event
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPOScanReportInfoVar —
Data-Update-Var RT_VAR
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPOScanReportInfoFixed —
EVENT
Data-Update-Fixed RT_FIXED
REPORT
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPO ScanReportInfoMPVar —
Data-Update-MP- RT_MP_VAR
Var
MDS-Dynamic- Confirmed MDC_NOTI_SCAN_REPO ScanReportInfoMPFixed —
Data-Update-MP- RT_MP_FIXED
Fixed
⎯ MDS-Configuration-Event:
This event is sent by the thermometer agent during the configuring procedure if the manager
does not already know the thermometer agent’s configuration from past associations or because
the manager has not been implemented to recognize the configuration according to the
thermometer device specialization. The event provides static information about the supported
measurement capabilities of the thermometer agent.
⎯ MDS-Dynamic-Data-Update-Var:
This event provides dynamic measurement data from the thermometer agent for the body
temperature numeric object. These data are reported using a generic attribute list variable
format. The event is sent as an unsolicited message by the agent (i.e., an agent-initiated
measurement data transmission). See 8.5.3 for more information on unsolicited event reporting.
MDS events for temperature readings shall be sent no faster than once per second.
⎯ MDS-Dynamic-Data-Update-Fixed:
This event provides dynamic measurement data from the thermometer agent for the body
temperature numeric object. These data are reported in the fixed format defined by the Attribute-
Value-Map attribute of the object. The event is sent as an unsolicited message by the agent (i.e.,
an agent-initiated measurement data transmission). See 8.5.3 for more information on
unsolicited event reporting.
⎯ MDS-Dynamic-Data-Update-MP-Var:
This is the same as MDS-Dynamic-Data-Update-Var but allows inclusion of data from multiple
people.
⎯ MDS-Dynamic-Data-Update-MP-Fixed:
This is the same as MDS-Dynamic-Data-Update-Fixed but allows inclusion of data from
multiple people.
NOTE—IEEE Std 11073-20601 requires that managers support all of the MDS object events listed above.
6.5.4 Other MDS services
6.5.4.1 GET service
A thermometer agent shall support the GET service, which is provided by the MDS object to retrieve the
values of all implemented MDS object attributes. The GET service can be invoked as soon as the
thermometer agent receives the Association Response and moves to the Associated state, including the
Operating and Configuring substates.

© IEEE 2010 – All rights reserved

The manager may request the MDS object attributes of the thermometer agent; in which case, the manager
shall send the “Remote Operation Invoke | Get” message (see roiv-cmip-get in IEEE Std 11073-20601) with
the reserved MDS handle value of 0. The thermometer agent shall report its MDS object attributes to the
manager using the “Remote Operation Response | Get” message (see rors-cmip-get in IEEE Std 11073-
20601). See Table 4 for a summary of the GET service including some message fields.
Table 4 —Thermometer MDS object GET service
Service Subservice Mode Subservice Parameters Results
type name type
GET GetArgumentSimple GetResultSimple
confirmed> = (obj-handle = 0), = (obj-handle = 0), attribute-
attribute-id-list list

See 8.5.2 for details on the procedure for getting the MDS object attributes.
6.5.4.2 SET service
The thermometer specialization does not require an implementation to support the MDS object SET
service.
6.6 Numeric objects
6.6.1 General
The thermometer DIM (see Figure 1) contains one required object for body temperature, which is described
in 6.6.2.
Sometimes, the interpretation of one attribute value in an object depends on other attribute values in the
same object. For example, Unit-Code and Unit-LabelString provide context for the observed values.
Whenever a contextual attribute changes, the agent shall report these changes to the manager using an MDS
object event (see 6.5.3) prior to reporting any of the dependent values.
6.6.2 Temperature
Table 5 summarizes the attributes of the body temperature numeric object. The nomenclature code to
identify the numeric class is MDC_MOC_VMO_METRIC_NU. The body temperature numeric object
shall be supported by a thermometer agent.

© IEEE 2010 – All rights reserved

Table 5 —Body temperature numeric object attributes
Attribute name Extended configuration Standard configuration
(Dev-Configuration-Id = 0x0320)
Value Qual. Value Qual.
Handle See IEEE Std 11073-20601. M 1 M
Type {MDC_PART_SCADA, M {MDC_PART_SCADA, M
MDC_TEMP_zzz}. MDC_TEMP_BODY}.
Supplemental-Types See IEEE Std 11073-20601. NR Attribute not initially present. If present NR
follow IEEE Std 11073-20601.
Metric-Spec-Small mss-avail-intermittent, mss- M mss-avail-intermittent, mss-avail-stored-data, M
avail-stored-data, mss-msmt- mss-upd-aperiodic, mss-msmt-aperiodic, mss-
aperiodic, mss-acc-agent- acc-agent-initi
...


NORME ISO/
INTERNATIONALE IEEE
11073-10408
Première édition
2010-05-01
Informatique de santé — Communication
entre dispositifs de santé personnels —
Partie 10408:
Spécialisation des dispositifs —
Thermomètre
Health informatics — Personal health device communication —
Part 10408: Device specialization — Thermometer

Numéro de référence
©
ISO 2010
©
IEEE 2010
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO et l'IEEE
déclinent toute responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO et de l'IEEE. Dans le cas peu probable où surviendrait un problème
d'utilisation, veuillez en informer le Secrétariat central de l'ISO ou l'IEEE à l'une des adresses ci-dessous.

DOCUMENT PROTÉGÉ PAR COPYRIGHT

©  ISO 2010
©  IEEE 2010
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
soit de l'ISO soit de l'IEEE, à l'une ou l'autre des adresses ci-après.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc.
Case postale 56 • CH-1211 Geneva 20 3 Park Avenue, New York • NY 10016-5997, USA
Tel. + 41 22 749 01 11 E-mail stds.ipr@ieee.org
Fax + 41 22 749 09 47 Web www.ieee.org
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © IEEE 2010 – Tous droits réservés

Sommaire Page
1. Description.1
1.1 Domaine d'application.1
1.2 Objet .1
1.3 Contexte.2
2. Références normatives.2
3. Définitions, acronymes et abréviations .2
3.1 Définitions.2
3.2 Acronymes et abréviations .3
4. Introduction à l'ISO/IEEE 11073 portant sur les dispositifs personnels de santé.4
4.1 Généralités.4
4.2 Introduction aux constructions de modélisation de l'IEEE 11073-20601.4
5. Concepts et modalités relatifs aux dispositifs thermométriques .5
5.1 Généralités.5
5.2 Température corporelle.5
6. Modèle d'informations du domaine du thermomètre .6
6.1 Description .6
6.2 Extensions de classes.6
6.3 Diagramme d'instance d'objet .6
6.4 Types de configurations .7
6.5 Objet système de dispositif médical.8
6.6 Objets numériques.12
6.7 Objets groupement d'échantillons en temps réel.14
6.8 Objets énumération .14
6.9 Objets PM-store.14
6.10 Objets analyseur .14
6.11 Objets extensions de classe.14
6.12 Règles d'extension de modèle d'informations du thermomètre.14
7. Modèle de services de thermomètre .15
7.1 Généralités.15
7.2 Services d'accès à l'objet.15
7.3 Services de rapport d'événement d'accès à l'objet.17
8. Modèle de communication du thermomètre.17
8.1 Description générale.17
8.2 Caractéristiques de communication.17
8.3 Procédure d'association .18
8.4 Procédure «Configuration» (procédure de configuration) .19
8.5 Procédure «Operating» (procédure de fonctionnement).21
8.6 Synchronisation dans le temps.21
9. Associations pour test.21
9.1 Comportement avec la configuration normalisée .22
9.2 Comportement avec des configurations étendues .22
10. Conformité .22
10.1 Applicabilité.22
10.2 Spécification de conformité.22
10.3 Niveaux de conformité .23
10.4 Déclarations de conformité de la réalisation .23
© IEEE 2010 – Tous droits réservés iii

Annexe A (informative) Bibliographie.28
Annexe B (normative) Toutes les définitions supplémentaires de l'ASN.1.29
Annexe C (normative) Allocation d'identificateurs .30
Annexe D (informative) Exemples de séquences de messages .31
Annexe E (informative) Exemples d'unités de données de protocole.33

iv © IEEE 2010 – Tous droits réservés

Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales
est en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une
étude a le droit de faire partie du comité technique créé à cet effet. Les organisations
internationales, gouvernementales et non gouvernementales, en liaison avec l'ISO participent
également aux travaux. L'ISO collabore étroitement avec la Commission électrotechnique
internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les documents normatifs de l'IEEE sont développés au sein des sociétés de l'IEEE et des Comités
de Coordination des Normes du Conseil des Normes de l'Association des normes IEEE (IEEE-SA).
L'IEEE développe ses normes par le biais d'un processus de développement de consensus
approuvé par l'American National Standards Institute, qui rassemble des volontaires représentant
divers points de vue et divers intérêts pour parvenir au produit final. Les volontaires ne sont pas
nécessairement des membres de l'Institut et aucune compensation ne leur est attribuée. Bien que
l'IEEE administre le processus et établisse des règles pour favoriser l'équité au cours du processus
de développement du consensus, l'IEEE n'évalue pas, ne teste pas ou ne vérifie pas de manière
indépendante l'exactitude des informations contenues dans ses normes.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de
Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. Leur publication comme Normes internationales requiert l'approbation de 75 % au moins des
comités membres votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire
l'objet de droits de propriété intellectuelle ou de droits analogues. Du fait de la publication de la
présente Norme, aucune position n'est adoptée en ce qui concerne l'existence ou la validité de droit
quelconque de brevet en rapport avec celle-ci. Il n'incombe pas à l'ISO/IEEE d'identifier des brevets
essentiels ou des revendications de brevet essentielles pour lesquels une licence peut être requise,
ni de conduire des enquêtes en ce qui concerne la validité légale ou la portée des brevets ou des
revendications de brevet ou de déterminer si des termes ou conditions d'attribution de licence
fournis en rapport avec la soumission d'une lettre d'assurance ou d'une déclaration de brevet et du
formulaire de déclaration d'attribution de licence, s'il y en a, ou dans des accords d'attribution de
licence quelconques sont raisonnables ou non discriminatoires. Les utilisateurs de la présente
Norme sont expressément avisés que la détermination de la validité de tout droit de brevet et le
risque de violation de ces droits leur incombent entièrement. Des informations supplémentaires
peuvent être obtenues auprès de l'ISO ou de l'Association des normes IEEE.
L'ISO/IEEE 11073-10408 a été élaborée par le Comité 11073 de la Société d'Ingénierie en
Médecine et Biologie de l'IEEE (en tant que norme IEEE 11073-10408:2008). Elle a été adoptée par
le comité technique ISO/TC 215, Informatique de santé, parallèlement à son approbation par les
organismes membres de l'ISO dans le cadre de la « procédure rapide » définie par l'accord de
coopération entre les Organisations Partenaires de Développement de Normes que sont l'ISO et
l'IEEE. Les deux parties sont responsables de la tenue à jour du présent document.
L'ISO/IEEE 11073 comprend les parties suivantes, présentées sous le titre général Informatique de
santé — Communication entre dispositifs de santé personnels (le texte entre parenthèses donne une
variante du sous-titre):
⎯ Partie 10101: (Communication entre dispositifs médicaux sur le site des soins) Nomenclature
⎯ Partie 10201: (Communication entre dispositifs médicaux sur le site des soins) Modèle
d'informations du domaine
© IEEE 2010 – Tous droits réservés v

⎯ Partie 10404: Spécialisation des dispositifs — Oxymètre de pouls
⎯ Partie 10407: Spécialisation des dispositifs — Moniteur de pression sanguine
⎯ Partie 10408: (Communication entre dispositifs de santé personnels) Spécialisation des
dispositifs — Thermomètre
⎯ Partie 10415: (Communication entre dispositifs de santé personnels) Spécialisation des
dispositifs — Plateau de balance
⎯ Partie 10417: Spécialisation des dispositifs — Glucomètre
⎯ Partie 10471: (Communication entre dispositifs de santé personnels) Spécialisation des
dispositifs — Concentrateur d'activités pour une vie autonome
⎯ Partie 20101: (Communication entre dispositifs médicaux sur le site des soins) Profils
d'applications — Norme de base
⎯ Partie 20601: (Communication entre dispositifs de santé personnels) Profil d'application —
Protocole d'échange optimisé
⎯ Partie 30200: (Communication entre dispositifs médicaux sur le site des soins) Profil de
transport — Connexion par câble
⎯ Partie 30300: (Communication entre dispositifs médicaux sur le site des soins) Profil de
transport — Faisceau infrarouge

vi © IEEE 2010 – Tous droits réservés

Introduction
Les normes ISO/IEEE 11073 permettent des communications entre des dispositifs médicaux et des systèmes
1)
informatiques externes. Le présent document utilise le cadre optimisé créé dans l'IEEE 11073-20601 et décrit
une approche de communication interopérable spécifique pour les thermomètres. Ces normes s'alignent sur et
s'inspirent des normes existantes focalisées sur les sujets cliniques pour fournir un support de communication
de données depuis les dispositifs de santé cliniques ou personnels.

1)
Pour des informations sur les références, se reporter à l'Article 2.

© IEEE 2010 – Tous droits réservés vii

NORME INTERNATIONALE ISO/IEEE 11073-10408:2010(F)

Informatique de santé — Communication entre dispositifs
de santé personnels —
Partie 10408:
Spécialisation des dispositifs — Thermomètre
NOTE IMPORTANTE: La présente norme n'a pas pour but d'assurer la sécurité, la sûreté, la
santé ou la protection de l'environnement dans toutes les circonstances. Il incombe aux
personnes ou organismes mettant en œuvre la norme de déterminer les exigences
appropriées en matière de sécurité, de sûreté, d'environnement et de pratiques de santé ou
d'exigences réglementaires.
Le présent document de l'IEEE est mis à disposition afin d'être utilisé sous réserve de
notes importantes et de rejets de responsabilité légale. Ces notes et rejets de
responsabilité apparaissent dans toutes les publications contenant le présent document et
peuvent être trouvés sous l'en-tête " Note importante " ou " Notes importantes et rejets de
responsabilité concernant les documents de l'IEEE ". Ils peuvent également être obtenus
sur demande auprès de l'IEEE ou visualisés sur le site :
http://standards.ieee.org/IPR/disclaimers.html.

1. Description
1.1 Domaine d'application
Dans le contexte de la famille de normes ISO/IEEE 11073 relatives à la communication entre des
dispositifs, la présente norme établit une définition normative de la communication entre des
dispositifs thermométriques personnels de télésanté et des moteurs informatiques (par exemple
des téléphones cellulaires, des ordinateurs personnels, des équipements personnels de santé et
des boîtiers décodeurs) d'une manière qui permet une interopérabilité du type prêt à l'emploi.
Elle s'appuie sur les parties appropriées de normes existantes, y compris la terminologie, des
modèles d'informations, des normes de profils d'applications et des normes de transport de
l'ISO/IEEE 11073. Elle spécifie l'utilisation de codes, de formats et de comportements en termes
spécifiques dans les environnements de télésanté, en limitant les choix à des cadres de travail de
base en faveur de l'interopérabilité. La présente norme définit un noyau commun de
fonctionnalités de communication pour les thermomètres personnels de télésanté.
1.2 Objet
La présente norme répond au besoin d'une norme indépendante définie de manière ouverte
portant sur la commande de l'échange d'informations entre des dispositifs personnels de santé et
des moteurs informatiques (par exemple des téléphones cellulaires, des ordinateurs personnels,
des équipements personnels de santé et des boîtiers décodeurs). L'interopérabilité est la clé de la
croissance du marché potentiel de ces dispositifs et pour permettre aux personnes d'être des
acteurs mieux informés dans la gestion de leur santé.
© IEEE 2010 – Tous droits réservés 1

1.3 Contexte
Voir l'IEEE 11073-20601 pour une description générale de l'environnement dans lequel la
présente norme est écrite.
Le présent document, l'IEEE 11073-10408, définit la spécialisation des dispositifs comme le
thermomètre qui est un type d'agent spécifique, et elle fournit une description des concepts du
dispositif, de ses capacités et de sa mise en œuvre conformément à la présente norme.

La présente norme est fondée sur l'IEEE 11073-20601, qui à son tour tire ses informations de
2)
l'ISO/IEEE 11073-10201:2004 [B3] et de l'ISO/IEEE 11073-20101:2004 [B4]. Les règles de
codage des dispositifs médicaux (MDER) utilisées dans la présente norme sont décrites en
totalité dans l'IEEE 11073-20601.

La présente norme reproduit les parties appropriées de la nomenclature qui se trouve dans
l'ISO/IEEE 11073-10101:2004 [B2] et ajoute de nouveaux codes de nomenclature pour les
besoins de la présente norme. Entre la présente norme et l'IEEE 11073-20601, tous les codes de
nomenclature requis pour la mise en œuvre font l'objet de documents.

NOTE Dans la présente norme, le terme IEEE 11073-104zz est utilisé pour faire référence à l'ensemble de
normes relatives à la spécialisation des dispositifs qui utilisent l'IEEE 11073-20601 et zz peut être tout
3)
nombre de 01 à 99 inclus .
2. Références normatives
Les documents de référence suivants sont indispensables à l'application du présent document
(c'est-à-dire qu'ils doivent être compris et utilisés, de sorte que chaque document de référence soit
cité dans le texte et que sa relation avec le présent document soit expliquée). Pour les références
datées, seule l'édition citée s'applique. Pour les références non datées, la dernière édition du
document de référence s'applique (y compris les éventuels amendements).

IEEE 11073-20601:2008, Informatique de santé — Communication entre des dispositifs de santé

4) 5)
personnels — Partie 20601: Profil d'application — Protocole d'échange optimisé .

3. Définitions, acronymes et abréviations
3.1 Définitions
Pour les besoins de la présente norme, les termes et définitions suivants s'appliquent. Il convient
de faire référence à «The Authoritative Dictionary of IEEE Standards Terms [B1]» en ce qui
concerne les termes qui ne sont pas définis dans le présent article.

3.1.1 agent: nœud qui collecte et transmet des données personnelles de santé à un gestionnaire
associé.
3.1.2 température corporelle: mesurage de la température corporelle profonde de la personne.

2)
Les numéros entre crochets correspondent à ceux de la bibliographie à l'Annexe A.
3)
Les notes dans le texte, les tableaux et les figures sont données pour informations seulement et ne
contiennent pas des exigences nécessaires à l'utilisation de la norme.
4)
Les normes ou les produits IEEE auxquels il est fait référence dans le présent article sont des marques
commerciales de l'Institute of Electrical and Electronics Engineers, Inc.
5)
Les publications de l'IEEE sont disponibles auprès de l'Institute of Electrical and Electronics Engineers,
445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org).

2 © IEEE 2010 – Tous droits réservés

3.1.3 classe: dans une modélisation orientée objet, elle décrit les attributs, les méthodes et les
événements que les objets instanciés à partir de la classe utilisent

3.1.4 moteur informatique: voir gestionnaire.

3.1.5 dispositif: terme utilisé pour désigner un appareil physique mettant en œuvre un agent ou

ayant un rôle de gestionnaire
3.1.6 température corporelle à une extrémité: mesurage de la température aux extrémités du
corps de la personne, par exemple un doigt ou un orteil

3.1.7 poignée: nombre de 16 bits sans signe qui est unique localement et identifie l'une des
instances d'objet dans un agent

3.1.8 gestionnaire: nœud recevant des données d'un ou de plusieurs systèmes d'agents. Certains
exemples de gestionnaires incluent un téléphone cellulaire, un appareil de santé, un boîtier
décodeur ou un système informatique

3.1.9 poignée – objet (obj-handle): voir poignée.

3.1.10 objet: dans une modélisation orientée objet, instanciation particulière d'une classe.
L'instanciation réalise des attributs, des méthodes et des événements à partir de la classe

3.1.11 dispositif personnel de santé: dispositif utilisé dans des applications personnelles de
santé
3.1.12 dispositif personnel de télésanté: voir dispositif personnel de santé.

3.2 Acronymes et abréviations
APDU application protocol data unit (unité de données de protocole d'application)
ASN.1 Abstract Syntax Notation One (notation à syntaxe abstraite un)
BPM beats per minute (battements par minute)
DIM domain information model (modèle d'informations du domaine)
EUI-64 extended unique identifier (64 bits) [identificateur unique étendu (64 bits)]
ICS implementation conformance statement (mention de conformité pour la mise
en œuvre)
MAP mean arterial pressure (pression artérielle moyenne)
MDC medical device communication (communication entre dispositifs médicaux)
MDER medical device encoding rules (règles de codage de dispositif médical)
MDS medical device system (système de dispositif médical)
MOC managed object class (classe d'objet géré)
RT-SA real-time sample array (groupement d'échantillons en temps réel)
PDU protocol data unit (unité de données de protocole)
PHD personal health device (dispositif personnel de santé)
VMO virtual medical object (objet médical virtuel)
VMS virtual medical system (système médical virtuel)
© IEEE 2010 – Tous droits réservés 3

4. Introduction à l'ISO/IEEE 11073 portant sur
les dispositifs personnels de santé
4.1 Généralités
La présente norme et le reste de la série des normes ISO/IEEE 11073 portant sur les dispositifs
personnels de santé (PHD) s'intègrent dans le contexte plus large de la série des normes
ISO/IEEE 11073. La suite complète de normes permet aux agents de s'interconnecter et
d'interopérer avec les gestionnaires et avec les systèmes d'informations informatisés de soins.
Voir l'IEEE 11073-20601 pour une description des principes directeurs pour cette série de normes
ISO/IEEE 11073 portant sur les dispositifs personnels de santé.

L'IEEE 11073-20601 prend en charge la modélisation et la mise en œuvre d'un ensemble
important de dispositifs personnels de santé. La présente norme définit des aspects du dispositif
thermométrique. Elle décrit tous les aspects nécessaires à la mise en œuvre des services de la
couche d'application et du protocole d'échange de données entre un agent thermométrique PHD
de l'ISO/IEEE 11073 et un gestionnaire. La présente norme utilise un sous-ensemble des classes
et la fonctionnalité définie dans l'IEEE 11073-20601, définit les objets nécessaires pour modéliser
un thermomètre et ajoute de nouvelles définitions de modélisation lorsque cela est approprié.
Toutes les nouvelles définitions sont données à l'Annexe B en Notation à Syntaxe Abstraite Un
(ASN.1) [B5]. Les codes de nomenclature auxquels il est fait référence dans la présente norme,
qui ne sont pas définis dans l'IEEE 11073-20601, sont définis de manière normative à l'Annexe C.

4.2 Introduction aux constructions de modélisation de
l'IEEE 11073-20601
4.2.1 Généralités
La série de normes ISO/IEEE 11073, et en particulier l'IEEE 11073-20601, est fondée sur un
paradigme de gestion de systèmes orientée objet. Le modèle de système global est divisé en trois
principales composantes: le modèle d'informations du domaine (DIM), le modèle de service et le
modèle de communication. Voir l'IEEE 11073-20601 pour une description détaillée des
constructions de la modélisation.

4.2.2 Modèle d'informations du domaine
Le DIM est un modèle hiérarchique qui décrit un agent sous la forme d'un ensemble d'objets. Ces
objets et leurs attributs représentent les éléments qui déterminent le comportement et rapportent
l'état de l'agent et les données qu'un agent peut communiquer à un gestionnaire. La
communication entre l'agent et le gestionnaire est définie par le protocole d'application dans
l'IEEE 11073-20601.
4.2.3 Modèle de service
Le modèle de service définit les mécanismes conceptuels pour les services d'échange de
données. De tels services sont mappés sur des messages qui sont échangés entre l'agent et
le gestionnaire. Les messages de protocole dans la série de normes ISO/IEEE 11073 sont
définis en ASN.1. Les messages définis dans l'IEEE 11073-20601 peuvent coexister avec les
messages définis dans les autres profils d'application de normes définis dans la série de normes
ISO/IEEE 11073.
4.2.4 Modèle de communication
D'une manière générale, le modèle de communication prend en charge la topologie d'un ou de
plusieurs agents qui communiquent sur des connexions logiques de point à point avec un seul
gestionnaire. Pour chaque connexion logique de point à point, le comportement dynamique du
système est défini par une machine à états finis de connexion, telle que spécifiée dans
l'IEEE 11073-20601.
4 © IEEE 2010 – Tous droits réservés

4.2.5 Mise en œuvre des modèles
Un agent mettant en œuvre la présente norme doit mettre en œuvre tous les éléments
obligatoires des modèles d'informations, de service et de communication, de même que tous les
éléments conditionnels où la condition est satisfaite. Il convient que l'agent mette en œuvre les
éléments recommandés et il peut mettre en œuvre toute combinaison des éléments optionnels.
Un gestionnaire mettant en œuvre la présente norme doit utiliser au moins l'un des éléments
obligatoires, conditionnels, recommandés ou optionnels. Dans ce contexte, «utiliser» signifie
utiliser l'élément en tant que partie de la fonction primaire du dispositif gestionnaire. Par exemple,
un gestionnaire dont la fonction primaire consiste à afficher des données devrait afficher un
élément de données dans l'élément pour l'utiliser.

5. Concepts et modalités relatifs aux dispositifs
thermométriques
5.1 Généralités
Le présent article présente les concepts généraux relatifs aux dispositifs thermométriques. Dans
le contexte des dispositifs personnels de santé de cette famille de normes, un thermomètre est un
dispositif qui mesure la température à un certain endroit sur le corps d'une personne. En général,
le thermomètre prendra une mesure représentative de la température corporelle profonde et,
traditionnellement, des mesurages oraux et rectaux sont utilisés pour des contrôles ponctuels ou
sont fixés sous les aisselles (creux de l'aisselle) pour une surveillance prolongée. Des
thermomètres en bande sont placés sur les zones exposées de la peau, souvent le front, mais
ceux-ci ne sont pas considérés comme précis. Habituellement, le thermomètre est placé sur le
site de mesure pendant un temps suffisant pour que la sonde de mesure atteigne la même
température que le site du corps et, lorsque celle-ci est stable, une mesure numérique directe de
la température de la sonde est relevée.

Les méthodes pour déterminer la température de la sonde varient, mais les méthodes courantes
incluent la variation des propriétés des matériaux avec la chaleur, telles que la résistance ou la
tension de bande interdite des semi-conducteurs. Les thermomètres pour le tympan mesurent la
température de la caisse du tympan par mesure infrarouge et ceci se fait sans contact et est
immédiat. À moins que cela ne soit pertinent, la méthode utilisée pour déterminer la température
est ignorée dans la présente norme.

Les thermomètres peuvent être conçus à des fins de surveillance spécialisée. Par exemple, des
thermomètres incorporés dans des capsules peuvent être avalés et leurs données transmises en
vue d'une surveillance au cours de périodes d'activité physique intense pour déceler des signes
de surchauffe.
Les mesurages peuvent être effectués aux extrémités du corps (doigts, orteils) et seront
habituellement utilisés pour surveiller des signes de problème dus à la circulation ou à une
hypothermie.
5.2 Température corporelle
La présente norme suppose qu'un mesurage de température est normalement considéré comme
étant représentatif de la température corporelle profonde et, par conséquent, le site réel du
mesurage n'a pas d'importance. Pour cette raison, l'attribut des types pour l'objet température
dans la configuration de la norme est considéré comme étant la température générique du corps.

Lorsque le site ou la méthode importent, cela sera indiqué grâce à l'utilisation d'un type séparé
pour la température dans une configuration étendue.

Les principales unités utilisées en médecine sont les échelles Celsius et Fahrenheit.

© IEEE 2010 – Tous droits réservés 5

6. Modèle d'informations du domaine du thermomètre
6.1 Description
Le présent article décrit le modèle d'informations du domaine du thermomètre.

6.2 Extensions de classes
Dans la présente norme, aucune extension de classe n'est définie en ce qui concerne
l'IEEE 11073-20601.
6.3 Diagramme d'instance d'objet
Le diagramme d'instance d'objet du modèle d'informations du domaine du thermomètre, défini
pour les besoins de la présente norme, est représenté à la Figure 1.

Les objets du DIM, tels qu'ils sont représentés à la Figure 1, sont décrits de 6.4 à 6.12. Ceci inclut
l'objet système de dispositif médical (MDS) (voir 6.5) et les objets numériques (voir 6.6). Il n'y a
pas d'objets groupement d'échantillons en temps réel (RT-SA) (voir 6.7), d'objets énumération
(voir 6.8), d'objet PM-store (voir 6.9) ou d'objet analyseur (voir 6.10) dans le thermomètre. Voir
6.11 pour les règles d'extension du modèle d'informations du thermomètre au-delà des éléments
tels que décrits dans la présente norme. Chaque paragraphe qui décrit un objet du thermomètre
contient les informations suivantes:

– Le code de nomenclature utilisé pour identifier la classe de l'objet. Un exemple de l'endroit
où ce code est utilisé est l'événement de configuration, où la classe d'objet est signalée pour
chaque objet. Cela permet au gestionnaire de déterminer si la classe de l'objet qui est
spécifiée est une classe numérique, une classe de groupement d'échantillons en temps réel,
une classe énumération, une classe d'analyseur ou une classe PM-store.

– Les attributs de l'objet. Chaque objet a des attributs qui représentent et acheminent des
informations sur le dispositif physique et ses sources de données. Chaque objet a un attribut
Poignée qui identifie l'instance d'objet dans un agent. Les valeurs des attributs font l'objet
d'un accès et elles sont modifiées en utilisant des méthodes telles que GET et SET. Les
types d'attributs sont définis en utilisant une notation ASN.1. Les définitions de la notation
ASN.1 pour de nouveaux types d'attributs spécifiques de la présente norme se trouvent à
l'Annexe B et les définitions de l'ASN.1 pour les types d'attributs existants auxquels il est fait
référence dans la présente norme se trouvent dans l'IEEE 11073-20601.

– Les méthodes disponibles sur l'objet.

– Les événements potentiels générés par l'objet. Les données sont envoyées au gestionnaire
en utilisant des événements.
– Les services disponibles tels que l'obtention ou la fixation des attributs.

Les attributs pour chaque classe sont définis dans des tables qui spécifient le nom de l'attribut, sa
valeur et son qualificateur. Les qualificateurs sont les lettres qui signifient: M – l'attribut est
obligatoire, C – l'attribut est conditionnel et dépend de la condition mentionnée dans la colonne
Remarque ou Valeur (s'il est fait référence à l'IEEE 11073-20601, alors elle contient les
conditions), R — l'attribut est recommandé, NR — l'attribut n'est pas recommandé et O — l'attribut
est optionnel. Les attributs obligatoires doivent être mis en œuvre par l'agent. Les attributs
Conditionnels doivent être mis en œuvre si la condition s'applique et peuvent être mis en œuvre
d'une autre manière. Il convient que l'agent mette en œuvre les attributs recommandés. Il convient
6 © IEEE 2010 – Tous droits réservés

que l'agent ne mette pas en œuvre les attributs non recommandés. Les attributs optionnels
peuvent être mis en œuvre par l'agent.

Les attributs peuvent être soit statiques, ce qui signifie qu'ils doivent rester inchangés après que la
configuration a fait l'objet d'un accord, soit dynamiques, ce qui signifie que l'attribut peut changer à
un certain instant après la configuration.

PHD - Instances de l'objet thermomètre

MDS
Thermomètre
Numérique
Température corporelle
Figure 1 — Thermomètre — Modèle d'informations du domaine

6.4 Types de configurations
6.4.1 Généralités
Comme spécifié dans l'IEEE 11073-20601, il existe deux styles de configurations disponibles. Les
paragraphes 6.4.2 et 6.4.3 introduisent brièvement la configuration normalisée et la configuration
étendue.
6.4.2 Configuration normalisée
Les configurations normalisées sont définies dans les parties spécialisées IEEE 11073-104zz (par
exemple dans la présente norme) et se voient affecter un identificateur bien connu (Dev-
Configuration-Id). L'utilisation de la configuration normalisée est négociée à l'instant de
l'association entre l'agent et le gestionnaire. Si le gestionnaire reconnaît la configuration et choisit
de fonctionner en utilisant la configuration, alors l'agent peut envoyer les mesurages
immédiatement. Si le gestionnaire ne reconnaît pas la configuration, l'agent fournit la configuration
avant de transmettre les informations de mesure.

6.4.3 Configuration étendue
Dans les configurations étendues, la configuration de l'agent n'est pas prédéfinie dans une norme.
L'agent détermine les objets, les attributs et les valeurs qu'il souhaite utiliser dans une
configuration et affecte un identificateur de configuration. Lorsque l'agent s'associe à un
gestionnaire, il négocie une configuration acceptable. Habituellement, le gestionnaire ne reconnaît
pas la configuration de l'agent à la première connexion, de sorte que le gestionnaire répond que
l'agent doit envoyer ses informations de configuration sous la forme d'un rapport d'événement de
configuration. Cependant, si le gestionnaire reconnaît la configuration, soit du fait qu'elle est
© IEEE 2010 – Tous droits réservés 7

préchargée d'une certaine manière, soit du fait que l'agent s'est précédemment associé avec le
gestionnaire, alors le gestionnaire répond que la configuration est connue et qu'aucune
information de configuration supplémentaire ne doit être envoyée.

6.5 Objet système de dispositif médical
6.5.1 Attributs d'objet MDS
Le Tableau 1 constitue un récapitulatif des attributs de l'objet MDS thermomètre. Le code de
nomenclature pour identifier la classe MDS est MDC_MOC_VMS_MDS_SIMP.

Tableau 1 — Attributs d'objet MDS
Nom de l'attribut Valeur Qual.
Poignée 0 M
System-Type (Type de Attribut non présent. Voir l'IEEE 11073-20601. C
Système)
System Model (Modèle de {«Fabricant», «Modèle»}. M
Système)
System-Id (Identificateur du Identificateur unique étendu (64 bits) (EUI-64). M
système)
Dev-Configuration-Id Configuration normalisée: 0x0320 (800) M
(Identificateur de configuration-
Configurations étendues: 0x4000-0x7FFF.
Dev)
Attribute-Value-Map (Mappe de Voir l'IEEE 11073-20601. C
Valeurs d'Attributs)
Production-Specification Voir l'IEEE 11073-20601. O
(Spécification de fabrication)
Mds-Time-Info (Informations de Voir l'IEEE 11073-20601. C
Temps du Mds)
Date-And-Time (Date et Heure) Voir l'IEEE 11073-20601. C
Relative-Time (Heure Relative) Voir l'IEEE 11073-20601. C
HiRes-Relative-Time (Temps
Voir l'IEEE 11073-20601. C
relatif HiRes)
Date-And-Time-Adjustment Voir l'IEEE 11073-20601. C
(Réglage de la Date et de
l'Heure)
Power-Status (Statut de Sur batterie ou sur secteur R
l'alimentation)
Battery-Level (Niveau de la Voir l'IEEE 11073-20601. R
batterie)
Remaining-Battery-Time Voir l'IEEE 11073-20601. R
(Temps restant pour la batterie)
Reg-Cert-Data-List (Liste de Voir l'IEEE 11073-20601. O
données Cert-Reg)
System-Type-Spec-List (Liste
{MDC_DEV_SPEC_PROFILE_TEMP, 1}. M
de spécifications du type de
système)
Confirm-Timeout (Confirmer Voir l' IEEE 11073-20601. O
l'expiration du temps imparti)

NOTE Voir l'IEEE 11073-20601 pour des informations pour déterminer si un attribut est statique ou
dynamique.
8 © IEEE 2010 – Tous droits réservés

Dans la réponse à une commande Get de l'objet MDS, seuls les attributs mis en œuvre et leurs
valeurs correspondantes sont renvoyées.

Voir l'IEEE 11073-20601 pour des explications descriptives des attributs individuels de même que
pour des informations sur l'identificateur de l'attribut et sur le type d'attribut.

L'attribut Dev-Configuration-Id contient un identificateur localement unique de 16 bits qui identifie
la configuration du dispositif. Pour un agent thermomètre doté d'une configuration étendue, cet
identificateur est choisi dans la plage de extended-config-start (début de configuration étendue) à
extended-config-end (fin de configuration étendue) (voir l'IEEE 11073-20601) comme indiqué
dans le Tableau 1.
L'agent envoie l'attribut Dev-Configuration-Id au cours de l'état Associating (association) (voir 8.3)
pour identifier sa configuration pendant la durée de l'association. Si le gestionnaire possède déjà
les informations de configuration se rapportant à l'attribut Dev-Configuration-Id, il reconnaît
l'attribut Dev-Configuration-Id et l'état Configuring (configuration) (voir 8.4) est sauté. L'agent et le
gestionnaire entrent alors dans l'état Operating (fonctionnement). Si le gestionnaire ne reconnaît
pas l'Attribut Dev-Configuration-Id, l'agent et le gestionnaire entrent dans l'état Configuring
(configuration).
Si un agent met en œuvre de multiples spécialisations selon l'IEEE 11073-104zz, l'attribut
System-Type-Spec-List est une liste de paires type/version, chacune faisant référence à la norme
du dispositif respectif et à la version de cette norme.

6.5.2 Méthodes de l'objet MDS
Le Tableau 2 définit les méthodes (actions) de l'objet MDS. Ces méthodes sont appelées en
utilisant le service Action. Dans le Tableau 2, la colonne Subservice type name (nom de type de
sous-service) définit le nom de la méthode, la colonne Mode définit si la méthode est appelée en
tant qu'action non confirmée (c'est-à-dire roiv-cmip-action de l'IEEE 11073-20601) ou en tant
qu'action confirmée (c'est-à-dire, roiv-cmip-confirmed-action). La colonne Subservice type (type de
sous-service) (action-type) définit le code de nomenclature utilisée dans le champ action-type
(type d'action) d'une demande et d'une réponse d'action (voir l'IEEE 11073-20601). La colonne
Parameters (Paramètres) (action-info-args) définit la structure associée de données en notation
ASN.1 (voir l'IEEE 11073-20601 pour les définitions ASN.1) à utiliser dans le message d'action
pour le champ action-info-args de la demande et la colonne Results (résultats) (action-info-args)
définit la structure à utiliser dans les paramètres action-info-args de la réponse.
Tableau 2 — Méthodes de l'objet MDS
Service Subservice type Mode Subservice type Parameters Results
name (type de sous-service) (Paramètres) (Résultats)
(Nom de type (action-type) (action-info- args) (action-info- args)
de sous-service) (type d'action)
ACTION Set-Time Confirmed MDC_ACT_SET_TIME SetTimeInvoke —
(Régler le (Confirmé)
temps)
Set-Time (Réglage du Temps)
Cette méthode permet au gestionnaire de régler une horloge en temps réel dans l'agent sur le
temps absolu. L'agent indique si la commande Set-Time est valide en utilisant le bit mds-time-
capab-set-clock dans l'attribut Mds-Time- Info (voir l'IEEE 11073-20601). Les agents ayant une
horloge interne en temps réel (RTC) doivent indiquer cette capacité en armant également le bit
mds-time-capab-real-time-clock dans l'attribut Mds-Time-Info.

© IEEE 2010 – Tous droits réservés 9

6.5.3 Événements de l'objet MDS
Les agents ne suivant que cette spécialisation de dispositif doivent envoyer des rapports
d'événements en utilisant une transmission de données de mesure initiée par l'agent. Les autres
agents ne doivent pas le faire. Au cours de la procédure d'association (voir 8.3),
DataReqModeCapab doit être établie à la valeur appropriée pour le style de rapport d'événement
(établi à data-req-supp-init-agent). Le gestionnaire doit supposer que l'agent thermomètre
n'accepte aucune des caractéristiques de MDS-Data-Request (voir l'IEEE 11073-20601 pour les
informations supplémentaires). Le bit data-req-init-manager-count doit être établi à zéro et le bit
data-req-init-agent-count doit être établi à 1.

Les agents suivant cette spécialisation de dispositif de même que d'autres doivent envoyer des
rapports d'événements de la manière appropriée. Au cours de la procédure d'association
(voir 8.3), le bit DataReqModeCapab doit être établi à la valeur appropriée pour le style de rapport
d'événement.
Le Tableau 3 définit les évén
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...