Integration of IEEE 1451 and HL7 exchanging information for patients' sensor data.

HL7 (Health Level 7) is a standard developed for exchanging incompatible healthcare information generated from programs or devices among heterogenous medical information systems. At present, HL7 is growing as a global standard. However, the HL7 standard does not support effective methods for treating data from various medical sensors, especially from mobile sensors. As ubiquitous systems are growing, HL7 must communicate with various medical transducers. In the area of sensor fields, IEEE 1451 is a group of standards for controlling transducers and for communicating data from/to various transducers. In this paper, we present the possibility of interoperability between the two standards, i.e., HL7 and IEEE 1451. After we present a method to integrate them and show the preliminary results of this approach.

Introduction

HL7 is a messaging standard for exchanging medical information that is becoming a world standard. Among medical information such as a text or an image, HL7 deals with text information (HL7 Organization. [http://www.hl7.org]; HL7 Version 2.5.1 Messaging Standard). Recently, as the ubiquitous era is approaching, a new type of information, i.e., streaming data, has appeared. These data usually come from sensors from various networks such as wireless LANs, wired LANs, or cellular networks and increasingly have important role in e-healthcare, u-healthcare, and other health systems. Since various wireless networks are widely spread and the performances of many devices such as PDAs, notebooks, or cellular phones improve, the use of sensors for patients will become popular as well, and thus the quality of life for patients will improve. Sooner or later, HL7 should include information from mobile patients, mobile devices, and mobile sensors.

In the area of electrical and mechanical engineering, sensors have been used for a long time to check and monitor the status of machines and devices. In these areas, there has been a group of standards IEEE 1451 which deal with various aspects of sensors, such as the definition of sensors and actuators, the format of data sheets, and how to connect and disconnect the sensors from a system. Also, these standards deal with communication protocols. Recently, the advent of various sensors such as wireless sensors has led the IEEE to develop a complete set of standards that deal with these types of sensors [1-5]. The family of IEEE 1451 standards will become a global standard in all areas that use sensors.

This paper studies the possibilities of the interoperability of the two standards; IEEE 1451 and HL7 v2.5. HL7 v2.5 is more suitable for processing steaming data than HL7 v3. Since the data structure of the TEDS (Transducer Electronic data sheet), which is the core of IEEE 1451, and the format of the HL7 message are different, we implemented a new messaging format for communicating data among the TEDS and HL7 v2.5 based applications or systems. Based on this, we implemented this engine into a hardware platform including a PDA, sensors, and wireless and wired LAN.

This paper is organized as follows. In Section 2, we introduce the three standards: IEEE 1451, HL7, and IEEE 11073. In Section 3, we consider the interoperability of the HL7 and IEEE 1451. Finally, in Section 4, we show the results of implementation.

IEEE 1451, HL7, and IEEE 11073

IEEE 1451

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.

Fig. 1

The structure of the sensor modules and NCAP in IEEE 1451

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.

Fig. 2

IEEE 1451 family of standards

HL7

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

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.

Model for integration of IEEE 1451 and HL7

Overall scenario

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.

Fig. 3

Overall scenario

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.

Model for exchanging messages between IEEE 1451 and HL7

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.

Fig. 4

Interface between IEEE1451 and HL7

IEEE 1451 TEDS

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

Table 1

The structure of the IEEE 1451 TEDS and the items of Template 39

TEDS structure	Example biosensor information
Basic TEDS	Manufacturer ID	1
	Model number	2
	Version number	1.1
	Serial number	1123
Item of Template 39	Template ID	39
	Sensitivity	0.01
		°C
	Reference temp	−40
	MinPhyVal	−40
	MaxphyVal	123.8
	MinElecVal	0
	MaxElecVal	16,384
	MapMeth	1

HL7 message format

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.

Table 2

Proposed attribute table-OBX for interface between IEEE1451 and HL7

SEQ	LEN	DT	OPT	RP/#	TBL#	Item#	Element name
1	4	SI	O			569	OBX Set ID-OBX
2	2	ID	R		125	570	Value type
3	250	CE	R			571	Observation identifier
4	20	ST	R			572	Observation sub-ID
5	65536	NA or MA	C			573	Observation value
6	250	CE	X			574	Units
7	60	ST	X			575	References range
8	5	ID	O	Y	78	576	Abnormal flags
9	5	NM	X			577	Probability
10	2	ID	X	Y	80	578	Nature of abnormal test
11	1	ID	R		85	579	Observation result status
12	26	TS	X			580	Effective date of reference range values
13	20	ST	X			581	User defined access checks
14	26	TS	X			582	Date/time of the observation
15	250	CE	X			583	Producer's ID
16	250	XCN	O	Y		584	Responsible observer
17	250	CE	X	Y		936	Observation method
18	22	EI	O	Y		1,479	Equipment instance identifier
19	26	TS	O			1,480	Date/time of the analysis
20	2	NM	R				Manufacture ID
21	50	ST	R				Model number (sensor type)
22	2	NM	R				Version number
23	2	NM	R				Serial number
24	1	NM	R				Template ID
25	120	NM	R				Sensitivity
26	250	ST	O				Sens-ref. (unit)
27	20	NM	O				Ref. temp
28	50	NM	R				Minimum physical value
29	30	NM	R				Maximum physical value
30	60	NM	R				Minimum electrical value
31	80	NM	R				Maximum electrical value
32	250	NM	C	Y			Mapping method

TEDS-HL7 software interface engine

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.

Fig. 5

The process of sending and receiving a message between the engines

Implementation

Hardware and software Platform

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.

Fig. 6

Hardware platform (a) an armband attached on patients’ arms and (b) a PDA

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

Implementation

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.

Fig. 7

Monitor screen of a patient at the PDA and server at the patient’s side. a Page for the patient’s information. b Page for monitoring patient’s sensor data

Fig. 8

An example that shows the transmitted and received message after translation. a ORU^W01 message based on TEDS-HL7 message protocol. b Received message at the remote site

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.

Conclusion

In this paper, we studied the possibility of the interoperation between the IEEE 1451 and HL7 and presented our preliminary results. As ubiquitous systems are growing, u-healthcare will eventually be used. Thus, patients will wear sensors that check and measure the patients’ status in real time and transmit these data to remote sites such as a hospital or an emergency center. This real time steaming data will develop with time, eventually HL7 must accept these kinds of data so that it can interoperate with various online sensor data. To do this, we must consider two possible choices. One is to develop a new standard to deal with medical sensors and actuators. The other is to integrate HL7 with developed or existing standards such as IEEE 1451. We believe that the latter is more probable than the former because the latter can save time, man-month, and money. If this is correct, the best option will be to choose IEEE 1451. Although integration requires time, we think that this result has shown that HL7 and IEEE standards can interoperate with each other.