GlobeStar Systems World Connex — Day One
I’m at GlobeStar System’s annual user group meeting this week, in Lisbon, Portugal. Attendance is about 150, equivalent to last year’s meeting.
The messaging middleware market is transitioning from middleware to an enterprise application. GlobeStar has been in the business just over 10 years. Unlike Emergin, who started in paging messaging, GlobeStar got their start in the 1990s integrating Austco nurse call and Nortel’s Companion (the first wireless phone system in North America). Over the years, the company (and the market) have evolved from a single nurse call/phone integration to a platform supporting many different systems and devices both on the input and output sides — and incorporating workflow automation through rules, alert initiation, and escalation.
The conference kicked off with introductory presentations from David Tavares, CEO of GlobeStar; Dr Teresa Sustelo, President of Centro Hospitalar de Lisboa Central (a large multi hospital system); and Dr Miguel Correia, Regional Secretary of Health, Azores. During his opening remarks, Miguel Correia noted the broad applicability of improved messaging. He spoke to the extension of messaging systems to tracking and eventually orchestrating complext processes and tasks. This is a vital requirement in health care delivery.
GlobeStar’s technology has been applied outside health care too. They monitor automobile painting production lines and “man down” systems in mining. Miguel Correia mentioned that they’re using ConnexAll in CO2 monitoring at volcanos in the Azorres. Now they’re moving further into workflow automation.
Keynote Presentation
My keynote presentation theme was, “everything is connected” and contrasted this with provider’s tendency to only focus on the immediate problem — or what they think is the problem.
Putting the health care IT market aside, the point of care market is divided into 6 separate market segments: wireless phones, patient flow applications, medical device connectivity, messaging middleware, nurse call, and real time location systems (RTLS), not to be confused with indoor positioning system infrastructure vendors like Sonitor and CenTrak. For some time, buyer’s haven’t been able to buy a product from one of these segments without impacting one or more of the others. Connections to medical devices, and the nurse-to-patient assignment process are common points of contention.
GE Healthcare Acquires Agility Healthcare
A unit of GE Healthcare’s global Diagnostic Imaging Services business acquired Agility Healthcare Solutions today for an undisclosed sum. This is the same group that did the deal with Anywhere several years ago, and most recently signed a distribution deal with CenTrak, which was announced at HIMSS 2008 (press release).
What started as a straight on asset management strategy has grown in scope.
“Any hospital administrator knows about the daily headaches caused by the logistical coordination of providing patient care. For each and every patient interaction, patient, clinician, staff, space, assets & supplies must come together at the same time. Agility’s visualization system is the one tool we’ve found that lets us visualize these interactions to predict and prevent bottlenecks before they occur,” said Jeffrey Burke, Vice President and Regional Chief Information Officer, Bon Secours Health System.
The RTLS (real time location system) market’s initial focus was asset management. The industry consensus at the time was that asset management was easy to understand and had an attractive ROI – most hospitals lease some of their equipment that ends up poorly utilized due to hoarding and misplacing equipment. An RTLS can significantly reduce the amount of equipment leased through increased visibility and thus, utilization. Sadly, the hospital market was not sufficiently compelled to adopt this application (regardless of the ROI) at the rate that entrepreneurs and venture capitalists expected.
The founders at Agility, being software guys from McKesson, started with software. After some initial experience in the market they decided to stick with software and resell whatever infrastructure best suited their customer’s application. And the applications the market pulled them to are the kinds of things Bon Secours is doing.
Awarepoint RTLS Installed at UCSF
Awarepoint was chosen for asset tracking at University of California San Francisco Medical Center (UCSF). The vendor selection team looked at 6 different systems and selected Awarepoint. The story in Healthcare IT News highlights the technology’s use for improving productivity in the surgery department.
Here’s what jumped out at me:
Installation and the tagging of 700 assets throughout UCSF Medical Center took under 48 hours.
Whoa. The 700 tags is not much for a 500+ bed hospital; what got my attention was the 48 hour installation time. A brief blurb on the product explains:
Awarepoint’s RTLS needs no hardwiring or fixed infrastructure due to
wireless sensors, which plug into electrical outlets. Assets are
attached with small, battery-powered tags, which are tracked using the
Web-based Searchpoint search engine.
Pictured at right is an Awarepoint ZigBee receiver, shot in the wild.
New Infrared RTLS Vendor
Well, new to me anyway. The company is CenTrak, located in Newtown, PA, South Korea and Chennai, India. The company, a consumer electronics company years earlier, launched an active RFID real time location system (RTLS) called TagAlert in 2005. Following the release of TagAlert, the company developed InTouch, an indoor positioning system targeting hospitals, long-term care and commercial facilities.
InTouch is is a zone based system – tag position is determined by the tag being within the presence of a receiver, or having just passed a receiver. Unlike a computational based system, where location is computed from the signal received at multiple receivers, the InTouch system uses receivers laid out in specific locations that act as gateways or choke points. When the presence of a tag is sensed by the receiver in a patient room, the system “locates” the tag in that room. Other zone based systems include Sonitor and RF Code. Some systems like AeroScout use both computational and zone methods to determine location
It is interesting to note that two vendors who previously touted infrared, Versus and Radianse, have downplayed the use of that technology. Rumors that another RTLS player was going to launch an infrared based RTLS remain just that – rumors.
What’s really interesting about InTouch is that the receivers are battery powered and wireless. This design feature joints Awarepoint and RadarFind as solutions that drastically reduce RTLS installation costs. Vendors with wired receivers require power and a network connection routed to each receiver, an expensive and trouble some proposition in most hospitals.
Pictured right is the InTouch Spider, their wireless battery powered infrared receiver.
Philips Acquires Emergin
Philips announced this week that they have acquired private health care IT vendor Emergin for an undisclosed sum. From the Philips press release:
transmit medical alarm signals throughout hospitals. The transaction is
expected to close in the fourth quarter of 2007, upon which Emergin will
become part of the Patient Monitoring business unit within Philips
Healthcare sector. Through this acquisition, Philips will expand the use
of information technology in healthcare - and
specifically in its patient monitoring business -
to improve patient outcomes and help hospitals work more efficiently.
Philips Healthcare CEO, Steve Ruschowski, brags on Philips' number one position in the patient monitoring market, and notes that the addition of Emergin will provide the means to address a long standing unmet market need – alarm notification. Sure, Ruschowski's not that direct, he refers to, “solutions that help them access the critical
patient data that our monitors provide, quickly and flexibly throughout
the hospital.” Same thing.
It seems that Philips is thinking that the Emergin acquisition fills a very specific gap:
notification software helps ensure that critical information is sent
rapidly to the right caregiver on the personal communication device of
their choice - be it a pager, wireless
telephone, PDA or LED sign. Emergin
software has wide acceptance among hospital chief information officers
(CIOs), who increasingly play a central role in the purchasing decisions
at hospitals. The acquisition of Emergin will enable Philips to
integrate the functionality offered by Emergin
software directly into Philips' current and
future patient monitoring products. Philips also expects to capitalize
on Emergin's strong relations with hospital
CIOs. Philips has a leading position in the global patient monitoring
market, which in 2006 was estimated to be approximately EUR 2 billion or
approximately USD 3 billion.
I guess that the first thing Philips will do is get premarket approval for Emergin's software for alarm notification. It's one thing for a small entrepreneurial software company to claim their product only provides “secondary” alarm notification, it's another when you're a big medical device company. Philips also realizes that alarm notification without a sample of the waveform that generated the alarm is of limited value. Displaying waveforms with the alarm appears to be the line drawn in the sand by the FDA; “secondary” alarm notification without waveforms will not be noticed, alarm notification with a waveform get you a lot of notice (just ask Cisco). Besides, Philips doesn't want any more of these.
The quote above also hints are a mid to long term vulnerability for Philips. Patient monitoring is a sorely undifferentiated market, and numerous big and small competitors will be entering the field over the next few years. Philips has the broadest, most up to date patient monitoring product line. But Philips will need more than their shiny new patient monitors to beat this competition. Future continuation of hospitals standardizing on one patient monitoring vendor will be dependent on delivering some real enterprise value. They are way behind with the solutions required to provide an enterprise solution that the market needs, and the Emergin acquisition will go a long way to fill that gap.
Post acquisition, Philips would be crazy not to continue an independent
Emergin distribution strategy. Only by actively selling Emergin's
solution, independent of patient monitoring sales, will other device
vendors be compelled to maintain integration with Emergin. Think back
to DataCritical. Their alarm management solution, StatView, got a lot of market traction – and a 510(k)
- and was resold by GE, Philips and others. After DataCritical was
acquired by GE Healthcare, vendors reselling StatView slowly evaporated.
Philips (then Hewlett-Packard) has apparently learned a lot from their Heartstream debacle. The brain drain that resulted from moving the company from McMinnville, Oregon (in the heart of the Willamette valley wine country) to the Boston suburb of Andover wrung a lot of the value out of the deal. The ATL Ultrasound acquisition was handled much better. Plans are to leave Emergin in their Florida digs. Senior management has probably signed the obligatory “we'll stay around a few years” contracts to help ease the transition.
More important questions will revolve around distribution strategy and product strategy. You'll note that the press release mentions Emergin's relationship with hospital CIOs, but says nothing about the many relationships it has with other medical device vendors. Emergin acts like the Switzerland of the point of care, integrating with everyone on an equal basis. Yet cooperation between direct competitors is not done among medical device vendors. While the Philips and GEs of the world dream of hospitals dominated by single vendors, we still live in a heterogeneous market. How Philips balances the de facto proprietary end-to-end product strategy with a product like Emergin's will determine how much value they can get from this transaction (and for how long).
For Emergin competitors this is good news. Until now, the big medical device vendors have withheld cooperation from other medical device middleware vendors like Globestar and Ascom because Emergin had the critical mass of vendor interoperability and they wanted to conserve R&D resources. Now vendors will be scrambling to secure compatible alternatives to their biggest competitor's offering. This news should be a real plus for a more clinically oriented competitor like Cardiopulmonary whose value proposition has been reinforced by Philips' move. Others, including Global Care Quest, LiveData, Nuvon and even Sensitron can claim a certain validation for cross vendor/cross device connectivity.
For hospitals, this is a mixed blessing. How Philiips balances the Dr. Stranglove compulsion towards proprietary systems and the open interoperability Emergin offers will tell the tale. (It's almost too bad that a health care IT vendor like Cerner or McKesson didn't buy Emergin.) Workflow automation at the point of care is difficult just because so many things are interrelated. Initiatives like wireless communications, meds administration, charting, alarm notification – all of these impact multiple systems, and there are no single vendor solutions. Heck, you can't even buy vents, pumps and patient monitors from one vendor. Hospitals should walk slowly, buy when there is a clear ROI matched with a released product, and take vendor roadmaps with a grain of salt.
Pictured right is a view from Emergin's integration lab.
Is Microsoft HealthVault Safe?
Many have criticized HealthVault regarding privacy and security concerns, or perceived limitations of HV as a personal health record (PHR). I suspect that HV is challenged more by the market's perception of Microsoft's long running security issues than with any actual shortcomings of that type in HV. And since HV is not a PHR, but rather a “platform,” criticisms about any lack of PHR features is not relevant.
One topic I've not seen addressed is the safety and effectiveness of the data within HV – and I don't mean “safety” as in the data is secure from unauthorized access or misuse. I mean “safety” as in the utilization of data stored in HV by other applications won't result in an unsatisfactory patient outcome, you know, like death or injury.
Certainly at first blush HV does not fall under the FDA's purview, but things could end up that way. (More on this later.) A key tool mandated by the FDA's Quality System regulation (QSR) to ensure quality and safety is the risk analysis. Any kind of connectivity needs to be thought of with risk analysis in mind – what can go wrong and how can those risks be mitigated?
If HV is more than just an interface engine, pushing data from one application to another, the risks are narrow. Sample risks include: data corruption during transfer into or out of HV, and data corruption during conversion of the data from one standard format into another. Mitigating these risks is straight forward; common data communications techniques to ensure data quality, and design and testing of the HV platform itself to verify data conversions are done accurately and reliably.
What if HV is more than a translator, but a repository of patient data? Most applications have a database that is written, updated and controlled by that application. It is the application that ensures that the data in the database is correct and valid. It is the application that provides the workflow to safely and reliably validate, edit and update data.
How is data quality ensured when various applications can read and write that resides on HV? Let's say data is edited or a calculated value is generated and then rewritten to HV. Does it overwrite the existing data? If there are multiple sets of the same data, how do you know which set is the best and most accurate data? Do you assume that the most current values are correct? What if they're not? What if that “better” data is not rewritten to HV but remains in the clinical information system in which it was generated – and another application comes along and uses the “wrong” data?
HV does track the properties, history and sharing of patient data. It also logs the time received and the source of the data. (You can see more detail in this page from the HV Developer Center.) Is this sufficient? Perhaps. What seems to be missing is the logic that controls the workflow between various applications, both what they do to the data and how they use it. Also needed is a formal verification process to ensure that any logic concerning HV data is implemented properly between applications, which is not mentioned on the HV Going Live! page.
The first red flag for the FDA regarding HV is the Connection Center (CC). Here data is acquired from medical devices, and if that data is to be used in rendering a diagnosis or guiding therapy (clearly the case with hypertension, diabetes and other chronic diseases) then CC meets the legal definition of a medical device. Presently, the FDA does not actively regulate products like CC, although there are examples of standalone connectivity products and features similar to CC that are built into broader based products that have received the FDA's premarket approvals. The regulatory risk for Microsoft is that the FDA could change its position and recall the product until it receives premarket approval. This change could result from political pressure (Congress or advocacy groups), adverse publicity from reports of patient injuries or deaths, or if Microsoft markets HV (or HV CC) in a way that gets the FDA's attention.
Regardless of the FDA's potential interest, the real issue is provider confidence. If Microsoft cannot demonstrate its ability to ensure the safe and effective use of data on the HV platform, then HV will never see much adoption. Such uncertainties could also dissuade vendors from incorporating HV if they feel that providers won't adopt.
There are many important contributions that HV can make to health care, and Microsoft is off to a good start. As a beta product there are still a few gaps to fill.
See previous Microsoft HealthVault posts here and here. Pictured right is the futuristic HealthVault logo.
