Interoperable Medical Instrument Networking and Access System with Security Considerations for Critical Care

The recent influx of electronic medical records in the health care field, coupled with the need of providing continuous care to patients in the critical care environment, has driven the need for interoperability of medical devices. Open standards are needed to support flexible processes and interoperability of medical devices, especially in intensive care units. In this paper, we present an interoperable networking and access architecture based on the CAN protocol. Predictability of the delay of medical data reports is a desirable attribute that can be realized using a tightly-coupled system architecture. Our simulations on network architecture demonstrate that a bounded delay for event reports offers predictability. In addition, we address security issues related to the storage of electronic medical records. We present a set of open source tools and tests to identify the security breaches, and appropriate measures that can be implemented to be compliant with the


INTRODUCTION
Critical care requires complex medical instruments to report and record patient health in a timely and accurate manner.Current technology and health record systems rely on these instruments to be utilized by the healthcare personnel, who then record health information into an electronic system.This mandates that a healthcare personnel be at the bedside of a critical patient full-time, to enable continuous care.Moreover, manual entry of health information into an electronic system by healthcare personnel is prone to error.Therefore, a bottom-up approach to realizing health record monitoring, archiving, and access should be developed that utilizes instrument data to be posted on the electronic system without the need of a healthcare professional's manual entry.
Automatic transmission of medical data from an instrument is possible with proprietary mechanisms that vendors provide for each instrument.However, the critical care room is typically equipped with instruments from various vendors.Therefore, a uniform access point to all patient data is impossible without interoperability among vendor application interfaces.This paper proposes an interoperable networking of all critical care bedside instruments, with a secure access mechanism to all patient health records.

PREVIOUS WORK
There has been an emerging interest in combining the strength of the communication networks with monitoring capabilities of medical devices in order to deliver an automated support system for medicine.On one hand, standardization efforts such as the IEEE 11073 led the way towards a unified data structure among the point-of-care devices.On the other hand, there were numerous demonstrations of wireless and wired networked medical devices/instruments.Previous works can be categorized into three major areas as far as this paper's focus is concerned: (i) networking and standardization, where interoperability of individual medical instruments on a network environment has been explored; (ii) isolated automation demonstrations, where integrations of medical instrument and patient care have been proposed towards automated care; and (iii) automation and security of medical health records.
Networking and standardization: One study demonstrated a system with a complete requirements list to amplify the effectiveness rather than swapping of the staff with an automated data delivery protocol [1].More work has been done on incorporation of radio frequency (RF) identification technology into a complete system delivery for healthcare [2] as well as data acquisition from instruments again using a standard management information base [3,4].The interoperability issues of these standards have been extensively studied towards creation of a relational database tree among the relevant monitoring parameters [5].However, when the standards are not followed by industry products because of their complexity and an uncooperative environment, they fail to emerge as an acceptable method.The demonstrations in the research laboratories are promising to the extent of a proof-of-concept [6].These demonstrations are desired to be picked up by the industry to gain momentum in a successful standardization process.Other open standards have been utilized such as the fieldbus technology to build patient monitoring systems [7].This work outlined an extensive list of requirements for bedside monitoring and signal representation in terms of ease of use.In order to further the standardization efforts, a study on medical instrument companies and their family of products has been investigated [8,9].These studies have been focused on the technical details of interfacing specific medical instruments, without attention to standardization of the medical data that are reported.For example, signals captured can be in the form of monitoring parameters such as the heart rate, events such as an alarm indicating increase in blood pressure, or data streams such as plethysmograph.The feasibility of telemedicine and standardization efforts with costbenefit ratios has been studied for European as well as American healthcare needs [10].The results show an exceptionally high benefit in automation and communication of the medical instruments through a network.

638
Interoperable Medical Instrument Networking and Access System with Security Considerations for Critical Care Isolated automation demonstrations: An anesthesia alarm system was proposed and demonstrated as early as 1993 as an attempt to minimize human errors resulting from inconsistent standards and calibrations of various medical instrument vendors [11].Also, ventilator management with an integrated knowledge-based technology has been proposed [12].Most automated monitoring studies tend to give heart monitoring more emphasis on vital state monitoring such as the object-oriented implementation demonstration to assess patient status using cardiovascular data [13].
There has been an identified need to utilize technology to better the care in a critical environment such as the critical-care centers, emergency and surgery rooms, or the intensive care units (ICU).Wireless PDAs have been demonstrated to carry ICU telemedicine [14] as well as home-based healthcare data [15].The ICU monitoring networks have been developed to an advanced level of web-based representation [16] with emphasis on protocol design for such applications [17].The wearable technologies are also very attractive in on-the-fly monitoring of patient health care [18].However, they are limited in scope of what can be monitored and the relevance of monitored data to the patient's diseases.Home-based systems also make use of the wireless technologies in their monitoring systems with a limited access to only RS-232 serial interfaced medical instruments [19].However, there is not a single system demonstration that would incorporate all possible medical instruments and administrative information into one information network.
Security of medical health records: Electronic medical record (EMR) systems are used for storing the patient's medical history and profile, data on patient care and management, and financial reimbursement information.The EMR system raised the issues of patient privacy and data security.The mistrust and insecurity created by the ease with which unauthorized persons can have access to sensitive medical information pushed Congress into enacting the Health Insurance Portability and Accountability Act of 1996 (HIPAA).HIPAA places strict compliance standards regarding the security of individual health information.Security and privacy are two indispensable aspects of all EMR systems.Security ensures that data are securely stored and transferred, and privacy ensures that data can be accessed only by the people who have authorization to view and use the data [20].Attributes of information systems that play a key role in EMR security include authentication, authorization, integrity, accountability (including Non-repudiation), confidentiality, consent and audit ability [21][22][23][24][25][26][27].Most security constructs for EMRs are based on a series of specifications regarding these attributes coupled with compliance to a set of laws and regulations governing the healthcare system (viz.HIPPA) [28].A detailed discussion of the various EMR system designs is beyond the scope of this study and is not presented here.HIPAA mandates covered entities to implement policies and procedures to safeguard an individual's EMRs whilst in transmission, at rest, and in storage.In this study, we focus on the security of stored medical records, such as those obtained from networked medical devices as described earlier.Database servers with stored records are particularly prone to security attacks.Since a database contains most of the demographic, insurance and identity information of a patient, it is essential to secure it from attacks.We implemented open source tools [29] for National Security Agency (NSA) defined IAM and IEM methodologies to assess and evaluate the risks a database server housing medical information is subject to.
The rest of this paper is organized as follows: section 3 is on the networking issues and the proposed networking solution to medical instrument networking; section 4 is on the security issues for access to such medical instrument and patient examination data; section 5 summarizes our conclusions.

NETWORK OF MEDICAL INSTRUMENTS
Medical professionals need to be present at the location of all medical instruments such as at the bedside of a critical care patient in order to capture vital information.In many cases, medical professionals may have to manually control and adjust parameters of an instrument according to the measurements from a different instrument.Statistical research on personalized care is hard to execute when data are scattered and access is limited.Capturing and entering patient data is still a tedious, time-consuming, and error-prone process even though the information has to be real-time and potentially very sensitive for the well-being of the patient.Patient care itself is prone to errors because of error-prone manual recording of instrument measurements.There is a need for a common standard which allows for inter-networking of medical devices from different manufacturers.

A. Networking of Critical Care Medical Instruments
In 2000, CEN, ISO and IEEE joined to build a single set of standards called ISO/IEEE 11073 for point-of-care device communications to unify the interfaces of all medical devices [30,31,32].Two of these five 11073 standards, ISO/IEEE 11073-30200 (cableconnected) and ISO/IEEE 11073-30300 (infrared-wireless), provide communication services and protocol definitions, consistent with IrDA (Infrared Data Association) specifications which are adapted as appropriate for ISO/IEEE 11073 applications.However, ISO/IEEE 11073 has not been able to generate a meaningful adoption by the industry.With advances in network communications technology, many researchers have been trying to connect isolated bedside medical instruments into a network.Most manufacturers have developed their own proprietary solutions failing to gain general acceptance.
MediCAN™ technology suite creates the interfacing hardware and related communication protocol in an open standard fashion for instruments to network in any healthcare environment.MediCAN™ system works towards a similar goal as ISO/IEEE 11073 [33,34,35]   (ii) MediCAN™ Control Protocol (MCP) is the protocol layered over on ISO 11898:1995 CAN 2.0B (Control Area Network) defining physical layer and data link layer used for integrating medical instruments into the MediCAN™ System.MCP provides plug-and-play capability.Proposed MediCAN™ system is illustrated in Fig. 2 with one adaptor per instrument interfacing with a tightly-coupled CAN-based network for each set of bedside instruments.
Topology and Network: MCP allows direct communication only between a primary node called the Gateway (GNode) and one or more Device Nodes (DNodes) using a shared broadcast CAN bus as shown in Fig. 2. A DNode is the local access point for one or more medical devices.According to CAN 2.0B, the maximum data rate of a 40-meter-long bus is 1 Mbps.GNode is a system providing an access point between a medical instrument network (using MCP) and an Ethernet network (using the MediCAN™ Gateway Protocol -MGP) over UDP.

Figure 2.
MediCAN™ system is composed of instrument adaptors at the bedside connected to a hub and then with other beds to a gateway to be accessed by users of the enterprise network.
Protocol Stack: Physical layer defines how signals are actually transmitted and deals with the description of Bit Timing, Bit Encoding, and Synchronization.CAN is a carrier-sense multiple-access protocol with collision detection and arbitration on message priority (CSMA/CD+AMP).With CSMA, each node on a bus must wait for a prescribed period of inactivity before attempting to send a message, and with CD+AMP, collisions are resolved through a bit-wise arbitration based on priority of each message in the identifier field of a message: the higher priority always wins the bus access.

B. Tightly-Coupled Network at the Bedside
The simulation of MCP was realized with three DNodes and one GNode on the CAN bus using discrete-event simulation approach.Measurement of the latency on frames transmitted between three DNodes and the GNode has been achieved.In particular, the latency only means the delay times any DNode would experience while waiting for the CAN bus to be idle before transmitting their frames.

642
Interoperable Medical Instrument Networking and Access System with Security Considerations for Critical Care

(i) Simulation Assumptions
The simulation utilized the CAN bus with constant data rate of 1 Mbps with no propagation delay and processing delay on any point.There are three DNodes: DNode 1 , DNode 2 , and DNode 3 , assumed that they all have passed Connect/Grant phase and already assigned an unique address from the GNode.DNode 1 always transmits constant bit rate data frames with the first frame randomly generated based on the exponential distribution.DNode 1 is simulating a streaming medical instrument such as a pulse oximeter's plethysmograph output.Streaming outputs involve a constant sampling rate signal to be sent at a constant bit rate.The ultimate goal of the simulation is to analyze the latency experienced by an event (e.g., a low heart rate) reported through a lower priority medical instrument while a higher priority medical instrument is continuously transmitting on the shared link.DNode 1 , DNode 2 , and DNode 3 always transmit random data frames based on exponential distribution with DNode 2 having a higher priority on the bus than DNode 3 .According to MCP frame types, DNode 1 is assumed to transmit report frames, and DNode 2 and DNode 3 to transmit response frames in function calls.Therefore, DNode 1 inherently has the most priority on the bus based on Typ field at the beginning of each frame followed by DNode 2 , and DNode 3 .In addition, for any function calls, the simulation assumed that there was no frame direction from GNode to either DNode 2 or DNode 3 and, certainly based on CAN communication, there was no frame transmission amongst the nodes DNode 1 , DNode 2 and DNode 3 .Only frames from DNode 1 , DNode 2 and DNode 3 to GNode are implemented.At any point of time, all the DNodes have equal bit rates.Each MCP frame contains eight data bytes with total of 128 bits per frame based on CAN2.0B specification.Each simulation was run for 1 to 2.5 second, with each measurement repeated ten times.Data reported is the mean of these ten values.
There are two conditions of contention and retransmission: • If a node tries to transmit when one of the other nodes is already transmitting the frame, the former has to wait until the latter finishes transmission plus inter-frame space interval.• If a lower-priority DNode is about to send its frame at the same time a higher priority DNode tries to transmit, the higher priority node will be able to send its frame immediately and the lower-priority DNode has to stop and wait to resend the entire frame until the higher-priority DNode is done transmitting plus an inter-frame interval.(ii) Simulation Results Simulation 1: A streaming medical instrument (e.g., DNode 1 represents a continuous measurement of oxygen saturation in blood) and another instrument (e.g., DNode 2 represents a temperature monitor) with event reporting capability.This experiment was designed for measuring the average delay of frames from DNode 1 (report data) with variable utilization of DNode 2 (function call data) and constant bit rate at 0.1 Mbps.

Average delay of DNode1 vs. utilization of DNode2
As shown in Fig. 3, as utilization of DNode 2 increases (as for example, when more events are reported due to an emergency), the delay experienced by the highest priority medical instrument (DNode 1 with streaming continuous data) also increases -from 0.2 msec to 2.2 msec.The increase in utilization of the lower priority node causes an increase in delay of the streaming nodes packets.However, the delay of the streaming node (highest priority node) is bounded for increasing rates of data streams in the CAN network.For a given frequency of emergency data reports, the streaming of the high priority medical data will experience a deterministic range of delay.For example, if DNode 1 has a pulseoximeter, when emergency traffic on a low priority temperature monitor on DNode 2 is increased, additional delays would be added to DNode 1 's reports in a bounded manner.
Simulation 2: Considering the same instrument assignments as in simulation 1, this experiment was designed for measuring the average delay of frames from DNode 2 and DNode 3 (as the lower priority nodes on the bus) with several bus utilizations (0.1, 0.5, and 0.9) and variable utilization for DNode 1 .In this scenario, as the utilization of the link increases, frame rate also increases.Therefore, more bus arbitrations are won by DNode 1 resulting in more frame delays for the lower priority nodes.This explains why increased utilization (from 0.1 up to 1) for each of DNode 2 and DNode 3 caused increased delay (from ~2 msec -~20 msec) in Fig. 4  This simulation demonstrates the strength of a tightly-coupled system: a bounded delay for event reports, which provides predictability, as critical information would be reported through events, and is a desirable attribute for medical instrument networks for critical care.For example, if DNode 1 has a pulseoximeter and the monitoring rate is increased, this would not incur any additional delays for a low priority temperature monitor on DNode 3 .
The simulations above demonstrate key features of the MediCAN™ protocol that would be beneficial for multiple devices networked in the intensive care environment.For example, simulation 1 suggests that increased utilization on DNode 2 can increase the delay experienced by DNode 1 (hosting a high priority device).This would allow a device reporting an emergency, such as an abnormal temperature to increase its utilization of the bus, while a streaming device is delayed -but, only in a bounded fashion.Critical monitoring needs of ICU would benefit from somewhat predictable delay expectations.
The data from the medical devices interfaced on the network can be automatically stored in the database for use as electronic medical records.In the following section, we briefly discuss security of stored data, and present a framework for evaluation of security constructs.

SECURITY CONSIDERATIONS
The responsibility of protecting health information stored in a database is critical for security and privacy management.Access to EMR should be granted on a strict needto-know basis.The scope of this case study was to identify, assess and evaluate risks faced by a database server.To demonstrate the use of open source tools and NSA triad for HIPAA compliance, a server hosting a web application with a Structured Query Language (SQL) database backend was used.The server specifications are as follows: Operating System; Microsoft Windows 2008 server, Database; SQL Server 2005 and Web Application Server; IIS7.0.
NSA's triad for information security (INFOSEC) consisting of INFOSEC Assessment methodology (IAM) [36], INFOSEC Evaluation methodology (IEM) [37] and Red Teaming methodologies were employed to demonstrate a process that HIPAA covered entities may use to assess their policies and procedures, scan for vulnerabilities, and check for the level of difficulty of their exploitation [28].

Phase I -INFOSEC Assessment Methodology (IAM)
The assessment phase involves (1) review of medical information security policies, procedures and practices already in place, and (2) defining critical medical information, and creating an information criticality matrix.Details of the policies and procedures are dependent on the system, institutional and application requirements.We adopted the security policies and procedures mandated by the Information Technology Office at the University of Houston.Components of the critical medical information related to patient privacy include data on identity information [21], health information, suggested treatment, and login credentials.After identifying medical information critical for our application, the information criticality matrix shown in Table 1  .The risk rating for each of the CVEs identified was obtained from the National Vulnerability database and a vulnerability matrix was created to assess the amount of risk our organization may face if any of these vulnerabilities is exploited [37].This matrix was built on two axis points; (1) the Information Criticality/Priority defined during Assessment process (shown in Table 1), and (2) the Vulnerability Priority as defined by industry standard ratings for each technical finding of CVE -Common Vulnerabilities and Exposures.The scores for each block in the matrix are then determined based on the industry ratings for the found vulnerabilities, input from the IAM about the criticality of each information type, and the opinion of the evaluator on the actual impact of the vulnerability based on expertise.Using this procedure, and based on the Common Vulnerability Scoring System (CVSS) severity rating, we determined the vulnerability matrix for our test server (see Table 2).
For the test server in this study built based on the networking and storing of medical instrument and patient data, the vulnerability matrix in Table 3 was created Table 3. Vulnerability ratings identified for a patient information database server.

Phase III -Red Teaming Methodology
The last phase of the NSA Triad, Red Teaming, involves conducting penetration tests to gain unauthorized access to the test server.Most data storage servers are networked to allow accessibility through the internet.The four most common attacks to compromise a database server include direct connection, password cracking, SQL Injection and direct exploit [38].First, an attacker can try to directly connect to a SQL server without firewall protection.Thus, placing database servers behind a firewall is the first line of defense against their compromises.The attacker can easily identify, scan for and establish a connection with naked servers using Nmap and SQLPing (tool used to (i) reveal information such as details about all named instances installed on a server prior to connection, and (ii) send discovery packets to entire networks for mass interrogation).Second, via password cracking a hacker can compromise all of the data stored in the database.The attacker can attempt to look for and crack weak passwords used for logging in to the SQL Server.SQL Servers configured with a default password are most prone to this kind of attack.Additionally, weak user passwords for SQL Server authentication mode are prone to brutal force and dictionary attacks using any freely available password cracking tools [39].Third, via SQL Injection, an attacker or a malicious insider compromises the application that provides the interface for database access, and uses SQL statements to edit, delete or update the patient data.The attacker could also modify stored procedures to create new system logins.He/She could 'watch' the database and have access to any patient data entered in the database.SQL Injection attacks exploit the vulnerabilities in query text such as the single quote apostrophe that is used as a string delimiter, the line comment identifier of the double hyphen, the semicolon used to delimit separate SQL queries on one line, the union operator to append data from other tables to the originally intended result set, and the ability to find out database settings, table names and column information [40].Finally, a hacker or an insider with a malicious intent can directly exploit servers by making use of tools like Nessus or Microsoft Baseline Security Analyzer (MBSA) to look for database and underlying OS vulnerabilities.Unpatched servers found can be exploited by a hacker using a penetration testing tool like Metasploit's msfconsole.Metasploit can be downloaded directly from the Metasploit website [41].Thus in the Red Teaming Phase, we used SQLPing, Metasploit and SQL Injection methodologies to check if the database could be exploited.Table 4 lists the risks identified during the preliminary testing of our system, and outlines strategies to address the risks.4. List of risks identified using the NSA triad assessment and mitigating strategies.
General SQL server 2005 security best practices [42] can help covered entities securely configure, manage and audit their database servers.With a little effort, the tools described in this study can successfully depict an organization's security posture and help fix vulnerabilities discovered.

CONCLUSION
We have presented security overview and network architectural considerations for medical instrument networking in critical care.Network architectures are presented with a comparison between a proposed standard of IEEE 11073 suite of standards and a tightly-coupled case implemented with MediCAN™.The comparison showed strengths of the standard as a unified object-oriented information model with high overhead in the networking architecture.On the other hand, the tightly-coupled system showed less overhead on the network with strengths in event/alarm handling while a stream of monitoring data is present on the shared link.We have implemented such a patient information server with storage of medical data in a database.According to HIPAA, any risk associated with these stored data records needs to be identified, quantified, mitigated and monitored.In this paper, we proposed the use of NSA triad and open source tools for health care providers to optimize HIPAA compliance of medical data in storage.Although there are numerous other open source tools, we implemented a set of tools that are considered to be the most capable and ranked among the top 10 security tools.The INFOSEC Assessment phase defined critical medical in being a candidate to become an open standard.MediCAN™ addresses communication services and protocol definitions based on Control Area Network (CAN) communication.MediCAN™ uses instrument adaptors and networking equipment to connect instruments on a CAN bus and then to a network, such as the Ethernet.(i)In IEEE 11073, both wired and wireless versions are intended to provide communication between medical devices and external computer systems with plugand-play and interoperable interfaces.Based on IrDA specifications, the connection link between Device Communications Controller (DCC) and Bedside Communications Controller (BCC) is a half-duplex, point-to-point communication.Topology and Network: BCC or primary node is a hub connecting a local or remote external site via LAN or WAN.DCC or secondary node connects each medical 640Interoperable Medical Instrument Networking and Access System with Security Considerations for Critical Care instrument to the communication network via BCC.Each device has a DCC and a BCC connecting to a gateway[30].As shown in Fig.1, adapter modules (DCC) together with the bedside modules (BCC) create the interfacing of the medical instruments to the network.Infrared Link Access Protocol (IrLAP): BCC as a primary node would initiate a transaction such as device discovery or link negotiation.The secondary node (DCC) responds when spoken to by the primary.IrLAP consists of four phases: Device Discovery, Link Negotiation and Connection Establishment, Information Exchange, and Disconnection.Every frame has an address, a control field, and the payload.

Figure 1 .
Figure 1.IEEE 11073 provides interfaces of instruments to the network through DCC-BCC (device and bedside communication controller) pairs.Implementations of this architecture have been limited to single PC demonstrations.The communication is based on IrDA and RS-232.

Table 1 . Information Criticality Matrix. Critical information is classified as high, medium and low based on the financial and reputational losses faced by the covered entity in the event this information is lost or misused Information Confidentiality Integrity Exposures
) numbers.Information about the Common Vulnerabilities and Exposures can be obtained from http://cve.mitre.org/cve/.Each CVE is given a rating by the Common Vulnerability Scoring System (CVSS)[xviii]