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.

AAMI 2007 – Exhibits, Part 2

Posted by Tim Gee on Jun 20, 2007 in Company Profiles, Patient Flow, Patient Safety | 0 comments

Respironics was showing Respi-Link, remote monitoring capabilities through an RS232 serial port. The biomed must take the device down to their shop and connect it to a computer that runs a special Respironics client. Through this connection, users can download firmware updates and do run some diagnostics. Respironics is using Axeda for this feature, and support the Esprit, NICO and new vents. No word on wireless network connectivity.

Walking down the aisles, I came across the IMT Medical booth. The Viasys Vela ventilator they were using to demonstrate their test fixture sported an RJ45 connector for what is apparently an Ethernet connection. The product page only mentions “data output port for graphic and information systems” – which sounds suspiciously like a serial port to me. Perhaps a reader can enlighten us further.

The Tyco booth was dominated by Nellcor – and a rep sporting an attractive forehead worn SpO2 sensor. I was going to get a photo of him, but I'm really not that mean. Nellcor wasn't showing the wireless SpO2 monitor they displayed at the Rapid Response Systems conference last month in Pittsburgh. In the back of the booth was a Puritan Bennett ventilator – no connectivity really, just an RS232 serial port.

Radianse showed a new real time location system (RTLS) receiver. Unlike the previous boring rectangle, the new receiver sports a modern wave-like shape. Referred to by some as the “Captain Cruch hat,” the wider form factor supports a new antenna with a horizontal egg shaped receiving area. This new antenna reduces sensitivity to tags on adjacent floors, but maintains excellent coverage for the floor on which it is locationed. The back of the new receiver sports both power over Ethernet (POE) and a plug for a DC power supply. There is also a slot for a WiFi card so the receivers can be configured to talk to a wireless network rather than a wired Ethernet.

Radianse mentioned that there's a new patient worn single-use tag in the works, due later this year. This tag will be 40% smaller and less expensive.

At Draeger's booth, they showed their new telemetry system. This is the same system they showed last year as a “pre approval” system. They have received their 510(k) and will be shipping in the next few months. You can see a quick demo of this unique telemetry system here.

Draeger also showed a new “clinical PC,” the Infinity C700. This device sports a wide-screen display that shows a few more seconds of waveform. Like previous versions, there is an Ethernet connection between the patient monitor (in this case an Infinity Delta patient monitor).

Spacelabs was showing their Flexport. It was not really clear whether this was a new product or not. The module interfaces third party devices (they had an Edwards cardiac output monitor hooked up in the booth) to Spacelab patient monitors. A serial D-connector goes to the third party device, and an RJ45 connection goes to the Spacelabs monitor – it was not clear whether the RJ45 was an Ethernet link or what, but the module is configurable (by Spacelabs only). The module integrates both numeric and waveform data from third party devices, and supports alarms and alarm notification through Spaclabs' central station. It was not clear if the third party device data could also be passed to the EMR via a Spacelabs HL7 interface.

After the initial flurry of new RFID vendors, I was surprised to come across a brand new vendor. RadarFind has been in development for a number of years and offers a unique approach to indoor positioning – an approach they assured me was vastly superior to anything else on the market.

This system uses 900 Mhz, so it's not a WiFi based system like Ekahau or AeroScout. Here's the good part – the receivers are built into wall outlets and use the electrical wiring to transmit positioning data to a collector that aggregates data from multiple readers. This reduces installation costs considerably. Collectors are connected to the positioning engine (the software that determines location) via Ethernet.

Another difference with RadarFind is that the readers initiate communications with the tags, rather than the other way around. Tags run about $50 or less, depending on features. Their top dollar tag has a 3 position sliding switch that can be used to indicate status – so a caregiver or tech could indicate a specific status, like room occupied, dirty, or clean. Readers go for $200-$300 each.

The real secret sauce in any positioning system is how they determine position. RadarFind uses highly engineered MIMO (multi in/multi out) antennas in both the receivers and tags. The math used in the positioning engine utilizes both signal timing and strength in what they called “windowed RSSI.” They use “active null-busting” to minimize the effect of multipath interference, which is common in hospitals. Positioning accuracy was claimed to be between 8 and 9 feet. The system is installed in their first beta site, so they don't have data on percent of room level accuracy readings, etc. The company is VC funded, has raised about $5.5 million in 2 rounds, has 11 employees (they contract a lot of their engineering), and sells direct.

I stopped by Physio Control – their booth was sort of slow, what with the FDA stopping product shipments and all. Most of us from the vendor side for any length of time have lived through a similar experience; it is not fun. Physio does have some interesting things in development, and the first is released but had a “soft launch.”

They've got a solution that uses an ambulance gateway to link their monitor/defibs to a server farm on the Internet. These servers will serve up a web application for the review of “STEMI” patients – that's ST elevated myocardial infarction patients, those who benefit most from rapid therapy administration. The application will be community focused providing access to multiple hospitals so any diversion issues can be quickly resolved. The system is already in use in two communities, one in the tri-cities in Eastern Washington state and the other in the North East.

One unresolved product feature question is whether they will open up the system and allow other vendor's monitor/defibs connect to the servers on the Internet. I predict that if they keep the system closed (for a misguided competitive advantage) the system will see very limited adoption. If they open up the the system, many more communities will buy because they have devices from multiple vendors – either it's too expensive to replace all their monitor/defibs at once, or they're owned by separate entities. In this latter scenario, Physio will still have a competitive advantage against every vendor who has yet to integrate with the solution – integration for Zoll, CardiacScience or Welch Allyn could easily take 12 to 24 months, and some may even be foolish enough to refuse the opportunity to participate. Tendencies towards proprietary systems strategies run deep – I don't expect Physio to open the system, but time will tell. A couple of Physio's devices include Bluetooth and they are looking at WiFi connectivity.

Zoll showed a new R-Series monitor/defib intended for hospital crash cart use. The device will soon sport an 802.11b radio – when I teased them about their “primitive” radio, they noted that a follow-on radio will support 802.11b/g. What's really weird is that the radio will only work peer-to-peer, talking to a PDA used to capture data and document code events in Zoll's PC-based CodeNet application. A future version of the radio will connect to the infrastructure (the hospital's access points) to provide an enterprise-wide defib dashboard. This device maintenance and readiness application will indicate test results, devices that require servicing, and in a future version download firmware updates, provide network clock sync, distribute the hospital's standard defib configuration, and provide access for remote diagnostics from the Zoll mothership.

The Anritsu RF analyzer is the preferred tool for RF trouble shooting and identifying sources of interference. At $14,000 this tool is not as widely available as it should be. Current barriers to adoption include price, complexity, and the perceived skill level required of users. With the rapid uptake of wireless technologies in hospitals, some improved marketing could make this device part of the standard kit in every hospital's clinical engineering shop. Hopefully they'll start to think outside the box and get this important tool into a greater number of sites.

Pictured right is the Anritsu Spectrum Master.

UPDATE: Word has it that Physio Control will open their STEMI Internet-based information system to third party monitor/defibs. This is driven by the fragmented market where a community may have multiple EMS agencies, referring hospitals and PCI centers.

AAMI 2007 – Day Two

Posted by Tim Gee on Jun 17, 2007 in Patient Safety | 0 comments

The day kicked off with a two part session on “Applying Real-Time Integration in the OR.” The presenters started with “blood and guts” anesthesiologist, Warren Sandberg. He noted that the surgery department has limited – and frequently constrained – resources. He described the value of extending data beyond the location

What Sandberg’s describing is more than audio visual data (combining images of displays from various cameras and device displays), but data integration that allows for the rearrangement and massage of data to better manage clinical care delivery.

Mark Meyer compared and contrasted the differences between the value of surgical video alone and video with real-time data from patient connected instrumentation combined with operational (procedure, personnel) and clinical data (relevant history, allergies, etc.). A large screen display may be able to aggregate all the data in an OR, but an important requirement is to provide different views of the data, based on roles or what the user’s trying to accomplish.

The system Meyer’s uses at Mass General is from LiveData. This system acquires data (not just images) into a comprehensive “recording” that captures a complete record of each case. The system also captures positioning data of the patient, staff and equipment. The system can also create data trends from data aggregated across all patient connected devices, and display different screen formats based on reaching certain milestones in the surgical case. The data is all archived, and takes about 50 MB per case.

Conventional full disclosure systems are proprietary, run on a proprietary network, very costly, and are unit based (rather providing an enterprise architecture). The LiveData system captures data from multiple vendors with a goal to improve throughput and patient safety in the OR.

Next up, Phil Brzezinski, VP for Healthcare Systems at LiveData. He was inundated with questions about their system (as presented by Sandberg and Meyer) before he even had a chance to present. The 50 MB figure above does not include digital video – video generates a huge amount of incremental data. He notes that while other HIT apps may collect most of the same data, buyers must ensure that they can get access to the data in the form and at the time in which it serves the greatest good.

LiveData’s initial market was the electrical power distribution industry, where they created dashboards for utilities. Back in 2003 and 2004 they did their core research, looking at medical devices – the data generated, data formats, interfaces, etc. They also spent considerable time within the surgical environment gathering requirements.

Visual integration: “Using the clinical workflow at the point of care to determine the optimal display of patient data, images, communication tools and ancillary information to maximize quality and efficiency of care.” This is much more than just a “picture.” Their value proposition:

• Improving patient safety and productivity (thus improving throughput and utilization),
• Improving communications and coordination between departments,
• Leveraging IT investments by extending and synthesizing the data from multiple systems into new information, and
• Gathering data critical for “quality of service” payments.

In the realm of patient safety, LiveData helps reinforce Joint Commission safety protocols. The system also improves situational awareness and facilitates safe patient hand-offs.

All of the data in the LiveData dashboard comes from other systems – nothing is entered into LiveData. A common display configuration may include staff which is updated by scheduling apps, positioning systems and other sources. The patient data includes basic demographics, orders, allergies, etc. The central portion of the display is tabbed to follow case set-up, briefing, intraop, closing, debriefing, and protocol. Users are able to note when logistical problems crop up for later analysis. on the right is the progress log and a summary of cases for that room for the rest of the day. An example was also show where the day’s schedule was laid out horizontally along the bottom of the display along a time line. The system provides team communications: coordination, awareness, cooperation, and communications.

The LiveData Historian is the archive module, allowing for retrospective playback and analysis of procedures for process optimization. The archive module can provide specialized displays that match video of the case with any other data that occurs in time sync.

Phil presented a brief vision of the “visually integrated” hospital as a lead in to how LiveData systems are configured and delivered to customers. There are 6 key components:

1. Data sources and mappings
2. Workflow description and definition
3. Custom user interface or workflow
4. IT and Biomed integration for security and system maintenance
5. Image routing and management choices
6. Facilities

They start the process by identifying data sources and mapping relationships. The actual system configuration is completed, along with data mapping. A rapid prototyping process is used to enable customers to confirm the configuration, and rapidly arrive at an optimal system configuration.

Guess what? Vendors who are already established in the OR are not really keen on the integration that LiveData is providing. This is the common reticence vendors feel when presented with solutions that move beyond the conventional end-to-end proprietary product strategy. Some vendors may claim provide many of the same capabilities as LiveData – caveat emptor. Hospitals will have to push their vendors to support an integrated vision. You must insist your vendors support standards and process unification efforts. Demand open systems at a lower level of granularity – in other words, integration between complete systems is frequently ineffective; integration between sub modules is frequently necessary for meaningful integration. When looking at vendor solutions, consider vendors outside the list of usual suspects to include open source and innovative startups.

Questions: LiveData has yet to deal with a company that is not willing to share integration data, although some vendors are not ready technically for this, or are limited in what they’re really willing to share. The LiveData system does not replace anesthesia record keeping system, but integrates with them to get data, drive the dashboard, and track workflow. The LiveData system will integrate with a third party audio visual integration system from vendors like Stryker or Storz. A question of customer readiness shed light on the fact that LiveData customers are currently “early innovators” who already have high levels of automation. Less automated hospitals look to LiveData to do more than integrate existing data, and help with basic automation too.

Warren Sandberg finished these two marathon sessions with an indepth view of the financial issues (and ROI) that revolve around care delivery – using the OR as an example. Today’s reimbursement environment is rife with highly detailed mundane documentation requirements in order to realize optimal reimbursement. Any “up coding” where codes that reflect higher than normal clinical complexity must be appropriately documented – “if it’s not documented you didn’t do it, even if you did.” Pay for performance (P4) is increasingly adding to the “mundane documentation” requirement for physicians and caregivers. Sandberg’s presentation demonstrated how they used an anesthesia information management system and some additional systems facilitated the consistent capture of this detailed documentation as required be the case and payor. The financial impact was significant at MGH.

The benefits of this improved documentation included a significant financial impact, as well as reductions in LOS and improved patient outcomes. As reimbursement becomes more entwined with patient safety and outcomes (e.g., P4P), systems for billing, department operations, logistics systems,other clinical information systems, and medical devices will become more tightly integrated. LiveData is positioned facilitate this integration.

Siemens Partners with Ekahau for RFID

Posted by Tim Gee on Jun 14, 2007 in Company Profiles, Patient Safety | 0 comments

Siemens Communications and Ekahau announce a strategic relationship, “By adding Ekahau's RTLS and site survey solutions to its HiPath
Wireless portfolio, Siemens enables companies to benefit not only from
user mobility but also from the cost-effective integration of asset and
people tracking in their business processes.” Siemens HiPath Wireless is their rebranded Chantry Networks acquisition.

Surgical Sponge Counting System Gets FDA Approval

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

ClearCount Medical Solutions announced that they received FDA approval its RFID-based SmartSponge System for use (press release – pdf).

ClearCount has a recently improved return on investment due to the draft CMS rules for reimbursement for 2008 where they will no longer reimburse hospitals for preventable adverse events. Number 3 on the list is, “objects left in after surgery.”

Pictured right is the ClearCount tag. You can read more about ClearCount here.

Wireless Vendors Challenge Cisco in Hospitals

Posted by Tim Gee on Jun 12, 2007 in Company Profiles, Healthcare IT, Patient Flow, Patient Safety, Standards & Regulatory | 0 comments

Things are changing in the WiFi market. At HIMSS 2007 I noted the booth traffic Aruba Networks and Meru garnered. There was also new comer Extricom who showed a wireless LAN that has a “one-channel” deployment, like Meru.

Since the show, I've heard rumblings of vendor trials at hospitals where the sales eventually went to someone other than Cisco. Until recently, Cisco was the undisputed IBM of networking, including wireless. You know, “no one ever lost their job buying Cisco.” Well, it seems that those days may be over – at least for now.

Wireless networking vendor Aruba Networks has been gaining increasing momentum in health care lately. Aruba was selected by Welch Allyn as the preferred infrastructure for their new 802.11a/b/g radio embedded in their patient monitors, and for their nurse-carried alarm notification system (more here). Aruba's latest marketing vehicle is a market report titled: Healthcare WLAN Appliations: North American Hospital Survey Results. The report identifies the top five wireless LAN applications in hospitals – mobile EMR, VoWLAN, automated meds administration, WiFi-based indoor positioning systems, and wireless patient monitoring. At the right you can see that mobile support for EMR adoption leads the
application pack, and wireless VoIP runs a close second. Surprisingly,
automated meds administration is third, followed by indoor positioning
and monitoring. Note that most hospitals expect to deploy all 5
applications. (You can download your own copy of the paper here.)

The adoption of these 5 applications is roiling the wireless LAN market in health care; the reasons are bandwidth and mobility. While much is made about wireless LAN coverage, the challenges facing vendors are accommodating the bandwidth required by these apps, and providing the active management to ensure that the data streams for each of these apps meet the different requirements of each application. Implied in “active management” is the ability to also monitor each application's performance on the network. Word to the wise: the ability of current vendors to meet these requirements is highly variable. Make assumptions about what might be a “safe choice” (or take vendor statements at face value) at your own risk.

At HIMSS 2007 I spoke with Peter Mongroo of Aruba, who is their man responsible for the health care vertical. I was impressed with his (and Aruba's) understanding of the market, and especially what it means to put life critical data on the enterprise wireless LAN. Applications that demand true mobility and can come with heavy bandwidth loads can challenge wireless LANs. There are many highly technical issues, so techie that even my eyes started to roll up into my head. Peter mentioned 3 key issues.

First, to support true mobility, wireless LANs must allow clients to roam between access points (APs) quickly. More conventional products can do things like encrypt the wireless link at the AP rather than the switch. This means that encryption keys must be passed between APs as clients roam, adding overhead and reducing roaming performance.

Quality of service (QoS) is another key requirement, especially for life critical data and streaming applications like VoIP. Conventional QoS is done at layer 2 of the ISO network model and keys QoS to devices (using MAC address) that are divided into groups based on bandwidth requirements. The problem with this is that many devices are multi purpose – a PDA could do meds administration, alarm notification, and include a soft client for wireless VoIP. The high mobility requirement is QoS that is managed by application, regardless of the device.

Like a lot of medical device connectivity solutions, wireless LAN security can be based on wired ports. Mobile users must be able to move beyond the area covered by a wired port (say a nursing unit or surgery department). Security policy must follow the user as they move across the enterprise, and even use different devices.

Aruba sponsored a webinar last week that highlighted 2 of the 5 applications: Welch Allyn's wireless patient monitors and Ekahau's indoor positioning system. While both presentations were enlightening, we'll focus on patient monitoring. Welch Allyn's presenter was their wireless rocket scientist, Steve Baker, PhD. Steve described how Welch Allyn overcame regulatory hurdles with the process they developed for deploying life critical data across enterprise wireless LANs. Very interesting stuff – you can download the webinar presentation here, and an archive of the webinar here.

Draeger was the first to deploy patient monitors across the enterprise wireless LAN with their Infinity OneNet, and there are many things I like about their implementation. Unfortunately, Draeger doesn't have much market share in the US (although they're won a number of big deals in Europe against Philips with the new network technology). GE Healthcare and Spacelabs can also run on enterprise wireless LANs. Philips continues to push their proprietary WMTS wireless network based on the European telephony standard DECT. While Philips sells 802.11b/g enabled patient monitors outside the US, their ability to implement on a shared enterprise wireless LAN is limited. Philips appears to be

NOTE: Due to a glitch with my content management software, an earlier draft of this post – which has been extensively revised – was posted on the blog. Please disregard the earlier version, and sorry for the confusion.