30th Annual International IEEE EMBS Conference Vancouver, British Columbia, Canada, August 20-24, 2008
Medical Instrument Data Exchange Suman Gumudavelli, Student Member, IEEE, Paul K. McKneely, Pongnarin Thongpithoonrat, Student Member, IEEE, D. Gurkan, Member, IEEE, Frank M. Chapman
Abstract— Advances in medical devices and health care has been phenomenal during the recent years. Although medical device manufacturers have been improving their instruments, network connection of these instruments still rely on proprietary technologies. Even if the interface has been provided by the manufacturer (e.g., RS-232, USB, or Ethernet coupled with a proprietary API), there is no widely-accepted uniform data model to access data of various bedside instruments. There is a need for a common standard which allows for internetworking with the medical devices from different manufacturers. ISO/IEEE 11073 (X73) is a standard attempting to unify the interfaces of all medical devices. X73 defines a client access mechanism that would be implemented into the communication controllers (residing between an instrument and the network) in order to access/network patient data. On the other hand, MediCAN™ technology suite has been demonstrated with various medical instruments to achieve interfacing and networking with a similar goal in its open standardization approach. However, it provides a more generic definition for medical data to achieve flexibility for networking and client access mechanisms. In this paper, a comparison between the data model of X73 and MediCAN™ will be presented to encourage interoperability demonstrations of medical instruments.
D
I. INTRODUCTION
model of a system represents the structure, categorization, and definitions of information to be used when communicated between end points. Such a model is necessary to enable access in a fast and efficient manner. A protocol based on this data model should define an access service to the data so that networking and interface technologies can be created in a complementary fashion. In the case of Point-of-Care (PoC) medical device systems, data model plays a very important role since it contains vital signs of patients. The data may be classified into three types based on their use: Clinical, Instrument, and Vendor (or Manufacturer). Clinical data is related to the health condition of a patient, e.g., vital signs information. Instrument data provides the condition of the instrument itself, e.g., maintenance of the instrument by the manufacturer or the administration. Vendor (manufacturer) data is a vendor-specific (and possibly only vendoraccessed) information domain. Currently, the emphasis on healthcare information ATA
Manuscript received April 7, 2008. S. Gumudavelli, P. Thongpithoonrat, and D. Gurkan are with the Engineering Technology Dept. University of Houston, Houston, TX 772044020 USA (phone: 713-743-4037 e-mail:
[email protected]). P. K. McKneely and F. M. Chapman are with the MediCAN Systems Inc., Houston, TX 77079 USA (e-mail:
[email protected]).
978-1-4244-1815-2/08/$25.00 ©2008 IEEE.
systems has been more on the electronic health records (EHR) and similar administrative-medical joint data [1-3]. This paper does not study such data models; it rather addresses the actual measurements of health status of a patient. Unless data from the real source is retrieved automatically while in electronic domain, networking of such data will be possible only if a medical personnel manually enters it to facility database. When instruments have interfaces to report their data through a network; data transmission, ubiquitous access, and storage will be possible. Hence, researchers can use this data to improve personalized care, medical personnel to improve care, and healthcare facilities to better administer their operations. ISO/IEEE 11073 (X73) is a point-of-care medical device communication standard aimed at providing interoperability among medical instruments [4-6]. MediCAN is a proposed technology suite that is also aimed at providing interoperability among medical devices in an open standard fashion. MediCAN™ uses instrument adaptors and networking equipment to connect instruments on a CAN bus and then to a network such as the Ethernet [7]. MediCAN and X73 both try to unify instrument interfaces so that plugand-play of medical devices will be possible in a healthcare network. This paper is on the comparison of existing data models developed by MediCAN Systems Inc. and the X73. Networking of medical instruments has been tested and demonstrated using MediCAN data model. Each data model will be presented with respect to their support of interoperability of instruments of different manufacturers. II. ISO/IEEE 11073 AND MEDICAN DATA MODELS Data distribution in a healthcare facility will serve clients who would like to access healthcare and administration information. In this respect, instrument interfaces to the network provides the transmission medium for patient data whereas interface software applications deliver this data to the users. In this respect, the interface at the instrument site should be able to answer the needs of a higher level client application program interface (API). For example, bedside instruments may deliver monitoring and measurement data to the network while medical personnel on a remote site might retrieve archived or real-time data. MediCAN’s goal is to provide a tightly-coupled interfacing network to medical instruments while the remote user access is a left to be loosely-coupled to provide flexibility to customize applications. X73 takes a more loosely-coupled approach from the instrument up to the
1809
client access levels by generic medical data references instead of specific medical data categorization. Since X73 includes the complete hierarchy up to the hospital enterprise in the data model, the system demonstrations have been limited to dedicated PC based instrument adaptors rather than small form factor embedded controllers [4, 8] (Here, instrument adaptors have been used to represent device communications controller and bedside communications controller pairs). Variations exist in user access representative definitions: e.g. MediCAN defines a variable of an instrument and leaves the user to define relational groups whereas X73 also defines a variable of an instrument in addition to an optional channel object that can be used for any relational grouping for the application. Gateway
Client
Bed/BCC X73 adaptor Packages: Objects:
Pulse oximeter
DCC/Instrument Virtual Medical Device
System
Sample Array Numeric
Alert
Remote Control
...
...
Simple Hydra Composite Value Bed
...
Figure 1. Medical instrument interface data model in X73 includes packages: 1. Medical, 2. Control, 3. Alert, 4. Communication, 5. Archival, 6. Patient, 7. System, 8. Extended services. The objects under these packages have dependencies defined in X73.
A. Domain Information Model of IEEE 11073 Domain Information Model defines an object-oriented model representing the relevant information (i.e., data) and functions (e.g., device controls) encountered in the problem domain of medical device communication, including measurement information, contextual data, and device control methods (handled by CMDISE - Common Medical Device Interface Service Element). For communicating systems MDIB (Medical Data Information Base) is a structured collection of these managed medical objects representing the vital signs information. Attribute data types, hierarchies, and behavior of objects in MDIB are defined in this standard. MDIB is subdivided into different packages: Archival, Patient, System, Medical, Alert, Control, Communication, and Extended Services. System Package represents devices that derive or process vital signs information and comply with the definitions in this standard. Archival Package deals with storage and representation of bio-signals, status, and context information in an on-line or an off-line archive. Communication Package includes with objects that enable and support basic communication. Patient Package has all patient-related information that is relevant in the scope of this standard, but is not vital signs information modeled in
the Medical Package. Extended Services Package contains objects that provide extended medical object management services that allow efficient access to medical information in communicating systems. Such access is achieved by a set of objects that package attribute data from multiple objects in a single event message. Control Package contains objects that allow remote measurement control and device control. Alert Package deals with objects that represent status information about patient and/or technical conditions influencing the measurement or the function of the device. Medical Package has vital signs information model. B. MediCAN Hierarchical Data Model MediCAN uses a hierarchical model for organizing data. The system is tightly-coupled on a CAN bus to keep track of all resources that are available at a given instant of time. The basic hierarchy includes: Gateway (GNode), Port (Bed or Hub or Patient), Device (DNode, namely the instrument), Object (System or Application), Group (Parameter, Stream, Event), Scope (Vendor, Instrument, Clinical), Variable (8bit field). The user application can build its hierarchy and access permissions at the top of this data delivery architecture. The instrument adaptor has been implemented by MediCAN Systems for a Pulse Oximeter instrument (Nelcorr). One parameter variable is the pulse of a patient. One stream variable is the plethysmograph sampled from the analog output of the instrument. The adaptor is built on a HC08 core from Freescale Semiconductor. It has 1/2K of RAM (volatile) and 32K of flash (non-volatile) memory. This 8-bit architecture is a simple low-end design that is suitable for small, low-power and low-cost interfaces. Gateway
Client
Bed/Hub/Patient Pulse oximeter
Node/Instrument MediCAN adaptor
Object
Vendor, Instrument, Clinical
Scope
Parameter, Stream, Event
Value
Group
Variable
Figure 2. Medical instrument is networkable using the instrument adaptor. Data model includes a node to represent an instrument. Below the node/instrument, all data representation resides in the MediCAN adaptor. A client connected to the gateway can access instrument data using the enterprise networking infrastructure.
The gateway is a system that provides an access point via an Ethernet network to a set of resources within one or more instruments. Each gateway connects its ports to beds. Gateways keep track of all connected devices and clients. Each bed is associated with one patient. The device is a plug-and-play system (medical instrument) that can dynamically “show up” or “go away” at any bed. MediCAN Control Protocol (MCP) provides access to instrument data. MCP has been described in other publications by the authors
1810
[7, 9]. Parameters are variables that are generally set by operating personnel. Stream variables are data values that are measured from constantly changing sensors. Events are variables that have finite states (values). Variable values are provided with time stamps through MCP. All values may be polled or automatically reported depending on the application. Vendor scope variables are defined by the manufacturer of the instruments so their definitions are not dictated by MediCAN. Instrument scope variables address the well-being of the instrument itself for diagnostic and maintenance purposes. Clinical scope variables directly relate to the patient being monitored. The communication of data in MediCAN is transparent to the network. Gateway coordinates the requests from different clients to the devices connected to it. A report function enables the devices to report events unconditionally. III. FUNCTIONAL COMPARISON The functional hierarchy of medical data transmission from the instruments to the users of the system is the determining factor in the creation of an interoperable medical instrument network. In this respect, a tightlycoupled system at the bedside will help improve the interoperability between medical instruments by providing methods and structure for the manufacturers to represent their measurement outputs [10]. The rest of the network can be loosely coupled for various protocols and applications to be able to access data from medical instruments. Medical Instrument
Parameter Stream Event
Medical Instrument Tightly-coupled system
Facility Client Gateway
Facility Client
Content Distribution Network
Figure 3. Medical instruments can form a tightly coupled system to deliver the content in a deterministic manner. A content distribution network in a health facility can handle the access by users.
The instrument has sensors that will provide monitoring data from the patient. The content can be (i) a parameter such as the heartbeat, (ii) an event, e.g. call nurse when heartbeat < threshold, or more complex, or (iii) a stream of measurements such as a plethysmograph output from a pulse oximeter as depicted in Fig. 3. A medical information system would serve the users by providing functions such as medical data transfer, alerts on emergencies such as patient health or instrument failures, real-time medical monitoring services with remote control and configuration of medical instruments, archive of data, and support of access points. The infrastructure should have system management and a communications infrastructure that keep track of resources, access points, authorization rights, and archivals. System: IEEE 11073 defines Simple, Hydra, Composite Single Bed, and Composite Multiple Bed MDS objects to represent single or multiple medical devices on the network. The Event Log object is a general Log object that stores
system events in a free-text representation. In MediCAN, any instrument has one system object and one or more application objects. The grouping of applications and systems is left to the user application on the content distribution network of the enterprise. Communications: The DCC object is a Communication Controller object used by medical devices operating as agent systems (i.e., association responders). The BCC object is a Communication Controller object used by medical devices operating as manager systems (i.e., association requestors). Both of them contain one or more Device Interface objects which represent a particular interface, i.e., port. IrDA or RS232 protocol is used to transmit data from the instruments to a BCC relying on the manufacturer’s methods of variable definitions and data transmission. In MediCAN, DCC is analogous to a node and BCC to a gateway. MediCAN control protocol (MCP) governs the communication of instruments with gateway to transmit measurements [7, 9]. Archival and Patient Data: X73 and MediCAN leave the patient data system (such as an HL7 or Electronic Health Record database) to the user’s custom needs. A. Medical Data IEEE 11073: Virtual medical device (VMD) is an abstraction for a medical subsystem (hardware or software). Channel object is used for grouping metric objects and thus allows hierarchical information organization. For example: A blood pressure VMD may define a Channel object to group all metrics that deal with the blood pressure (e.g., pressure value, pressure waveform). Numeric Object is on measurements and status information, e.g. amplitude measurements, counters, heart rate. Sample Array Object represents real-time or sample array objects which have their observation values reported as arrays of data points, e.g. ECG real-time wave. Observation values are presented free text form. The PM-Store object is used for archival. MediCAN: Data structure and context has been defined more specifically to guide manufacturers towards a common categorization of medical data. Each variable is a member of one of three groups: Parameter, Stream, or Event. Each group is under one scope: Vendor, Instrument, or Clinical. Further grouping of variables is transparent in MediCAN. Client requirements may be varied and complex. Therefore, grouping at bedside is not preferred to keep the adaptor memory requirements to a minimum. For example, the adaptor implementation for the Nelcorr pulse oximeter, under clinical scope, parameters include lower and upper alarm limits, streams include plethysmograph analog plot, beats per minute, pulse amplitude, events include sensor stability, pulse rate alarm, saturation alarm. B. Alerts IEEE 11073: The alarm can be either a physiological alarm or a technical alarm condition of a related object [e.g., MDS (i.e., medical device system), VMD, Metric]. The Alert object has a reference to its corresponding object instance in
1811
the Medical Package. The Alert Status object represents the output of an alarm process. The Alert Status object collects all alarm conditions related to a VMD object hierarchy or related to an MDS object and provides this information in list-structured attributes. The Alert Monitor object is the output of a device or system alarm processor and provides a list of all alarm conditions of the system in its scope. This list includes global state information and individual alarm states that allow the implementation of a safety-standardcompliant alarm display on a remote system. MediCAN: Single event reporting in a corresponding scope handles the events/alerts. For example, physiological alarms are reported in clinical scope variable and technical alarms are reported in instrument scope variable. In MediCAN, each client can configure alarms, events, and alerts according to their requirements. This means that alarm variables can perform independently. C. Remote Control of Instruments IEEE 11073: The Service and Control Object (SCO) is responsible for managing all remote-control capabilities that are supported by a medical device: (a) Simple transaction processing, which prevents inconsistencies when a device is controlled from multiple access points (e.g., local and remote) and during the processing of control commands; (b) State indications, which allow local and remote indication of ongoing controls. Also, Operation objects like Select Item, Set Value, Toggle Flag, Activate, Limit Alert, Set Range allows the system to modify or configure specific attributes. MediCAN: SCO is analogous to the gateway which manages connections between clients and instruments through MCP. MediCAN uses function calls: read/write variable and set range. D. Attribute Scanning Services IEEE 11073: Scanners scan the managed medical objects for their attributes. Scanner objects maintain an attribute group scan granularity. Scanner objects can be configurable or non-configurable with respect to the attribute scan list. For example, alert scanners are not configurable as they are security sensitive. Episodic scanners are configurable and they report all attribute values whenever any of the listed attributes value changes. Periodic scanners are also configurable but they report periodically even when there is no listed attribute value change. MediCAN: Whenever the value of a parameter changes or whenever a pre-defined condition is met an event is reported. The scan granularity is defined by the client and events from multiple objects are not packaged into a single event message. They still function independently to support the varying requirements of clients. That is, periodic reporting would be requested by the individual clients on the gateway network with potentially many simultaneous client connections. Event scanning is initiated by individual client according to its custom requirements.
IV. CONCLUSIONS ON INTEROPERABILITY SUPPORT The hierarchical structure of medical data divides the networking into two. Hence, from an instrument to the network, two layers of interoperability requirements exist. (i) The sensors (medical instruments/devices) will require a tightly-coupled network where data is being transmitted deterministically. (ii) After the network storage node is reached, all transmission problems are analogous to internet content distribution networks. The interoperability of a medical instrument network has two main thrusts: (i) medical device interface should be on a deterministic network with minimal loss and delay; (ii) the storage and retrieval of patient health data is a content distribution network with various user expectations. For example, a clinical researcher would need to collect monitoring data in a continuous fashion with streams whereas a diagnostic application would need only sufficient amount of data that reflects changes in the status of a patient. If the medical instrument interface is uniform for all devices, the access to data can be realized using mature networking technologies. REFERENCES [1]
D. Kalra, “Electronic health records: the European scene,” British Medical Journal, 1994, vol. 309, pp. 1358-1361. [2] Continua Alliance web site: http://www.continuaalliance.org/home [3] HL7 Technical Committee: http://www.hl7.org [4] M. Gallaraga, et.al., “Proposal of an ISO/IEEE 11073 platform for healthcare telemonitoring: plug-and-play solution with new use cases,” 29th IEEE EMBC, 2007. [5] S. Warren, et. al.,, “ Reconfigurable point-of-care systems designed with interoperability standards,” IEEE EMBC – Proceedings, 2004. Vol. 26, pp. 3270 – 3273. [6] IEEE Standards Association page: http://standards.ieee.org/ [7] P. K. McKneely, F. Chapman, and D. Gurkan, “Plug-and-Play and Network-Capable Medical Instrumentation and Database with a Complete Healthcare Technology Suite: MediCAN,” Jnt. Wshp. on High Confidence Med. Dev. Software Sys. and Medical Device Plugand-Play Interoperability (HCMDSS - MD PnP 2007), Boston. [8] I. Martinez, et. al., “Implementation experience of a patient monitoring solution based on an end-to-end standards,” IEEE EMBC, 2007. [9] Pongnarin Thongpithoonrat, et. al.,, "Networking and plug-and-play of bedside medical instruments," submitted to the IEEE EMBC 2008. [10] P. H. Longstaff, “can unpredictable systems be managed?” IEEE International Conference on Systems, Man, and Cybernetics, 2003. Vol. 2, pp. 2013 – 2020.
1812
