MD PnP Update

Posted by Tim Gee on Jun 26, 2007 in Patient Safety, Standards & Regulatory | 0 comments

After the break, Julian Goldman provided a brief update on the MD PnP program.

First, Goldman presented ways integrated systems can support safety, using examples from non-healthcare applications. The classic example from Goldman’s stump speech is the automotive brake/automatic transmission interlock, an almost universal interoperable safety feature.

Safety Inter-locks

From aviation, the airplane landing gear smart alarm annunciates when a plane is landing if landing gear is not down. This example demonstrates contextual awareness, an important feature needed for health care safety.

Clinical analogs that would improve safety were presented including:

Heart lung machine and ventilator – switching from bypass and back. Ventilators are sometimes not turned on – simple human error that could be eliminated. Citation: Anesthesiology. 87(4):741-748, October 1997

Blood pressure measurement errors can occur if the invasive blood pressure monitor is not manually zero’d when patient’s height and inclination is changed relative to pole mounted patient monitor. Human error occurs when the clinician forgets to recalibrate the pressure transducer after moving the patient.Citation: Acta Anaesthesiol Scand. 2006 May;50(5):600-3

Given the potential patient safety benefits, and the relative simplicity of these initial potential applications, the goals of MD PnP include:

1. Lead adoption of open standards
2. Define a regulatory pathway
3. Elicit clinical requirements
4. Use a vendor neutral lab to test and verify solutions

APSF Endorsement of Interoperability

Awareness of these potential patient safety improvements is growing. From the Anesthesia Patient Safety Foundation’s (APSF) endorsement of interoperability, March 2007:

“APSF believes that intercommunication and interoperability of devices could lead to important advances in patient safety, and that the standards and protocols to allow such seamless intercommunication should be developed fully with these advances in mind.

APSF also recognizes that as in all technologies for patient safety, interoperability poses safety and medicolegal challenges as well. Development of standards and production of interoperable equipment protocols should strike the proper balance to achieve
maximum patient safety and outcome benefit.”

The APSF has also noted Dangers of Postoperative Opioids – PCA pump related patient deaths and the need to automatically terminate PCA infusions when monitoring indicates.

“We advocate widespread acceptance of the goal that no patient shall be harmed by opioid-induced respiratory depression in the postoperative period.

“Thus, immediately, we urge health care professionals to consider the potential safety value of continuous monitoring of oxygenation (pulse oximetry) and ventilation in patients receiving PCA or neuraxial opioids in the postoperative period.”

APSF has also publish recommendations regarding PCA pumps:

“A particularly attractive feature may be the ability to automatically terminate or reduce PCA (or PCEA) infusions when monitoring technology suggests the presence of opioid-induced respiratory depression. To facilitate such capabilities, we strongly endorse the efforts to develop international standards for device interoperability and device-device communication.

It is critical that any monitoring system be linked to a reliable process to summon a competent health care professional to the patient’s bedside in a timely manner.”

Kaiser Purchase Contract Language

Providers are also beginning to make demands on vendors regarding connectivity and integration. Kaiser is the first to include purchase contract language that places systems integration responsibilities unambiguously upon the vendor:

“Supplier agrees to participate with Kaiser in the development of a medical device plug and play integration standard (the “Integration Standard”), and … will make reasonable efforts to conform to the Integration Standard when approved and formulated by the parties in writing. Until the Integration Standard is approved, Supplier intends to continue … to provide open interfacing protocols …”

Other providers are evaluating Kaiser’s position and are expected to follow suit.

New Standards Development

Clinical requirements lie at the heart of medical device connectivity. The MD PnP program is currently working to collect use cases and requirements relating to interoperability.

The MD PnP program is also developing a new standard, the “Integrated Clinical Environment” of networked medical devices. Focused on risk management, the project does not specify technology. For risk management, they are specifying data logging, data security, integration with the hospital network, and plug-and-play device discovery.

Another area of focus is the IEC 60601-1-10, the requirements for the development of physiologic closed loop controllers (the PCLC standard). This standard will support distributed patient connected devices that control a patient variable. Example applications include a patient warming system that controls body temperature, and the infusion of a medication to maintain blood pressure in a target range.

The PCLC standard will permit distributed PCLCs that involves more than one item of equipment of a medical electrical system. Distributed PCLCs can also be widely separated in distance. An example here would be the control of blood pressure by networking a bedside blood pressure monitor and an infusion pump, and the titration of inspired oxygen concentration of a lung ventilator with a stand-alone pulse oximeter.

Rob Kolodner Presents Keynote Address

Posted by Tim Gee on Jun 25, 2007 in Healthcare IT | 0 comments

Robert Kolodner MD, is the National Coordinator of the Office of the National Coordinator for Health Information Technology. He's the newest and second coordinator charged with the responsibility to facilitate the adoption of health care IT.

Kolodner started his presentation with some sobering patient safety data:

• Medical errors are killing more people per year, in the U.S., than breast cancer, AIDS, or motor vehicle accidents.
• The lack of immediate access to patient
  health care information is the source of
  one-fifth of these errors.
• Health care is expected to account for $1 of every $5 spent in the United States.
• Cost of health insurance will rise 6.4% annually.
• Spending on health care will continue to outpace the entire economy – $4 Trillion total in 2016.

He noted a variety of factors contributing to changes in health care delivery in the US.

While Kolodner admitted that his presentation was not prepared for our group, he did seem to present his overview of the government's efforts in promoting health care IT with an increased awareness of the important role played by medical devices. He noted that medical devices is not on the list – something that he will have to address. He did mention standards and interoperability of health information and that this must extend to medical devices soon.

We are all potential patients – and if not us, than family members, friends, neighbors. As we go forward promoting medical device interoperability, make it personal.

He noted that we have lots of data locked up in lots of devices, device systems, information systems.

The 4 cornerstones to reach HHS Secretary Leavitt’s goal of improved health care: the value driven health care agenda

1. Connecting the system
2. Measure and publish quality
3. Measure and publish price
4. Create positive incentives

Change occurs not in a straight line, but one must look for the tipping points. The federal governments points of leverage include laws, procurement, conditions of doing business, reimbursement and collaborations. All levers that are being vigorously pursued.

The American Health Information Community – AHIC “the Community” is a federal advisory committee chaired by Leavitt. The committee has 17 members and provides input and recommendations to HHS. Detailed work is performed in work groups and brought back to committee. To date, 7 workgroups have been established, with over 50 meetings. There are no workgroup on connectivity or systems engineering – yet. The workgroups create use cases that go to standards panel who selects/endorses standards and supports certification.

He showed past current and potential use cases. Potential use cases for 2008 include: Remote Monitoring of Vital Signs & Labs, Referrals and Transfer of Care, Remote Consultation, and others. In parallel Kolodner is focused on governence, policy, technology – interop: standards harmonization by HITSP, and adoption.

Questions:

Kolodner “Personal health record may be the disruptive tech of the future”
What about global perspective (“super commuters”) ? Until we move forward in the US, we can’t move beyond borders. He has been in discussions with Euro, China and Australia.

Contrast between IOM adjetives around quality of care and Kolodner’s longitudinal slide – what about adoption at the front line of care? Moving in steady thoughtful fashion. Safe Harbor is one move that has gained some traction. They’re looking at other things in a discovery and learning process.

How do you know it will all work? Software isn’t perfect, and we’re adding a level of complexity and combining multiple systems – what steps are/shoud be taken to realize the same level of confidence in our software as we have in devices? The device area has some real challenges that differe the HER. EHRs have been moving data around reliably for some time. Linking devices entails more interoperability rather than just passing data back and forth. There will be errors along the way, and we’ll need a patient safety role to pick up safety issues as they occur. When software is controlling devices,.. Kolodner really didn’t have an answer. He recognized the need. He knows our execution here will not be perfect – need risk analysis to determine benefit of new risk over patients that are currently killed.

Who are the certifying agencies for medical device interoperability? CCHIT is not an exclusive body with published criteria that could be used by another body.

Nat Sims mentioned a medical device integration project they’re doing among ambulatory clinics and practitioners.

Made distinction between data in devices and data in software. What about work on the issues regarding moving data between devices and HIT? There are not any policies in place for this, especially when considering safety inter locks rather than just moving data. This is an area that will require work in the future.

He noted that he received a number of very challenging questions.

Comment on the role of data generated by medical devices in HIT, and, how far does your mandate extend down to sources of clinical data?

Pictured right is Insup Lee, Robert Kolodner, and Julian Goldman.

The Medical Device Interop Conference Kicks-Off (How Did We Get Here?)

Posted by Tim Gee on Jun 25, 2007 in Uncategorized | 1 comment

I really couldn’t fit the actual title of this event into the title field of my blog software, so I had to wing it. The actual name is:

The Improving Patient Safety through Medical Device Interoperability and High Confidence Software joint workshop on High Confidence Medical Devices, Software, and Systems (HCMDSS) and Medical Device Plug and Plan (MD PnP) Interoperability.

The meeting started this morning at the Cambridge Hyatt hotel. There are a total of 130 attendees at this meeting, with an interesting mix of vendors, providers, academics and regulators.

John Parrish MD, Director of CIMIT, welcomed everyone, noting the importance of interoperability on improving patient safety. “The attendees at this event are ‘make it happen’ folks, so this could be a turning point in our mission.”

Insup Lee PhD, U of Penn and co-chair was next up. Lee noted that this is the first medical device connectivity event to provide a forum to exchange new research and development results by the emerging community of researchers, developers, regulators, users and manufacturers involved in HCMDSS and MD PnP.

Any event like this has a history. Previous meetings – 2 HCMDSS meetings, Nov 2004; 59 attendees; goal: identify crucial medical device software and systems issues and stake holders that will help shape research needs agenda for a larger workshop in 2005.

Past activities of HCMDSS has been based on 3 observations:

1. The Federal government recognizes that the rapidly increasing software complexity of medical devices makes the development of high integrity medical device software and systems a crucial issue in public health.
2. Software for future medical devices cannot be developed using existing design and productivity technologies.
3. The increasingly heterogeneous nature of medical device design requires the need to identify emerging technical and scientific issues in
   medical devices and to identify obstacles to the development and certification of medical device software and systems.

The meeting in 2004 targeted 8 topics:

• Enabling Technologies for Future Medical Devices
  • Implantable regulatory devices, networked biosensors, telesurgery, robotic surgery
• Foundations for Integration of Medical Device Systems/Models
  • Component-based foundations for accelerated design and verifiable system integration
• System of systems (including models, medical devices, care-givers, patients)
• Distributed Control & Sensing of Networked Medical Device Systems
  • Robust, verifiable, fault-tolerant control of uncertain, multi-modal systems
• Patient Modeling & Simulation
  • Large scale, high fidelity organ and patient models for design and testing
• Embedded, Real-Time, Networked System Infrastructures for MDSS
  • Architecture, platform, middleware, resource management, QoS (Quality of Service), PnP (Plug-and-Play) of MDSS
• High Confidence Medical Device Software Development & Assurance
  • Care-giver requirements solicitation and capture, design and implementation V&V (Verification and Validation)
  • Heterogeneity in environment, architecture, platform in medical devices
• Medical Practice-driven Models and Requirements
  • User-centered design, risk understanding, and use/misuse modeling in medical practice
• Certification of MDSS
  • Quantifiable incremental certification of MDSS, role of design tools
  • COTS, non-determinisitic and self-adaptive medical device systems

The next milestone was a meeting in June 2005, which had 99 attendees. There was an open call for contributions, and 40 papers were accepted. The motivation for this meeting was to improve the development, certification and operation of medical device software and systems that will result in better and more cost effective medical care.

The meeting’s objective was to identify short term and long term technology challenges faced by medical device manufacturers and regulators. Specific goals were to identify research challenges and emerging issues. A comprehensive report on research needs and recommended roadmap were completed.

Six 6 working groups were created:
1. Foundations for Integration of MDSS (Medical Devices Software and Systems)
2. Distributed Control and Sensing in Networked Medical Device Systems
3. Patient Modeling and Simulation
4. Real-Time, Embedded, Networked System Infrastructures for MDSS
5. High-Confidence Medical Device Software Development & Assurance and Medical Practice-driven Models
6. Validation and Certification of MDSS

This meeting brings together the HCMDSS and MD PnP communities of medical device specialists from the clinical environment, industry, research labs, academia, and government.

The other co-chair, Julian Goldman MD is the director of the Medical Device Plug and Play program at CIMIT. Goldman noted that at a previous meeting in 2004 they asked the question, “is this the right time to re-consider medical device interoperability? And, if so, what can be learned from prior mis-steps?”

Pictured right is a representation of the social network of the attendees at the 2004 meeting, as created by June Holley.

Here’s what they learned when pursuing interoperability:

• Must be clinical-requirements based
• Regulatory obstacles were perceived
• Legal concerns were deal-breakers
• What is the business case?
• No widely adopted standards
• In summary: Interoperability requires more than standards

They learned at the meeting that key needs must be addressed, like:

• Must be clinical requirements based
• Regulatory obstacles were perceived
• Legal concerns on the part of providers and vendors
• What is the business case?
• No widely adopted standards
• In summary, interoperability requires a lot more than standards

So, why are we here today? Is it the abilithy to plug any device into any other and transfer data? Standardization on USB and WiFi? Remote control of medical devices?

Ultimately interoperability is about empowerment of the user/customer. Look at consumer electronics world, especially digital photography, PC peripherals, and USB – all examples of consumer electronics interoperability. Health care providers need similar empowerment. It will allow clinicians and biomedical engineers to leverage medical devices and IT systems to solve clinical problems, improve patient safety, and improve efficiency.

The role of medical device devices in health care automation efforts is undeniable. Diagnosis and treatment are usually performed with medical devices – they are the “sharp end” of patient care. Medical devices are responsible for the integrity of data, and are the actuators that deliver energy and IV medications.

Comprehensive integration of devices and data from clinical and environmental systems, using the latest computer-science methodologies, will prevent errors and inefficiencies across the continuum of care. Medical device connectivity is critical for complete and accurate EMRS. What also remains is the ability to “close the loop” in many medical device use scenarios. What is needed are smart alarms that include event awareness, decision support to guide diagnosis and therapy, and workflow support to improve productivity and patient satisfaction.

The adopt of medical device interoperability will support:

1. Clinical decision support systems
2. Smart clinical alarms
3. Medical device safety interlocks
4. Closed-loop control of ventilation, medication and fluid delivery
5. Support of remote health care delivery (home, battlefield, e-ICU)
6. Automated system readiness assessment (prior to starting invasive clinical procedures)
7. Complete, accurate electronic medical records
8. Increased quality and completeness of national research databases
9. Facilitation of disaster preparedness: real-time inventory of hospital equipment in-use and national stockpiles, and rapid deployment of devices in makeshift emergency care settings
10. Understanding key issues at the heart of Biomedical Engineering (BME)-IT “convergence”

Goldman closed with the rhetorical question, “If not now, when?”

You can read subsequent posts about the conference here:

• Rob Kolodner Presents Keynote Address
• MD PnP Update
• Panel Discussion: Clinical Need for Interoperability
• Technical Session 1: Interoperability Challenges
• Technical Session 2: High Confidence Medical Devices, Software, and Systems
• Day 2 Keynote: John Rushby on Accidental Systems

AAMI 2007 – Final Thoughts

Posted by Tim Gee on Jun 22, 2007 in Patient Flow, Real Time Location Systems | 0 comments

I was in hog heaven at this year’s AAMI meeting. Connectivity was a major theme, and during every time slot in the program there was at least one presentation dealing with connectivity. During my presentation Monday afternoon, there was one I really wanted to see that dealt with alarm notification.

Lots of discussion centered around the evolving role of biomeds and clinical engineers and the kinds of training they might need in the future. There were rumblings from some in the ACCE who wanted to hold their annual meeting at HIMSS next year rather than AAMI. There certainly is a life-critical systems role that needs to be filled, and clinical engineers could fill that role. To this observer, it seems that clinical engineers will slowly become marginalized if they do not move in the “systems” direction. Even biomed techs will need IT skills to manage and support increasingly complex and pervasive medical device systems.

During the GE sponsored breakfast, there was a session on managing RF in your hospital. Reportedly the perennial “WMTS versus ISM” debate reared its tired ugly head. For many reasons mentioned here in the past (just google “WMTS” in the search box on the left colum). The WMTS bands will never have the bandwidth or (more importantly) the management tools to support more than a small portion of the wireless medical devices in a hospital. Only the usual suspects can even afford to develop the prorpietary radios required for WMTS, which is why 802.11 has seen so much uptake with device vendors.

But the inherent limitations of WMTS do not make 802.11 a slam-dunk. In fact, recent experience has highlighted the need for more rigorous RF engineering, wireless LAN design, and ongoing RF and network monitoring to ensure a reliable network. Hospitals are perhaps the most hostile environment for wireless networking. When it comes to networks, hospitals are faced with both selecting a hardware vendor that best meets their needs and a VAR (value added reseller – the indirect reps used by IT vendors to sell their products) who really knows what they’re doing. Only the best VARs can design and install a reliable network that supports all the big apps: data, wireless VoIP, positioning, and medical devices.

In a nod to presidential politics, “It’s the workflow, stupid.” To most, connectivity is about extracting data and moving it some place else. The real objective is to automate workflow – and how connectivity is implemented has a huge impact on what workflows it supports, and ultimately the usability of the system. A fundamental piece of this workflow is patient context, the association between a patient, their medical devices, and the data that comes out of them. Patient context remains a concept that’s poorly understood by most users and vendors. Many still try to fudge patient context by associating the patient to a port number or bed location. Guess what? Patients move, and mobile devices especially, must establish patient context in the device itself to be safe and effective. I would love to see some of the fantasy-based risk analysis and mitigation documents done for certain connectivity features that I saw this week.

All of this gets to another big change reflected in this weeks conference. Stand alone embedded products are evolving into real systems that extend functionality way beyond the box itself. This “systemization” of medical devices requires some changes in thinking. No longer can you focus on building safe and effective boxes, and after the fact plugging them together with other stuff and be sure the result is still safe and effective. Nor can you manage and support interconnected devices simply by maintaining the device – the entire system must be configured and maintained as a whole.

One of the good things to come from the increased involvement of IT in device connectivity is their insistence on a test system to support the “production” system. They do this with all their software systems. An indicator that connectivity is an afterthought is the total absence of test fixtures for an integration lab. Another symptom is the scarcity of such labs in hospitals and the limited capabilities of most manufacturers’ verification labs. As systems grow and become more complex, hospitals will increasingly demand support for these labs – in the absence of test fixtures, that means customers with clout will insist on indefinite loaners so they can effectively maintain their systems.

During the ACCE Clinical Engineering Symposium Saturday morning, Bridget Moorman referred to medical device connectivity as “brittle.” I know more than one person had an epiphany upon hearing that term. Any change, no matter how small, along the chain from medical device to target computing device renders the device interface inoperable. Device firmware changes, pin-outs, cable connections, terminal server configurations, network configurations, and interface configurations – on either side of the interface – all result in failure. Planning for these interfaces (hopefully by the vendor before product development) must take this brittleness into account. At the very least, customers must be able to monitor their connectivity all the way to the device, not just a server or terminal server.

Finally we come to FDA regulatory issues. I met an FDA representative in the exhibits. She works on the Issues Management Staff, a tiger team that addresses patient safety related issues that reach a point where they must be dealt with. Can you guess one of the simmering issues that may soon become an Issue? That’s right, medical device connectivity. Much of the current regulatory framework (both vendors regulatory strategies and how the FDA manages the process) is based on standalone medical devices, and “oh, by the way, it gets plugged into all this other stuff to do… stuff.” We can expect to see regulatory perspectives shift increasingly to a systems view, especially when multiple vendors are involved.

The contortions many vendors go through to avoid FDA regulation is a symptom of this spreading systemization of medical devices. While the FDA has a responsibility to ensure safety and effectiveness, they are also responsible for accomplishing their mission in a way that doesn’t drive undeserving vendors out of business or stymie the development of innovative solutions that promise even better safety and effectiveness. Don’t expect them to accept the status quo for long. I ask everyone who’s skirting the regs if they are committed to building a quality product, and the answer is inevitably yes. All it usually takes to get a 510(k) is compliance with a basic quality system (the FDA’s Quality System regulation) and 60 days for the FDA to process your 510(k) paperwork. And yet the reticence to be regulated suggests that things like prototype code makes it into finished products all too often.

Masimo Prepares Respiratory Monitoring Technology

Posted by Tim Gee on Jun 22, 2007 in Company Profiles, Real Time Location Systems | 0 comments

A while back, Masimo acquired a Canadian firm that developed a novel bioacoustic respiratory sensor. The fruits of that acquisition are soon to be on the market (press release). In recent studies, “Masimo Acoustic Respiratory Monitoring technology (ARM) is “at
least as accurate as capnometry” and “significantly more reliable” for
monitoring respiration in spontaneously breathing patients.”

At the Rapid Response Systems conference last month in Pittsburgh, studies were presented indicating that the most important parameter for identifying patients with deteriorating clinical conditions is respiration. At the same time, those studies showed that respiration was the most poorly documented physiological parameter – by far. A common problem with respiration is manually assessing the respiration rate through observation, that's why many recordings show a standard 12 breaths per minute.

Masimo also indicates in this same press release that we can see a product built around this parameter:

Pictured right is the respiratory bioacoustic sensor. You can read a story in Anesthesia News, and one of the papers (pdf).