Customers Want More than the Box

There are many barriers to entry in health care: regulatory hurdles, entrenched competitors and gatekeepers like group purchasing organizations (GPOs). Increasingly, connectivity is becoming a barrier to entry - or perhaps a new price of admission. There are few medical device product categories that don’t have some connectivity requirements. (More on the actual requirements below.) But besides buying the embedded device, providers are increasingly interested in buying whole product solutions.

Coined by Geoffrey Moore, a whole product solution is just that, all of the components and services required to fully realize the potential of the overall solution. Thus if one of your connectivity requirements is integration with an EMR for electronic charting, just putting a serial port on your device is not a whole product solution. Of course neither do you have to do the whole solution yourself. Frequently the best strategies entail providing part of the solution directly (developed yourself, outsourced, licensed, etc.) and creating the rest through business development and alliances with other vendors.

Connectivity As Competitive Advantage

Sometimes connectivity can be leveraged to gain competitive advantage. Point of care testing (POCT) startup EPOCAL is a great example. This company has apparently done an exemplary job in recognizing market requirements and formulating a design that maximizes connectivity features and capabilities, while minimizing development costs and time to market. If this new system is successful, established competitors will have to scramble to catch up.

CardioNet is another startup that leveraged connectivity from the get go.  The acquisition of ECG signals is pretty routine. The algorithms for analyzing ECGs are also well understood, but continues to yield occasional innovations. Besides superior ECG analysis algorithms, CardioNet implemented a near-continuous connection with a remote service center that wirelessly acquires and reviews patient ECG waveforms - during the diagnostic test. This continuous recording and analysis contrasts with conventional holter monitors that record a batch of heartbeats (typically 24 or 48 hours) that are read at the end of the study. This unique connectivity enabled workflow provides CardioNet with unique clinical capabilities that have resulted in much higher diagnostic confidence than conventional holters - and a sustained competitive advantage. (more…)

The story provides an overview of connectivity in both acute care and remote monitoring, from both vendor and customer perspectives. The story closes with this observation:

“The medical device companies are becoming chimeras, where they’re part IT company, and they’re part embedded system company,” Gee noted. But, as long as their mindset remains that of an embedded system company trying to protect the “black box” of proprietary system design, it will be difficult to move forward, he said.

Jason Williams expresses a similar lament about the lack of connectivity in a great post on NeoTool’s blog titled, Bridging the Device Divide. In a comment to the post, standards guru Todd Cooper observes:

Bottom line is that medical device vendors make more money with either proprietary connectivity or strategic partnerships, and end users - provider orgs - do not demand open standards-based connectivity. It is often called out in RFPs - but gets dropped in the decision making process. K-P [Kaiser Permanente] is one of the few org’s drawing a line in the sand on PnP med dev connectivity. “Collaborative partnerships” are the status quo and have been the basis of controlling and limiting device connectivity both at the PoC and to the enterprise.

Todd’s referring to Kaiser’s new purchase contract language that specifies medical device vendor responsibilities for supporting connectivity. You can read an except of the contract language in this post. Rumor has it that Philips has recently declined to meet some of those requirements; it will be interesting see if Kaiser sticks to their guns and drops Philips as their patient monitoring vendor going forward.

In Jason’s blog post he quotes Robert Nadler who says, “…our business is building medical devices, not EMR solutions.” I don’t think medical device vendors will have the luxury of maintaining that point of view for much longer. I spoke with David Freeman and Munesh Makhija of GE Healthcare’s patient monitoring group a few weeks ago. They attended the CMEF and saw an exhibit floor filled with vendors who are doing the same color displays with waveforms that GE is doing - at 30% lower cost. Rather than playing the manufacturing cost game, GE is looking to software to add clinical value and differentiate from low price competitors. Philips seems to be taking a similar approach with their acquisitions of Emergin and VisICU.

The days of staying in that nice familiar embedded device comfort zone are limited. This has always been the case as connectivity transforms medical device product categories. Remember E for M? They were once the market leader in cath lab recorders. They too decided they didn’t want to do software. They contrast nicely with Marquette Electronics who saw connectivity as an opportunity and redefined the product category - driving E for M out of business and capturing a major share of the cath lab market. (Another great example of leveraging connectivity is Alaris.)

You can access both Jason’s and Bob’s excellent blogs from the Blog Roll in the right hand column of this web page.

Yours truly was quoted in a HealthLeaders technology story about, you guessed it, medical device connectivity.

Information technology consultant Tim Gee has a nontechnical description of the current state of connecting medical devices to clinical information systems: “It’s a mess.” Not that direct data capture from medical devices is impossible; some hospitals have been exporting data from devices into clinical information systems for years. But as Gee and other experts point out, the effort can be so confounding that many hospitals don’t even try. Even in highly automated inpatient settings, a common method of data capture from the plethora of monitors, pumps and ventilators is good old pen and paper. Someone, often a nurse, writes down the value and either logs it on paper or re-enters the data online.

The writer, Gary Baldwin, must have caught me on a bad day, it seems I couldn’t say anything nice about anyone.

Trinity exemplifies the industry’s challenge in capturing data directly from medical devices. The health system maintains more than 2,000 physiologic monitors and 9,750 IV pumps, says Kini, adding that the equipment comes from at least five different manufacturers. In this scenario, the key problem, Gee contends, is the absence of industry standards for how data is formatted and exported from the devices. Even devices from the same manufacturer may vary, he says. “Unless a device has the identical model number, the protocol may change,” he says. “To the medical device vendor, their product is the center of the universe. The idea of connectivity is one that vendors have to be pushed kicking and screaming into by their customers.”Hospitals have been willing accomplices up to now, Gee acknowledges. “Most hospital IT departments don’t think about data capture from devices,” he says. “They suffer from the same perspective vendors have. The IT department figures nurses will just type in the data.”

Gary also interviews Julian Goldman, who lends his more soothing perspective to the challenges of connectivity.

Be sure to read the whole thing.

I found a blog reader’s email in my inbox this morning. It seems not everyone at his hospital is keen on investing in medical device connectivity. He wrote about a near term need for connectivity to a planned EMR. Sadly, medical device connectivity is sort of the Rodney Dangerfield of EMR deployments, frequently an afterthought or put off for some “future phase” mainly due to complexity and cost. What follows is my reply.

Device connectivity impacts EMR adoption in a number of ways. (In no particular order.)

• User adoption - a jaded observer could view many HIT projects as an exercise in getting one set of users to either change the way they do things, or to take extra steps, for a benefit of other users. Manually entering medical device data into an EMR is widely perceived as “extra work” or “double entry” by caregivers on the floor. This occurs when physiological parameters from devices are manually recorded and then later typed into the record. Automated acquisition of medical device data is perceived as a benefit of EMR adoption by most caregivers, because it’s - you know - actually automating an otherwise manual task. Since a big part of the success of an EMR deployment rests with caregivers, medical device connectivity is a big carrot that can engender EMR adoption; of course the opposite (the negative impact of manual entry of device data) is also true.
• Timeliness of data - a big benefit of EMRs is the ability to get data into the electronic chart as soon as it is available by integrating various diagnostic (e.g., radiology, lab) and medication systems (e.g., an electronic MAR and integration with pharmacy IT). Data from medical devices is frequently overlooked as a source of data with a timeliness requirement. The manual entry of data from medical devices is frequently delayed. Caregivers are frequently interrupted in their tasks, and the act of entering the data into the electronic record can be delayed by minutes or hours. Which brings me to the next issue:
• Missing data - as caregivers write down medical device data (on scrap paper, their scrub suit or hand) they sometimes get distracted and lose that scrap paper or forget. Consequently, that data never makes it into the electronic record. Over 50% of point of care diagnostic tests are never recorded in the patient’s chart, let alone an EMR. There is a lower rate of missing data for vital signs data.
• Poor data quality - the inherent weaknesses of paper charts include illegibility of entries, entries that are incomplete or not made, transposed data, or accurate data entered for the wrong patient. Without automating the acquisition of data, an EMR really only improves illegibility. Thus manually recorded device data that is keyed into the EMR can result in transposed data or data entered into the wrong patient’s record. Medical device connectivity eliminates these problems, just like an interface to your lab system.

All of the above issues become more important as patient acuity increases because the higher the acuity, the more device data that’s generated. Hospital patient acuity is increasing, as reflected in the hospital trend to increasingly monitoring patients outside of conventional monitored units (ICU, telemetry, step down, etc.).

I can think of two additional drivers for medical device connectivity:

1. The Joint Commission’s new National Patient Safety Goal for the identification and response to patients with a deteriorating clinical condition (goal 16) necessitates that hospitals tighten up the completeness, timeliness and accuracy of vital signs data (and in some cases, increasing the frequency). Research has shown that vital signs capture is pretty poor in many hospitals (more on this later). Medical device connectivity will help maximize the quality and timeliness of your vital signs data.
2. Starting next year, CMS will not reimburse for certain adverse events. These “hospital acquired conditions” are all preventable and many focus on infections. While care practices like ventilator toilet will minimize these infections, high quality medical device data (along with lab data) will allow your staff to identify infections most quickly. Since CMS will no longer reimburse you for the costs to care for these infections, the sooner they are identified, the sooner they can be treated - minimizing the financial loss to the hospital. (More here and here.)

For data and references to put around the above, there are a number of sources (besides the links embedded above). Vital signs vendors with device connectivity features like Welch Allyn (Connex) or Sensitron are the best source for data on the incidence of missing, delayed or inaccurate manual data. I would talk to both vendors to increase your pool of data.

Another source of information (one that I forgot to mention to my reader) includes studies on pervasive short falls in vital signs documentation. This was one of the main topics at the 4th annual Rapid Response Systems: Teams Systems for Safety conference. You can access the conference presentations here. This presentation by Gary B. Smith MD provides specific data on the completeness and accuracy of typical vital signs records.

But medical device connectivity justification is really the easy part. The lack of standards and vendor’s obsessive pursuit of proprietary end-to-end solutions can make connectivity very expensive at best, and confusing and hard to use at worst. It’s easy to get painted into a corner by proprietary systems, or forced to adopt a mosaic of systems from vendors who only provide part of the solution. And due to the cost, not to mention the pervasive use of medical devices, implementing connectivity must be done in phases over time.

A good connectivity plan is based on a thorough needs assessment that encompasses current practice and future plans for HIT, telecommunications, medical device purchase/replacement, and care delivery processes. Initiatives like continuous quality improvement, improving patient flow, and extending patient monitoring into new clinical areas all impact connectivity requirements. Then all of this must be distilled into a set of requirements used to create a phased connectivity plan.

The next challenge is to address vendor variability. Besides details about what and how vendors do what they do, you have to try to take into account their roadmaps, or future product plans - otherwise you might end up with a plan to use products that you can’t buy from anyone.

The end goal of all this is a connectivity roadmap for your hospital that takes into account planned funding, anticipated changes in the needs assessment areas mentioned above, and vendor variables all laid out in a timeline. Now you’re ready to put together a capital budget for phase one.

So, hopefully I’ve helped with articulating the need and justification for medical device connectivity. And just like I told me reader, if you’ve got questions, let me know.

If you gain the momentum to move forward with connectivity in your hospital, and you’d like some help let me know. I can provide targeted feedback and advice, come in and do the whole thing (assessment, connectivity roadmap, system design, and vendor selection) turn-key, or anything in between.

Pictured right is a serial cable dongle typically used to connect legacy medical devices that don’t have network connections.

UPDATE: Health Data Management reports that Applied Digital subsidiaries Verichip and Digital Angel are working with sensor company Receptors LLC to create an implantable glucose sensor that transmits data using a passive RFID scheme.

The following is a continuation from the the Improving Patient Safety through Medical Device Interoperability and High Confidence Software joint workshop last week in Boston. I’ve got a bunch more notes that I’ll be tweaking and posting this week. This next bit is from a panel discussion that described the need for high confidence systems and interoperability. The panel was introduced by co-chair Julian Goldman.

The foundation for any quality product is requirements. Inadequate or incorrect requirements mean not just a lousy product, but one that could be unsafe or unreliable. This panel discussion targets the clinical need driving high confidence systems and interoperability.

A market for any kind of product is made up of both producers and buyers, each with their own responsibilities. Device vendors (and to a lesser degree, HIT vendors) have not demonstrated much command of either a good understanding of the workflows that occur around their devices, or a mastery of workflow requirements gathering. To achieve success with medical device interoperability, one must have high quality requirements.

At the same time, buyers are responsible for actively shaping demand and motivating vendors to build the best products possible with the right features. Healthcare providers must demonstrate a market for interoperable systems in order to provide vendors the motivation (and eventual financial return) on more comprehensive requirements gathering efforts.

The expectation is a phased market implementation, with medical device connectivity first, and then interoperability between devices, and between devices and systems. Such advances must support clinically meaningful use-cases. Standards can be used to mitigate risk and support interoperability, but they have yet to mature sufficiently to make connectivity or interoperability easy: a classic “chicken or the egg” conundrum.

The Clinical Needs panel included:

Jeff Cooper PhD, Anesthesia Patient Safety Foundation
Sandy Weininger PhD, FDA
Jennifer Jackson MBA, CCE, Brigham & Women’s Hospital
Jim Philip MD, Brigham & Women’s Hospital
Steven Dain MD, University of Western Ontario
Jim Fackler MD, Johns Hopkins
Moderator: Julian Goldman MD

Cooper’s introductory remarks went to his motivation for participating in the APSF and his interest in medical device interoperability. He described two experiences, the son of friend who went into respiratory arrest on a PCA. In another experience, a friend was in the hospital and he saw first hand what is the best and worst (disruption in care, interrupted communications) in hospital care.

“Hospitals today are not safe – if you go into the hospital, take someone with you. One of the biggest problems is that technology advancement has outstripped the infrastructure (how the technology is deployed and used) to ensure safety. The technology with perhaps the biggest potential impact on patient safety is the interoperability of medical devices.”

After Jeff Cooper described the need, Sandy Weininger, noted some accepted approaches to developing high confidence systems. Looking into the future, he also offered some rhetorical questions on creating safe and effective systems.

“Absolutely Safe,” how do you define it? How do you implement it? In reporting to the FDA (users voluntarily report, and manufacturers have mandatory reporting) they receive more than 100,000 reports per year. The FDA estimates that that figure represents just 2% of actual incidents. Of the fraction of events that the FDA does receive, they are hard to analyze and understand.

Best practices for interoperability and systems integration include:

• Clinical requirements are necessary to understand what a complex medical device system is intended to do
• “Interoperability” must be described using rich set of scenarios/use cases
• Must address safety, security, effectiveness
• Look at current clinical challenges and hazards, mitigations, future solutions and new risks

Given that this whole interoperability thing extends way beyond the actual “medical device,” Sandy went on to note the legal definition of a medical device:

An instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, orintended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it’s primary intended purposes through chemical action or on not dependent upon being metabolized

Device vendors, systems integrators and hospitals should study this definition.

Weininger also asked some important questions, like, “How do you enable innovators (who lack the resources to create their own vertically integrated systems) to contribute innovations that work safety?” and “How do you validate a system that is greater than the sum of its parts?”

He contrasted how one builds a conventional medical device with additional factors that should go into the broader scale systems resulting from interoperability and systems integration. The issue is a systems engineering challenge that requires the involvement of numerous specialties. This is not new – aviation is a great example. The best solutions require a multi disciplinary approach. These skills include control systems design, operations research, safety engineering, reliability engineering, interface design, cognitive systems engineering – human factors, in addition to communication protocols and security engineering.

Risk analysis is essential to designing a safe system. Weininger suggested the IEC 60300-3-9: Risk Analysis of Technological Systems standard as offering a good methodology for risk analysis.

Another important factor is the proper identification and description of requirements. Two common approaches are clinical scenarios and use cases. Clinical scenarios are descriptions of the current clinical situation and related problems identified from clinical stories, adverse event reports, near misses, etc. Use cases are a detailed look at a specific part of the clinical workflow. A work flow may not be required for a use case, but is helpful for examining human interaction.

Weininger wrapped up asking, “so, when is a system validated?” The answer with a stand alone embedded system medical device is unambiguous. When medical devices and information systems are combined, the answer is much less clear.

Jennifer Jackson discussed the recent popularity of ethnographic analysis for capturing medical device requirements. But even with these expensive and supposedly sophisticated requirements elicitation techniques, Jackson noted that providers are really struggling with good connectivity solutions in the absence of solutions from vendors that meet their needs.

The vast majority of connectivity solutions fall short, considerably short of safe and reliable systems needed by hospitals that are easy to use, and easy to maintain and support. One of the key reasons for this is a dearth of good requirements.

Jackson described clinical engineers as the interface between medical device vendors and regulators on one hand, and nurses and physicians on the other.

She noted that medical devices have traditionally had a 7-10 year lifespan. With the adoption of general purpose computer components into medical device systems, this length of time is falling. Vendor software updates (especially those driven by operating system patches or connectivity problems) are most problematic. The need for software updates is very unpredictable, and software releases frequently take 6 to 12 months – way too long. Vendor suggested workarounds place considerable burden on providers as they retrain users to the new operation, and because workarounds usually require some new manual steps that can introduce user error and lower productivity.

Current interoperability options are typically proprietary end-to-end systems. This is good because a single vendor provides quality and design control, and there’s a predictable market for the vendor. For customers, there is limited choice and “best of breed” is reduced to “what we have to offer.”

Jackson also noted a structural weakness that was a theme of the conference: that interoperability is usually a post-planning, post-market thought. Consequently, the solution is usually compromised by:

• Unreliable performance, slow (and too frequent) software updates
• Poor vendor ability to support integrated systems
• Poor design with multiple points of failure that are – what do you know, prone to failure.

Jackson used an example of a ventilator-patient monitor alarm integration project they did in an ICU. The layout of their ICU inhibits the ability to hear ventilator alarms.

The solution from the vendor was “dongle-ware,” an external module that connects to the serial port on the back of the device. This approach works most of the time, but the interface is brittle with many links in the chain of connectivity that can render the interface inoperable.

Jackson described currently unmet connectivity requirements in a slide generously titled: Interoperability Tomorrow. In this scenario, vendors have a real competency in systems integration, providing software updates in a timely fashion, with technical support that understands general purpose computing environments in addition to medical devices and clinical environments.

Even with improved vendor execution, we’re still limited to what the device will output (not everything), and the interface still represents multiple points of failure in the system. This current state of connectivity adds unplanned costs to installations. The costs for interfaces are expensive (plus cabling costs), and the hardware required takes up a lot of space (often unallocated at the design stage).

Kaiser has estimated simple EMR connectivity costs at $10,500 per bed. Not including CE/IT labor to configure, support and maintain the integration.

The perfect solution uses a standardized interface language embedded in the medical devices. No dongles. Systems integration, clinical and technical support tools are incorporated with other utilities. No dongles. And these capabilities are offered as part of the basic connectivity offering, rather than positioned as optional, higher cost features.

The cost to retrofit their hospital is prohibitive. The cost of moving forward when purchasing new technology is also very high.

Jim Philip MD, MGH, is a clinical anesthesiologist and the director of bioengineering at Brigham & Women’s Hospital. His contribution to the panel discussion was a case study highlighting the potential benefits of high reliability and interoperability.

The case is a laparoscopic cholecystectomy on a middle aged female with no other medical problems.

Preparation included:

18 Gauge IV catheter
Monitors applied and connected
ECG
NIBP (q 1 minute)
Oxygen saturation (Pulse Oximeter)
Airway Gas Sampling and monitor for
Oxygen
CO2
Agent

Anesthetization:

Sodium Pentothal for Induction of general anesthesia
Tracheal tube inserted under direct vision
Inhalation anesthesia administered via Anes Delivery System
Moderate-duration muscle relaxant (Vecuronium 4 mg)
18 F Gastric Tube passed via mouth
Stomach emptied of gas and liquid

Abdominal Insufflations (where they inflate the abdomen for visability):

GI Surgeon, trained in laparoscopic surgery, division director, began surgery
15:28:16, BP 128/66 and pulse 90 / minute,
Minute Ventilation = 5.7 L/min, ET pCO2 = 30
Veris Needle placed in the abdomen for insufflation
Trochar with self-retracting incisor
Scope inserted

Monitoring Observations:

15:29:20, the NIBP monitor failed to record a blood pressure
15:29:40, peak inspiratory pressure (PIP) rose as peritoneal pressure was raised with insufflation
15:30:00 minute ventilation (VE) = 5.7 L/min and constant 15:30:40, pulse oximeter failed to record SpO2 or heart rate
but pulse was palpable
15:31:00, end-tidal CO2 fell from 30 mmHg to 18 mmHg, heart rate constant at 90 / minute, peripheral pulse not palpable, carotid pulse weak.

Clinical Communication:

15:31:00
Anes: “was there was bleeding when you inserted trochar?”
Surgeon: “a tiny bit”
Anes: “If there was bleeding, would you see it?”
Surgeon: “No, not able to visualize”
Anes: “I think you have major bleeding”
Surgeon: “What should I do?”
Anes: “Cut now
Surgeon to Scrub Tech: “knife”
Surgeon Action: Incision
15:31:10

Action:

15:31:10 Abdominal Exploration Incision
Surgeon Observation: Blood poured out, 2 L in suction
Surgeon Action: Finger on palpable site of bleeding Aorta
Call for Vascular Surgeon to assist
Surgeon: ”How the ‘h” did you know that?”

Anes: “That’s why we monitor carefully and continually and try to integrate it all”.

Resuscitation:

15:31:20 Anes Action: Call for help (more IV)
3 L Lactated Ringers solution over 10 minutes
Albumen 75g
15:45:03 NIBP = 44/31, ETCO2 = 24 mmHg
2 U Packed Red Blood Cells, more late
15:47:20: pulse 117, NIBP = 83/47, ETCO2 = 24
15:50:00 ABGs: pO2= 468, pCO2= 37, BE=- 4, Hct=13%
16:05:00 NIBP = NIBP = 100/60
Event declared under control
17:00:00 Emergence with patient awake and alert

Resolution:

PO Day 2 Ileus resolving
PO Day 4 Patient discharged home, alive and well

Philip noted that until they could detect the problem and make the diagnosis the patient was at considerable risk. Here’s a summary of the time line:

15:28:16 Event
15:29:20 First sign
15:31:00 Diagnosis
15:31:10 Definitive treatment
00:02:54 Event to Treatment
00:01:50 First sign to Treatment
00:00:10 Diagnosis to Treatment

This clinical scenario (which would be a worthy addition to requirements for an anesthesia system) demonstrated how lots of data and integration was used to achieve a good outcome. Much of this data was integrated in a particular monitor that was developed just for this kind of situation at Partners. This monitor is no longer made and not available. Data integration from multiple sources and presented in an integrated way is essential. Hospitals can no longer afford to build their own systems of this type, and universal interoperability is required and desperately needed to bring these capabilities the broader market at large.

Steven Dain MD, Director of Anesthesia Informatics at the University of Western Ontario, provided a historical perspective to interoperability. Back in 1990 he was asked to write a program to collect blood pressure and heart rate from an NIBP monitor every 2.5 minutes, and SpO2 from an oximeter every 10 seconds and put it into an Excel spreadsheet. Easy, right? After this character building experience, he wrote the paper: Anesthesia Monitoring and the Computer Interface: The Need for Standardization of Communications Protocols.

The NIBP monitor had an RS232 interface, but the SpO2 device was a custom interface and required a clinical engineering project to get access to the data link.

Dain asked, “What’s changed in 14 years?” Not much. We still have proprietary electronic interfaces; it is still difficult to connect medical devices; expensive custom software is needed for each device; and there are still no usable standards for the electrical interface, syntax or semantics.

There have been lots of standards committees: the International Electrotechnical Commission (IEC) committees and working groups, ISO TC Health Informatics, ISO TC’s for medical equipment, IEEE, SNOMED, MSHUG, HL7, IHE, IOTA, HIMSS, WHO, and various national agencies and standards bodies (see Kolodner’s presentation). But these groups are often working in isolation, and frequently at cross purposes.

In addition, past attempts at medical device communications standardization have proven unsuccessful. There has also been a lack of a multidisciplinary needs analysis and use scenarios. And even with ethnographers, efforts to completely understand the complex clinical environment in which healthcare providers work have failed.

In addition to the above, Dain suggested that a multi disciplinary approach is needed to design, manufacture, sell and support interoperable systems. Most vendors lack the core competencies to provide effective connectivity and interoperability solutions – still.

With his clinical and vendor experience, Jim Fackler MD, intensivist Johns Hopkins, offered a different perspective. He noted that, “Dr Kevorkian does not hold a candle to what I can do as a participant in the current health care delivery system.”

Fackler went on to describe the hostile clinical environment in which he and his peers provide care. Patients are surrounded by myriad medical devices, where nothing talks to anything; alarms are simple threshold alarms, that don’t know where they come from (based on variable locations of equipment). He showed photos of his clinical environment where as many as 350 data elements can come off of each patient – in a unit with a total of 26 kids.

A fundamental problem with patient safety in hospitals is the fact that humans can only handle 7 things at once. This bit of ground breaking research, known as cognitive psychology, dates from 1956. And one bit of information is the amount that we need to make a decision between two equally likely alternatives. It is no wonder patient safety is in the state it is, when the clinical environment exceeds to known human limitations.

More recent research looking at what differentiates chess masters from mere mortals reinforced the findings in the study from 1956. The chess masters research found that adults could memorize and then recognize random patterns as well as masters, but that chess masters recognized patterns of chess pieces at a much higher rate than adults. Part of physicians training is to turn them into something like a chess master so they can recognize patterns of symptoms to make a diagnosis.

The ability to correlate and process data in the head is best in surgery where there is a 1:1 anesthesiologist to patient ratio. In an NICU like Fackler’s, the ratio goes up to 1:27. I private practice the ratio averages 1:5,000. Is it little wonder that more should be done to improve the clinical environment?

The first line of care and vigilance in the hospital is the nurse, who receives little or none of the “chess master” type training received by physicians.

Interoperability complexity increases as scope of patient and care delivery grows. For example, when a weight scale used for home monitoring breaks the patient can’t go to Bed Bath and Beyond for a new one.

Questions to the panel:
What is needed to drive the adoption of interoperability standardization? Capitalization versus standards imposed on the market. Providers must demand change when buying new products and systems.

Plea to industry – you will create proprietary systems with artificial intelligence providing decisions support. You will be automating exactly what we have now, but physicians don’t have the data they need now. Without putting all data into a “bus” that is interoperable, the potential to impact patient safety and outcomes will be severely limited.

Used aerospace as an analog to medical device industry. Suggesting that aerospace has a small number of large integrated vendors pr0ovide most solutions. False assumption – aerospace has many small subcontractors and contract engineering services companies; all large aerospace systems (like a new plane or even new major components) are constituted from many sub contractors and contract engineering shops, under the management of a general contractor. In fact, unlike medical devices where subcontractors are hidden from the market, aerospace projects are very open about the many subcontractors that participate in a project.

Someone in the audience who was in aerospace before health care noted that airplanes are very complex, like medical device systems, but unlike medical devices they are not reconfigurable – they are integrated once over 10 or 15 years of development.

It was suggested that the industry was at a tipping point where manufacturers developing and maintaining large and unwieldy proprietary systems could give way to multi vendor interoperability with a focus on core technologies. This would allow medical device vendors to compete on what they’re best at, rather than the general purpose computing systems used to provide connectivity.

Open source software on standard platforms was noted as a potential solution (for both vendors and providers) that had yet to be mentioned.

Now that I’m done with my HIMSS wrap up piece for MX magazine, I’m going to be posting on items that didn’t make it into the story. (FYI - here’s last year’s HIMSS report.) For obvious reasons magazines don’t want to publish content that’s already been published here. This first post reports on a presentation by Julian Goldman at HIMSS 2007. Much of his talk was about the OR of the future program at CIMIT, but what really grabbed me was what he had to say about the dearth of medical device interoperability and the resulting impact on patient safety.

In his presentation, Goldman succinctly described many of the challenges resulting from the confluence of HIT and medical devices at the point of care – and the potential impact on patient safety. In his “Views From the Top” presentation (pdf), Goldman used research done at the Massachusetts General Hospital OR of the Future and elsewhere to explore interoperability, “error-resistant” systems, and patient safety.

The frustration for providers is the fact that caregivers represent the only point in which pertinent patient information is accumulated, processed and correlated to create the contextual awareness necessary to provide nursing vigilance and deliver safe and effective therapy. The creation of this contextual awareness is a manual process done in a frequently chaotic and interrupt driven environment. Dependence on these manual processes combined with over crowding, high nurse to patient ratios and increasing patient acuity in general care areas, represents a systemic failure in health care. It is no wonder that failure to rescue remains the most common patient safety incident at 134 per 1,000 at risk admissions.

According to Goldman,

“The acute care endgame is to automate the workflow that provides contextual awareness through improved communications and by linking the various medical devices connected to the patient to clinical information like orders and diagnostic results. In an interoperable environment, this data can then provide safety interlocks to generate smart alarms and to ensure or interrupt harmful therapies.”

Goldman provided 5 examples of simple safety interlocks between devices or between devices and information systems that would save patient lives but don’t exist. Goldman’s example that results in perhaps the greatest number of adverse events is the patient-controlled analgesia (PCA) pump. When PCA pumps are used in place of nurse administered analgesics, the chance for patient harm is increased more than 3.5 times. Interoperability between a continuous patient monitor and the PCA pump could detect a decline in the patient’s condition, lock-out additional pain medication infusion, and generate an alarm. The adverse events that result from standalone PCA pumps represent system failures rather than a lack of alarms or inadequate vigilance on the part of clinicians.

Despite broad interoperability in other vertical markets like manufacturing, telecommunications, IT, and consumer electronics, health care has yet to move past proprietary end-to-end solutions. Creating “one-off” solutions is not practical for vendors, systems integrators or hospitals. “Patient and clinician interaction with medical devices has not received the same attention from vendors as medical record-related data communications,” according to Goldman.

The patient safety market requirement is to automatically create context for decision support using data from devices and information systems. Not surprisingly, HIT vendors, start-ups and smaller device companies view patient safety and the point of care as important product differentiators in an attractive and untapped market. Established device vendors must develop business strategies and products that meet these long standing patient safety market requirements, or they will face declining market share.

Goldman dropped another very interesting nugget of information during his presentation. Using current technology, simple connectivity to integrate medical device data into EMRs is prohibitively expensive, representing 40% of the total cost of ownership of medical devices. This is the first time I’ve heard this cost quantified, and it represents a huge hidden cost to providers. Medical device connectivity, systems integration, management and support is something device vendors don’t want to provide; third party vendors are way expensive, and is a substantial burden for internal resources. Large providers are starting to include a “connectivity clause” in their standard purchase agreements putting the device vendor squarely on the hook for delivering fully implemented connectivity. Of course the lack of any standards in this area makes things more costly and complex for everyone. It has been estimated that an interoperability standard would save a health care delivery organization like Kaiser Permanente an estimated $40 million annually for 10 years - that’s some serious money.

Pictured right is a view of the OR of the Future at MGH.

In health care delivery, the network is a medical device. Okay, not always, but when devices like patient monitors or infusion pumps are connected to a network that carries data critical to patient surveillance or alarm notification, the network is part of the regulated medical device. Now the FDA has been kind enough to mostly look the other way regarding wired and wireless local area networks. The FDA would be well within their legal jurisdiction to tell network vendors to follow the Quality System Regulation (QSR) and get premarket approvals for their products in applications that are regulated medical devices. To date (with a few minor exceptions) the FDA has been content to let people who really know what they’re doing (i.e., medical device vendors) manage networks as off-the-shelf technology incorporated into their regulated devices. Device vendors follow the QSR so vendors like Microsoft and Cisco don’t have to.

As networked medical devices and the resulting distributed systems of devices, servers and clients become more complex, the need to actively monitor and manage those networks becomes increasingly important. In days past, vendors could create their own proprietary island of information, and by creating a tightly controlled and isolated system they could reduce performance variables (especially pesky external variables) to the point where a system that is certified upon installation will pretty much run reliably on its own - until some major component, like a network switch or something, fails - which becomes a simple break/fix task.

Hospital IT has been breaking down islands of information, forcing them into enterprise solutions, for as long as I’ve been in the industry - over 20 years. That day is dawning for medical devices. Virtually every patient monitoring and infusion pump vendor has a gateway server product that converts their proprietary protocols to HL7 so they can export patient identifiable clinical data to EMRs and such. But many of these vendors still rely on private networks, their own VLAN, or some other inconvenient and obtrusive method for isolating their system from the customer’s enterprise infrastructure. Now most of these vendors will tell you that that’s the way it has to be, and will mumble “FDA” or some other such higher power to justify their position. Draeger’s OneNet was the first patient monitoring system designed to run across the customer’s enterprise infrastructure - and even supports the customer’s choice of wireless network cards. This radical departure was not made without special tools to ensure safety and efficacy - in this case the Packeteer Quality of Service network appliance.

With all this in mind, a recent deal between NextNine and Apparent Networks caught my eye.

Networks have become the lifeline of all IP communication systems and business applications. With the integration of NextNine Service
Automation and the Apparent Networks AppCritical™ Technical Support Edition, support organizations can proactively maximize system availability by accurately identifying performance issues in their IP networks and resolving them quickly and effectively in an automated fashion. Designed specifically for remotely assessing and troubleshooting converged networks, AppCritical™ provides end-to-end visibility into any live network and identifies and outlines all conditions and faults that will impact network quality.
NextNine’s intuitive Virtual Support Engineer™ checks the equipment on-site, correlates this information with network data and rapidly resolves the identified problem, all without the need for field visits or customer assistance.

NextNine Service Automation Ecosystem Edition automates support processes that allow vendors and support providers across the service ecosystem to deliver efficient, superior, scalable services while lowering costs. NextNine’s innovative, proprietary Virtual Support Engineer™ can either be deployed at the customer’s support organization for 24X7 proactive support or downloade on demand to resolve issues when required. The company’s products have been deployed by global leaders such as GE Healthcare, Allscripts,
Openwave, Comverse, and airwide solutions.

Apparent Networks’ AppCritical™ Technical Support Edition provides network-dependent vendors the ability to instantly pinpoint problems on their customers’ networks and discover why their applications are not working properly. With its focused and intuitive remote network troubleshooting capabilities, AppCritical™ provides unobtrusive access to customers’ networks beyond their firewalls. Its ability to instantly identify whether the application problem rests within the network or not enables an accurate and targeted approach to problem resolution, therefore saving time and money and boosting customer confidence. Its ease of use encourages broad
levels of adoption within the support organization and the unequaled depth of knowledge present within AppCritical’s expert systems ensures non-network experts are able to confidently troubleshoot and resolve problems.

The press release mentions GE Healthcare, Allscripts, Comverse, Openwave and airwide solutions as users.

Network design and management is a lot like managing RF in a hospital - there is no magic “one way” that one follows when throwing up a network or deploying wireless devices - this is complicated stuff, and diligent proactive planning and management, plus better tools are needed. Putting life critical applications on enterprise networks is not always the best choice - redundancy has advantages - but having the option to run on enterprise networks is important to the market. Since they have released NetOne, Draeger has won a number of high profile sales against Philips in Europe. Draeger has little market share in the US and has not greatly impacted “private network” vendors here. But vendors like Spacelabs and Welch Allyn are making similar, if not quite so dramatic, moves as Draeger.

Pictured right is Welch Allyn’s new nurse-carried alarm notification product, introducted at HIMSS07 (pending FDA approval). I’ve much more to say about this later, but for now note that upon release (later this year) it will run on an Aruba WLAN - and a follow-on version will run on Cisco infrastructure.

As a follow on the post EMR Adoption and Medical Device Connectivity, let’s look at connectivity basics and market requirements. We’ll cover some of the basics here, and explore actual connectivity solutions and the state of the art in subsequent posts.

Medical device connectivity has 3 basic components. At minimum, devices themselves must be able to export data. The next component is some sort of software that converts the device’s communications protocol into something that can talk to the target system (for this post, an EMR). Finally, the target system must have the ability to “talk to” or receive data from external systems.

Most current medical devices, and the vast majority of legacy devices, use a serial port to export data. Newer products typically use USB (universal serial bus) connectors that provide a standardized hardware interface. Older devices use some sort of serial D-connector with various pin-outs (the “pin-out” is the assignment of specific electronic signals to specific conductors or pins in the connector). Unfortunately, the pin-outs on medical devices are highly variable, frequently requiring different versions of cables that must be paired with the different connector pin-outs of devices. In some cases, use of the wrong cable can damage equipment.

The next high level piece of the device/EMR integration puzzle is software that translates data from the device to the EMR. The format of data coming out of medical devices is in a proprietary format, a format that can vary between vendors, between products from the same vendor, and even vary between different versions of the same product. The various device protocols need to be converted to some common format that can then be formatted into a format that can be understood by the EMR. This common format can be a health care specific format like HL7, or a computer industry standard like pdf files, comma delimited files or some flavor of XML. The particular standard is less important that the ability of both the conversion software and what the EMR or target system can understand.

Finally, the target system (EMR) must have the ability to receive data from external systems. This ability is usually a software module or option that supports device and other types of interfaces.

So, now we have 3 basic requirements for connectivity: device output, translation software, and the target system’s ability to receive data. We’ll talk about various ways to implement these 3 requirements in following posts.

Market segmentation has a big impact in how this type of connectivity is implemented. Market requirements vary based on the types of target systems and IT resources that are available. Hospitals have extensive IT resources that include programmers and a variety of technicians. Many other health care providers have little or no on-site IT resources, which obviously impacts their ability to implement and support connectivity.

Given the above, the connectivity market can be segmented into two key markets: hospitals who have IT departments, and everyone else who doesn’t. The folks without an IT department include physician practices (except perhaps for the very largest practices), outpatient diagnostic and surgery centers, and some ambulatory clinics. Frequently these segments are called acute and sub acute markets, but other terms are also used.

In house IT departments can obviously provide installation and ongoing support for an interface that is not available in sites without IT resources – this has a big impact on how connectivity is delivered to customer. Subsequent posts will focus on market requirements for each segment separately.

Pictured right is a Smiths Medical SpO2 monitor.

24×7 Magazine published a story of mine on connectivity. Variously described as “automating workflow” and “deciphering medical device connectivity,” the story approaches the topic from a provider’s viewpoint. After a bit of history and description of immediate and longer term reasons to connect (EMR integration and point of care workflow automation), we dive right into the part about “plug and pray.”

Connectivity is really easy if you’re willing to buy all new devices, and buy some new IT infrastructure to boot. Oh, and you have to be willing to replace most or all of it every time you change vendors (or even product lines from the same vendor). Oops, almost forgot, none of the different categories of devices will work together - and forget about any cross vendor compatibility. If this sounds unappealing to you, you’re not alone.

The story addresses legacy devices, proprietary end-to-end systems and some interesting third party connectivity solutions on the market. And you can’t talk about connectivity without mentioning standards:

Medical device connectivity requires a connection between the device and the target information systems. Legacy devices use a serial connection to a terminal server that converts the RS-232 signal to a network connection. Both wired and wireless local-area networks are used to connect devices to information systems. Older device-connectivity systems run on “private” networks that are physically or logically separate from the wider hospital network. The resulting proliferation of these “islands of information” is giving way to integrating devices into the hospital network. Because health care is inherently mobile, with patients moving throughout their stay and highly mobile caregivers, wireless networks offer the most flexible and least obtrusive network connection.

With the exception of diagnostic imaging modalities and some clinical lab equipment, the data that comes out of medical devices is in a proprietary format. Devices with end-to-end connectivity systems aggregate data from devices at a server, which converts the data into a standard—typically Health Level Seven (HL7) or SOAP/XML—and passes it on to another system. Devices that have only an RS-232 output must convert the serial interface to a network connection, where the data from multiple devices is aggregated in a server, which also converts the data into a standard for use by other systems.

Efforts of the Integrating the Healthcare Enterprise patient care device workgroup, standards bodies like the Institute of Electrical and Electronics Engineers Inc 1073 workgroup, and HL7 are working to improve the plug-and-play capabilities of medical devices. Goldman’s MD PnP group is also driving connectivity with use case development and a new verification lab. But it will probably be years before medical devices like those mentioned above achieve the ease of connectivity currently enjoyed in radiology with digital imaging and communications in medicine.

The real question is not about standards but what a provider can do to navigate this confusing mess.

How one finds their way through this bewildering sea of competing choices is a challenge. The interrelated nature of the devices, users, and workflows means that any one connectivity choice will inevitably impact subsequent decisions down the line. “With many connectivity projects you don’t find all the hidden costs until after the project is complete,” says Craig Bakuzonis, director of clinical engineering, Shands Hospital (Gainesville, Fla). “Detailed planning and experience have been our best project-management tools.”

Perhaps the most important part of connectivity planning and execution is needs assessment. Unlike many projects in health care, connectivity crosses multiple organizational silos in a hospital and must sync up multiple moving targets. These moving targets are changes that occur in care delivery methods, medical device upgrade and purchase plans, and information technology (IT). Any resulting solution must fit today’s environments and support future changes planned across overlapping areas. Even seemingly unrelated projects are interrelated—will nurses want to carry a PDA for spot vital signs capture and another PDA for the Baxter “smart” pump system budgeted for next year? Probably not. Can we run both applications on the same PDA? Good question; probably not.

Good planning for connectivity incorporates requirements from nursing, biomedical engineering, and IT into a series of road maps. Each road map starts with current requirements and captures planned clinical and operational changes into the future. A good time
horizon would be one that equals the operating life your hospital expects from a new medical device. Each milestone on the road map needs an associated project description and list of requirements. If no one in your hospital can plan out as far as the estimated useful life of your medical devices, make sure constraints posed by keeping those devices are understood by all parties.

This is a rapidly evolving area with few established best practices. The classic business term is discontinuity, which certainly applies here. As providers seek to integrate medical devices with information systems, and medical device vendors and HIT vendors eye one another’s markets for future growth, the tradition of adopting vendor’s end-to-end solutions is getting more expensive and delivering less value. Much like the early PACS market, the “DICOMification” of medical devices - the breakdown between the actual device and associated analysis software on general purpose computers - requires buyers to chart their own course.

As medical device connectivity has evolved, administrative applications are giving way to those impacting patient care and safety. Systems have evolved from data gathering and export to alarm management. According to Goldman, the next big connectivity application will entail medical device interoperability. “In the future, connectivity will include medical device control that permits the
integration of distributed medical devices to produce ‘error-resistant’ systems with safety interlocks between devices,” Goldman says. This error resistance will decrease user errors and provide closed-loop systems to regulate the delivery of medications and fluids, improving patient safety and outcomes.

Special thanks to the following folks to provided their time and experience for this story:

Craig Bakuzonis, director of clinical engineering,
Shands Hospital (Gainesville, Fla)Troy Gillette,
director clinical engineering and patient equipment, Robert Wood Johnson
University Hospital (Brunswick, NJ)

Julian Goldman, MD, program leader of the Medical Device Plug-and-Play
(MD PnP) interoperability program, departments of anesthesia and biomedical
engineering at Massachusetts General Hospital (Boston)

Bridget Moorman, clinical systems engineer, biomedical engineering, Kaiser
Permanente (Berkeley, Calif)

Elizabeth Wykpisz, vice president,
Washington Heart and Vascular (Washington, DC)

Eric Yablonka, VP, CIO, University of Chicago Hospitals and
Health System (Chicago)

A question came up on the Biomed Listserv the other day about Philips’ new VM line of low acuity patient monitors (press release). The initial comment noted that the new VM line looked pretty impressive (it does), is HL7 ready, and questioned whether Philips OEMs the monitors or makes them themselves (they are Philips designed and made at a Philips plant in China). Given the innovative nature of this new line of patient monitors, I thought you, my gentle readers, might find it of interest.

I got a download on the new Philips VM line at AAMI. To my knowledge, this is the first line of medical devices that directly outputs HL7 from the device. Previously, medical devices output a proprietary protocol over a wireless or wired network to a server that converts the data to HL7. The server in turn “talks” to the other side of the HL7 interface, your EMR. The server also aggregates data feeds from multiple devices into one interface to an EMR or some other information system.The HL7 standard has (too) many configuration options and a high degree of variability in how it is implemented from vendor to vendor. Consequently, the state of the art for HL7 interfaces is a table driven interface that supports variations like data element labels, field lengths, and the ability to enable or disable individual fields in the interface. Some interfaces also support multiple versions of HL7. A table driven interface provides the necessary (at least up to this point) variability to integrate with the widest variety of other vendor’s HL7 interfaces. The bottom line: to date, HL7 is not a “plug and play” interface.

According to the Philips engineers I talked to at AAMI, the VM line outputs a fixed HL7 data stream through the Ethernet port on the back of the monitor. From what I learned, there is no table driven configuration of the HL7 output. (The fact that low acuity patient monitors targeting patients that are at least somewhat ambulatory doesn’t have wireless connectivity is a topic for another time.)

In a perfect world, the host side of the HL7 interface (there are always two sides - the device and the host) can be configured to support the Philips VM implementation of HL7. Your world may be less than perfect - painful even if your host can’t configure to match Philips’ implementation of HL7.

The direct HL7-out from the device, static nature of the interface, and absence of any table configuration utility makes the Philips VM HL7 implementation radical. If anyone can pull this off, Philips can; as the largest patient monitoring vendor they swing a lot of weight. Also the HL7 standard has been around a long time and has perhaps matured to the point where a non-configurable interface will work. Time will tell.

I’m sure many on the list would be interested in hearing from biomeds who’ve implemented the HL7 interfaces on the VM monitors, as well as more info from someone at Philips.

Evolving HL7 to a truly plug and play interface is good thing - I would recommend monitoring vendors duplicate Philip’s HL7 implementation - there’s no good reason not to, and several good reasons to do it. A lot of the variability in standards like HL7 is simply vendors who insist on including some quirk that they have already implemented (and don’t want to spend the NRE to change), or have some misguided notion that their implementation of HL7 is “better” because it’s different.

If you’re buying VM patient monitors and expect to integrate them with some electronic charting application (and who isn’t within the life of a new patient monitor?) best make sure your host system will support the Philips VM implementation - before you buy.

UPDATE: Conversations with Philips at the 2008 HIMSS conference indicated that the HL7 interface on the VM line of patient monitors is configurable.  It was not clear whether configurability was added since the introduction in 2006, or was there all along.