IEEE 11073-10408-2010 pdf download
IEEE 11073-10408-2010 pdf download.Health informatics – – Personal health device communication -Part 10408:Device specialization – – – Thermometer.
thermometers measure the temperature of the tympanum by infrared measurement, which is noncontact and immediate. Unless relevant, the method used to determine temperature is ignored in this standard.
Thermometers may be designed for specialist monitoring purposes. For example, thermometers embedded in capsules may be swallowed and their data transmitted for monitoring during periods of high physical activity for signs of overheating.
Measurements may be taken at the extremities of the body (fingers. toes) and would typically be used to monitor for signs of problems due to circulation or hypothermia.
5.2 Body temperature
This standard assumes that a temperature measurement is normally taken as representative of the core body temperature, and therefore, the actual site of its measurement is not relevant. For this reason, the type attribute for the temperature object in the standard configuration is set to generic body temperature.
When the site or the method is significant, this will be indicated by use of a separate type for the temperature in an extended configuration.
The main units used in medicine are the Celsius and the Fahrenheit scales.
6. Thermometer domain information model
6.1 Overview
This clause describes the domain information model of the thermometer.
6.2 Class extensions
In this standard, no class extensions are defined with respect to IEEE Std 11073-20601.
6.3 Object instance diagram
The object instance diagram of the thermometer domain information model, defined for the purposes of this standard, is shown in Figure 1.
The objects of the DIM, as shown in Figure 1, are described in 6.4 to 6.12. This includes the medical device system (MDS) object (see 6.5) and the numeric objects (see 6.6). There are no real-time sample array (RTSA) objects (see 6.7), enumeration objects (see 6.8), PM-store objects (see 6.9), or scanner objects (see 6.10) in the thermometer. See 6.11 for rules for extending the thermometer information model beyond elements as described in this standard. Each clause that describes an object of the thermometer contains the following information:
— The nomenclature code used to identify the class of the object. One example of where this code is used is the configuration event, where the object class is reported for each object. This allows the manager to determine whether the class of the object being specified is a numeric, real-time sample array, enumeration, scanner, or PM-store class.
The attributes of the object. Each object has attributes that represent and convey information on the physical device and its data sources. Each object has a Handle attribute that identifies the object instance within an agent. Attribute values are accessed and modified using methods such as GET and SET. Attributes types are defined using ASN.l. The ASN.l 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 I 1073-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 the agent. Conditional attributes shall be implemented if the condition applies and may be implemented otherwise. Recommended attributes should be implemented by the agent. Not recommended attributes should not be implemented by the agent. Optional attributes may be implemented by the agent.
The attributes can be either static, meaning that they shall remain unchanged after the configuration is agreed upon, or dynamic, meaning that the attribute may change at some point after configuration.