Distributed Antenna Systems – No Replacement for Wireless Strategy

Posted by Tim Gee on Feb 5, 2008 in Healthcare IT | 9 comments

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.

New Studies Dispel Misconceptions at Point of Care

Posted by Tim Gee on Dec 21, 2007 in Healthcare IT | 1 comment

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.

RHIOs Have Got It Wrong, Health Affairs Study Shows

Posted by Tim Gee on Dec 14, 2007 in Healthcare IT | 0 comments

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.

The New Enterprise Application – Medical Devices

Posted by Tim Gee on Dec 10, 2007 in Healthcare IT | 0 comments

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 Acquires Emergin

Posted by Tim Gee on Dec 7, 2007 in Company Profiles, Healthcare IT, Real Time Location Systems | 0 comments

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.

Medsphere Settles with Cofounders

Posted by Tim Gee on Oct 25, 2007 in Company Profiles, Healthcare IT | 0 comments

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.