Teaching Patient Monitors Communication Skills

From blood-pressure monitors and pulse oximeters to ECGs and blood glucose meters, patient-monitoring devices are a ubiquitous fixture in the OR, the examination room, and the home. But how does the veritable forest of patient-monitoring devices that grace medical facilities worldwide communicate with doctors and patients? What enables the medical professional to glean vital information about a patient's condition from these devices? The answer is software.

In patient-monitoring applications, software platforms perform myriad functions. From the bottom up, they provide the operating system architecture upon which medical device manufacturers can engineer a host of monitoring applications, graphical user interfaces, filtering technologies, and much more. However, to ensure that they are suitable for use in healthcare settings, software systems must undergo rigorous test and validation regimens. Moreover, the moment that patient monitors begin to communicate with doctors and clinicians over networked systems, data security becomes crucially important. Meeting these and other challenges is at the heart of designing and developing software platforms for patient-monitoring applications.

In the Beginning Was the OS
Open source or proprietary: That is the question facing medical device designers and developers when they must select an operating system for their patient-monitoring applications. "One trend in the development of medical devices is that open source software is gaining traction, including in patient-monitoring systems," remarks Chris Ault, product manager at QNX Software Systems (Ottawa, ON, Canada). "But there are hidden problems and costs associated with this trend." In contrast to open source operating system software, QNX's platforms are specifically tailored to meet the exacting specifications and standards required by the medical device manufacturing industry and a range of national regulatory bodies.

Because they are free, such open source platforms as Linux are attractive to software designers and developers, Ault comments. In addition, they offer a range of free development tools and provide engineers with access to a broad ecosystem of talented software developers. Nevertheless, medical device manufacturers that rely on open source operating systems are finding it increasingly difficult to meet regulatory, certification, and approval requirements without migrating beyond their core capabilities and becoming operating system companies in their own right. "Such manufacturers," according to Ault, "need to adopt, manage, and maintain the open source distribution themselves. As developers post changes on the Web, for example, OEMs must incorporate these changes but also perform the risk analysis these changes may make necessary." Thus, manufacturers that use open source operating system software incur overhead expenses in order to satisfy medical device regulatory requirements.

"One advantage of using QNX for medical devices is that we've already achieved compliance with the international standard IEC 62304, a standard harmonized by the European Union and the United States that specifies life cycle requirements for the development of medical device software," Ault says. "Thus, the OEM and its engineering team don't need to have intrinsic, inside, detailed knowledge of our product." Instead of having to own and maintain the operating system, medical device software developers that use a proprietary operating system can focus on their applications and intellectual property, he adds. "With open source, in contrast, the team needs to be much larger in order to maintain the OS kernel, which is really just running the system and not providing any unique intellectual property."

To achieve and maintain certifications and approvals for medical devices, OEMs must be able to prove that their devices--including the software components--are designed to function as intended and do not jeopardize patients or medical personnel. Thus, manufacturers must perform detailed analyses to prove that failure cases are handled properly and that their devices will operate properly. "In order to do that with open source software, device manufacturers and engineers need to understand the code on a line-by-line, function-call-by-function-call basis for the internal kernel image," Ault notes. "For Linux, this amounts to 2.7 million lines of code, which changes at a rate of 10,000 lines per day." Consequently, substantial effort is required to perform fault analyses and maintain the kernel for a portion of the software that's not related to the medical application itself.

Managing Risk

Used to communicate vital medical information between patients and caregivers, monitoring devices--including their software kernel--are subjected to thorough risk analyses to ensure against performance failures. During risk analysis, all of the functions and operations of the software image must be understood and documented in order to prove that subcomponent failures will not cause the medical device to fail, potentially causing harm to patients or medical personnel. Regardless of the size of the operating system, according to Ault, the risk-analysis process is very time-consuming, requiring intimate and detailed knowledge of the interworkings of the operating system.

By performing risk analysis themselves, providers such as QNX offer fully validated software products to manufacturers. "To ensure that the patient-monitoring operating system meets IEC 62304 standards, which address the details of the software-development lifecycle, QNX's 62304-compliant archive is shipped with a third-party-validated statement of compliance," Ault explains. "This statement certifies that we have performed risk analysis and fault handling and that the kernel complies with the standard."

In the medical device sphere, software risk mitigation is all about developing robust software platforms with the ultimate goal of reducing failure issues in the field, remarks Scott Scargle, OEM technology manager at SunTech Medical (Morrisville, NC), a provider of noninvasive blood pressure (NIBP) technologies. The biggest focus of risk management today is proving that medical device software is free of identified hazards--especially since the adoption of IEC 60601-1, clause 14, which addresses the development of programmable electrical medical systems and applies to hardware/software integration. "This philosophy is being emphasized more now than in the past," Scargle says. "In the past, the focus was, 'Here's the requirement, and here's how you test for it.' Now, there's a lot more emphasis on identifying all of the risks and hazards and documenting how a company has mitigated them to acceptable levels." As a result of the more up-front planning, testing, and risk-mitigation efforts required by IEC 60601-1, patients and healthcare providers should be safer, Scargle adds.

For example, in NIBP applications, pressure on the patient's arm represents a potential safety hazard. Overpressure or maintaining prolonged pressure in the cuff can damage arm tissue. The role of software in such applications is to control the pneumatic components that create and release this pressure. "As an NIBP supplier, one of our main focuses is understanding such hazards," Scargle says. "Our role is to document the risks, show that we have mitigated them, and then provide this information to our customers so that when they implement our modules, they have the documentation and the proof that these risks have indeed been mitigated."

Risk mitigation involves rigorous software testing, Scargle says. After being provided with a range of requirements, engineering staffs implement these requirements during the software design and development stage. "We don't rely on a single point of failure," Scargle adds. "It's going to take at least a double failure to cause a problem. That holds true for both hardware and software."

While the increased focus on risk management is crucial for improving patient safety, efforts to understand, prove, and document the risk-mitigation process are demanding and costly. "However, while these efforts slow down the development of new products, the good news is that new products will be safer and perform more reliably by complying with the new standards," Scargle comments.

Concentrating Data
ORs, examination rooms, and patient bedsides are replete with many individual devices dedicated to monitoring a host of vital signs. However, the sheer volume of monitoring devices in the procedure room would impede rather than promote communication between patients and doctors if not for software systems that concentrate vast amounts of data in a single place.

Trends in the area of designing and developing patient-monitoring systems can be boiled down to connectivity, remarks John Carey, senior vice president, business development of Foliage (Burlington, MA). "But while the move toward greater connectivity is not new, what is new is the demand to concentrate all of the patient-monitoring data gathered in a surgical setting, especially ambulatory settings in which procedures happen one after another," Carey says. "Because a lot of different monitoring goes on in such environments, it can be difficult for doctors and clinicians to keep track of everything."

Contributing to improved data communications in the OR and other healthcare settings, Foliage develops software platforms that concentrate large volumes of information in a single user interface. "Picture a cardiac catheterization lab," Carey says. "There are going to be lots of different monitors around, from vital signs to other physiological monitors. There will also be ultrasound or fluoroscopy imaging systems for the physician to view the insertion of the catheter. Information from these systems will be captured and fed back to yet another screen." Whether image- or data-based, the trend is for all of this information to be relayed back to a single multifunction display.

Data concentrators can communicate with patient monitors because their software components are designed according to a set of protocols and data-connectivity standards that must be followed by all software providers, according to Carey. For example, in order for a data concentrator to communicate with the data generated by a vital-signs monitor in an operating theater, an interface is required that provides medical staff with access to these data. Regulating such communications in the healthcare sphere are the Health Level 7 (HL7) standard for data-based information and the DICOM standard for image-based information.

To enable suppliers of data concentrators to retrieve information from patient monitors or imaging systems, device manufacturers must make their data available in HL7 or DICOM format, respectively. Conversely, data concentrators must also be able to understand HL7 and DICOM. Thus, to facilitate communications among patient monitoring systems, every monitor or imaging device in the operating theater or procedure area must be HL7- and DICOM-compatible, allowing different types of patient data to be displayed on a single screen and enabling clinicians and physicians to view them.

As a result of efforts by such software development companies as Foliage, large screens resembling those used in air-traffic-control facilities are beginning to appear in operating rooms, Carey notes. Regardless of how many vendor-specific monitors are used in the suite, data concentrators gather and display all the data generated by these devices on a single screen, helping caregivers to focus on the patient and accelerate procedures and surgeries.