Bridging the “Device Divide”
November 6th, 2007 by Jason Williams
(6 votes, average: 5 out of 5)
Loading ...Posted in EMR, HL7 Integration
During a recent stay at a very well respected Dallas area hospital that saw my wife and I welcome our first child into the world, I was reminded that the “Device Divide” that separates the vast majority of healthcare providers’ medical device data from the rest of their clinical information network is not limited to just small to medium-size hospitals.
Given the fact that the hospital is part of a large statewide chain and would likely be labeled as cutting edge from a technological standpoint, I was somewhat surprised to see a nurse come in every 2-3 hours to dutifully record my wife and son’s vitals in a paper chart. I’m sure that information was re-entered into an EMR at some point, but I couldn’t help but wonder how often the data gets transposed or forgotten.
That experience begs the question - why has it taken so long to bring patient care device data online, even at some of the nation’s largest hospitals? The problem of crossing the “Device Divide” – that gulf between the hospital network and its medical devices that is typically traversed by the nursing staff with pen and paper – is not an easy one.
One reason is a lack of cost-effective, reliable solutions for doing so. Device connectivity has only recently (within the past couple years) been given the attention that it warrants, and early solutions have been plagued with the same kinds of ‘kinks’ that any early stage technological advancements have encountered.
Another closely related explanation for the delay in crossing the “Device Divide” is that enabling devices to bridge that gap represents quite a leap outside of most manufacturers’ technological sweet spot. That’s not to say that they’re not extremely capable. In fact, the exact opposite is true – patient care device OEM employees are some of the brightest that I’ve run across. It’s just that, as Robert Nadler, an employee at a device manufacturer, recently blogged:
“The problem… is that we don’t have the resources to build each unique interface required to satisfy all of our customers. Plus that, our business is building medical devices, not EMR solutions.”
Device companies have spent years building R&D and engineering departments focused on building better and better equipment that takes more and more accurate readings in the easiest possible manner. Their aptitude for doing just that is what has always separated them from every other device manufacturer with whom they compete.
But bridging the divide requires a very different skill set – the ability to write software that provides HL7 integration capabilities that enable devices to interface with countless EMRs and other clinical applications. And once written those healthcare integration systems become much like an NFL referee – the good ones go unnoticed, and the bad ones gain the kind of notoriety we would all like to avoid. Despite representing a critical part of the total connected device solution, from the customer’s perspective there is nothing tangible about an interfacing system that will make them value it enough to justify the cost of ramping up a development shop to construct it in-house.
That’s why I think the interfacing conundrum is one that lends itself nicely to the idea behind Joseph Nemeth’s article entitled “The Drive Toward Collaborative Innovation for Medical Devices” in the August 2006 issue of Product Design & Development magazine. In it, he concludes that:
“Collaborative partnerships provide a balance of assessing what organizations require from outside sources given their need to innovate, and what they must retain to achieve their business and revenue objectives. It is a sound enterprise strategy that can minimize time to market, reduce costs, generate differentiated offerings, and drive a business model for sustained industry growth.”
Collaborating with a strategic partner well versed in ways to cross the “Device Divide” could prevent manufacturers from stretching their resources too thin and keep them from stepping too far outside their core competency. If chosen wisely, such a partner could help get a sound connectivity strategy in place for much less than the cost of taking on the initiative in a vacuum.
Last 5 posts by Jason Williams
- CDA - The American Bridge from HL7 V2.X to V3? - May 15th, 2008
- HL7 Sample Messages - Always the Best Way to Go - April 9th, 2008
- Overcoming the Barrier to Participating in the IHE Initiative - March 14th, 2008
- Bridging the "Device Divide" - November 6th, 2007
Please note: NeoTool is now Corepoint Health! Please visit our new Corepoint Health IT Blog for recent insights. Also visit our new HL7 Resources section for additional information.
Jason,
We couldn’t be in greater agreement. So far, the best post I’ve found is http://medicalconnectivity.com/ , he’s got great insight and experience in this area. I am as mystified as you are that this area still is outside the realm and such an obvious and unnecessary risk and time waster. There’s a group out of Fla that’s been working on monitor data collection, a partnership between Univ of Miami and IBM (ICU Data Systems maybe?). Does Neotool do a lot of device connectivity?
From my perspective Emergin (alarm capture and transmission) and Capsule Technologie are the leading vendors working in this space. There are about four other competitors to Capsule that I follow and one main competitor to Emergin that also warrants following if this of interest to you. Ultimately - these are functions that would be ideal in an integration engine with all the buzzwords included (BAM, BPM, Rules Engine, Agents).
John-
I too am a big fan of Tim Gee’s Medical Connectivity blog and referenced
it in one of our recent Fast15 webinars. I am not familiar with the U of
M/IBM collaboration but will definitely look into it - thanks for the tip.
NeoTool has in fact worked with multiple device manufacturers to develop
“translation” technologies that convert their proprietary reading
formats into HL7 messages that can be integrated into the patient care
facility networks. We’re also working with hospitals in an effort to
develop a solution that provides them with a single point of entry for
device data, regardless of manufacturer. Some of the efforts are still
in the early stages, but we are active with both vendors and providers.
Jason,
The key area that is not mentioned in this post is that the primary issue is a business one and not technological. 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 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.
Though there are “technological sweet spot” issues in some companies, but for the most major manufacturers, they are VERY competent technologically … but that is applied in proprietary configurations that bolsters their market position.
Also, a key difference from these devices and other HIT systems is the regulatory oversight (FDA) that they receive.
The good news is that there have been major advances in this area, especially by the IHE Patient Care Device group (www.ihe.net) which has published a Technical Framework that is based on HL7 v2.5 and ISO/IEEE 11073 med dev semantics standards to establish a message profile + content for communicating device data to enterprise applications. At the HIMSS ‘07 Showcase in New Orleans last February, B.Braun & Draeger & GE & LiveData & Philips & Welch Allyn publicly demonstrated this connectivity directly from system to system. This year these same vendors are joined by Epic, SpaceLabs, CapsuleTech, and … .NeoTool!
The next step in bridging the Device Divide is for providers to demand standards-based connectivity in their RFPs, calling out profiles such as those specified by IHE PCD.
Great discussion on connectivity! Much like diagnostic medical devices have incorporated connectivity to integrate and improve the diagnostic process, devices used at the point of care are becoming parts of an enterprise solution.
The traction that solutions like Emergin’s and Cardiopulmonary, the increasing success of Capsule Tech and the many new start ups like Sensitron, HCTSi, Cain Medical, etc. are tangible examples.
Much like proprietary embedded system features, vendors are trying to use connectivity for competitive advantage. This is creating a new barrier to entry for start-ups.
Fortunately for the market, unique and proprietary connectivity is a bit of an oxymoron. There are are alternative strategies that are open and foster interoperability that can provide significant competitive advantages as good as or superior to conventional proprietary end-to-end solution strategies.
Great discussion. I have to second the idea that Todd expressed to move the interoperability mission along…health care organizations must “demand” interoperability by design. If the purchasers exhibited behaviors that rewarded providers for interoperability initiatives, with purchases and publicity, and punished those who maintained inflexibility, the market demand would accelerate the appropriate supply.
[…] 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 […]