ISO/IEEE 11073-20601:2022
Health informatics — Device interoperability — Part 20601: Personal health device communication — Application profile — Optimized exchange protocol
Within the context of the ISO/IEEE 11073 personal health device standard family, this document defines an optimized exchange protocol and modeling techniques to be used by implementers of personal health devices to create interoperability between device types and vendors. This document establishes a common framework for an abstract model of personal health data available in transport-independent transfer syntax required to establish logical connections between systems and to provide presentation capabilities and services needed to perform communication tasks. The protocol is optimized to personal health usage requirements and leverages commonly used methods and tools wherever possible.
| Get this standard | Prices exclude GST | |
|---|---|---|
| PDF ( Single user document) |
$482.63 NZD
|
|
| HardCopy |
$532.13 NZD
|
|
| Networkable PDF |
Price varies
|
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Documents
Translations
Official statements
Comments on standards
Laws and regulations
Copyrights
Photocopies
Updating of IEEE Standards documents
Errata
Patents
1. Overview
1.1 Scope
1.2 Purpose
1.3 Context
1.4 Word usage
2. Normative references
3. Definitions, acronyms, and abbreviations
3.1 Definitions
3.2 Acronyms and abbreviations
4. Guiding principles
a) Personal health agents typically have very limited computing capabilities.
b) Personal health agents typically have a fixed configuration, and they are used with a single manager device.
c) Personal health agents are frequently battery powered, mobile devices, using a wireless communication link. Therefore, energy efficiency of the protocol is an important aspect.
d) Personal health agents are often not permanently active. For example, a weighing scale may provide data only once or twice a day. An efficient connection procedure is needed for minimum overhead for such devices.
e) Personal health managers tend to have more processing power, memory, and storage space so the protocol intentionally places more load on the managers.
f) Personal health agents and managers convey information that could be useful to clinical professionals. As such, the quality of the data may be considered to have clinical merit even if acquired in a personal health or remote monitoring environment.
5. Introduction to IEEE 11073 personal health devices
5.1 General
5.2 Domain information model (DIM)
5.3 Service model
5.4 Communication model
5.5 Compliance with other standards
5.6 Security
6. Personal health device DIM
6.1 General
6.2 Nomenclature usage
6.3 Personal health object class definitions
6.3.1 General
6.3.2 MDS class
6.3.2.1 General
6.3.2.2 MDS class identification
6.3.2.3 MDS class attributes
6.3.2.4 MDS object methods
6.3.2.5 MDS object events
6.3.2.6 Other MDS services
6.3.2.6.1 GET service
6.3.2.6.2 SET service
6.3.3 Metric class
6.3.3.1 General
6.3.3.2 Metric class identification
6.3.3.3 Metric class attributes
6.3.3.4 Metric object methods
6.3.3.5 Metric object events
6.3.3.6 Other metric services
6.3.4 Numeric class
6.3.4.1 General
6.3.4.2 Numeric class identification
6.3.4.3 Numeric class attributes
6.3.4.4 Numeric object methods
6.3.4.5 Numeric object events
6.3.4.6 Other numeric services
6.3.5 RT-SA class
6.3.5.1 General
6.3.5.2 RT-SA class identification
6.3.5.3 RT-SA class attributes
6.3.5.4 RT-SA object methods
6.3.5.5 RT-SA object events
6.3.5.6 Other RT-SA services
6.3.6 Enumeration class
6.3.6.1 General
6.3.6.2 Enumeration class identification
6.3.6.3 Enumeration class attributes
6.3.6.4 Enumeration object methods
6.3.6.5 Enumeration object events
6.3.6.6 Other enumeration services
6.3.7 PM-store class
6.3.7.1 General
6.3.7.2 PM-store class identification
6.3.7.3 PM-store class attributes
6.3.7.4 PM-store object methods
6.3.7.5 PM-store object events
6.3.7.6 Other PM-store services
6.3.7.6.1 GET service
6.3.7.6.2 SET service
6.3.8 PM-segment class
6.3.8.1 General
6.3.8.2 PM-segment class identification
6.3.8.3 PM-segment class attributes
6.3.8.4 PM-segment object methods
6.3.8.5 PM-segment object events
6.3.8.6 Other PM-segment services
6.3.9 Scanner classes
6.3.9.1 General
6.3.9.2 Conceptual model
6.3.9.3 Scanner class
6.3.9.3.1 General
6.3.9.3.2 Scanner class identification
6.3.9.3.3 Scanner class attributes
6.3.9.3.4 Scanner object methods
6.3.9.3.5 Scanner object events
6.3.9.3.6 Other scanner services
6.3.9.4 CfgScanner class
6.3.9.4.1 General
6.3.9.4.2 Configurable scanner class identification
6.3.9.4.3 Configurable scanner class attributes
6.3.9.4.4 Configurable scanner object methods
6.3.9.4.5 Configurable scanner object events
6.3.9.4.6 Other configurable scanner services
6.3.9.5 EpiCfgScanner class
6.3.9.5.1 General
6.3.9.5.2 Episodic configurable scanner class identification
6.3.9.5.3 Episodic configurable scanner class attributes
6.3.9.5.4 Episodic configurable scanner object methods
6.3.9.5.5 Episodic configurable scanner object events
6.3.9.5.6 Other episodic configurable scanner services
6.3.9.6 PeriCfgScanner class
6.3.9.6.1 General
6.3.9.6.2 Periodic configurable scanner object identification
6.3.9.6.3 Periodic configurable scanner object attributes
6.3.9.6.4 Periodic configurable scanner object methods
6.3.9.6.5 Periodic configurable scanner object events
6.3.9.6.6 Other periodic configurable scanner services
6.3.10 PHD DM Status object
6.3.10.1 General
6.3.10.2 PHD DM Status object attributes
6.3.10.3 PHD DM Status object methods
6.3.10.4 PHD DM Status object events
6.3.10.5 Other PHD DM Status services
6.3.11 Schedule-store class
6.3.11.1 General
6.3.11.2 Schedule-store class identification
6.3.11.3 Schedule-store class attributes
6.3.11.4 Schedule-store object methods
6.3.11.5 Schedule-store object events
6.3.11.6 Other Schedule-store services
6.3.11.6.1 GET service
6.3.11.6.2 SET service
6.3.12 Schedule-segment class
6.3.12.1 General
6.3.12.2 Schedule-segment class identification
6.3.12.3 Schedule-segment class attributes
6.3.12.4 Schedule-segment object methods
6.3.12.5 Schedule-segment object events
6.3.12.6 Other schedule-segment object services
6.4 Information model extensibility rules
7. Personal health device service model
7.1 General
7.2 Association service
7.3 Object access services
7.4 Specific application of object access EVENT REPORT services for personal health devices
7.4.1 General
7.4.2 Confirmed and unconfirmed event reports
7.4.3 Configuration event report
7.4.3.1 General
7.4.3.2 Agent device configuration
7.4.3.3 Configuration event report
7.4.3.4 Device specializations
7.4.3.5 Profiles
7.4.3.5.1 General
7.4.3.5.2 DIM constraints
7.4.3.5.3 Service model constraints
7.4.3.5.4 Communication model constraints
7.4.3.6 Types of configuration
7.4.3.6.1 Standard configuration
7.4.3.6.2 Extended configuration
a) The same Dev-Configuration-Id shall not be used by an agent for subsequent associations to identify a different device configuration.
b) An agent should use the same value for Dev-Configuration-Id in future Association Requests with the manager to denote the same configuration of the device.
7.4.4 Agent- and manager-initiated measurement data transmission
7.4.5 Variable, fixed, and grouped format event reports
7.4.6 Single-person and multiple-person event reports
7.4.7 Temporarily stored measurements
8. Communication model
8.1 General
8.2 System context
8.3 Communications characteristics
8.3.1 General
8.3.2 Common communications characteristics
a) An APDU may be processed in any manner (e.g., part by part as the APDU arrives or as a complete buffered APDU in memory), but the APDU shall be processed so that its effects are as an atomic transaction.
b) APDUs may be segmented and reassembled during transport, or they may be sent as a complete unit.
c) APDUs, in the agent-to-manager direction, shall be no larger than 63K (64 512) bytes in size. Specific device specializations, profiles, or implementations may evaluate the messages exchanged to determine a specific implementation size for a manage...
d) APDUs, in the manager-to-agent direction, shall be no larger than 8K (8192) bytes in size. Specific device specializations, profiles, or implementations may evaluate the messages exchanged to determine a specific implementation size for an agent re...
e) The overall length of the APDU shall be passed to and from the communications layers as metadata.
f) The communications layer shall indicate the overall length of the APDU to its peer communications layer.
8.3.3 Reliable communications characteristics
a) APDUs shall be received in the order they are sent.
b) APDUs shall be free of detectable errors.
c) APDUs shall not be duplicated.
d) APDUs shall not be missing.
e) APDUs are generally sent in an expeditious manner, but may be delayed due to retries.
f) The communications layers should provide a mechanism to indicate to the application layer when a complete APDU has been received.
g) The communications layers shall provide a mechanism to indicate to the application layer when a connection path between an agent and a manager is established.
h) The communications layers should provide a mechanism to indicate to the application layer when a connection is terminated or disconnected.
i) The communications layers shall provide a mechanism to indicate to the application layer when it is unable to send an APDU.
j) Flow control between the sending and receiving application shall be supported for complete APDUs. The lower layers may implement flow control for smaller subsets of the APDU.
8.3.4 Best-effort communications characteristics
a) An APDU may not be delivered in the order in which it was sent. It is possible for the communication channel itself, independent of the operation of a personal health device transmitter, to misorder packets.
b) An APDU may be lost or duplicated.
c) APDUs may arrive at a rate that causes buffer exhaustion at the receiver.
8.4 State machines
8.4.1 Agent state machine
8.4.2 Manager state machine
8.4.3 Timeout variables
8.5 Connected procedure
8.5.1 General
8.5.2 Entry conditions
8.5.3 Normal procedures
8.5.4 Exit conditions
8.5.5 Error conditions
8.6 Unassociated procedure
8.6.1 General
8.6.2 Entry conditions
8.6.3 Normal procedures
8.6.4 Exit conditions
8.6.5 Error conditions
8.7 Associating procedure
8.7.1 General
8.7.2 Entry conditions
8.7.3 Normal procedures
8.7.3.1 Agent procedure
8.7.3.1.1 General
8.7.3.1.2 Data-exchange protocol—defined by this standard
8.7.3.1.3 Data-exchange protocol—defined by the manufacturer
8.7.3.2 Association response
8.7.3.3 Manager procedure
8.7.4 Exit conditions
8.7.5 Error conditions
8.7.6 Test association
8.8 Configuring procedure
8.8.1 General
8.8.2 Entry conditions
8.8.3 Normal procedures
8.8.4 Exit conditions
8.8.5 Error conditions
8.9 Operating procedure
8.9.1 General
8.9.2 Entry conditions
8.9.3 Normal procedures
8.9.3.1 General
8.9.3.2 MDS object attributes
8.9.3.3 Measurement data transfer
8.9.3.3.1 General
8.9.3.3.2 Agent-initiated measurement data transmission
8.9.3.3.3 Manager-initiated data request
8.9.3.3.4 Scan report number management
8.9.3.4 Persistently stored metric data transfer
8.9.3.4.1 General
8.9.3.4.2 Persistently stored metric data transmission
a) Retrieving the PM-store attributes. When the agent and manager are in the Operating state, the manager can inspect the configuration negotiated with the agent to determine the number of PM-store objects in the agent. The manager may query each PM-s...
b) Retrieving the ID list of PM-segments. The manager retrieves information on the segments in a PM-store by sending an ACTION.Get-Segment-Id-List command to the specific PM-store (see Figure 19). The agent responds to the ACTION.Get-Segment-Id-List c...
c) Retrieving the PM-segment information. The manager retrieves information on the segments in a PM-store by sending an ACTION.Get-Segment-Info command to the specific PM-store (see Figure 20) with a request to return information from all segments, a ...
d) Transferring PM-segment content. The manager retrieves specific PM-segments by using the Trig-Segment-Data-Xfer ACTION method to initiate the data transfer (see Figure 21). In the first step, the manager sends the ACTION method to the agent with th...
e) Clear a PM-segment. The agent may support PM-segment clearing. The manager determines whether the agent supports any of the clearing functions by inspecting the pmsc-clear-segm-all-sup, pmsc-clear-segm-by-list-sup, and pmsc-clear-segm-by-time-sup f...
8.9.3.5 Schedule-stored information retrieval
8.9.3.5.1 General
8.9.3.5.2 Schedule-stored information retrieval
a) Retrieving the schedule-store attributes. When the agent and manager are in the Operating state, the manager can inspect the configuration negotiated with the agent to determine the number of schedule-store objects in the agent. The manager may que...
b) Retrieving the ID list of schedule-segments. The manager retrieves information on the segments in a schedule-store by sending an ACTION.Get-Schedule-Segment-Id-List command to the specific schedule-store. The agent responds to the ACTION.Get-Schedu...
c) Retrieving the schedule-segment information. The manager retrieves information on the segments in a schedule-store by sending an ACTION.Get-Schedule-Segment-Info command to the specific schedule-store (see Figure 24) with a request to return inform...
d) If the manager invokes the Get-Schedule-Segment-Info method but the agent does not support the specified choice, then the agent shall respond with a roer DataApdu with a RoerErrorValue of “unsupported-choice”.
e) Transfer schedule-segment content. The manager retrieves specific schedule-segments by using the Trig-Schedule-Segment-Data-Xfer ACTION method to initiate the data transfer (see Figure 25). In the first step, the manager sends the ACTION method to ...
8.9.4 Exit conditions
8.9.5 Error conditions
8.9.5.1 General
8.9.5.2 Confirmed Action
8.9.5.3 Confirmed Event Report
8.9.5.4 Get
8.9.5.5 Confirmed Set
8.9.5.6 Special timeouts
8.10 Disassociating procedure
8.10.1 General
8.10.2 Entry conditions
8.10.3 Normal procedures
8.10.4 Exit conditions
8.10.5 Error conditions
8.11 Message encoding
8.12 Time coordination
8.12.1 General
8.12.2 Absolute time
8.12.2.1 General
8.12.2.2 Comparable time
8.12.3 Base time with offset
8.12.4 Relative time
8.12.5 High-resolution relative time
9. Conformance model
9.1 Applicability
9.2 Conformance specification
9.3 Implementation conformance statements (ICSs)
9.4 General conformance
9.4.1 General ICS
9.4.2 Minimum requirements ICS
9.4.3 Service support ICS
9.5 Device additions/extensions ICS
9.5.1 General additions/extensions ICS
9.5.2 Personal health device DIM object and class (POC) ICS
9.5.3 POC attribute ICS
9.5.4 POC behavior ICS
9.5.5 POC notification ICS
9.5.6 POC nomenclature ICS
Annex A (normative) ASN.1 definitions
A.1 General
A.2 Common data types
A.2.1 Integer and bit string data types
A.2.2 Identification data type
A.2.3 Handle data type
A.2.4 Instance number data type
A.2.5 Type ID data type
A.2.6 Attribute value assertion (AVA) data type
A.2.7 Attribute list data type
A.2.8 Attribute ID list data type
A.2.9 Floating point type (FLOAT-Type) data type
A.2.10 Short floating point type (SFLOAT-Type) data type
A.2.11 Relative time data type
A.2.12 High-resolution relative time data type
A.2.13 Absolute time data type
A.2.14 Base time with offset data type
A.2.15 Operational state data type
A.3 Attribute data types
A.3.1 MDS attributes
A.3.2 Metric attributes
A.3.3 Numeric attributes
A.3.4 RT-SA attributes
A.3.5 Enumeration attributes
A.3.6 Scanner attributes
A.3.7 Configurable scanner attributes
A.3.8 Episodic configurable scanner attributes
A.3.9 Periodic configurable scanner attributes
A.3.10 PM-store and PM-segment attributes
A.3.11 PHD DM Status attributes
A.4 ACTION-method-related data types
A.5 Message-related data types
A.6 Other
A.7 Personal health device protocol frame
A.8 Association protocol definitions
A.9 Presentation protocol definitions
A.10 Data protocol definitions
A.10.1 General
A.10.2 Data protocol frame
A.10.3 EVENT REPORT service
A.10.4 GET service
A.10.5 SET service
A.10.6 ACTION service
A.11 Data types for new object attributes and object services
A.11.1 General data types
A.11.2 MDS-related data types
A.11.3 Metric-related data types
A.11.4 Scanner-related data types
A.11.5 MDS services
A.11.6 Scanner services
A.11.7 Numeric-related data types
A.11.8 PM-store and PM-segment related data types
A.11.9 Schedule store and schedule-segment related data types
Annex B (informative) Scale and range specification example
B.1 General
B.2 Thermometer example
Annex C (informative) The PM-store concept
C.1 General
C.2 Persistent metric (PM) store object hierarchy
C.2.1 General
C.2.2 PM-store object
C.2.3 PM-segment object
C.2.4 PM-segment entry (within the fixed-segment-data)
C.2.5 PM-segment entry element
Annex D (informative) Transport profile types
D.1 General
D.2 Type 1
D.3 Type 2
D.4 Type 3
D.4.1 General
D.4.2 Type 3a
D.4.3 Type 3b
D.4.4 Type 3c
D.5 Summary
Annex E (normative) State tables
E.1 General
E.2 Events
E.3 Agent state table
E.4 Manager state table
Annex F (normative) Medical device encoding rules (MDER)
F.1 General
F.2 Supported ASN.1 syntax
F.3 Byte order
1) Representation in diagrams uses the NBO format shown in Figure F.1.
2) No alignment is used in MDER. In other words, additional bytes are not added to byte strings, e.g., to obtain lengths that are divisible by two or four. However, variable-length data items, i.e., strings, should have an even length for performance ...
3) MDAP communicants are restricted to using the NBO (big-endian) convention.
4) The association protocol shall use ISO MDER to provide for universal interoperability during negotiation of MDER conventions. All other PDUs exchanged in the life cycle of device-host communication will be based in MDER, e.g., CMIP* and ROSE* PDUs....
F.4 Encodings
F.4.1 General
F.4.2 INTEGER
F.4.3 BIT STRING
F.4.4 OCTET STRING
F.4.5 SEQUENCE
F.4.6 SEQUENCE OF
F.4.7 CHOICE
F.4.8 ANY DEFINED BY and instance-of
F.5 Floating point numbers
F.6 Floating point data structure—FLOAT-Type
F.7 Short floating point data structure—SFLOAT-Type
F.8 Expression of precision of floating point numbers
Annex G (informative) Encoded data type definitions
Annex H (informative) Examples
H.1 General
H.2 Weighing scale
H.2.1 Association
H.2.1.1 Association request
H.2.1.2 Association response
H.2.2 Configuration information exchange
H.2.2.1 Remote operation invoke event report configuration
H.2.2.2 Remote operation response event report configuration
H.2.3 GET MDS attributes service
H.2.3.1 General
H.2.3.2 Get all MDS attributes request
H.2.3.3 Get response with all MDS attributes
H.2.4 Data reporting
H.2.4.1 Agent-initiated measurement data transmission
H.2.4.2 Response to agent-initiated measurement data transmission
H.2.4.3 Remote operation invoke confirmed action data request
H.2.4.4 Remote operation response confirmed action data request
H.3 Pulse oximeter
H.3.1 General
H.3.2 Initial conditions
H.3.3 Every 10th message
H.4 PM-store and PM-segment transactions
H.4.1 General
H.4.2 Configuration message
H.4.3 Manager invokes Get-Segment-Info ACTION
H.4.4 Agent responds to Get-Segment-Info with SegmentInfoList
H.4.5 Manager initiates transfer with Trig-SegmData-Xfer ACTION requesting segment 1 data
H.4.6 Agent responds to Trig-Seg-Data-Transfer
H.4.7 Agent sends first block of PM-segment measurements via Segment-Data-Event reports
H.4.8 Manager confirms reception of first block
H.4.9 Agent sends second block of PM-segment measurements
H.4.10 Manager confirms reception of second block
H.4.11 Agent sends last block of PM-segment measurements
H.4.12 Manager confirms reception of last block
H.4.13 Manager clears the PM-segment
H.4.14 Agent deletes segment and responds to manager
Annex I (normative) Nomenclature codes
Annex J (informative) Derivation and modification history
J.1 General
J.2 ASN.1 structures
J.3 Medical device encoding rules (MDER)
J.4 Nomenclature codes
J.4.1 General
J.4.2 Partition codes
J.4.3 Object infrastructure codes
J.4.3.1 MDC_MOC
J.4.3.2 MDC_ATTR
J.4.3.3 MDC_ACT
J.4.3.4 MDC_NOTI
J.4.3.5 MDC_RET_CODE
J.4.4 Medical supervisory control and data acquisition
J.4.5 Dimension codes
J.4.6 Communication infrastructure codes
J.4.6.1 MDC_DEV_SPEC_PROFILE
J.4.6.2 MDC_TIME_SYNC
Annex K (informative) The schedule-store concept
K.1 General
K.2 Schedule-store object hierarchy
K.2.1 General
K.2.2 Schedule-store object
K.2.3 Schedule-segment object
K.2.4 Schedule-segment entry (within the fixed segment data)
K.2.5 Schedule-segment entry element
Annex L (informative) Revision history
Annex M (informative) Bibliography
Blank Page
Previous versions
Keep me up-to-date
Sign up to receive updates when there are changes to this standard
Related Information
Similar Standards
-
BS 30440:2023
Validation framework for the use of artificial intelligence (AI) within healthcare. Specification
-
BS 8684:2024
Technology enabled care. Assessment of user needs and risks, system design, installation and maintenance. Code of practice
-
BS EN 1064:2020
Health informatics. Standard communication protocol. Computer-assisted electrocardiography
-
BS EN 1068:2005
Health informatics. Registration of coding systems
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards Documents
Translations
Official statements
Comments on standards
Laws and regulations
Copyrights
Photocopies
Updating of IEEE Standards documents
Errata
Patents
1. Overview
1.1 Scope
1.2 Purpose
1.3 Context
1.4 Word usage
2. Normative references
3. Definitions, acronyms, and abbreviations
3.1 Definitions
3.2 Acronyms and abbreviations
4. Guiding principles
a) Personal health agents typically have very limited computing capabilities.
b) Personal health agents typically have a fixed configuration, and they are used with a single manager device.
c) Personal health agents are frequently battery powered, mobile devices, using a wireless communication link. Therefore, energy efficiency of the protocol is an important aspect.
d) Personal health agents are often not permanently active. For example, a weighing scale may provide data only once or twice a day. An efficient connection procedure is needed for minimum overhead for such devices.
e) Personal health managers tend to have more processing power, memory, and storage space so the protocol intentionally places more load on the managers.
f) Personal health agents and managers convey information that could be useful to clinical professionals. As such, the quality of the data may be considered to have clinical merit even if acquired in a personal health or remote monitoring environment.
5. Introduction to IEEE 11073 personal health devices
5.1 General
5.2 Domain information model (DIM)
5.3 Service model
5.4 Communication model
5.5 Compliance with other standards
5.6 Security
6. Personal health device DIM
6.1 General
6.2 Nomenclature usage
6.3 Personal health object class definitions
6.3.1 General
6.3.2 MDS class
6.3.2.1 General
6.3.2.2 MDS class identification
6.3.2.3 MDS class attributes
6.3.2.4 MDS object methods
6.3.2.5 MDS object events
6.3.2.6 Other MDS services
6.3.2.6.1 GET service
6.3.2.6.2 SET service
6.3.3 Metric class
6.3.3.1 General
6.3.3.2 Metric class identification
6.3.3.3 Metric class attributes
6.3.3.4 Metric object methods
6.3.3.5 Metric object events
6.3.3.6 Other metric services
6.3.4 Numeric class
6.3.4.1 General
6.3.4.2 Numeric class identification
6.3.4.3 Numeric class attributes
6.3.4.4 Numeric object methods
6.3.4.5 Numeric object events
6.3.4.6 Other numeric services
6.3.5 RT-SA class
6.3.5.1 General
6.3.5.2 RT-SA class identification
6.3.5.3 RT-SA class attributes
6.3.5.4 RT-SA object methods
6.3.5.5 RT-SA object events
6.3.5.6 Other RT-SA services
6.3.6 Enumeration class
6.3.6.1 General
6.3.6.2 Enumeration class identification
6.3.6.3 Enumeration class attributes
6.3.6.4 Enumeration object methods
6.3.6.5 Enumeration object events
6.3.6.6 Other enumeration services
6.3.7 PM-store class
6.3.7.1 General
6.3.7.2 PM-store class identification
6.3.7.3 PM-store class attributes
6.3.7.4 PM-store object methods
6.3.7.5 PM-store object events
6.3.7.6 Other PM-store services
6.3.7.6.1 GET service
6.3.7.6.2 SET service
6.3.8 PM-segment class
6.3.8.1 General
6.3.8.2 PM-segment class identification
6.3.8.3 PM-segment class attributes
6.3.8.4 PM-segment object methods
6.3.8.5 PM-segment object events
6.3.8.6 Other PM-segment services
6.3.9 Scanner classes
6.3.9.1 General
6.3.9.2 Conceptual model
6.3.9.3 Scanner class
6.3.9.3.1 General
6.3.9.3.2 Scanner class identification
6.3.9.3.3 Scanner class attributes
6.3.9.3.4 Scanner object methods
6.3.9.3.5 Scanner object events
6.3.9.3.6 Other scanner services
6.3.9.4 CfgScanner class
6.3.9.4.1 General
6.3.9.4.2 Configurable scanner class identification
6.3.9.4.3 Configurable scanner class attributes
6.3.9.4.4 Configurable scanner object methods
6.3.9.4.5 Configurable scanner object events
6.3.9.4.6 Other configurable scanner services
6.3.9.5 EpiCfgScanner class
6.3.9.5.1 General
6.3.9.5.2 Episodic configurable scanner class identification
6.3.9.5.3 Episodic configurable scanner class attributes
6.3.9.5.4 Episodic configurable scanner object methods
6.3.9.5.5 Episodic configurable scanner object events
6.3.9.5.6 Other episodic configurable scanner services
6.3.9.6 PeriCfgScanner class
6.3.9.6.1 General
6.3.9.6.2 Periodic configurable scanner object identification
6.3.9.6.3 Periodic configurable scanner object attributes
6.3.9.6.4 Periodic configurable scanner object methods
6.3.9.6.5 Periodic configurable scanner object events
6.3.9.6.6 Other periodic configurable scanner services
6.3.10 PHD DM Status object
6.3.10.1 General
6.3.10.2 PHD DM Status object attributes
6.3.10.3 PHD DM Status object methods
6.3.10.4 PHD DM Status object events
6.3.10.5 Other PHD DM Status services
6.3.11 Schedule-store class
6.3.11.1 General
6.3.11.2 Schedule-store class identification
6.3.11.3 Schedule-store class attributes
6.3.11.4 Schedule-store object methods
6.3.11.5 Schedule-store object events
6.3.11.6 Other Schedule-store services
6.3.11.6.1 GET service
6.3.11.6.2 SET service
6.3.12 Schedule-segment class
6.3.12.1 General
6.3.12.2 Schedule-segment class identification
6.3.12.3 Schedule-segment class attributes
6.3.12.4 Schedule-segment object methods
6.3.12.5 Schedule-segment object events
6.3.12.6 Other schedule-segment object services
6.4 Information model extensibility rules
7. Personal health device service model
7.1 General
7.2 Association service
7.3 Object access services
7.4 Specific application of object access EVENT REPORT services for personal health devices
7.4.1 General
7.4.2 Confirmed and unconfirmed event reports
7.4.3 Configuration event report
7.4.3.1 General
7.4.3.2 Agent device configuration
7.4.3.3 Configuration event report
7.4.3.4 Device specializations
7.4.3.5 Profiles
7.4.3.5.1 General
7.4.3.5.2 DIM constraints
7.4.3.5.3 Service model constraints
7.4.3.5.4 Communication model constraints
7.4.3.6 Types of configuration
7.4.3.6.1 Standard configuration
7.4.3.6.2 Extended configuration
a) The same Dev-Configuration-Id shall not be used by an agent for subsequent associations to identify a different device configuration.
b) An agent should use the same value for Dev-Configuration-Id in future Association Requests with the manager to denote the same configuration of the device.
7.4.4 Agent- and manager-initiated measurement data transmission
7.4.5 Variable, fixed, and grouped format event reports
7.4.6 Single-person and multiple-person event reports
7.4.7 Temporarily stored measurements
8. Communication model
8.1 General
8.2 System context
8.3 Communications characteristics
8.3.1 General
8.3.2 Common communications characteristics
a) An APDU may be processed in any manner (e.g., part by part as the APDU arrives or as a complete buffered APDU in memory), but the APDU shall be processed so that its effects are as an atomic transaction.
b) APDUs may be segmented and reassembled during transport, or they may be sent as a complete unit.
c) APDUs, in the agent-to-manager direction, shall be no larger than 63K (64 512) bytes in size. Specific device specializations, profiles, or implementations may evaluate the messages exchanged to determine a specific implementation size for a manage...
d) APDUs, in the manager-to-agent direction, shall be no larger than 8K (8192) bytes in size. Specific device specializations, profiles, or implementations may evaluate the messages exchanged to determine a specific implementation size for an agent re...
e) The overall length of the APDU shall be passed to and from the communications layers as metadata.
f) The communications layer shall indicate the overall length of the APDU to its peer communications layer.
8.3.3 Reliable communications characteristics
a) APDUs shall be received in the order they are sent.
b) APDUs shall be free of detectable errors.
c) APDUs shall not be duplicated.
d) APDUs shall not be missing.
e) APDUs are generally sent in an expeditious manner, but may be delayed due to retries.
f) The communications layers should provide a mechanism to indicate to the application layer when a complete APDU has been received.
g) The communications layers shall provide a mechanism to indicate to the application layer when a connection path between an agent and a manager is established.
h) The communications layers should provide a mechanism to indicate to the application layer when a connection is terminated or disconnected.
i) The communications layers shall provide a mechanism to indicate to the application layer when it is unable to send an APDU.
j) Flow control between the sending and receiving application shall be supported for complete APDUs. The lower layers may implement flow control for smaller subsets of the APDU.
8.3.4 Best-effort communications characteristics
a) An APDU may not be delivered in the order in which it was sent. It is possible for the communication channel itself, independent of the operation of a personal health device transmitter, to misorder packets.
b) An APDU may be lost or duplicated.
c) APDUs may arrive at a rate that causes buffer exhaustion at the receiver.
8.4 State machines
8.4.1 Agent state machine
8.4.2 Manager state machine
8.4.3 Timeout variables
8.5 Connected procedure
8.5.1 General
8.5.2 Entry conditions
8.5.3 Normal procedures
8.5.4 Exit conditions
8.5.5 Error conditions
8.6 Unassociated procedure
8.6.1 General
8.6.2 Entry conditions
8.6.3 Normal procedures
8.6.4 Exit conditions
8.6.5 Error conditions
8.7 Associating procedure
8.7.1 General
8.7.2 Entry conditions
8.7.3 Normal procedures
8.7.3.1 Agent procedure
8.7.3.1.1 General
8.7.3.1.2 Data-exchange protocol—defined by this standard
8.7.3.1.3 Data-exchange protocol—defined by the manufacturer
8.7.3.2 Association response
8.7.3.3 Manager procedure
8.7.4 Exit conditions
8.7.5 Error conditions
8.7.6 Test association
8.8 Configuring procedure
8.8.1 General
8.8.2 Entry conditions
8.8.3 Normal procedures
8.8.4 Exit conditions
8.8.5 Error conditions
8.9 Operating procedure
8.9.1 General
8.9.2 Entry conditions
8.9.3 Normal procedures
8.9.3.1 General
8.9.3.2 MDS object attributes
8.9.3.3 Measurement data transfer
8.9.3.3.1 General
8.9.3.3.2 Agent-initiated measurement data transmission
8.9.3.3.3 Manager-initiated data request
8.9.3.3.4 Scan report number management
8.9.3.4 Persistently stored metric data transfer
8.9.3.4.1 General
8.9.3.4.2 Persistently stored metric data transmission
a) Retrieving the PM-store attributes. When the agent and manager are in the Operating state, the manager can inspect the configuration negotiated with the agent to determine the number of PM-store objects in the agent. The manager may query each PM-s...
b) Retrieving the ID list of PM-segments. The manager retrieves information on the segments in a PM-store by sending an ACTION.Get-Segment-Id-List command to the specific PM-store (see Figure 19). The agent responds to the ACTION.Get-Segment-Id-List c...
c) Retrieving the PM-segment information. The manager retrieves information on the segments in a PM-store by sending an ACTION.Get-Segment-Info command to the specific PM-store (see Figure 20) with a request to return information from all segments, a ...
d) Transferring PM-segment content. The manager retrieves specific PM-segments by using the Trig-Segment-Data-Xfer ACTION method to initiate the data transfer (see Figure 21). In the first step, the manager sends the ACTION method to the agent with th...
e) Clear a PM-segment. The agent may support PM-segment clearing. The manager determines whether the agent supports any of the clearing functions by inspecting the pmsc-clear-segm-all-sup, pmsc-clear-segm-by-list-sup, and pmsc-clear-segm-by-time-sup f...
8.9.3.5 Schedule-stored information retrieval
8.9.3.5.1 General
8.9.3.5.2 Schedule-stored information retrieval
a) Retrieving the schedule-store attributes. When the agent and manager are in the Operating state, the manager can inspect the configuration negotiated with the agent to determine the number of schedule-store objects in the agent. The manager may que...
b) Retrieving the ID list of schedule-segments. The manager retrieves information on the segments in a schedule-store by sending an ACTION.Get-Schedule-Segment-Id-List command to the specific schedule-store. The agent responds to the ACTION.Get-Schedu...
c) Retrieving the schedule-segment information. The manager retrieves information on the segments in a schedule-store by sending an ACTION.Get-Schedule-Segment-Info command to the specific schedule-store (see Figure 24) with a request to return inform...
d) If the manager invokes the Get-Schedule-Segment-Info method but the agent does not support the specified choice, then the agent shall respond with a roer DataApdu with a RoerErrorValue of “unsupported-choice”.
e) Transfer schedule-segment content. The manager retrieves specific schedule-segments by using the Trig-Schedule-Segment-Data-Xfer ACTION method to initiate the data transfer (see Figure 25). In the first step, the manager sends the ACTION method to ...
8.9.4 Exit conditions
8.9.5 Error conditions
8.9.5.1 General
8.9.5.2 Confirmed Action
8.9.5.3 Confirmed Event Report
8.9.5.4 Get
8.9.5.5 Confirmed Set
8.9.5.6 Special timeouts
8.10 Disassociating procedure
8.10.1 General
8.10.2 Entry conditions
8.10.3 Normal procedures
8.10.4 Exit conditions
8.10.5 Error conditions
8.11 Message encoding
8.12 Time coordination
8.12.1 General
8.12.2 Absolute time
8.12.2.1 General
8.12.2.2 Comparable time
8.12.3 Base time with offset
8.12.4 Relative time
8.12.5 High-resolution relative time
9. Conformance model
9.1 Applicability
9.2 Conformance specification
9.3 Implementation conformance statements (ICSs)
9.4 General conformance
9.4.1 General ICS
9.4.2 Minimum requirements ICS
9.4.3 Service support ICS
9.5 Device additions/extensions ICS
9.5.1 General additions/extensions ICS
9.5.2 Personal health device DIM object and class (POC) ICS
9.5.3 POC attribute ICS
9.5.4 POC behavior ICS
9.5.5 POC notification ICS
9.5.6 POC nomenclature ICS
Annex A (normative) ASN.1 definitions
A.1 General
A.2 Common data types
A.2.1 Integer and bit string data types
A.2.2 Identification data type
A.2.3 Handle data type
A.2.4 Instance number data type
A.2.5 Type ID data type
A.2.6 Attribute value assertion (AVA) data type
A.2.7 Attribute list data type
A.2.8 Attribute ID list data type
A.2.9 Floating point type (FLOAT-Type) data type
A.2.10 Short floating point type (SFLOAT-Type) data type
A.2.11 Relative time data type
A.2.12 High-resolution relative time data type
A.2.13 Absolute time data type
A.2.14 Base time with offset data type
A.2.15 Operational state data type
A.3 Attribute data types
A.3.1 MDS attributes
A.3.2 Metric attributes
A.3.3 Numeric attributes
A.3.4 RT-SA attributes
A.3.5 Enumeration attributes
A.3.6 Scanner attributes
A.3.7 Configurable scanner attributes
A.3.8 Episodic configurable scanner attributes
A.3.9 Periodic configurable scanner attributes
A.3.10 PM-store and PM-segment attributes
A.3.11 PHD DM Status attributes
A.4 ACTION-method-related data types
A.5 Message-related data types
A.6 Other
A.7 Personal health device protocol frame
A.8 Association protocol definitions
A.9 Presentation protocol definitions
A.10 Data protocol definitions
A.10.1 General
A.10.2 Data protocol frame
A.10.3 EVENT REPORT service
A.10.4 GET service
A.10.5 SET service
A.10.6 ACTION service
A.11 Data types for new object attributes and object services
A.11.1 General data types
A.11.2 MDS-related data types
A.11.3 Metric-related data types
A.11.4 Scanner-related data types
A.11.5 MDS services
A.11.6 Scanner services
A.11.7 Numeric-related data types
A.11.8 PM-store and PM-segment related data types
A.11.9 Schedule store and schedule-segment related data types
Annex B (informative) Scale and range specification example
B.1 General
B.2 Thermometer example
Annex C (informative) The PM-store concept
C.1 General
C.2 Persistent metric (PM) store object hierarchy
C.2.1 General
C.2.2 PM-store object
C.2.3 PM-segment object
C.2.4 PM-segment entry (within the fixed-segment-data)
C.2.5 PM-segment entry element
Annex D (informative) Transport profile types
D.1 General
D.2 Type 1
D.3 Type 2
D.4 Type 3
D.4.1 General
D.4.2 Type 3a
D.4.3 Type 3b
D.4.4 Type 3c
D.5 Summary
Annex E (normative) State tables
E.1 General
E.2 Events
E.3 Agent state table
E.4 Manager state table
Annex F (normative) Medical device encoding rules (MDER)
F.1 General
F.2 Supported ASN.1 syntax
F.3 Byte order
1) Representation in diagrams uses the NBO format shown in Figure F.1.
2) No alignment is used in MDER. In other words, additional bytes are not added to byte strings, e.g., to obtain lengths that are divisible by two or four. However, variable-length data items, i.e., strings, should have an even length for performance ...
3) MDAP communicants are restricted to using the NBO (big-endian) convention.
4) The association protocol shall use ISO MDER to provide for universal interoperability during negotiation of MDER conventions. All other PDUs exchanged in the life cycle of device-host communication will be based in MDER, e.g., CMIP* and ROSE* PDUs....
F.4 Encodings
F.4.1 General
F.4.2 INTEGER
F.4.3 BIT STRING
F.4.4 OCTET STRING
F.4.5 SEQUENCE
F.4.6 SEQUENCE OF
F.4.7 CHOICE
F.4.8 ANY DEFINED BY and instance-of
F.5 Floating point numbers
F.6 Floating point data structure—FLOAT-Type
F.7 Short floating point data structure—SFLOAT-Type
F.8 Expression of precision of floating point numbers
Annex G (informative) Encoded data type definitions
Annex H (informative) Examples
H.1 General
H.2 Weighing scale
H.2.1 Association
H.2.1.1 Association request
H.2.1.2 Association response
H.2.2 Configuration information exchange
H.2.2.1 Remote operation invoke event report configuration
H.2.2.2 Remote operation response event report configuration
H.2.3 GET MDS attributes service
H.2.3.1 General
H.2.3.2 Get all MDS attributes request
H.2.3.3 Get response with all MDS attributes
H.2.4 Data reporting
H.2.4.1 Agent-initiated measurement data transmission
H.2.4.2 Response to agent-initiated measurement data transmission
H.2.4.3 Remote operation invoke confirmed action data request
H.2.4.4 Remote operation response confirmed action data request
H.3 Pulse oximeter
H.3.1 General
H.3.2 Initial conditions
H.3.3 Every 10th message
H.4 PM-store and PM-segment transactions
H.4.1 General
H.4.2 Configuration message
H.4.3 Manager invokes Get-Segment-Info ACTION
H.4.4 Agent responds to Get-Segment-Info with SegmentInfoList
H.4.5 Manager initiates transfer with Trig-SegmData-Xfer ACTION requesting segment 1 data
H.4.6 Agent responds to Trig-Seg-Data-Transfer
H.4.7 Agent sends first block of PM-segment measurements via Segment-Data-Event reports
H.4.8 Manager confirms reception of first block
H.4.9 Agent sends second block of PM-segment measurements
H.4.10 Manager confirms reception of second block
H.4.11 Agent sends last block of PM-segment measurements
H.4.12 Manager confirms reception of last block
H.4.13 Manager clears the PM-segment
H.4.14 Agent deletes segment and responds to manager
Annex I (normative) Nomenclature codes
Annex J (informative) Derivation and modification history
J.1 General
J.2 ASN.1 structures
J.3 Medical device encoding rules (MDER)
J.4 Nomenclature codes
J.4.1 General
J.4.2 Partition codes
J.4.3 Object infrastructure codes
J.4.3.1 MDC_MOC
J.4.3.2 MDC_ATTR
J.4.3.3 MDC_ACT
J.4.3.4 MDC_NOTI
J.4.3.5 MDC_RET_CODE
J.4.4 Medical supervisory control and data acquisition
J.4.5 Dimension codes
J.4.6 Communication infrastructure codes
J.4.6.1 MDC_DEV_SPEC_PROFILE
J.4.6.2 MDC_TIME_SYNC
Annex K (informative) The schedule-store concept
K.1 General
K.2 Schedule-store object hierarchy
K.2.1 General
K.2.2 Schedule-store object
K.2.3 Schedule-segment object
K.2.4 Schedule-segment entry (within the fixed segment data)
K.2.5 Schedule-segment entry element
Annex L (informative) Revision history
Annex M (informative) Bibliography
Blank Page