IEEE 11073-10407-2010 pdf download

IEEE 11073-10407-2010 pdf download.Health informatics一Personal health device communication -Part 10407:Device specialization – Blood pressure monitor.
6. Blood pressure monitor domain information model
6.1 Overview
This clause describes the domain information model of the blood pressure monitor.
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 blood pressure monitor domain information model, which is defined for the purposes of this standard, is shown in Figure 1.
The objects of the DIM, as shown in Figure 1, are described in 6.4 to 6.12. This includes the medical device system (MDS) object (see 6.5), the numeric objects (see 6.6), the real-time sample array (RT-SA) objects (see 1.1), the enumeration objects (see 1.1), the PM-store objects (see 6.9), and the scanner objects (see 6. 1 0). See 6. 11 for rules for extending the blood pressure monitor information model beyond elements as described in this standard. Each clause that describes an object of the blood pressure monitor 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 physical device and its data sources. Each object has a Handle attribute that identifies the object instance within an agent. Attribute values are accessed and modified using methods such as GET and SET. Attribute types are defined using an 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 0 — Attribute is Optional. Mandatory attributes shall be implemented by an 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 on an agent.
The attributes can be either static, meaning that they shall remain unchanged after the configuration is agreed upon, or dynamic, meaning that the attribute may change at some point after configuration.
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.
6.4.2 Standard configuration
Standard configurations arc defined in the IEEE 1 1073-lO4zz specializations (such as this standard) and are assigned a well-known identifier (Dev-Configuration-Id). The usage of a standard configuration is negotiated at association time between the agent and the manager. If the manager acknowledges that it recognizes and wants to operate using the configuration, then the agent can begin sending measurements immediately. If the manager does not recognize the configuration, the agent provides the configuration prior to transmitting measurement information.
6.4.3 Extended configuration
In extended configurations, the agent’s configuration is not predefined in a standard. The agent determines 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 needs to send the 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.