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.

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 announced this week that they have acquired private health care IT vendor Emergin for an undisclosed sum. From the Philips press release:

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:

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.

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.

The ventilator market is an interesting one - there are many more vendors than in most other product categories, and greater product differentiation between vendors. This is also a product category where hospitals have, for the most part, been unsuccessful in standardizing on a single vendor.

I came across an interesting ventilator vendor the other day, eVent Medical. Their adult and neonatal ventilators are pictured right. Key features include:

• Invasive and noninvasive ventilation
• 5 hour battery life
• Emergency backup compressor
• Integral nebulizer
• Heliox gas support

What intrigued me about their product is the optional web server. The product has both serial and Ethernet network connectivity - obviously, a network connection is require to serve web pages. Remote surveillance has become important as ventilated patients are increasingly placed outside of critical care areas where nurse to patient ratios are lower and the patients covered by a respiratory therapist could be sprinkled widely across a hospital.

This feature suggests certain product architectures that could perhaps support some truly innovative and compelling patient safety and workflow automation features. I hope to learn more soon.

The Kaiser Family Foundation reports that the latest HealthGrades Hospital Quality in America study shows that Medicare patients in the “highest-ranked U.S.
hospitals are 71% less likely to die than those who receive care in the
lowest-ranked facilities.”

The study is available on the HealthGrades home page under “research” - download your copy now.

The HealthVault (HV) beta was launched October 4, 2007. Between the confusion surrounding the launch and work, I've tried to gather some thoughts and get some questions answered.

The launch was a classic Microsoft launch: big, dramatic, expensive, and well executed, right down to the goody bags (you had to be there to get one, so I missed out). Typical with such events, naysayers were out in force, and there was a bit of confusion. You can also find some good information on the big picture of HV from Vince Kuraitis and Enoch Choi.

Perhaps the most confusion around HV is whether or not it is a personal health record (PHR). Many of the “news stories” that recycled the HV press release referred to HV as a PHR. A few, Vince and Enoch among them, noted that HV is in fact not a PHR. From what I and others can see, there is very little in the way of a user interface that would allow patients to maintain and manage a PHR.

According to one Microsoft executive I talked with, HV is a “platform” that's intended to be used by other applications, and is not a PHR. He reported that Microsoft's taken a more consumer focused approach, surrounding them with their information so they can share their health data with whom they wish. So, the absence of a robust PHR user interface is apparently a conscience
decision on Microsoft's part. Nor would it be to awfully difficult to
provide one should they move in that direction.

The published API, data interoperability via numerous standards, data storage, security, authentication, and the patient's ability to control their data creates a veritable Swiss Army knife for health data. Microsoft has tried to create a new kind of platform that's ideal for health information. They certainly have some ideas about how it can be used (and currently monetized - by ad revenue), but my contact acknowledged that they expect partners and consumers to take the platform in unforeseen directions. As a beta product, there are many unknowns beyond the mid term horizon.

Device Connectivity
Microsoft sees devices for health and fitness and chronic disease management as a big piece of HV. Medical devices are integrated into HV via the Connection Center (CC). The HV CC includes a device driver (specified by Microsoft and developed by the device vendor) that integrates a remote monitoring device into a Windows PC, and the CC application that runs on the PC and integrates with the HV web site. Microsoft has an SDK for creating a serial device driver for connecting these devices to Windows PCs, along with the HV CC sync program that allows consumers to capture, review and share data via HV. There do not seem to be any data editing capabilities in HV CC - more on this in an upcoming post.

My contact used the digital camera analogy when describing what this might mean for remote monitoring devices. In the early days, digital cameras came with their own proprietary software that allowed you to connect your camera to a computer and download pictures. As the technology matured, cameras adopted the USB standard and now plug and play with PCs.

This ubiquitous connectivity sounds great, but Microsoft is not anything like the USB Implementers Forum. While their device to PC SDK is open, the software on the PC is not. In fact, one wonders how HV will play out against another medical device group, the Continua Health Alliance.

Remote monitoring systems have 4 components: the medical device, a gateway device for aggregating data from multiple devices and moving that data over a network to an application, the application that manages the patient data (which usually runs on a server on the Internet), and some sort of integration with EMR/billing system(s). Continua is working to provide multi vendor plug and play interoperability between each of these components. Microsoft is not a member of Continua and is providing an open, but proprietary means to link devices with server applications - turning the Windows PC into a virtual gateway.

The HV CC turns your Windows PC into a remote monitoring gateway. The application can aggregate data from multiple devices and push that data into your HV account. To then get the data into the remote monitoring application it is transferred (automatically?) from HV to a compatible application.

Most remote monitoring gateway devices pull data from remote monitoring devices and push it directly into the target application. In fact the data may not be “ready” for third party applications until it is processed by the target application - more on this issue in an upcoming post. Certainly Internet-based remote monitoring server applications can leverage HV to provide interoperable data between other applications like physician EMRs.

Will vendors implement both Continua and HV connectivity? The fact that Continua validated interoperable products won't be available until the end of 2008 is an issue than you might think. Any vendor starting development now will take at least that long to finish their product. So they must make the decision whether to base their new product on Continua, HV, or both. (Hint: this is not a “o brainer” question.)

Closing Thoughts
Regardless of those that claim Microsoft “won round one” against Google, there is no first mover advantage in any of this. In fact, follow on solutions will likely benefit greatly from Microsoft's very public experience. Other big vendors or efforts mentioned in the press include Google, Cisco, and Dossia (which includes Intel, Wal-Mart and other big employers). I talked about non health care companies entering the health care market before. This is not an easy transition; it will take longer and cost a whole lot more that most anticipate.

Check back throughout the week; I'll have some follow on posts on adoption, network effect and other topics.

Pictured right is Bill Gates, from a PhotoShop contest on Gizmodo, that tickled my fancy.

These days phone companies like AT&T are more like network services providers than old time POTS (plain old telephone service) monopolies. Most, if not all of their land-line voice traffic runs over IP networks and the wireless unit is moving to full IP networking for wireless voice when they move to LTE in a few years.

That said, the whole “public utility” thing is becoming more a liability than the license to print money that it once was. In response to this transition, AT&T has been beefing up their networking and IT hosting services. Now they’ve taken the plunge and announced an RFID managed service designed for hospitals. From this RFID Journal story we learn that AT&T will design, install and manage your WiFi network. For an extra fee, they’ll throw in some AeroScout RFID tags and provide Asset Visibility. It is not clear whether they’re using the Cisco or AeroScout positioning engine.

I can certainly see hospitals using AT&T’s wide area network services, and maybe even NOC (network operations center) services. As a relative newbie to hospital wireless network, I’m skeptical. Ditto for any near term success selling RFID. If you’ve had any experience with AT&T networking services, let me know.

[Hat tip: StatCom newsletter]

I found a blog reader's email in my inbox this morning. It seems not everyone at his hospital is keen on investing in medical device connectivity. He wrote about a near term need for connectivity to a planned EMR. Sadly, medical device connectivity is sort of the Rodney Dangerfield of EMR deployments, frequently an afterthought or put off for some “future phase” mainly due to complexity and cost. What follows is my reply.

Device connectivity impacts EMR adoption in a number of ways. (In no particular order.)

• User adoption - a jaded observer could view many HIT projects as an exercise in getting one set of users to either change the way they do things, or to take extra steps, for a benefit of other users. Manually entering medical device data into an EMR is widely perceived as “extra work” or “double entry” by caregivers on the floor. This occurs when physiological parameters from devices are manually recorded and then later typed into the record. Automated acquisition of medical device data is perceived as a benefit of EMR adoption by most caregivers, because it's - you know - actually automating an otherwise manual task. Since a big part of the success of an EMR deployment rests with caregivers, medical device connectivity is a big carrot that can engender EMR adoption; of course the opposite (the negative impact of manual entry of device data) is also true.
• Timeliness of data - a big benefit of EMRs is the ability to get data into the electronic chart as soon as it is available by integrating various diagnostic (e.g., radiology, lab) and medication systems (e.g., an electronic MAR and integration with pharmacy IT). Data from medical devices is frequently overlooked as a source of data with a timeliness requirement. The manual entry of data from medical devices is frequently delayed. Caregivers are frequently interrupted in their tasks, and the act of entering the data into the electronic record can be delayed by minutes or hours. Which brings me to the next issue:
• Missing data - as caregivers write down medical device data (on scrap paper, their scrub suit or hand) they sometimes get distracted and lose that scrap paper or forget. Consequently, that data never makes it into the electronic record. Over 50% of point of care diagnostic tests are never recorded in the patient's chart, let alone an EMR. There is a lower rate of missing data for vital signs data.
• Poor data quality - the inherent weaknesses of paper charts include illegibility of entries, entries that are incomplete or not made, transposed data, or accurate data entered for the wrong patient. Without automating the acquisition of data, an EMR really only improves illegibility. Thus manually recorded device data that is keyed into the EMR can result in transposed data or data entered into the wrong patient's record. Medical device connectivity eliminates these problems, just like an interface to your lab system.

All of the above issues become more important as patient acuity increases because the higher the acuity, the more device data that's generated. Hospital patient acuity is increasing, as reflected in the hospital trend to increasingly monitoring patients outside of conventional monitored units (ICU, telemetry, step down, etc.).

I can think of two additional drivers for medical device connectivity:

1. The Joint Commission's new National Patient Safety Goal for the identification and response to patients with a deteriorating clinical condition (goal 16) necessitates that hospitals tighten up the completeness, timeliness and accuracy of vital signs data (and in some cases, increasing the frequency). Research has shown that vital signs capture is pretty poor in many hospitals (more on this later). Medical device connectivity will help maximize the quality and timeliness of your vital signs data.
2. Starting next year, CMS will not reimburse for certain adverse events. These “hospital acquired conditions” are all preventable and many focus on infections. While care practices like ventilator toilet will minimize these infections, high quality medical device data (along with lab data) will allow your staff to identify infections most quickly. Since CMS will no longer reimburse you for the costs to care for these infections, the sooner they are identified, the sooner they can be treated - minimizing the financial loss to the hospital. (More here and here.)

For data and references to put around the above, there are a number of sources (besides the links embedded above). Vital signs vendors with device connectivity features like Welch Allyn (Connex) or Sensitron are the best source for data on the incidence of missing, delayed or inaccurate manual data. I would talk to both vendors to increase your pool of data.

Another source of information (one that I forgot to mention to my reader) includes studies on pervasive short falls in vital signs documentation. This was one of the main topics at the 4th annual Rapid Response Systems: Teams Systems for Safety conference. You can access the conference presentations here. This presentation by Gary B. Smith MD provides specific data on the completeness and accuracy of typical vital signs records.

But medical device connectivity justification is really the easy part. The lack of standards and vendor's obsessive pursuit of proprietary end-to-end solutions can make connectivity very expensive at best, and confusing and hard to use at worst. It's easy to get painted into a corner by proprietary systems, or forced to adopt a mosaic of systems from vendors who only provide part of the solution. And due to the cost, not to mention the pervasive use of medical devices, implementing connectivity must be done in phases over time.

A good connectivity plan is based on a thorough needs assessment that encompasses current practice and future plans for HIT, telecommunications, medical device purchase/replacement, and care delivery processes. Initiatives like continuous quality improvement, improving patient flow, and extending patient monitoring into new clinical areas all impact connectivity requirements. Then all of this must be distilled into a set of requirements used to create a phased connectivity plan.

The next challenge is to address vendor variability. Besides details about what and how vendors do what they do, you have to try to take into account their roadmaps, or future product plans - otherwise you might end up with a plan to use products that you can't buy from anyone.

The end goal of all this is a connectivity roadmap for your hospital that takes into account planned funding, anticipated changes in the needs assessment areas mentioned above, and vendor variables all laid out in a timeline. Now you're ready to put together a capital budget for phase one.

So, hopefully I've helped with articulating the need and justification for medical device connectivity. And just like I told me reader, if you've got questions, let me know.

If you gain the momentum to move forward with connectivity in your hospital, and you'd like some help let me know. I can provide targeted feedback and advice, come in and do the whole thing (assessment, connectivity roadmap, system design, and vendor selection) turn-key, or anything in between.

Pictured right is a serial cable dongle typically used to connect legacy medical devices that don't have network connections.

UPDATE: Health Data Management reports that Applied Digital subsidiaries Verichip and Digital Angel are working with sensor company Receptors LLC to create an implantable glucose sensor that transmits data using a passive RFID scheme.

FierceHealthIT notes a new CDC study on ED overcrowding - it's getting worse.

The 32 page report is fuel for the American College of Emergency Physicians lobbying efforts to get congress to, “create a commission to study the ED overcrowding problem. Under the
terms of the ACEP-backed bill, hospitals would have to report to HHS on
how many patients are boarded in the ED, and how long they're boarded.” [Patient “boarding” is the practice of placing patients in hallways, usually in the ED, where they wait for an inpatient room to become available. Patients commonly wait for hours, and sometimes more than a day, on a stretcher parked in a hallway.]

Ambulance diversion data is tracked by hospitals, regional and state hospital associations, and sometimes the state. This data is not available to the public or most state health agencies. Given how bad ED diversion is, I'm not surprised hospitals want to keep this data private - especially the worst offenders. Data on patient boarding is tracked less often by hospitals and to my knowledge, is not tracked across hospitals by associations.

Public reporting of both diversions and boarding would provide an important customer service metric and patient safety indicator and should be available to prospective patients. It is too bad that such a requirement must be forced on the industry by government.

You can download your own copy of the CDC report here (pdf).