I received the following blog post from Stephen Olsen, Principal at Integra Systems. Steve has spent more than 20 years in the wireless industry in engineering, sales and business development. Steve’s wireless experience extends beyond health care to include public safety, cellular and 802.11.

In the past I’ve extended an invitation to a few select industry experts and thought leaders to post their writing. Steve is the first to take me up on my offer. Enjoy:

Over the last few years, MobileAccess and InnerWireless have generated considerable interest in broadband Distributed Antenna Systems (DAS) for the healthcare market. These systems can support a wide range of applications (WiFi, cell phones, mobile radios, pagers, WMTS) and frequency ranges (400/800 MHz up to 6 GHz).

The appeal to providers is the idea that a broadband DAS will remove all wireless headaches: no more cell phone complaints, WiFi will work better, no more dead spots for mobile radios, no more tricky RF interference problems, etc. Disappointment ensues when the DAS does not live up to its promise. (more…)

I spoke with founder and managing director of Spyglass Consulting,
Gregg Malkary yesterday about two of his most recent studies. The latest is
Point of Care Computing for Nursing (press
release - pdf), and released this October, the same topic targeting physicians (press
release - pdf). Gregg did his first study on mobile computing
in 2003, with follow on studies targeting nurses and physicians in 2004
and 2005. Two years down the road, it was time to take another look -
with some surprising results. The bottom line: significant progress in many areas, but overall there’s still a long way to go.

This latest study provides a nationwide perspective that reveals both product
shortcomings and pitfalls for deploying technologies. In further support of the adage, “you don’t know what you
don’t know,” some of the findings are counter intuitive. According to
Gregg, a lot of the findings are actually misconceptions. Impressions created by trade publications and vendor sales and marketing creates most of these
misconceptions - held by providers and vendors who have drunk their own (or others) Kool-Aide. Let’s start with
networks.

The study found that 64% of nurses in more than
half of the hospitals
believe their wireless network is not reliable enough to support point
of care computing solutions. That’s a frightening majority of the hospitals with poorly
designed, installed and/or managed wireless LANs. This contrasts with
the perception that wireless LANs are pervasively deployed, with great
coverage and solid performance. The study describes a
hospital in the Chicago area where nurses have taped X’s on the floor
were they can get a good network connection. With the
exception of the leading edge hospitals - the magnet or “most
wired” hospitals - wireless network deployments in patient care areas
have a long way to go.

Another misconception includes
computers on wheels (COWs) that are intended to be rolled up to the bedside for meds
administration and paperless charting. Barcoded patient
wristbands are read by the scanner mounted on the COW. The
survey found that the majority of COWs remain in the hallway and
are rarely (if ever) pushed to the bedside. And those barcodes are
frequently hard to scan (especially depending on the selection of
barcode, printers and wristband material). Hospitals were found to make extra
copies of wristband barcodes (or to cut them off patient wrists) and scanned at the nursing
station - apparently where it’s more convenient to scan the darn things
several times each. Perhaps if the cable on the barcode scanner were
long enough to reach the patient from the hallway…

One of the conclusions from the report is that many point of care devices are not well integrated
with applications and workflow. Many applications are not tuned for
clinicians and are hard to use. There are few examples where point of care device and application vendors get together to, you know, make their stuff work well together.

Most point of care devices (with the exception of Motion’s C5, the Emano Tec, and a very few others) are really intended for corporate applications, your stock broker or the UPS gal. These devices lack key features for clinical environments. And it seems that neither device or software vendors want to optimize applications for specific devices.

Security was another common complaint. The
way many IT departments have implemented security it takes 1 to 3
minutes to log in. And of course every time the caregiver has to leave
the keyboard - and they’re constantly interrupted - they have to log
back in. Many caregivers end up making notes on paper and then typing them into the EMR later in the shift when they have more time.

The integration of technologies, training, and user acceptance were found to be key to successful deployments. This is no secret, but the frequency at which these things are poorly executed may surprise you. Sites with active nursing informatics departments had the best implementations. The farther down the scale in nursing involvement, the worse the implementation. Conclusion: IT (and many vendors) just don’t understand clinical workflows.

From the Physician study, it seems vendors are still in love with the physician market - not that there’s been a lot of adoption to encourage such interest. The inclination to “follow the money” does not fit this market segment. While physicians account for almost all the revenue generated in a hospital, the vast majority of these docs do not work for the hospitals. In fact, in most community hospitals there is this an unhealthy co-dependent relationship between physicians and hospital administration that works against consistent IT usage.

Few hospitals have any reason to buy technology for physicians, nor to expect physicians to actually use what the hospital may buy for them. These studies show a hopeful trend. Hospitals are increasingly enforcing IT usage among attending and consulting physicians. Some hospitals are even suspending physician privileges for non compliance. Older docs are getting more comfortable with technology, through cell phones, the Internet, and email. The big are of contention uncovered by the study is private practice, and whether the physician wants to change or invest in technology like a practice EMR.

Surprisingly, 75% of physicians use smart phones. Usage though is limited to communications, personal productivity, and the occasional reference tool (if no other reference is available). There’s lots of vendor hype around smart phones and similar devices. For most uses the screens are too small, and vendors aren’t optimizing their user interface for these kinds of devices.

Here’s an except of data from the studies published by iHealthBeat:

Forty percent of nurses surveyed in September said health care IT
vendors were delivering high-quality solutions targeting nursing
workflow, up from 28% in June 2004, according to a survey by Spyglass
Consulting Group.The September survey also found that 64% of
nurses surveyed said they were concerned that their facilities lacked
the appropriate infrastructure to support point-of-care technology,
including reliable networks, interoperability and security
requirements.

About one-third of nurses surveyed in September
said they were ready to adopt computing applications at point of care.
This represents a 325% increase from June 2004, when just 8% of nurse
surveyed said they were ready. However, just 34% of nurses said their
organizations are investing in point-of-care computing technology, down
from 35% who said the same in June 2004.

The need to improve patient safety and reduce the risk of medical errors drive investments in point of care automation. The market has made progress, but little or nothing has been done to improve clinician workflow. Effective solutions must provide
timely access to the right information to support better and more timely
decisions at the point of care - that means good workflow.

Current deployments of meds administration and nursing documentation apps show increased utilization, but also that they are not being used as intended. The hardware to support these apps are both
fixed location devices (nursing stations, COWs) and mobile devices.

Based on findings from both studies, it is clear that there is no one killer device. The best device depends on the environment, personal preference, tasks to be performed, urgency of the situation, and how well the complexity of the application is matched with the device - you’re not going to do patient charting on a Blackberry.

You can read about some other Spyglass studies here and here. Pictured right is the Emano Tech tablet computer - not perfect, but getting close.

I’m frequently amused by the constant flow of stories on regional health information organizations, or RHIOs. The emphasis on developing the right “business model” - a euphemism for finding the rubes who will provide the hundreds of thousands or millions of dollars to fund a typically gold-plated RHIO - is perhaps the most frequent topic of discussion.

Health Affairs has just published The State of Regional Health Information Organizations: Current Activities and Financing (abstract). You can also download your own PDF of the paper. This survey of RHIOs is not pretty.

Most all RHIOs are focused on clinical data - test results, inpatient history, medication history - exchanged between hospitals and physicians. Sure a few patients may benefit from better care, but the real winner is the payor who is frequently absent from participating in the RHIO. The benefit is so indirect (relative to the hospitals and providers in the RHIO) and so diffused (for patients and payors) that after almost 15 years health care has yet to provide a steady stream of cash to fund RHIOs. (The Health Affairs paper has some good data on RHIOs, including the types of clinical data being exchaned.)

Here’s a better idea. Health care trading parties in a local market (and all health care is local) go through an insane amount of common transactions on a daily basis. And these transactions are done via fax and phone calls. If you’ve walked through the back office in a practice, hospital or payor, you’ll see fax machines (sometimes several of them) with stacks of received faxes. By midday, these faxes are not measured in pages, but in how many inches the stacks are at each fax machine. This is so bad that it is not uncommon for a health care trading partner to ask for something to be re-faxed just so it’s at the top of the pile and can be found.

These transactions are for relatively simple things like eligibility look ups (increasingly important with high deductibles), referral requests, benefit details, and claims summaries. Automating these transactions will save everyone money (and endless frustration), especially those directly using the system: physicians, hospitals and payors.

The best example of this that I know is OneHealthPort in Seattle, Washington. Rick Rubin, CEO, and Sue Merk, VP of Product Management & Bus Dev, came to OneHealthPort from Pointshare. During the Internet bubble, RHIOs (and Pointshare) were called “e-health connectivity” solutions, and before that they were CHINs (community health information networks). OneHealthPort is a non-profit consortium founded by a group of providers and payors in the Pacific Northwest, and delivers real value to the participating trading partners at a reasonable cost.

The other point that seems to escape RHIO proponents is cost. While interface engine and other HIT vendors see dollar signs in their eyes at the mention of the acronym RHIO, it seems pretty clear physicians and hospitals aren’t interested in paying conventional interface engine prices. If participants thought they could get into data interoperability with local health care trading partners at a reasonable price - say $10k per hospital and $1k for physician offices - I think there’d be a lot more interest.

Open source software is a potential resource for reasonably priced solutions for RHIOs. The Mirth Project is an example of what’s out there. Like other open source projects, Mirth software can be downloaded for free. But what really sets Mirth apart is the availability of the software purchased in an appliance - this provides a “ready to go” product, with vendor support, for those who want a product rather than a science project.

Another big value in using an open source based appliance is that many users put their interface configuration files (what Mirth calls “connectors” and “transformers”) into the open source community, greatly reducing systems integration costs. Way cool.

You can even use Mirth to “talk” to (and parse) medical device serial interfaces. Pictured right is the enterprise version of the Mirth appliance.

One of my favorite Clinical Engineers called today, prompted by last week’s post on the Emergin acquisition by Philips. Like many that I’ve talked to, this person was surprised that Emergin was not snapped up sooner. A list of potential bidders were mentioned, but my lips were sealed. I will say this about potential suitors for Emergin - the lines are blurring between conventional categories of vendors, on both the health care IT and device sides.

Also discussed were two continuing problems with medical device connectivity, alarm notification and point of care automation (we’ll just call it “middleware” for this post). The first deals with hidden costs - on both the device side and infrastructure side. As you work through the details of plumbing everything together, you tend to uncover situations where to get feature X you have to upgrade your medical device system to version Y. If this happens more than a time or two, the cost of your upgrades quickly eclipses the cost of your middleware.

On the infrastructure side few enterprise networks, wired or wireless, were designed to support the life critical applications of medical devices. Providing surveillance and alarm notification are more than mission critical, and require proper management, monitoring and documentation. Historically, device vendors installed their own physically separate networks so these issues were not apparent to hospital IT departments (and IT departments didn’t mess up device vendor’s networks).

Medical devices are becoming enterprise applications, and no longer justify isolated networks. Hospitals looking to benefit from the features of a system like Emergin’s are looking at rejiggering and upgrading their network (and maybe a lot more). So after you’ve upgraded your medical device systems and network, your total middleware costs have perhaps tripled from original estimates. Ouch.

Medical device vendors continue to push device integration issues off on hospitals. Sure they’ll install a server and manage it (apply upgrades, diagnose problems and get it running again when needed), but they won’t take any responsibility for the actual operation of device connectivity. What clinical engineers need is a software app that actually monitors medical device connectivity and interoperability - sort of like an HP OpenView for medical devices.

As things stand, the biomeds responsible for medical device integration can’t even tell if a disconnected serial cable is the cause of an interruption in data from a medical device. This is way outside the core competencies of medical device vendors. But there are solutions to this kind of problem, Nuvon for one. Presently hospitals are left to their own devices to solve this problem, unless they know to insist that device vendors fill this gap.

Most alarm notification, point of care automation and medical device connectivity solutions continue to be difficult to buy solutions, mainly because everything out there is a partial solution, with gaps and overlap everywhere. In marketing-speak, this is still an early adopter market. The early majority of the market is sitting on the sidelines until someone can field a whole product solution.

Pictured right is Smiths Medical’s Cadd System Pro meds administration software.

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.

For those of us interested in new business models and open source software, Modern Healthcare has a nice overview story the evolving relationship between Medsphere and the open source movement.

You can read a history of the company that Steve Shreeve, posted here
after the Medsphere lawsuit against him and his brother
was filed. Brother Scott Shreeve said after the settlement,

The Schreeves' position aside, there is no litmus test for open source software vendors. All such enterprises derive most of their revenue from services. Some offer software that is fully open source, and some offer software that is mostly open source while withholding some “secret sauce” as proprietary.

When I met with Ken Kizer (former Medsphere CEO and now Chair) at HIMSS 2007, we spoke about Medsphere's tiff with the Schreeves. He noted Medsphere's commitment to open source and the company strategy to retain product differentiation through keeping some software proprietary.

Balancing open source and proprietary software is not easy. A product must be open source enough to attract a community of developers who will contribute to the code base. Your resulting solution, including services, must be sufficiently commoditized (i.e., priced lower) than conventional solutions, otherwise the market will stick with conventional vendors.

The barriers to entry for the software business are low. The biggest barrier to health care IT is the investment required to develop big applications like EMRs and other key hospital information systems. If an application is purely open source, that primary barrier falls away. A fully open source solution also presents product differentiation challenges to a vendor. As an open source vendor, you want reasonable competitive barriers to entry and sufficient differentiation to provide a basis upon which to compete with other's in the open source community.

The question frequently comes down to how much is enough, and when do you go too far?

Is the creation of a new development platform on Java an irresistible incentive to attract open source contributors to the VistA code base, or an important product differentiator for Medsphere? Of course, there is no one right way to draw that line. What matters is the result, commercial success or insufficient adoption.

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.

Goldman Sachs analyst Randall Stanicky, “pointed out that no rival has health care IT offerings as comprehensive as McKesson's.”

Two thoughts come to mind. First, don't think that Cardinal Health, AmerisourceBergen and other competitors aren't leveraging software (and other things) to create their own unique value proposition. I don't see HIT as some inherently superior differentiator relative to all the other market segments and differentiators available to vendors.

The second thought is that McKesson's strength could also be its weakness. Hospitals love single vendor solutions. At the very least, they get “one throat to choke” when it comes to product and service issues. In the best case, you have a broad well integrated solution that provides one solution that takes the place of multiple vendor's systems.

In reality, there are very few broad well integrated solutions - and it seems the broader you get, the less well integrated the overall solution. Consequently, the best case promise of single vendor solutions is rarely realized. And many hospitals forgo operational or clinical performance as a consequence of the conscious decision to remain faithful to one strategic vendor.

The breadth of the McKesson portfolio makes me nervous. If I was a CIO, I'd want to know how much is being budgeted to actually integrate those recent acquisitions to create a truly superior solution. Few things in life are black and white; so too with single vendor versus best of breed solutions. An enterprise architecture made up of a combination of a few key vendors rounded out by best of breed solutions should provide greater performance and value than either extreme.

Pictured right is a photo from McKesson's 2006 national sales meeting.

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.

Hospital IT shops can be very keen on single vendor solutions - sometimes to the point of accepting significant shortcomings in parts of the vendors comprehensive offering. This tendency applies to networking in spades. Certainly you need central management, but you assume the AP and controller vendor has all the answers at your own risk - as Duke learned.

Certain vendors are taking this to extremes, offering hospitals WLAN site surveys and recommending the replacement of any technologies that don't sport their logo. Hospitals have received “advice” to replace $300,000 wireless patient monitoring systems because they weren't validated for that vendor's APs. The justification for these recommendations is that I just bought a new 30' sailboat third party systems can't be integrated into our enterprise solution. (If a vendor offers to do a free site survey of your facility, by all means take them up on it - just be sure to have someone else review the findings and offer a less biased assessment.) “And the story sounds so great, “Implement our solution and it will fix itself when it breaks and protect itself when security policies are breached.” Who wouldn't want that?“

In addition, as much as big market leaders would like to believe that single vendor
solutions are the new “best of breed,” we live in a multi vendor world.

Unlike commercial office space, or an open warehouse, the WLAN environment can be extremely challenging. Putting all your eggs in one network vendor is fine when all you're doing is supporting portable users moving from room to room charting or administering drugs. But when you start adding things like wireless VoIP, indoor positioning or wireless medical devices - with truly mobile users crossing subnets - look out.

Be sure to read Bruce's post, he's got some great recommendations.

UPDATE: Here are some previous posts on WLAN issues: Cisco Stumbles in Health Care, and Cisco Wireless LAN Technical Issues - Update.