Integration of IEEE 1451 and HL7 Exchanging Information for Patients’ Sensor Data

The IEEE 1451 is composed of several standards that are concerned with smart transducers. Transducers are usually composed of sensors and actuators. The IEEE 1451 deals with data formats, communication protocols of the transducers and other devices [1‐4]. Here, the transducers are said to be smart if they have three characteristics. The first is that the transducers are described by machine-readable transducer electronic data sheets (TEDS). The second is that the control and data associated with the transducers are digital. Finally, to work the transducer properly, we must use triggering, status, and control [1].

The merits of using IEEE 1451 based transducers are as follows. First, the IEEE 1451-based transducers provide plug-and-play capabilities. In other words, the transducers can be connected through physical communication media without changing system software. When we attach or detach transducers from a patient, we do not have to worry about system functions such as configuration. The second merit is that the data that describe the patients and sensors that the patients are wearing can be stored in TEDS so that the information for the identification of a patient is automatically transmitted to a hospital or an emergency center. Also, IEEE 1451-based transducers can reduce human error, which may occur when operators send signals by hand. Considering these reasons, IEEE 1451 based transducers are useful in medical fields as well as other professional disciplines.

The structure of the transducers and their networks defined by the IEEE 1451 standards is shown in Fig. 1 [5]. On the left side, there are smart transducers which are composed of sensors, actuators, A/D converters, and simple signal processing units. The data measured from sensors are transmitted to an NCAP (Network capable application processor), which resides at the other side of the figure. These data are again transmitted to other places via other networks including LANs and cellular networks.

IEEE 1451 is composed of several standards. The relationship among these standards is shown in Fig. 2. Among the standards that compose the IEEE family of standards, 1451.0 is the most important. This standard provides a common framework or all the standards in the IEEE 1451 family to be interoperable. It defines the functions that are performed by a smart transducer interface module (STIM) and the common characteristics for all devices that implement the STIM. It also specifies the formats for Transducer Electronic Data Sheets (TEDS) and defines various commands to facilitate the setup and control of the STIM as well as reading and writing of the data used by the system and the STIMs. Application programming interfaces (APIs) are defined to facilitate communications with the STIM and with other applications. IEEE 1451.1 defines a common object model and programming paradigm for smart transducer systems. IEEE 1451.2 characterizes a transducers-to-NCAP interface and TEDS for a point-to-point configuration [1]. IEEE 1451.3 defines a transducer-to-NCAP interface and TEDS for multi-drop transducers using the Home PNA (Home Phoneline Networking Alliance) communication protocol. IEEE 1451.4 defines a mixed-mode interface for analog transducers with analog and digital operating modes. IEEE 1451.5 has recently been approved and defines a transducer-to-NCAP interface and TEDS for wireless transducers. Wireless standards such as 802.11 (WiFi), 802.15.1 (Bluetooth), 802.15.4 (ZigBee), and 6LowPAN are being considered as physical interfaces [1, 4]. The IEEE P1451.6 defines a transducer-to-NCAP interface and TEDS using the high-speed CANopen network interface [1]. In addition to these, the IEEE P1451.7 defines an interface and communication protocol between transducers and RFID systems.

Medical entities such as hospitals, doctors, and others must be able to send and receive various types of data such as patient information, medical images, as well as biomedical data such as ECG. Since medical data have different data formats and interface methods, these data must be presented in a standardized format to allow for exchange of information (HL7 Organization. [http://​www.​hl7.​org]; HL7 Version 2.5.1 Messaging Standard). HL7 (Health Level 7) is an ANSI approved standard that allows for exchange of medical data among computer applications. It is one of the most successful messaging standards in the medical field. The HL7 developed an international set of open standards for a message format and semantically interoperable data that allow different health information systems to easily and effectively communicate with one another (HL7 Organization. [http://​www.​hl7.​org]; HL7 Version 2.5.1 Messaging Standard). This standard deals with clinical observation, laboratory, pharmacy, medical devices, imaging and insurance transactions. It also provides the exchange, management and integration of data that support patient care and care management, as well as the delivery and evaluation of healthcare services.

The standard currently addresses the interfaces among systems that send or receive patient admissions/registration, discharge or transfer (ADT) data, queries, resource and patient scheduling, orders, results, clinical observations, billing, master file update information, medical records, scheduling, patient referral, and patient care. It does not assume a particular architecture with respect to the placement of data within applications. However, it is designed to support a central patient care system as well as a distributed environment. Although HL7 tries to cover numerous aspects related to medical data, HL7 does not cover sensor parts, especially from mobile patients or mobile devices. The growth in e-healthcare and u-healthcare means that HL7 will eventually accept data sensors, sensor networks, and mobile patients and may even interoperate with existing standards such as IEEE 1451.

IEEE 11073 is also a collection of standards that define all aspects of the communication among medical devices and/or other outside computers and especially of the communications with medical devices at the POC (Point of Care) [6, 7]. The main purpose of these standards is to provide a real time plug and play property and interoperability for patient-connected medical devices. They are also meant to facilitate the efficient exchange of vital signs and medical device data acquired at the point-of-care. IEEE 11073 is one of the most actively studying standards and is under development.

This standard is developing under the assumption that all the devices defined in IEEE 11073 should be interoperable with HL7. So, we do not consider the interoperation of IEEE 11073 and HL7. It is also possible for IEEE 1451 to interoperate with IEEE 11073. We do not consider the integration with IEEE 11073 with IEEE 1451 or HL7 in this study.

The overall system that we are considering is shown in Fig. 3 [8]. Here, we assume that a patient has possible intermittent diseases such as stroke or epilepsy but wants to live a normal life. To accomplish this, if there is a problem, devices or sensors notice this and inform an emergency center, hospital, or doctor. Therefore, the patient must wear sensor modules equipped with communication modems such as Zigbee or Bluetooth. These sensors measure biomedical data such as ECG, SpO2, or body temperature constantly and send them to a PDA that the patient is also wearing on wire or by several wireless communication methods such as Zigbee or Bluetooth. In this scenario, we assume that the sensors are implemented and meet the requirement of the IEEE 1451 standards. The wireless sensors are implemented to meet the specification of IEEE 1451.5 and the sensors meet IEEE 1451.4.

The data collected at the PDA may be processed. Some of the possible processing skills include calibration, extraction of features, decision on the status of the patient, or compression. The processed, possibly compressed, data or the raw data are eventually sent to a hospital or an emergency center through cellular, wireless LAN, or wired LAN communications. Usually, when the patient is at home or at work, the data are sent via a wireless LAN or a wired LAN. This is one of the most reliable and cheapest methods. If the patient is moving, the data may be sent to the remote places via cellular networks. The hospital or the emergency center constantly monitors the data and calls doctors or an ambulance in case of emergency.

In hospitals and emergency centers, doctors, nurses, technicians, treat all the patients’ data through standardized way such as HL7 or DICOM, etc. Thus, for all the people in medical area to access all the data from patients, they should be translated into HL7 compatible form. Here, we consider the translation of the sensor data into HL7 compatible form.

One of the most important parts of the IEEE 1451 standard is the TEDS [1‐5]. The TEDS is the information structure that contains critical sensor information that enables the plug-and-play operation. This is important to initiate transmission of the sensor data and specific information about the patient. The data structure of the TEDS in the IEEE1451 is different from that of the HL7. Thus, the two systems cannot interoperate with each other. To guarantee the interoperability, the data need to be translated into HL7 message format and vice versa. To do this, the data structures of both IEEE 1451 and HL7 need to be redefined.

In Fig. 4, we extracted the components that are related with the transfer of medical data from Fig. 3. Since we assumed that all the sensors are implemented to meet the specification of the IEEE 1451 standard, the sensors carry TEDS. In the TEDS, all the information on the patient, smart sensors are stored and sent with the sensor data. The data which are collected and transmitted to the PDA, are transmitted to the NCAP (Network capable application processor) and eventually to the Hospital. In the NCAP and the hospital, they have transcoders or transformers between IEEE 1451 TEDS and HL7.

IEEE 1451 defines the TEDS structure in a compact and flexible way that allows for the handling of a wide range of sensor types and requirements. In IEEE 1451.4, there are three compliance levels called Tiers [3]. Tier 1 provides minimum capability and includes Basic TEDS. Tier 2 and Tier 3 have standard and extended system capabilities and can use advanced templates. We consider Tier 2 and Tier 3 transducers. For the Tier 2 and Tier 3 transducers, in addition to the basic TEDS, they may have IEEE-defined templates called the standard template TEDS. The basic TEDS contains the manufacturer ID, the model number, the version number, and the serial number. The standard template TEDS contains the key characteristics of sensors or actuators such as type, sensitivity, measurement range, bandwidth, etc. The standard template TEDS defines Template IDs, which are 25 to 43, according to general classification of the sensors. These include accelerometer, microphones, resistance sensors, thermistor, and potentiometric voltage divider. Each template includes required characteristics for each specific sensor. Among these, since the sensors used in this study are mainly of voltage types, we use Template ID 39, which is a potentiometric voltage divider type transducer template. Table 1 shows an example that we intend to use for the structure of the Basic TEDS and Template 39. If there are different types of transducers, then we can use other templates [3].

For the HL7, a new type of message can be accepted and a new segment group can be added. Also, a new data format can be created with the HL7 (HL7 Organization. [http://​www.​hl7.​org]). The measured sensor signals such as ECG or EEG can be represented in waveform and HL7 can support the waveform data format. The WAV category OBX result segment is used to transmit the actual waveform data (the time-series digitized values from an analog-to-digital converter (ADC) or other sources of sampled digital data). For the integration of IEEE 1451 and HL7, we use a trigger event W01 and message type ORU. The W01 is a trigger event that identifies ORU messages which can transmit waveform data coming from the results of an ordered test or series of observations. This may be used to identify ORU messages sent as the eventual response to a QRY message specifying a deferred mode query for waveform results/observation with record-oriented format. One or more ORU messages with the W01 trigger event may result from this type of QRY message.

To exchange data, this study proposes the addition of 13 categories of the IEEE 1451 TEDS, a patient's biosensor data, to the existing HL7 attribute table-OBX (HL7 Version 2.5.1 Messaging Standard). This means that four categories of the Basic TEDS (e.g. manufacturer’s ID, model number, version number, and serial number) and 9 categories of the Templates 39 (e.g. Template ID, Sensitivity, Sens-Ref, Minimum Physical Value, Maximum Electrical Value, Minimum Electrical Value, Maximum Electrical Value, Mapping method) are added to the existing 19 OBX fields. A standard message was generated and encoded based on the proposed TEDS-HL7 based Message protocol and was transmitted to the hospital system. In Table 2, we show the proposed attribute in the OBX table.

Software that exchanges data based on HL7 standards is called a software interface engine. Simple software interface engines that can send and receive messages in the engine according to the interworking of the 1451 and the HL7 standard are shown in Fig. 5. As shown in Fig. 5, on the clients’ side, the user TEDS-HL7 software interface engine translates the IEEE 1451 TEDS and the transducer data into HL7 messages and transmits them. On the server side, the TEDS-HL7 based software interface engine receives the translated HL7 messages and begins to parse them. If the message has no problems, the engine issues an acknowledgement.

To guarantee patient mobility and convenience, the patient wears several sensors and a wireless modem on an armband. Also, the patient is wearing a PDA which collects, processes, and transmits all the data from the sensor modules. In Fig. 6, we show the hardware platform. The sensor module has a pulse sensor to measure patients’ pulse, a temperature sensor to determine the patient’s body temperature, and a humidity sensor. This module also has a Zigbee modem that can form a wireless sensor network. The PDA is a Compaq iPAQ 5450 that has a built-in WLAN modems. The temperature sensor is placed close to the patient’s body to correctly measure body temperature.

The software we use is as follows. For the OS for the operating sensor module and wireless sensor network, we used TinyOS. The TinyOS is an open-source operating system designed for wireless embedded sensor networks (http://​www.​tinyos.​net). It features component-based architecture which enables rapid innovation and implementation while minimizing code size as required by the severe memory constraints inherent in sensor networks. For the development of PDA related software, we used the embedded Visual C++3.0 and Platform Builder. For the development of server related programs, we used Windows XP as a Server OS and Visual C++6.0. The programs for monitoring the strength of the signal were developed through NDIS (Network Driver Interface Specification) and SDK (Software Development Kit).

In Figs. 7 and 8, we present some of the results. Figure 7a shows a patient’s information. This can be displayed if we press ‘Patient Inf.’ button at the top of the screen. On the upper left side of Fig. 7a, we can see the patient’s personal information including a picture, name, and SS#. On the right side is a list of sensors that the patient is wearing. If we select a sensor here, then we can see its information. This also includes the information about the sensor that is stored in the TEDS and is displayed beneath the list. At the lower left corner, we have reserved this space to display the patient’s medical history or possible symptoms. If we select a sensor and press the ‘Monitoring’ button at the upper side of (a), we can go to the monitoring page shown in Fig. 7b. In (b), we can see the picture of the data that are coming from the sensors. While monitoring the data, if we need to record the data, then we can press ‘Capture’ button to freeze and capture the current data. If we need to need to translate the data into HL7 format, then we can press ‘HL7 Message Generation’ button. Also, if we need to send the translated HL7 message to a server at a remote site, then we can press ‘send’ button.

Figure 8a is a picture of the message that is translated into HL7 format and transmitted to a remote center. Here, we initiated a W01 as an event, and according to this, the translated message from HL7 is shown at the lower part. Here, we can see that the TEDS and other related information is encoded along with sensor data. Figure 8b is the received message at the remote side. From these results, it is possible to produce a sensor standard, IEEE 1451 and medical standard HL7 that can interoperate with each other.