Day 2 Keynote: John Rushby on Accidental Systems

Posted by Tim Gee on Jul 31, 2007 in Patient Safety | 0 comments

Self proclaimed the, “oldest guy with a computer science degree,” John Rushby with SRI International started the second day with a presentation on Accidental Systems. Using aviation as a model, Rushby discussed interactive complexity and system failures. Exploring the causes of accidents, Rushby noted, “that sufficiently complex systems can produce accidents without a simple cause.” He related aviation failures to health care, noting that in many patient safety incidents, it is the system that fails rather than the clinician.

Aviation is a good model because the extensive reporting of both failures and incidents. Incidents are “near misses” rather than actual accidents. In aviation, because there was no crash, incidents are a rich source of reliability and failure data. He noted that the scarcity of near misses in health care (i.e., adverse events) makes similar analysis much more difficult.

Interactive complexity and tight coupling were noted as important factors to system safety. He then went through a number of failure scenarios in military aviation, demonstrating how complex systems can fail due to a lack of understanding interactions among various variables.

“Nearly all failure indications were not due to actual hardware failures, but to design oversights concerning unsynchronized computer operation.”

Rushby noted that we are pretty good at building and understanding components. But systems are about the interactions of components that manifests “emergent behavior.” We are not so good at understanding this because many interactions are unintended and unanticipated; only some are the result of component faults. There are often multiple and latent faults, and they can malfunction or exhibit an unintended function rather than a simple and obvious loss of function. Many failures are simply due to . . . complexity.

Unlike medical devices, the FAA certifies components only as part of an airplane or engine. That’s because it is not currently understood how to relate the behavior of a component in isolation to its possible behaviors in a system (i.e., in interaction with other components).

So, what are we doing in medical devices? We’re making components and plugging them together, creating “accidental systems.” These medical device systems are created without conscious design. The resulting interconnects produce desired behaviors – most of the time – but may promote unanticipated interactions leading to system failures or accidents.

The solution is simple; we just need to think it all through before we build it. There are two problems with this. First, it’s not known how to do this in general due to the complexity. Second, in health care we regulate components that are then assembled into accidental systems.

Rushby went on to describe some partial techniques for improving the safety of systems. Modes of interaction are key. Examples include interaction:

• Among computational components
• Through shared resources (e.g., the network)
• Through the controlled plant (the patient)
• Through human operators
• Through the larger environment

Computer scientists have worked out how to predict and verify the combined behavior of interacting systems – sometimes. One method is called “assume/guarantee reasoning.” This method and others can be employed as an informal method or formally. Other formal methods include automated theorem proving, model checking and static analysis.

A cool new technology is “assumption generation.” This is well suited to human physiology, which can be quite variable – unlike a radar or jet engine. Using this engine you can define the loosest set of variables. Assume/guarantee reasoning combines a model or specification of your component(s) that includes assumptions about its environment. The assumed environment can be made part of the component specification using techniques like interface automata. (Interface automata (IA) is a light-weight formalism used to describe the temporal interface behaviors of software components.) The IAs of various components can be combined to create a state machine that can verify that a collection of components satisfy each others IAs. Data types and a state machine are extracted from these assumptions with the goal of creating a high confidence in system operation across the assumed environmental range (the assumption guarantee).

He also offered some simple tips to reduce interactive complexity:

• Send sensor samples with use-by date rather than time stamp
• For sensor fusion, send intervals rather than point estimates
• Define data with respect to an ontology, not just basic types
  • E.g., raw output of blood pressure sensor vs. corrected for bed height
• Critical things should not depend on less critical things
  • E.g., intervention for low blood pressure depends on blood pressure which depends on bed height sensor
  • Consequently, the bed height sensor is as critical as the blood pressure intervention or alarm

A key challenge with medical devices lies in the need to integrate device systems with other information technology infrastructure to facilitate the communications and sharing of data. Interaction through shared resources becomes a major factor in safe and effective systems engineering. The concept of partitioning went to the heart of the trade off between specialized embedded systems and general purpose computing platforms – or to look at it another way, between a standalone system and a medical device system deployed on a shared enterprise infrastructure.

Assume/guarantee reasoning is about computational interactions and relies on there being no paths for interaction other than those intended and considered. But commodity operating systems and networks provide lots of additional and unintended paths – hard to model variability. Typically, A and B get disrupted because X has gone bad and the system did not contain its fault manifestations. So safety- and security-critical functions in airplanes, cars, military, nuclear power etc. don’t use Windows, Ethernet, CAN etc. Avionics and military high-reliability applications are highly partitioned using very specialized system software, architectures and rigorous verification and validation. These make the world safe for assume/guarantee reasoning but are too expensive (and overkill) for medical device interoperability.

Contention on shared resources is a classic example where assume/guarantee reasoning breakdowns. An approach to solving this problem is interaction through a controlled plant. In medical devices, the controlled plant is the patient’s body. Medical device development would involve controller and plant models. A plant model may include only a few physiological parameters. Different devices will have different plant models and may be ignorant of other devices’ parameters – yet will interact in actual use.

Obvious perils include normal but unmodeled interactions, especially in the presence of faults. But problems can also occur due to inferior outcomes from lack of beneficial interaction, e.g., a harmonic relation between heart and breathing rates (Buchman).

Rushby’s final interaction is human interaction, with humans as cognitive agents (users) rather than the plant (or patient). Many things attributed to human error are in fact gross design errors. Even safety interlocks can introduce errors if the operator does not understand why an action is or is not happening. These kinds of problems suggest we may not be able to rely on skilled human intervention once we introduce automation – unless we design it right.

Modeling mental models can minimize human error. Operators use mental models to guide their interaction with automated systems. Problems arise due to divergence between an operator’s mental model and the actual behavior of the device or system. Design engineers can represent plausible mental models as state machines, e.g., use the training manual, and then simplify using insights of Denis Javaux. Then compare all behaviors of the mental model against the actual automation (using model checking). Divergences between the mental model and actual operation represent your automation “surprises.”

Beyond specific interactions, there is the larger environment. The purpose of a system is to change some relationships in the environment external to the system. So requirements specification should focus on those changes. But changing intended relationships may also change unintended ones. Requirements engineering should focus on these issues where unintended relationships can result in failures. This can be done by building models of the environment and exploring interactions. Model checking and other formal methods allow exploration of all possible behaviors.

So, now we have these various sources of unintended interactions and suggested some ways to detect and avoid them. The next challenge is to provide assurance that we’ve detected and avoided unintended interactions. All assurance is based on arguments that purport to justify certain claims, based on documented evidence. There are two approaches to assurance: implicit (standards based), and explicit (goal-based).

Aviation and security use a standards-based approach to software certification. In this approach, the applicant follows a prescribed method (or processes) to deliver prescribed outputs like documented requirements, designs, analyses, tests and outcomes, traceability, etc. Standards usually define only the evidence to be produced. The claims and arguments are implicit. Hence, it is hard to tell whether given evidence meets the intended use. This approach works well in fields that are stable or change slowly. A standards-based methodology tends to institutionalize lessons learned and best practices, but is less suitable with novel problems, solutions, and methods – like medical device interoperability.

The goal-based approach involves the applicant developing an assurance case whose outline form may be specified by standards or regulation. This approach makes an explicit set of goals or claims, and provides supporting evidence for the claims and arguments that link the evidence to the claims. Underlying assumptions and judgments are explicitly and unambiguously stated. This approach should allow different viewpoints and levels of detail. In practice, the case is evaluated by independent assessors who evaluate claims, evidence, and argument.

So what should evidence look like? There are two types of relevant evidence, evidence about the process, organization, people, and evidence about the product. Certification reviews are based on human judgment and consensus, e.g., requirements inspections, code walk throughs. Analysis can be repeated and checked by others, and potentially by machine. Formal methods/static analysis and tests are also used.

The interesting opportunity is to create a science of certification. Certification is ultimately a judgment that a system is adequately safe/secure/whatever for a given application in a given environment. But the judgment should be based on as much explicit and credible evidence as possible. A Science of Certification would be about ways to develop that evidence.

The bottom line is that there is enough damage caused by the practice of medicine that the introduction of inherently flawed medical device systems provides a net improvement. Consequently, there is no immediate requirement to rush to implement the kind of systems engineering and certification used in aviation or other high reliability endeavors.

A worst case scenario is a medical device system that results in death or injury to multiple patients – like when all the passengers are lost in a catastrophic airplane failure. This could quickly shift the health care environment where aggressive safety engineering is required.

All of this flies in the face of current software licensing via the ubiquitous EULA. The typical EULA asserts extensive liability limitations. Software vendors need to start making specific claims and backing them up with evidence.

Questions:
Given the interactions discussed, how is criticality addressed? There is no simple answer to that – one way is to calculate all the paths that this could occur and ensure all the paths are workable. In the context of systems it’s really hard to know how to do these things.

A CANopen proponent witnessed to the gathered multitude about the use of CAN in high-reliability systems like helicopters, naval ships, etc. Rushby noted that this field is not without controversy, but noted that CAN is used but that he would prefer not to fly on an airplane using CAN.

A group has been working on an ICE standard on medical device interoperability. There is a requirement in the standard for the vendor to create a mental model, and a fall-back mode in the event of unanticipated failure. Tight coupling is inherent in close loop control. Adding slack into such a system may be advantageous in accommodating human operator variability.

What is the possible impact on medical devices of the sometimes draconian measures that aviation uses for time-sliced partitioning? This approach is very costly to developers, placing many constraints upon the engineer. The flexibility inherent in human physiology may be better served by an approach that is different from time-slicing partitioning.

How close do you think we are to the “science of certification?” Rushby said he thinks we’re far away from that. Much if this is due to the transformative change in the aviation industry. There is also much yet to be learned about controller-synthesis, and how it would roll up into a certification science.

Read More

Baxter Recall Problems Mount

Posted by Tim Gee on Jul 30, 2007 in Patient Safety | 0 comments

Baxter just can't seem to get a break. Just 4 months after their Colleague pump comes off ship hold (more here), Baxter and the FDA announce new recalls.

The FDA upgraded Baxter's recall of the 3 channel Colleague pump to a Class I recall (the most serious) for a software bug. Here's Baxter's press release and the FDA's notice.

On top of all this, Baxter employees at a Phoenix service center have been caught falsifying records regarding the service and repair of 534 recalled Colleague and Flo-Gard pumps. From Baxter's home town paper, the Chicago Sun-Times:

Ouch. Pictured right is a Colleague triple-channel pump.

UPDATE: Here's the FDA recall notice for the pumps that had falsified repair, inspection & test data sheets mentioned above.

Read More

Healthcare Unbound 2007 Kicks Off

Posted by Tim Gee on Jul 27, 2007 in Patient Safety | 0 comments

Jay Srini, VP, Emerging Technologies, UPMC and Vince Kuraitis, Principal, Better Health Technologies, opened the conference.

Srini provided an update on the demographic tsunami represented by the aging population. Statistics show health care prevention has not worked. Over the last 10 years there has been a steady increase in obesity and diabetes. This is not because we're unaware or have not tried to do better. Lifestyle changes are the biggest impact on health. In fact, the extra weight people are carrying has cost the airlines extra in transporting passengers. Diet is the most critical factor that impacts health. Smoking and drinking also came in for some finger wagging.

Jay asked, “When we know there are preventable costs, can we declare we can't afford to insure everyone in the country?” The cost for obesity related care rose from 2% in 87 to 11.6% in 2002.

Every day, almost 11,000 boomers turn 50. Geez, that's depressing.

The (same old) bottom line is that health care delivery must change in the future as patient demand increases and resources (physicians, nurses, money) shrink or remain limited.

The solutions to our problems is in the boundaries, asserted Jay.

When he came up for his co-chair keynote, Vince Kuraitis asked, “How close are we to a tipping point?”

His theme: an individualists or group effort approach to health care?

First off, Vince explored the network effect and HU markets. Showing the classic hockey stick market adoption model, Vince referred to the fax machine as an example of the network effect. One fax machine is worthless, two has some value. But when you reach a critical mass (usually about 20%) the value of owning an individual fax machine increases substantially.

Four years ago Forrester published their $34 billion market forecast for Healthcare Unbound, and predicted the market entering a rapid growth phase in 2009 (just 2 short years away). The critical assumption was that payors would adopt HU, after some experimentation and proving out the value of HU. The market segments in the Forrester model are assisted daily living, or elder care; chronic disease management; and post acute care (including hospital at home).

How close are we to a tipping point? Right now we're just a sexy combination of very interesting companies that get nice stories on the evening news and start ups.

No sightings here – overall, HU has generated disappointing adoption. EHRs, telemedicine and some niche applications are getting some traction. Reimbursement remains absent. There is no network effect in sight here.

Where are we likely to see hyper growth or tipping points? Remote patient monitoring technologies could reach a tipping point in 2008. The work being done by Continua is addressing one of the biggest barriers to growth – the lack of interoperability between devices and systems. [But according to the report that David Whitlinger gave later in the day, next year is probably a couple years too soon.] Vince also described the realization that plug and play interoperability is required to provide the affordability and ease of use required for broad adoption.

The participants in remote patient monitoring come from two perspectives, conventional medical device vendors and consumer electronics companies. Medical device vendors think high prices (say $8,000 for a remote patient monitor) and a proprietary end to end solution are a good business strategy. Consumer electronics companies are more interested in selling hundreds of thousands of less expensive devices – and not having to build complete end to end solutions – than in selling a few tens of thousands of $8,000 monitors. They want interoperability to drive drive rapid market growth and adoption.

Other challenges remain with IT/integration, reimbursement, developing viable business models, and licensure – so physicians can operate across state lines.

Next Vince launched into his assessment of the disease management (DM) market. One year ago, it looked like Medicare DM was approaching a tipping point. Today, it's back to square one based on initial results of their demonstration projects. Medicare Health Support (MHS) appeared to be the favorite son demo to expand DM into Medicare. Medicare is testing a fairly narrow section of DM, the frail elderly. The winners of the MHS were a few of the largest established DM companies.

There has been no evidence of positive short term financial results and virtually no evidence of success. So it's back to the drawing board for CMS and the industry. If we're going to test narrow concepts, there are many other narrow slices to be tested. This will delay hyper growth by several years.

The early results of the MHS indicate that we need much greater integration between DM service providers and those providing direct patient care. Another approach is a Medical Home model that includes a fee for providers to provide HU to patients in their home.

Vince has spent a fair amount of time trying to figure out what Google's doing – and it relates to personal health records. In fact, Vince asserted that personal health records could be a real sleeper in the HU market. There are two models for PHRs, a personal PHR that the patient completes and maintains themselves, and one that's tethered to an employer, health plan, or provider. The problem with a personal PHR is that the vast majority of patients are not motivated to actually complete and maintain a PHR. The problem with a tethered PHR is trust (of your employer or health plan), the quality of data (claims data is not clinical data), and interoperability (can you take your PHR with you?). The market here is very fragmented, and there are only about 2 to 2.5 million of patients with their own PHR.

The first generation of PHRs were thought of as an application, an on line repository of personal health information. The next generation is the PHR as platform rather than an application. This platform provides a repository of data combined with interoperability for other applications. The formulation of genetically specific drugs for a patient was one example of how data in a PHR (in this case genetic information) could be used by an outside application to create a result (documentation about the personalized drug) that goes back in the patient's PHR.

Google Health is the next generation of PHR. This is the result of Vince's detective work and reading of tea leaves (you can read more about Google on his blog, here and here; a related post on Medical Connectivity here). The current structure for your PHR is data that's scattered everywhere. Nor is that data in standardized formats suitable for a global information economy. Google Health's model is patient centered where consumers own their own personal health data – they have complete control, not physicians, payors or drug companies. Each patient will have their own personal health URL (e.g., http://health.google.com/timgee) Also needed are automated data mechanisms to gather and store PHI. They will go to drug stores, clinical labs, etc., and they'll aggregate this data for patients. [Later during cocktail hour, someone suggested a Google spider initiated by and authenticated to an individual that would have the permissions to automatically extract data from a myriad of sources - say prescription history from a PBM, or results from a regional reference lab.] They will use XML and the Continuity of Care Record (CCR) standard. They'll provide a user interface for patients, providers and payors to use. They'll also have to provide security and confidentiality. And ultimately, they'll create some value added service (hopefully something besides online Canadian drug stores or male enhancement ads).

If we had a platform like Google Health to plug into to support HU applications and products, this would hasten market development.

One of the biggest tipping points of all is in mobile health technology. Qualcomm and Partners are launching a private branded virtual wireless carrier to target wireless remote monitoring applications (more here and here). Health 2.0, or social internet applications and websites, are also likely to reach a tipping point in the near term. “Hospital at home” (HaH) is something that's been used a great deal in Europe and other countries. The key here is that current HU technology and applications begin to make HaH possible.

How do we know HaH is the biggest HU market of all? He offered the Willie Sutton theory of HaH – because that's were the money is. If projected 2014 annual hospital costs are estimated to be $1.14 trillion, and the projected HU market at 2015 is $34 billion, Vince suggested that we're underestimating the opportunity for HaH.

Our success in HU is tied at the hip to HIT interoperability and making PHI transportable. There needs to be integration with local care providers. He asked the question, “Are PHRs the best candidate for a common technology platform?” It's not whether, but when HU succeeds.

Vince encouraged attendees to support the Continuity of Care Record and to join Continua. The conventional medical device business model approach to the market should be abandoned (you know, those expensive proprietary end-to-end solutions) for one that leverages standards to provide interoperability and some level of commoditization to grow the market for everyone.

Pictured right is Vince Kuraitis, Mike Barrett and David Kibbe. Sorry I missed Jay Srini, I'll try to catch her tomorrow.

Be sure to check out other posts from this conference here.

Read More

CDC Publishes Latest Emergency Department Summar for 2005

Posted by Tim Gee on Jul 7, 2007 in Patient Safety | 0 comments

FierceHealthIT notes a new CDC study on ED overcrowding – it's getting worse.

The 32 page report is fuel for the American College of Emergency Physicians lobbying efforts to get congress to, “create a commission to study the ED overcrowding problem. Under the
terms of the ACEP-backed bill, hospitals would have to report to HHS on
how many patients are boarded in the ED, and how long they're boarded.” [Patient "boarding" is the practice of placing patients in hallways, usually in the ED, where they wait for an inpatient room to become available. Patients commonly wait for hours, and sometimes more than a day, on a stretcher parked in a hallway.]

Ambulance diversion data is tracked by hospitals, regional and state hospital associations, and sometimes the state. This data is not available to the public or most state health agencies. Given how bad ED diversion is, I'm not surprised hospitals want to keep this data private – especially the worst offenders. Data on patient boarding is tracked less often by hospitals and to my knowledge, is not tracked across hospitals by associations.

Public reporting of both diversions and boarding would provide an important customer service metric and patient safety indicator and should be available to prospective patients. It is too bad that such a requirement must be forced on the industry by government.

You can download your own copy of the CDC report here (pdf).

Read More

More Hospitals Lift Cell Phone Bans

Posted by Tim Gee on Jul 7, 2007 in Healthcare IT, Patient Safety | 0 comments

According to a survey by CHIME, more hospitals are reducing restrictions on cell phones.

Twenty-three percent of the 185 survey respondents reported their organization has lifted all restrictions on mobile phone use, up 5.5% from a similar survey conducted by the Ann Arbor, Mich.-based organization in 2004. Only 11 respondents, or 6%, indicated that cell phone use is entirely
prohibited at their hospitals.

Sixty-nine percent of respondents reported mobile phone use is restricted only in certain areas, such as the emergency department or intensive care unit. And 39% indicated their organization has or will install technology to enhance cell phone signals.

Respondents, however, also reported that some problems have arisen as a result of increased use of mobile phones in their hospitals. For example, some say privacy and noise pollution concerns are compelling them to continue some mobile phone restrictions. Further, some respondents indicated their organization has specific bans on camera phones in patient areas.

As I noted on the Biomed Listserv this week, RF interference is a fact of life and cell phones are but one contributor. Regarding RF interference risk, cell phone’s will never be proven to be perfectly safe – but then neither will hair dryers, florescent light ballasts, microwaves ovens, and elevator motors. The key is risk management.

Sadly there’s no link to the actual report on CHIME’s web site. (You’d think they could have found a corporate sponsor for the study, and then published it in support of their advocacy for effective use of IT in health care and as a service to the industry – that is why CHIME exists, isn’t it?)

Read More

Panel Discussion: Clinical Need for Interoperability

Posted by Tim Gee on Jul 2, 2007 in connectivity, Events, Patient Safety | 0 comments

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.

Read More