ISO/IEEE 11073-10471:2010

INTERNATIONAL ISO/IEEE
STANDARD 11073-10471
First edition
2010-05-01
Health informatics — Personal health
device communication —
Part 10471:
Device specialization — Independant
living activity hub
Informatique de santé — Communication entre dispositifs de santé
personnels —
Partie 10471: Spécialisation des dispositifs — Concentrateur d'activité
vivante indépendante
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. 2
1.3 Context. 2
2. Normative references . 2
3. Definitions, acronyms, and abbreviations. 2
3.1 Definitions. 3
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 Std 11073-20601 modeling constructs. 4
5. Independent living activity hub device concepts and modalities . 5
5.1 General. 5
5.2 Concepts. 5
5.3 Collected data. 5
6. Independent living activity hub domain information model . 7
6.1 Overview. 7
6.2 Class extensions . 7
6.3 Object instance diagram. 7
6.4 Types of configuration . 9
6.5 MDS object . 10
6.6 Numeric objects . 13
6.7 Real-time sample array objects . 13
6.8 Enumeration objects. 13
6.9 PM-store objects . 26
6.10 Scanner objects . 26
6.11 Class extension objects . 26
6.12 Independent living activity hub information model extensibility rules. 26
7. Independent living activity hub service model . 27
7.1 General. 27
7.2 Object access services. 27
7.3 Object access event report services. 29
© IEEE 2010 – All rights reserved iii

8. Independent living activity hub communication model. 29
8.1 Overview. 29
8.2 Communication characteristics . 29
8.3 Association procedure. 30
8.4 Configuring procedure . 31
8.5 Operating procedure. 32
8.6 Time synchronization. 32
9. Test associations . 32
9.1 Behavior with standard configuration . 33
9.2 Behavior with extended configurations. 33
10. Conformance. 33
10.1 Applicability. 33
10.2 Conformance specification. 33
10.3 Levels of conformance. 34
10.4 ICSs. 34
Annex A (informative) Bibliography. 39
Annex B (normative) Any additional ASN.1 definitions. 40
Annex C (normative) Allocation of identifiers . 43
Annex D (informative) Message sequence examples . 45
Annex E (informative) Protocol data unit examples. 47

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-10471 was prepared by the 11073 Committee of the Engineering in Medicine
and Biology Society of the IEEE (as IEEE Std 11073-10471-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 independent living activity hubs. 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-10471:2010(E)

Health informatics — Personal health device
communication —
Part 10471:
Device specialization — Independant living activity hub
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 the communication between independent living activity hubs and
managers (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 and information models. It specifies the use of specific term codes, formats,
and behaviors in telehealth environments restricting ambiguity in base frameworks in favor of
interoperability. This standard defines a common core of communication functionality for independent
living activity hubs. In this context, independent living activity hubs are defined as devices that
communicate with simple situation monitors (binary sensors), normalize information received from the
simple environmental monitors, and provide this normalized information to one or more managers. This
information can be examined (for example) to determine when a person’s activities/behaviors have
deviated significantly from what is normal for them such that relevant parties can be notified. Independent
living activity hubs will normalize information from the following simple situation monitors (binary
sensors) for the initial release of the proposed standard: fall sensor, motion sensor, door sensor, bed/chair
occupancy sensor, light switch sensor, smoke sensor, (ambient) temperature threshold sensor, personal
emergency response system (PERS), and enuresis sensor (bed-wetting).

© IEEE 2010 – All rights reserved

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 managers (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.
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-10471, defines the device specialization for the independent living activity
hub, 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.
See Annex A for all informative material referenced by this standard.
3. Definitions, acronyms, and abbreviations
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.

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 Definitions
3.1 agent: A node that collects and transmits personal health data to an associated manager.
3.2 class: In object-oriented modeling, it describes the attributes, methods, and events that objects
instantiated from the class utilize.

3.3 compute engine: See: manager.
3.4 device: A term used to refer to a physical apparatus implementing either an agent or a manager role.
3.5 handle: An unsigned 16-bit number that is locally unique and identifies one of the object instances
within an agent.
3.6 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.7 obj-handle: See: handle.
3.8 object: In object-oriented modeling, a particular instantiation of a class. The instantiation realizes
attributes, methods, and events from the class.
3.9 personal health device: A device used in personal health applications.
3.10 personal telehealth device: See: personal health device.
3.11 sensor: An apparatus that measures physical properties. These comprise the primary inputs to an
independent living activity hub agent.
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
PERS personal emergency response system
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 2010 – All rights reserved

IEEE Std 11073-20601 supports the modeling and implementation of an extensive set of personal health
devices. This standard defines aspects of the independent living activity hub device. It describes all aspects
necessary to implement the application layer services and data exchange protocol between an
ISO/IEEE 11073 PHD independent living activity hub agent and a manager. This standard defines a subset
of the objects and functionality contained in IEEE Std 11073-20601 and extends and adds 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.
4.2 Introduction to IEEE Std 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.
© IEEE 2010 – All rights reserved

5. Independent living activity hub device concepts and modalities
5.1 General
This clause presents the general concepts of independent living activity hub devices. In the context of
personal health devices in this family of standards, an independent living activity hub is a device that
aggregates activity data sensor events from multiple sensor data sources, all of which are used in the
support of the independent living of one or more occupants. The occupants’ environment may vary greatly
and encompass a varying mixture of sensors; therefore, the activity data sensor events reported by any
particular agent have a corresponding variance.
5.2 Concepts
While there are many data generating sensors, they have a number of properties in common that influence
the design of this standard. Note that these are only generalities employed in the design and there may be
instances where an activity data generating sensor exceeds these properties.

⎯ Price: usually they are very inexpensive sensors.
⎯ Power: typically they are very low power sensors.
⎯ Communication: typically they use a very inexpensive communication technique and are quite
often wireless.
⎯ Frequency: typically they communicate very infrequently or only when an event occurs.
⎯ Quantity: there may be a wide range of sensors and many instances of any one sensor type.

It is the responsibility of the independent living activity hub agent to manage all these sensors.
Management of the sensors is likely to be within the proprietary purview of the agent both because there is
no acceptable existing industry standard and the desire to integrate existing legacy solutions with the
IEEE Std 11073-20601 framework. Therefore, this responsibility is outside the scope of this standard. Only
the communication between the independent living activity hub agent and the manager are covered by this
standard.
Additionally, due to the many different types of sensors that may be employed in any particular installation,
there is a range of functionality that the corresponding independent living activity hub agent presents to the
manager. On the one hand, a fully functional independent living activity hub agent could represent a
significant number of sensors and have a complex conversation with the associated manager. On the other
hand, a subset of this protocol could be employed by just one sensor such that it would appear to a manager
as an independent living activity hub agent with a single sensor.
5.3 Collected data
5.3.1 General
This clause provides an overview of the kinds of sensors and activity data that could be collected. This is
not to imply that all independent living activity hub agents would necessarily report values for all of these
sensors. Furthermore, this standard is not concerned with the form of the data nor the communication
between any actual sensor and the independent living activity hub; rather only the activity data sensor
events derived as a result of that data are considered part of this standard. See Clause 6 for the normative
definition of this derived data.
© IEEE 2010 – All rights reserved

5.3.2 Fall sensor
This sensor is used to notify the monitoring system that a fall sensor event has taken place. This could take
the form of a sensor of the type that detects a person’s fall and automatically generates the event.
5.3.3 PERS sensor
This sensor is used to notify the monitoring system that a personal emergency sensor event has taken place.
This would typically take the form of a button that the person presses to indicate some sort of perceived
emergency (“panic button”).
5.3.4 Environmental sensors
These sensors generate a sensor event whenever they sense an environmental aspect that is beyond a preset
threshold. Examples include smoke sensors, carbon monoxide sensors, water sensors, and natural gas/LP
gas sensors.
5.3.5 Motion sensor
This sensor generates a sensor event whenever it has sensed movement within its range above a preset level.
This type of sensor is typically employed in two manners: general motion and intruder detection.

In the case of general motion, the detection of the motion causes an immediate generation of a sensor event
and subsequent action. This may be used for tracking the activity level of the occupant to discern whether
behavior patterns have altered.

In the case of intruder detection, the motion sensor event could be used to trigger intruder detection actions.

Optionally, in the case of the primary entrances to the building, for example, the subsequent action to the
sensor event may be delayed for some period before taken. This is to allow for an authorized person to
enter the premises and to disable the sensor event before the action is taken (e.g., in the case where a
triggered sensor event will generate an intruder alert). Should the proper disabling not take place within the
expected delay time period, the normal subsequent action would take place. There may also be a sensor
event for the case when the motion sensor detects someone attempting to tamper with its function.
5.3.6 Property exit sensor
This sensor generates a sensor event whenever it has sensed the exit of an occupant from the premises. This
is commonly employed when there is an occupant with some cognitive issues who would encounter
difficulties in an unfamiliar environment. There may also be a sensor event for the case where the premises’
exit is left open.
5.3.7 Enuresis sensor
This sensor generates a sensor event when it detects occurrences of involuntary urination or bed-wetting.
This sensor could be utilized in a range of settings such as a bed, chair, or any similar structure.
5.3.8 Contact closure sensor
This sensor issues a sensor event whenever a contact is opened or closed. This sensor reports the state of
the contact after a transition, either from closed to open or from open to closed. Only a single sensor event
is sent for each transition. Examples of where this sensor would be deployed are passageway doors,
cupboard doors, drawers, windows, and pressure mats.
© IEEE 2010 – All rights reserved

5.3.9 Usage sensor
This sensor issues a sensor event to denote the start of use (into a bed/chair, for example) or the end of use
(out of a bed/chair, for example). It also issues a sensor event for an anticipated usage not occurring by an
expected preset time (expected use start violation) as well as a sensor event for the usage continuing
beyond an expected preset time (expected use stop violation). Additionally, there would be a sensor event
generated if during an expected usage time, the usage is discontinued for longer than a preset period of time
(intermittent absence violation). An example would be that during a normal sleep period, a person got out
of the bed and did not return in an expected period of time.
5.3.10 Switch use sensor
This sensor issues a sensor event for a switch changing states either to the used state (ON) or to the unused
state (OFF). Examples of this are light switches, fan switches, and other similar switches that control
electrical apparatus.
5.3.11 Simple medication dispenser
The dispenser is a container that contains doses of one or more medications. The medications are to be
taken in predetermined doses at predetermined times. A sensor event is generated for a presented dosage
being taken from the dispenser (dosage taken) and/or for a dose not being taken after a predetermined
amount of time (dosage missed).

NOTE—The sensor description presented here is of a conceptual model to aid in understanding. Be aware that the
same derived sensor events could be generated through many other means (such as a user interaction with some screen
interface). This standard is only concerned with the generated sensor events.
5.3.12 Temperature sensor
This sensor monitors the temperature in an environment. It issues sensor events based on the sensor value
being outside of a preset temperature limit. The sensor events could be that the ambient temperature has
risen above a certain level (high threshold) or dropped below a certain level (low threshold), or that the
rate-of-change is faster than a predetermined expected rate (rate-of-change). This can be used for detecting
conditions such as the temperature of a dwelling being dangerously high/low or that stove elements have
been left on after cooking has been completed.
6. Independent living activity hub domain information model
6.1 Overview
This clause describes the domain information model of the independent living activity hub.
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 independent living activity hub domain information model, defined for
the purposes of this standard, is shown in Figure 1.

The generic DIM of the independent living activity hub that is presented in Figure 1 defines all possible
data objects. However, it would be expected that most independent living activity hubs would implement
© IEEE 2010 – All rights reserved

only a restricted subset of the data objects. An independent living activity hub shall implement at least one
sensor instance.
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), the numeric objects (see 6.6), the real-time sample array (RT-SA) objects
(see 6.7), the enumeration objects (see 6.8), the PM-store objects (see 6.9), and the scanner objects (see
6.10). See 6.12 for rules for extending the independent living activity hub information model beyond
elements as described in this standard. Each clause that describes an object of the independent living
activity hub 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.
⎯ The attributes of the object. Each object has attributes that represent and convey information on
the activity data generating sensor 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
communication services 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 on, or dynamic, meaning that the attribute may change at some point after configuration.

© IEEE 2010 – All rights reserved

Figure 1 —Independent living activity hub—object instances
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
This standard does not define any standard configurations since the set of sensors for each agent
configuration is likely to vary significantly for each deployment scenario. Therefore, all configurations
shall be specified as extended configurations.
6.4.3 Extended configuration
In extended configurations, the agent’s configuration is not predefined in a standard. The agent determines
which objects, attributes, and values that it wants to use in a configuration and assigns a configuration
identifier. When the agent associates with a manager, it negotiates an acceptable configuration. 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 already understands 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 independent living activity hub 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 See IEEE Std 11073-20601. C
System-Model {“Manufacturer”,”Model”}. M
System-Id EUI-64. M
Dev- Extended configs: 0x4000–0x7FFF. M
Configuration-Id
Attribute-Value- See IEEE Std 11073-20601. C
Map
Production- See IEEE Std 11073-20601.  O
Specification
Mds-Time-Info See IEEE Std 11073-20601.  C
Date-and-Time See IEEE Std 11073-20601. M
Relative-Time See IEEE Std 11073-20601.  O
HiRes-Relative- See IEEE Std 11073-20601.  O
Time
Date-and-Time- See IEEE Std 11073-20601.  C
Adjustment
Power-Status onBattery or onMains. R
Battery-Level See IEEE Std 11073-20601.  R
Remaining- See IEEE Std 11073-20601.  R
Battery-Time
Reg-Cert-Data- See IEEE Std 11073-20601.  O
List
System-Type- {MDC_DEV_SPEC_PROFILE_AI_ACTIVITY_HUB,1}. M
Spec-List
Confirm- See IEEE Std 11073-20601.  O
Timeout
NOTE—See IEEE Std 11073-20601 for information on whether an attribute is static or dynamic.
© IEEE 2010 – All rights reserved

In the response to a Get MDS object command, only implemented attributes and their corresponding values
are returned.
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. For an independent living activity hub 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. Then 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 standard and version of that standard.
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-20
...

NORME ISO/
INTERNATIONALE IEEE
11073-10471
Première édition
2010-05-01
Informatique de santé — Communication
entre dispositifs de santé personnels —
Partie 10471:
Spécialisation des dispositifs —
Concentrateur d'activité pour une vie
autonome
Health informatics — Personal health device communication —
Part 10471: Device specialization — Independant living activity hub

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 .2
1.3 Contexte.2
2. Références normatives.2
3. Définitions, acronymes et abréviations .3
3.1 Définitions.3
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 concentrateurs d'activités pour une vie
autonome .5
5.1 Généralités.5
5.2 Concepts.5
5.3 Données collectées.6
6. Modèle d'informations du domaine du concentrateur d'activités pour une vie autonome.8
6.1 Description .8
6.2 Extensions de classes.8
6.3 Diagramme d'instance d'objet .8
6.4 Types de configurations .11
6.5 Objet système de dispositif médical.12
6.6 Objets numériques.16
6.7 Objets groupement d'échantillons en temps réel.16
6.8 Objets énumération .16
6.9 Objets PM-store.29
6.10 Objets Analyseur.29
6.11 Objets extension de classe.29
6.12 Règles d'extensibilité du modèle d'informations d'un concentrateur d'activités pour
une vie autonome.29
7. Modèle de services d'un concentrateur d'activités pour une vie autonome .30
7.1 Généralités.30
7.2 Services d'accès à l'objet.30
7.3 Services de rapport d'événement d'accès à l'objet.32
8. Modèle de communication du concentrateur d'activités pour une vie autonome .32
8.1 Description générale.32
8.2 Caractéristiques de communication.32
8.3 Procédure d'association .33
8.4 Procédure «Configuration» (procédure de configuration) .34
8.5 Procédure «Operating» (procédure de fonctionnement).35
8.6 Synchronisation dans le temps.36
9. Associations pour test.36
9.1 Comportement avec la configuration normalisée .36
9.2 Comportement avec des configurations étendues .36
10. Conformité .36
10.1 Applicabilité.36
10.2 Spécification de conformité.37
© IEEE 2010 – Tous droits réservés iii

10.3 Niveaux de conformité.37
10.4 Déclarations de conformité de la déclaration ICS.37
Annexe A (informative) Bibliographie.43
Annexe B (normative) Toutes les définitions supplémentaires de l'ASN.1.44
Annexe C (normative) Allocation d'identificateurs .47
Annexe D (informative) Exemples de séquences de messages .49
Annexe E (informative) Exemples d'unités de données de protocole.52

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 Standard 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 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-10471 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-10471: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 concentrateurs d'activités pour une vie
autonome. 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-10471:2010(F)

Informatique de santé — Communication entre dispositifs
de santé personnels —
Partie 10471:
Spécialisation des dispositifs — Concentrateur d'activité
pour une vie autonome
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 concentrateurs d'activités pour une vie autonome 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
de l'ISO/IEEE 11073 et des modèles d'informations. 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 dispositifs concentrateurs d'activités
pour une vie autonome. Dans ce contexte, des concentrateurs d'activités pour une vie autonome
sont définis comme des dispositifs qui communiquent avec de simples dispositifs de surveillance de
situation (capteurs binaires), normalisent des informations reçues des simples dispositifs de
surveillance d'environnement et fournissent ces informations normalisées à un ou plusieurs
gestionnaires. Ces informations peuvent être examinées (par exemple) pour déterminer le moment
où les activités ou les comportements d'une personne se sont particulièrement écartés de ce qui
constitue la normale pour eux de telle sorte que des tiers concernés puissent en être informés. Les
concentrateurs d'activités pour une vie autonome normaliseront des informations provenant des
simples dispositifs de surveillance suivants (capteurs binaires) dans le cadre de l'édition initiale de
la norme proposée: capteur de chute, capteur de mouvements, capteur de porte, capteur
d'occupation de lit/chaise, capteur d'interrupteur de lumière, détecteur de fumée, sonde de
température (ambiante) à seuil, système de réponse d'urgence personnel (PERS) et capteur
d'énurésie (lit mouillé).
© IEEE 2010 – Tous droits réservés 1

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 gestionnaires (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é.
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-10471, définit la spécialisation des dispositifs pour le
concentrateur d'activités pour une vie autonome 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 basé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é

Voir l'Annexe A pour toutes les informations référencées par la présente norme.

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

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)
© IEEE 2010 – Tous droits réservés 3

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)

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
concentrateur d'activités pour une vie autonome. 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 concentrateur d'activités pour une vie autonome PHD de l'ISO/IEEE 11073 et un
gestionnaire. La présente norme utilise un sous-ensemble des objets et des fonctionnalités définis
dans l'IEEE 11073-20601 et développe et ajoute des définitions 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 © IEEE 2010 – Tous droits réservés

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.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
concentrateurs d'activités pour une vie autonome
5.1 Généralités
Le présent article présente les concepts généraux relatifs aux dispositifs personnels concentrateurs
d'activité pour une vie autonome. Dans le contexte des dispositifs personnels de santé dans cette
famille de normes, un concentrateur d'activités pour une vie autonome est un dispositif qui
rassemble les événements de capteurs de données d'activité émanant de multiples sources de
données de capteurs, dont toutes sont utilisées dans le soutien de la vie autonome d'un ou plusieurs
occupants. L'environnement des occupants peut varier de manière importante et englober un
mélange divers de capteurs. Par conséquent, les événements de capteurs de données d'activité
rapportées par tout agent particulier présentent une variance correspondante.
5.2 Concepts
Alors qu'il existe de nombreux capteurs de génération de données, ils ont des propriétés communes
qui ont un effet sur la conception de la présente norme. Il faut noter qu'il ne s'agit que de généralités
employées pour la conception et il peut y avoir des cas où un capteur de génération de données
d'activités dépasse ces propriétés.

– Prix: habituellement, il s'agit de capteurs peu coûteux.
– Puissance: généralement, il s'agit des capteurs consommant très peu d'énergie.
– Communication: généralement, ils utilisent une technique de communication peu coûteuse et sont
souvent sans fil.
– Fréquence: généralement, ils communiquent de manière peu fréquente entre eux ou seulement
lorsqu'un événement se produit.
– Quantité: il peut y avoir une large gamme des capteurs disponibles et de nombreuses instances
d'un capteur.
La gestion de tous ces capteurs incombe à l'agent concentrateur d'activités pour une vie autonome.
© IEEE 2010 – Tous droits réservés 5

La gestion de ces capteurs est susceptible de s'inscrire dans le contexte propriétaire propre à l'agent
du fait de l'absence de norme industrielle existante acceptable et du souhait d'intégrer des solutions
antérieures existantes au cadre de travail de base de l'IEEE 11073-20601. Par conséquent, cette
responsabilité est en dehors du domaine d'application de la présente norme. Seule la
communication entre l'agent concentrateur d'activités pour une vie autonome et le gestionnaire est
couverte par la présente norme.

De plus, en raison des nombreux types différents de capteurs qui peuvent être employés dans toute
installation particulière, il existe une gamme de fonctionnalités que l'agent concentrateur d'activités
pour une vie autonome correspondant présente au gestionnaire. D'une part, un agent concentrateur
d'activités pour une vie autonome totalement fonctionnel pourrait présenter un nombre important de
capteurs et entretenir une conversation complexe avec le gestionnaire associé. D'autre part, un
sous-ensemble de ce protocole pourrait être employé par seulement un seul capteur de telle sorte
qu'il apparaîtrait à un gestionnaire comme un agent concentrateur d'activités pour une vie autonome
comportant un seul capteur.
5.3 Données collectées
5.3.1 Généralités
Le présent paragraphe donne un résumé des types de capteurs et de données d'activités qui
pourraient être collectées. Il ne s'agit pas de suggérer que tous les agents concentrateurs d'activités
pour une vie autonome rapporteraient nécessairement des valeurs pour l'ensemble de ces capteurs.
De plus, la présente norme n'est pas concernée par le formulaire de données ni par la
communication entre un capteur réel quelconque et le concentrateur d'activités pour une vie
autonome. Au lieu de cela, seuls les événements de capteurs de données d'activités déduits de ces
données sont considérés comme faisant partie de la présente norme. Voir l'Article 6 pour la
définition normative de ces données déduites.

5.3.2 Capteur de chute
Ce capteur est utilisé pour signaler au système de surveillance qu'un événement de capteur de
chute a eu lieu. Il pourrait prendre la forme d'un capteur de type qui détecte la chute d'une personne
et génère automatiquement l'événement.

5.3.3 Capteur PERS
Ce capteur est utilisé pour signaler au système de surveillance qu'un événement de capteur
d'urgence personnelle a eu lieu. Il prendrait généralement la forme d'un bouton que la personne
enfonce pour indiquer une certaine sorte d'urgence perçue (bouton de panique).

5.3.4 Capteurs d'environnement
Ces capteurs génèrent un événement de capteur à chaque fois qu'ils détectent un aspect de
l'environnement qui dépasse un seuil préétabli. Des exemples comprennent les détecteurs de
fumée, les capteurs de monoxyde de carbone, les capteurs de présence d'eau et les capteurs
de gaz naturel/gaz de pétrole liquéfié (GPL).

5.3.5 Capteur de mouvement
Ce capteur génère un événement de capteur à chaque fois qu'il a détecté un mouvement dans sa
plage au-dessus d'un niveau préétabli.

Ce type de capteur est généralement employé de deux manières: mouvement général et détection
d'intrus.
Dans le cas d'un mouvement général, la détection du mouvement entraîne la génération immédiate
d'un événement de capteur et une action ultérieure.

Ceci peut être utilisé pour suivre le niveau d'activité de l'occupant afin de distinguer si des modèles
de comportement ont été modifiés.

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

Dans le cas de la détection d'intrus, l'événement de capteur de mouvements pourrait être utilisé pour
déclencher des actions de détection d'intrus.

Éventuellement, dans le cas d'entrées principales dans le bâtiment, par exemple, l'action
consécutive à l'événement de capteur peut être retardée pendant un certain intervalle de temps
avant d'être entreprise. Ceci a pour but de permettre à une personne autorisée d'entrer dans les
locaux et de désactiver l'événement de capteur avant que l'action ne soit entreprise (par exemple
dans le cas où un événement de capteur déclenché génère une alerte intrus). Au cas où une
désactivation appropriée n'aurait pas lieu dans le délai de temps imparti, l'action ultérieure normale
aurait lieu. Il peut également s'agir d'un événement de capteur dans le cas où le capteur de
mouvement détecte une personne tentant de neutraliser cette fonction.

5.3.6 Capteur de sortie de la résidence
Ce capteur génère un événement de capteur à chaque fois qu'il a détecté la sortie d'un occupant de
la résidence. Ceci est généralement employé lorsqu'il existe un occupant présentant certains
problèmes cognitifs qui rencontrerait des difficultés dans un environnement non familier. Il peut s'agir
également d'un événement de capteur pour le cas où la sortie de la résidence est restée ouverte.

5.3.7 Capteur d'énurésie
Ce capteur génère un événement de capteur lorsqu'il détecte des événements d'incontinence ou de
lit mouillé. Ce capteur pourrait être utilisé dans une plage de meubles tels qu'un lit, une chaise ou
toute structure similaire.
5.3.8 Capteur de fermeture de contact
Ce capteur émet un événement de capteur à chaque fois qu'un contact est laissé ouvert ou fermé.
Ce capteur rapporte l'état du contact après une transition, soit de l'état fermé à l'état ouvert ou soit
de l'état ouvert à l'état fermé. Un seul événement de capteur est émis pour chaque transition. Des
exemples de l'endroit où ce capteur pourrait être déployé sont des portes dans des passages, des
portes d'armoire, des tiroirs, des fenêtres et des tapis détecteurs.

5.3.9 Capteur d'utilisation
Ce capteur émet un événement de capteur pour indiquer le début d'utilisation (par exemple, se
coucher dans un lit/s'asseoir dans une chaise par exemple) ou la fin de l'utilisation (sortir d'un lit ou
se lever d'une chaise, par exemple). Il émet également un événement de capteur pour une utilisation
anticipée ne survenant pas avant un instant préétabli attendu (violation de début d'utilisation
attendu) de même qu'un événement de capteur pour une utilisation se poursuivant au-delà d'un
temps préétabli attendu (violation d'arrêt d'utilisation attendu). De plus, il pourrait s'agir d'un
événement de capteur généré si au-delà d'un temps d'utilisation attendu, l'utilisation est interrompue
pendant plus longtemps qu'un intervalle de temps établi (violation d'absence par intermittence). Un
exemple serait qu'au cours d'une période normale de sommeil, une personne quitterait son lit et n'y
retournerait pas dans un intervalle de temps attendu.

5.3.10 Capteur d'utilisation d'interrupteurs
Le capteur émet un événement de capteur pour un interrupteur changeant d'état, en passant soit de
l'état utilisé (fermé) soit à l'état non utilisé (ouvert). Les exemples sont des interrupteurs de lumière,
des interrupteurs de ventilateurs et d'autres interrupteurs similaires qui commandent des appareils
électriques.
5.3.11 Simple distributeur de médicaments
Le distributeur est un récipient qui contient des doses d'un ou plusieurs médicaments. Les
médicaments doivent être pris à des doses prédéterminées à des intervalles de temps
prédéterminés. Un événement de capteur est généré pour une dose présentée qui est issue du
distributeur (dose prise) et/ou pour une dose qui n'est pas prise après un temps prédéterminé (dose
manquée).
NOTE La description du capteur représentée ici est issue d'un modèle conceptuel pour aider à la
compréhension. Il faut être conscient que les mêmes événements de capteur déduits pourraient être générés
par de nombreux autres moyens (par exemple une interaction de l'utilisateur avec certaines interfaces d'écran).
La présente norme est uniquement concernée par les événements de capteurs générés.

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

5.3.12 Capteur de température
Ce capteur surveille la température dans un certain environnement. Il émet des événements de
capteur sur la base de la valeur de capteur en dehors d'une limite de température prédéterminée.
Les événements de capteurs pourraient être que la température ambiante est montée au-delà d'un
certain niveau (niveau de seuil élevé) ou a chuté en dessous d'un certain niveau (niveau de seuil
bas) ou que la vitesse de variation est plus rapide qu'une vitesse escomptée prédéterminée (vitesse
de variation). Ceci peut être utilisé pour détecter des conditions telles que la température d'une
habitation qui est dangereusement haute/basse ou bien que des plaques de cuisson ont été
laissées allumées alors que la cuisson est terminée.

6. Modèle d'informations du domaine du concentrateur
d'activités pour une vie autonome
6.1 Description
Le présent article décrit le modèle d'informations du domaine du concentrateur
d'activités pour une vie autonome.

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 (DIM) du concentrateur
d'activités pour une vie autonome, défini pour les besoins de la présente norme, est représenté à la
Figure 1.
Le modèle DIM générique du concentrateur d'activités pour une vie autonome qui est présenté à la
Figure 1 définit tous les objets de données possibles. Cependant, il est escompté que la plupart des
concentrateurs d'activités pour une vie autonome ne mettent en œuvre qu'un sous-ensemble limité
des objets de données. Un concentrateur d'activités pour une vie autonome doit mettre en œuvre
au moins une instance de capteur.

Les objets du DIM, tels qu'ils sont représentés sur 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), les objets numériques (voir 6.6), les objets
groupement d'échantillons en temps réel (RT-SA) (voir 6.7), les objets énumération (voir 6.8), les
objets PM-store (voir 6.9) et les objets analyseurs (voir 6.10). Voir 6.12 pour les règles d'extension
du modèle d'informations du concentrateur d'activités pour une vie autonome au-delà des éléments
tels que décrits dans la présente norme. Chaque paragraphe qui décrit un objet du concentrateur
d'activités pour une vie autonome 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.

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

– Les attributs de l'objet. Chaque objet a des attributs qui représentent et acheminent des
informations sur le capteur de génération de données d'activités et ses sources de données.
Chaque objet a un attribut Handle (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
en 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 en notation 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 ser
...