Medical Device Interoperability Lags Behind Technological Capacity
Yours truly was quoted in an article in FDC Reports’ newsletter The Gray Sheet (subscription only) last week about connectivity. The story was inspired by a comment from Bill Crounse, the director of Worldwide Health at Microsoft, during the World Healthcare Innovation and Technology Congress held in Washington, D.C., earlier this month. He said, “”I no longer believe that technology is really the issue that prevents us from getting things done. We have the technology … We’ve cracked the code on things like mobility and wireless devices and broadband. The remaining barriers are really all-around barriers to adoption.”
The story provides an overview of connectivity in both acute care and remote monitoring, from both vendor and customer perspectives. The story closes with this observation:
“The medical device companies are becoming chimeras, where they’re part IT company, and they’re part embedded system company,” Gee noted. But, as long as their mindset remains that of an embedded system company trying to protect the “black box” of proprietary system design, it will be difficult to move forward, he said.
Jason Williams expresses a similar lament about the lack of connectivity in a great post on NeoTool’s blog titled, Bridging the Device Divide. In a comment to the post, standards guru Todd Cooper observes:
Bottom line is that medical device vendors make more money with either proprietary connectivity or strategic partnerships, and end users – provider orgs – do not demand open standards-based connectivity. It is often called out in RFPs – but gets dropped in the decision making process. K-P [Kaiser Permanente] is one of the few org’s drawing a line in the sand on PnP med dev connectivity. “Collaborative partnerships” are the status quo and have been the basis of controlling and limiting device connectivity both at the PoC and to the enterprise.
Todd’s referring to Kaiser’s new purchase contract language that specifies medical device vendor responsibilities for supporting connectivity. You can read an except of the contract language in this post. Rumor has it that Philips has recently declined to meet some of those requirements; it will be interesting see if Kaiser sticks to their guns and drops Philips as their patient monitoring vendor going forward.
In Jason’s blog post he quotes Robert Nadler who says, “…our business is building medical devices, not EMR solutions.” I don’t think medical device vendors will have the luxury of maintaining that point of view for much longer. I spoke with David Freeman and Munesh Makhija of GE Healthcare’s patient monitoring group a few weeks ago. They attended the CMEF and saw an exhibit floor filled with vendors who are doing the same color displays with waveforms that GE is doing – at 30% lower cost. Rather than playing the manufacturing cost game, GE is looking to software to add clinical value and differentiate from low price competitors. Philips seems to be taking a similar approach with their acquisitions of Emergin and VisICU.
The days of staying in that nice familiar embedded device comfort zone are limited. This has always been the case as connectivity transforms medical device product categories. Remember E for M? They were once the market leader in cath lab recorders. They too decided they didn’t want to do software. They contrast nicely with Marquette Electronics who saw connectivity as an opportunity and redefined the product category – driving E for M out of business and capturing a major share of the cath lab market. (Another great example of leveraging connectivity is Alaris.)
You can access both Jason’s and Bob’s excellent blogs from the Blog Roll in the right hand column of this web page.
EMR Connectivity for Medical Devices Is a Mess
Yours truly was quoted in a HealthLeaders technology story about, you guessed it, medical device connectivity.
Information technology consultant Tim Gee has a nontechnical description of the current state of connecting medical devices to clinical information systems: “It’s a mess.” Not that direct data capture from medical devices is impossible; some hospitals have been exporting data from devices into clinical information systems for years. But as Gee and other experts point out, the effort can be so confounding that many hospitals don’t even try. Even in highly automated inpatient settings, a common method of data capture from the plethora of monitors, pumps and ventilators is good old pen and paper. Someone, often a nurse, writes down the value and either logs it on paper or re-enters the data online.
The writer, Gary Baldwin, must have caught me on a bad day, it seems I couldn’t say anything nice about anyone.
Trinity exemplifies the industry’s challenge in capturing data directly from medical devices. The health system maintains more than 2,000 physiologic monitors and 9,750 IV pumps, says Kini, adding that the equipment comes from at least five different manufacturers. In this scenario, the key problem, Gee contends, is the absence of industry standards for how data is formatted and exported from the devices. Even devices from the same manufacturer may vary, he says. “Unless a device has the identical model number, the protocol may change,” he says. “To the medical device vendor, their product is the center of the universe. The idea of connectivity is one that vendors have to be pushed kicking and screaming into by their customers.”Hospitals have been willing accomplices up to now, Gee acknowledges. “Most hospital IT departments don’t think about data capture from devices,” he says. “They suffer from the same perspective vendors have. The IT department figures nurses will just type in the data.”
Gary also interviews Julian Goldman, who lends his more soothing perspective to the challenges of connectivity.
Be sure to read the whole thing.
AAMI 2007 – Day One, Clinical Engineering Symposium
First up today, the Clinical Engineering Symposium: Medical Device Integration Projects. A panel of rock stars will present case studies on medical device connectivity. Steve Grimes kicked things off to a full house – SRO, actually.
Case Studies from Beth Israel Deaconess
First up will be John Halamka, CIO at Beth Israel Deaconess Medical Center. His themes are:
- The importance of including medical devices in enterprise-wide EMR projects
- The importance of including clinical engineers and IT people during the planning stages
- The importance of looking to consensus-based standards
The American Health Information Community (known as “the community” rather than “a-hick”) identified 4 requirements to tackle in 2006 – a certification commission, standards, security and privacy, and a nationwide health information network architecture. Halamka noted there are over 700 health care standards that could be applied. He presented a nice model with a basic use case, actors, tasks and documentation – that is intended to lead up to the blessing of specific interoperable standards that will go into federal procurement standards (effectively a de facto standard). All of this has been worked through and presented to AHIC for formal adoption.
In 2007 the focus is privacy and security, emergency responder, PHRs, meds management, and quality (QI) – with the goal to again review, align and harmonize all of these areas into a common manageable process. Preliminary requirements for privacy and security are completed. For 2008 AHIC is looking at medical device standards, with focus on remote monitoring outside acute care settings.
The projects they’ve done at Beth Deaconess over the past few years include mobile glucometer interfaces to a lab system, an ICU information system (Philips monitors with MDsoft), anesthesia information system (Compurecord system from Philips), positive patient ID/eMAR (passive RFID for neonates and barcode), and active RFID.
The RFID deployment was justified on improved asset tracking -loss prevention, reduced time looking for assets, eliminating device hoarding. Their consensus on active RFID: not yet ready for prime time. Beth Israel went with WiFi based RFID and PanGo. He notes the higher access point (AP) density requirement – wireless data requires 1 AP visible per client, RFID requires 3 for even modest performance (and notes increasing co-channel interference issues with higher AP densities). They started with 450 Cisco APs, and they expect to add an additional 100 thin APs and one controller.
Tags were found to be a weakness – too expensive, too big, too short a battery life. With the release of third generation tags, most weaknesses are being overcome. Accuracy results: 33% of readings were room-level accurate; 50% of readings were off by one room; 17% were off by 2 or more or the tag was not even seen. This is great for finding IV pumps squirreled away nurses, but of little value for staff and patient tracking applications.
Note that this was a pilot evaluating just one vendor, and not RFID in general. They have decided to deploy the system house-wide for large assets and applications that require no more than 10 meter (30 feet) accuracy. The biggest surprise in the RFID project was with the Cisco wireless LAN. According to Halamka, there are two kinds of Cisco code: “safe harbor” code that is rock solid with basic functionality, and “bleeding edge” code that has all the cool advanced features and is almost completely unreliable. Cisco ended up putting a lot of their resources into kgetting and keeping Beth Israel operation.
Patient-Centric Medical Systems
Julian Goldman, director of the Medical Device Plug and Play lab in CIMIT presented next. With everything that’s going on in clinical engineering these days, he does not envy AAMI members, but he does admire them. His talk was titled, “can patient-centric medical systems integration improve safety at the “sharp edge” of health care delivery?” He reviewed CIMIT’s Operating Room of the Future (ORF) program, describing the workflow and how devices are integrated to support that workflow.
He talked about systems integration and medical device interoperability to create safety-interlocks and high reliability systems for care. The identification of “exception conditions” across a broad care delivery effort like surgery is perhaps more valuable than automating normal tasks and procedures. After numerous examples of interoperability that exist in our daily lives, he contrasted that with the almost total absence of interoperability in health care. Finally Julian described numerous interoperability projects and experiments – none of which are available commercially. The reason for the absence of these interoperable safety-interlocks was laid at the feet of vendors – and at the same time, Goldman appealed to hospitals to work together to “motivate” vendors to commercialize these kinds of capabilities. Be sure to check out his site for lots more information.
Connectivity Case Study – Kaiser
Bridget Moorman, Clincal Systems Engineer at Kaiser, was up next to talk about her project at Kaiser. They’re attempting to integrate medical devices with their Epic EMR on an enterprise scale – a daunting task. Bridget laid out the key requirements medical device connectivity, describing things like, “want[ing] seamless interconnection and data flow from biomedical devices to clinical information systems.” The means to effectively manage connectivity deployments was also discussed. She also presented a nice model for considering infrastructure hardening requirements for medical device connectivity.
Bridget next delved into standards: 11073, HL7, DICOM, CANopen, Continua Health Alliance, and XML. She reviewed numerous device vendor solutions (GE, Philips, Welch Allyn, Capsule Technologie, Sensitron, HCTSi iSirona, LiveData, iMetrikus) she has in her lab.
Perhaps the most important topic presented was a description of the “device interoperability” contract language that Kaiser has recently specified in their purchase contracts:
- Supliers will warrant that their products will interwork or interoperate with KP’s Epic systems and with other designated third party products
- Supplier will finalize any integration with third party products before delivery to kaiser and will do independent testing of the interoperatbility at CIMIT or the Sidney Garfield Center
- If unsuccessful interoperation, will reimburse Kaiser for product cost
- Do not specify interface standard due to current volatility in standards definition and development
This is radical stuff that places the systems integration role firmly on the shoulders of the medical device vendor.
After presenting an enterprise connectivity architecture, Bridget offered some great observations about connectivity pitfalls and lessons learned:
- IT folks frequently don’t understand clinical variable context, e.g., temp versus core temp
- Need for dual systems operation and limited HL7 message availability
- Limited or no availability of “test” devices – connectivity test systems rather than the actual device
- The duplication and complexity of interfaces and components to make medical devices with serial ports network-aware – creates problem-identification challenges
- Brittle interfaces where problems can ripple on either side of the interface when changes occur in either the device, interface system or CIS/EMR
- Prevalence of proprietary end-to-end solutions from device vendors
- The paucity of connectivity monitoring and management tools to help identify and fix signal propagation problems (due to limitations in devices and connectivity systems)
- Very limited interface configuration capabilities – scalability, message modification, number of ports, etc.
- Insufficient wireless capabilities – health care delivery is inherently mobile, connectivity must be too
- Establishing and maintaining patient context – older technology associates data to patient using port numbers or bed locations, and not actual patient name and ID
A sample device connectivity architecture was presented, highlighting the complexity and additional steps and vendors necessary to get device data into the EMR. Many device vendors have dragged their feet in adding network connectivity to their devices. The reliance on dongles or warts (modules that connect to the device’s serial output and convert data to network connection) is suboptimal, resulting in another unnecessary component to be configured, and maintained – when they get knocked off or banged against the wall or door jam. The best solution is an embedded radio and/or Ethernet port. Many device vendors need to redesign products with more microprocessing horsepower to enable better interfaces.
Bridget described their experience with Nuvon for remote monitoring of the device – connectivity system – EMR chain, including network connections. Kaiser is looking at this to help simplify the connectivity service tree (a sample of which was presented). She closed her presentation reporting that hospitals can expect to pay $10,500 per bed to export device data to HIT systems via HL7. This cost includes hardware, software and biomedical engineering labor costs. Any costs to purchase new medical devices to facilitate connectivity (like new Dynamaps with IrDA capability) is not included.
Medical Device Interoperability
Rich Schrenker, Systems Engineering Manager at Mass General, presented an very thought provoking look at interoperability – what it is and what it can be. After reviewing various interoperability definitions from the IEEE, HIMSS, the MD PnP lab, and the USB Implementers Forum Personal Healthcare Device Class – all different – Rick noted that connectivity remains a largely unsettled market.
In thinking about connectivity, Rick considered systems engineering and creating resilient systems. He noted a challenge in the following quote from S Dekker, Resilience Engineering:
“One marker of resilience… is the distance between operations as management imagines they go on and how they actually go on… Understand the gap between the system-as-imagined and the system as actually operated requires investment not only in understanding how the system really works bu also how it is imagined to work. The latter can sometimes even be more difficult.”
And from “To Err Is Human,”
People… become accustomed to design defects and learn to work around them, so often they are not recognized… Accidents are more likely to happen in certain types of systems. When they do occur, they represent failures i the way systems are designed. The primary objective of systems design ought to be to make it difficult for accidents and errors to occur and minimize damage if they do occur.”
The point of care is rife with users who are accustomed to bad design – too many rounded corners, too little consideration of the other things clinicians do that is beyond your own device. Sadly, this accommodation becomes requirements and sales objections for newer products that do not include those design defects.
Rick notes a major shortcoming of our health care delivery system: “No substantial perspective on the entire system of health care or training in the use and implications of systems tools and information/communications technologies for managing and improving the system is included in medical education… [and] engineering careers in medical care insitutions are nearly non-existent…”
In a market dominated by proprietary medical devices, Rich suggested open engineering and leveraging commons-based peer production. Like the open source software business model, why can’t more providers actively collaborate to encourage vendors to develop better products and evolve widely held best practices.
In considering connectivity and interoperability, Rick wrapped up with the following:
“When health care providers begin leveraging interoperability to construct systems of components in configurations not specifically intended by manufacturers and approved by FDA, they will be engaging in design and integration activities the likes of which are currently under regulatory control. That will be addressed, and ultimately somebody will be doing the necessary point-of-care engineering, whether experienced, familiar, informed by history and safety-conscious, or otherwise.”
Pictured right is presenter Bridget Moorman with Manny Furst, who presented on Monday.
Drivers and Barriers in Medical Connectivity
I’ve been wrapping up a pretty big project and so posting has been light this week. I do have some things that caught my eye this week that I will post later this weekend. Earlier this week I was asked:
- what connectivity capabilies are being built into medical devices now,
- what factors are driving these changes, and
- what barriers in your area(s), what are they?
The biggest trends driving what I call medical connectivity are EMR integration, workflow automation and alarm notification.
The basic capabilities required to meet the above include:
- the ability to establish patient context, acquire and transmit data from the medical device
- a server to capture, store, queue and transmit data (optionally, an HL7 interface for EMR integration, and logic to analyze data)
- client applications (usually served up by the server) to enter, review and edit patient data.
Current State of Medical Device Connectivity
It’s time for another fisking! This time, the website medical devicelink has an interesting story called IT Showcase from the Business Planning & Technology Development section of MX magazine. The story explores the integration of medical devices with information system technology (aka, connectivity). While this article touches on areas in and outside the hospital, my comments will be limited to the hospital environment. Let’s get started.
Even among healthcare professionals who are commonly the earliest adopters of new technologies, black boxes filled with zeroes and ones don’t have a lot of appeal. So it’s easy to understand how some users might be tempted to disregard some of the most complex—and even revolutionary—enhancements currently being made in the world of medical
product development.
Market adoption is a funny thing in hospitals (frustrating is frequently a better term). And yes, the times they are a changin’.
But little by little, device manufacturers are beginning to incorporate high-end information technologies (IT) into their products. And in doing so, they are gradually creating a world of next-generation healthcare products with features and functionality that users care about very much. Whether the need is for easier transmission and archiving of diagnostic imaging, quicker delivery of patient information to healthcare professionals on the move, or advanced monitoring of patients in alternate-site healthcare settings, device manufacturers are framing new solutions using advanced IT systems.
Of course connectivity is not as new as it sound here, vendors have been integrating devices with computers to add value and differentiate for more than 20 years. As medical device markets mature, products become less differentiated and end user requirements change. Requirements shift from the creation or quality of data to the management of data. I’ve written on these changes before, here and here.
Common connectivity applications include automated data analysis, report generation, data storage retrieval and query, workflow automation, surveillance, alarm notification/management and event logs.
While medtech manufacturers have seen device interfaces, communication standards, and networking topologies come and go over the years, most recognize that medical technology is now firmly on the path to convergence with information and communications technology. In response, they are increasingly designing and manufacturing their products to be fully compliant with industry standards.
The pressure to integrate IT is independent of whether or not standards exist to make that integration easy. It seems to me, that there has been little change in device interfaces, communications standards or networking topologies in device connectivity. Serial ports are ubiquitous on most medical devices, and have been for years. Serial interfaces require device drivers, an area with no standardization whatsoever — serial drivers and even cables vary across the same vendor’s product lines and even across different versions of the same product.
After some confusion in the 1980s (when ArcNet, IBM’s Token Ring and Ethernet all gained early adoption), Ethernet became the de facto networking standard. Network cabling did evolve, from coax cable to twisted pair and optical cable (used for long runs orhigh speed backbone). The latest wrinkle, introduced in the 1990s is the WLAN based on the IEEE 802.11 standard.
While this technology migration has been relatively stable and predictable it has added a significant cost to vendor’s sustaining engineering costs, as they have worked to incorporate current technology into new product releases. Because medical devic e life cycles are longer than computing components, vendors can be faced with doing an unplanned product release to keep up with technology. Minimizing this sustaining engineering cost and the cost to support different generations of technology are major vendor connectivity challenges.
A common engineering and IT joke is that the great thing about standards is that there are so many of them. Not only are there numerous established standards, but there are also de facto standards and what I call “wannabe” or pseudo standards. The only broadly adopted health care standards in this area are HL7 and DICOM. Other technology standards in broad use, like Ethernet and 802.11 don’t come close to “plug and play.”. An up and coming technology replacing RS232 is the Universal Serial Bus, or USB. These technology standards form a core set of de facto standards for medical device connectivity.
The Medical Information Bus, or MIB, is an example of a failed standard. Started in the late 1980s, progress towards plug and play connectivity (meaning that everyone’s serial device driver operated the same way), never got adoption. Now referred to as the IEEE 1073, I believe that this standard will merge with HL7, resulting in a higher level XML based standard that rides on a variety of connections.
Pseudo or wannabe standards include things like WMTS, or Wireless Medical Telemetry Service. WMTS is simply a radio frequency spectrum allocation to replace the previous VHF spectrum that the FCC has reallocated to other uses. Vendors using WMTS are positioning it as a “protected” standard. Unlike 802.11 which specifies both frequency and protocols, WMTS does not specify any protocols. Consequently, WMTS implementations are proprietary because a vendor’s WMTS infrastructure only works with their devices, creating a closed system. Traditionally the only devices using WMTS were telemetry monitors. Datascope has extended WMTS in their new Panorama system to include multi parameter patient monitors. Other WMTS users (GE, Philips, Spacelabs) limit WMTS to telemetry. I would not be surprised if some vendors attempt to leverage WMTS to create proprietary networks that connect medical devices beyond telemetry. You can read more about WMTS and ISM here and here.
Of course buyers want a very limited number of broadly adopted standards. Vendors, if they’re smart, want limited standards too so they can concentrate on their core competencies (building a better mouse trap). Frequently though, vendors end up spending considerable dollars (both theirs and their customer’s) on proprietary technologies in an effort to erect high switching costs to preserve market share.
The field of imaging has long been in the vanguard of information technology applications for medical equipment…While other sectors of the device industry are at square one in figuring out how to develop technical standards that will enable them to take advantage of IT-related opportunities, imaging companies already have more than a decade of experience at implementing such standards.
Taking advantage of this experience, a number of imaging companies have begun to turn the corner into the field of health information management, building new business units that may expand their presence in a variety of clinical environments. Companies in other sectors will have to move quickly to catch up with the imaging sector, but they can also learn a lot from the experience that imaging companies have already gained.
They are correct that imaging is a very mature connectivity market, perhaps the most mature. Once medical device markets go through the connectivity phase, the value proposition for that market shifts. This shift causes companies to adjust their strategies to maintain growth and recapture value in order to maintain margins. It’s been interesting to watch imaging vendors as they struggle to maintain growth and value — there has been a wide variety of strategies and results.
As hospitals prepare to implement end-to-end, enterprise wide information systems, integration and interoperability are the guiding watchwords. The electronic health record (EHR) will become the key focal point of clinical information systems. All electronic medical devices and equipment will be required to share and exchange information with EHRs, which are expected to become ubiquitous over the next 10 years as part of a federal government initiative to streamline the delivery of healthcare services.
The biggest driver to medical device connectivity at the point of care (POC) is the electronic medical record (more on this here). Hospitals face several challenges getting medical device data into clinical information systems. Most currently installed medical devices are several years old and lack connectivity capabilities beyond an RS232 serial port. Networked medical devices that are out there are “islands of information” running on private networks, many using outdated network infrastructure. On the vendor side, no one vendor makes all the devices that will eventually need to be connected (patient monitors, IV pumps and ventilators) so a single vendor solution is unavailable.
The traditional connectivity model for therapeutic and surveillance devices (pumps, vents, monitors, central stations) is based on the ICU. The ICU environment is characterized by gorked out patients, bolted down monitors and other devices that were wheeled up and remain with the patient much of their stay. As a consequence, the patient monitor became the data hub, using data concentrator products like GE’s DIDCA. Monitors are networked, but other medical devices plug into the monitor via RS232 serial cables. EMRs got their start as ICU charting systems, and this hardwired, monitor-centric approach worked fine. Companies like Capsule Technolgie and HEI sprang up to handle all those messy proprietary serial interfaces. This approach also relieved most devices of the complexity of establishing and maintaining patient context; “dumb” devices do not know the identity of the patient they’re connected to, they rely on the monitor, data hub or central station to know the patient (device x is plugged into port y, which is in room z, occupied by patient Jones).
As EMRs start to penetrate general patient care areas there are new environmental considerations. Multi parameter patient monitors are replaced by spot check vital signs monitors, and other medical devices (especially IV pumps) are used with no continuous patient monitor to act as a hub. There are no gorked out patients, they get up to go to the bathroom or take a smoke break and are encouraged to walk around as soon as they can. Now it becomes much more cost effective to wirelessly connect medical devices instead of installing data concentrators and device specific serial cables in each patient room. Because few patients outside the ICU are monitored, medical devices must connect on their own. And because they’re wireless there must be a way to reliably associate data from the device with a specific patient and maintain that association as patients move throughout the hospital, going in and out of coverage.
Patient acuity is rising in care areas outside the ICU, resulting in more aggressive therapeutic interventions and a greater need for surveillance. Variable acuity units are being adopted by more hospitals to relieve patient flow bottlenecks (and avoid considerable cost) in ICU and step down units. These trends take connectivity requirements even further from the ICU model. In response, vendors are stepping up with more sophisticated connectivity solutions. Some, like Sensitron’s or Care Fusion, offer systems targeting legacy devices with serial ports. The new Welch Allyn Propaq LT patient monitor (pictured at top) has state of the art connectivity built in; patient context is established at the monitor and connects wirelessly to a server with an HL7 interface that connects to the EMR. Stinger Medical sells a spot vital signs monitor that has all the connectivity built in as well.
By its nature, healthcare is a mobile profession. Whether making rounds at a hospital or going from patient to patient in a busy clinic or private practice, physicians cannot be tethered to fixed computer workstations to remain connected. Handheld devices, typically built around a personal digital assistant (PDA) or Tablet PC, are increasingly finding their way into a wide range of point-of-care medical devices. Typically running either the Palm or Microsoft Pocket PC operating system, these off-the-shelf devices can be readily adapted to both medical diagnostic and reference applications. Clinical data can be readily uploaded and downloaded from a PC using industry standard wired or wireless interfaces.
The mobile nature of health care is right on. In the hospital at least, focusing exclusively on the physician is a mistake. Caregivers have a much more direct impact on patient safety and the ability to deliver the most appropriate care in the lowest cost setting. Regardless of which user you’re focused on, the best market research I’ve seen on mobile computing in hospitals are the reports from Spyglass Consulting (who has reports on both physician and nurse mobile computing). Microsoft has won the mobile computing operating system battle in the hospital; Pocket PC and Windows CE are used extensively in both embedded medical devices and client software for PDAs. Palm has an installed base of physicians based on reference apps like Epocrates, but wireless interactive applications are being written for Microsoft rather than Palm.
Device selection must be based on use cases. Mobile computers at the point of care must be rugged, operate for a shift without recharging, and able to be wiped with disinfectant. Frequently barcode readers are required as well. The PDA leader in this space is Symbol, with Hand-Held Products coming on strong.
Mobile apps fall into two categories, data intensive activities like order entry or charting, and messaging apps delivering alarms, alerts, worklists and other time sensitive data. Data intensive apps require lots of screen real estate while alarms, messaging requires a device that’s small, light weight and easy to carry. There is no one device that meets both sets of requirements without seriously compromising one or the other. Messaging devices must be multi purpose because caregivers will only carry one, not one per vendor. Accessing multiple applications on a tablet, laptop or computer on wheels (COW) is similar to setting up a desk top client for the same purpose. I think the long term winner for messaging apps will be a VoIP phone with a graphics display (this Cisco phone is a good start).
Accessing multiple point of care messaging applications is much more complex, the device is less “general purpose” than a desk top PC and applications can be much more demanding. Messaging applications include alarm notification (life-critical FDA regulated), data capture, patient context management, results reporting alerts, and caregiver worklist management. The vendors involved include traditional HIT vendors, smart pump vendors, those making patient monitors (both spot vitals and continuous), and enabling vendors like Sensitron and Care Fusion. What a mess.
The rising costs of hospital-based healthcare have brought about a move to provide medical services at alternate sites, including the patient’s home. Reflecting this trend, homecare is now one of the fastest growing sectors of the medical industry.
As patients continue to be discharged only partially recovered, the need for home care will continue to increase. Better management of the chronically ill, especially those with comorbidities, will also improve. Growth in this area has never been held back by an absence of technology, but rather a general lack of reimbursement.
As manufacturers increasingly commit to integrating network connectivity and enterprise wide interoperability into their electronic medical devices and equipment to meet the competitive demands of the healthcare marketplace, what forces will shape the next generation of medtech equipment? If the electronic health record is to fulfill its promise of capturing clinical data at every point of contact, won’t every medical device have to become an electronic device?
Just to pick a nit, “every medical device” is in fact “an electronic device.” And yes, they will all end up connected. Smart IV pumps are just the latest in this wave of true connectivity integration — and most of the IV vendors have just started with the easy stuff like formulary management and the 5 rights. True interoperability (remote control of the device by another system) and life critical features like alarm notification represent a huge step beyond current capabilities. The use of wireless continuous patient monitors outside the ICU will continue to be adopted. Future spot vital sign monitors will also incorporate wireless connectivity and patient context — Datascope’s Duo is probably the last spot vital signs monitor to be introduced without wireless connectivity.
Vendors face important strategic decisions about connectivity that will directly impact their long term success. (More on vendor challenges here.) The installed base of current connectivity products is small, but as adoption increases hospitals will struggle with the integration of multiple point solutions and the inevitable migration to an enterprise approach to connectivity.
Many common medical office devices like temperature probes, stethoscopes, scales, and blood pressure measuring devices already feature digital circuitry, but are typically designed as stand-alone devices. Expect a major shift to wireless connectivity for these and numerous other devices in order to accommodate the networking requirements of electronic health records.
Vendors that play in both the private practice or ambulatory care market and the acute care market face additional challenges. While both markets share many requirements, the markets themselves and their environments are quite different. Developing a strategy that address both markets and minimizes unnecessary duplication is not trivial.
For medtech manufacturers, this is a world full of promise. But they’re not alone. With such unparalleled opportunities in healthcare markets, IT hardware and software manufacturers are also taking notice. The healthcare divisions already established by those companies could become medtech’s next competition.
Vendors in this “world full of promise” will find themselves struggling to operate outside their medical device comfort zone, while fighting a rear guard action against both health care IT and enabling technology vendors looking to separate (and pocket) the incremental value provided by connectivity from the device. The smart vendors will develop strategies to carve out their portion of this bigger pie, meeting customer requirements and holding these new competitors at bay. There is no doubt, however, that some market segments and product categories will be commoditized; new players will emerge and some current vendors will go into decline.
The risks are no less for hospitals. Traditional organizational silos (nursing, biomed, IT) must be breeched to bring a cross functional approach to the next big leap in hospital automation, the point of care. The absence of a potential single vendor solution means that hospitals will have to navigate the connectivity issues discussed here and plot a course that will support organizational goals on schedule and within a proscribed budget. There will be casualties on the hospital side as well, with system implementation, budgets and time lines all compromised by poor choices and unforeseen circumstances.
The Chinese adage, “may you live in interesting times” certainly applies to today’s connectivity market.
UPDATE: At the AACN/NTI meeting Philips announced WMTS support for their multi parameter patient monitors, specifically models MP20, MP30, MP40 and MP50.
