Healthcare Unbound 2007 Kicks Off
Jay Srini, VP, Emerging Technologies, UPMC and Vince Kuraitis, Principal, Better Health Technologies, opened the conference.
Srini provided an update on the demographic tsunami represented by the aging population. Statistics show health care prevention has not worked. Over the last 10 years there has been a steady increase in obesity and diabetes. This is not because we're unaware or have not tried to do better. Lifestyle changes are the biggest impact on health. In fact, the extra weight people are carrying has cost the airlines extra in transporting passengers. Diet is the most critical factor that impacts health. Smoking and drinking also came in for some finger wagging.
Jay asked, “When we know there are preventable costs, can we declare we can't afford to insure everyone in the country?” The cost for obesity related care rose from 2% in 87 to 11.6% in 2002.
Every day, almost 11,000 boomers turn 50. Geez, that's depressing.
The (same old) bottom line is that health care delivery must change in the future as patient demand increases and resources (physicians, nurses, money) shrink or remain limited.
The solutions to our problems is in the boundaries, asserted Jay.
When he came up for his co-chair keynote, Vince Kuraitis asked, “How close are we to a tipping point?”
His theme: an individualists or group effort approach to health care?
First off, Vince explored the network effect and HU markets. Showing the classic hockey stick market adoption model, Vince referred to the fax machine as an example of the network effect. One fax machine is worthless, two has some value. But when you reach a critical mass (usually about 20%) the value of owning an individual fax machine increases substantially.
Four years ago Forrester published their $34 billion market forecast for Healthcare Unbound, and predicted the market entering a rapid growth phase in 2009 (just 2 short years away). The critical assumption was that payors would adopt HU, after some experimentation and proving out the value of HU. The market segments in the Forrester model are assisted daily living, or elder care; chronic disease management; and post acute care (including hospital at home).
How close are we to a tipping point? Right now we're just a sexy combination of very interesting companies that get nice stories on the evening news and start ups.
No sightings here – overall, HU has generated disappointing adoption. EHRs, telemedicine and some niche applications are getting some traction. Reimbursement remains absent. There is no network effect in sight here.
Where are we likely to see hyper growth or tipping points? Remote patient monitoring technologies could reach a tipping point in 2008. The work being done by Continua is addressing one of the biggest barriers to growth – the lack of interoperability between devices and systems. [But according to the report that David Whitlinger gave later in the day, next year is probably a couple years too soon.] Vince also described the realization that plug and play interoperability is required to provide the affordability and ease of use required for broad adoption.
The participants in remote patient monitoring come from two perspectives, conventional medical device vendors and consumer electronics companies. Medical device vendors think high prices (say $8,000 for a remote patient monitor) and a proprietary end to end solution are a good business strategy. Consumer electronics companies are more interested in selling hundreds of thousands of less expensive devices – and not having to build complete end to end solutions – than in selling a few tens of thousands of $8,000 monitors. They want interoperability to drive drive rapid market growth and adoption.
Other challenges remain with IT/integration, reimbursement, developing viable business models, and licensure – so physicians can operate across state lines.
Next Vince launched into his assessment of the disease management (DM) market. One year ago, it looked like Medicare DM was approaching a tipping point. Today, it's back to square one based on initial results of their demonstration projects. Medicare Health Support (MHS) appeared to be the favorite son demo to expand DM into Medicare. Medicare is testing a fairly narrow section of DM, the frail elderly. The winners of the MHS were a few of the largest established DM companies.
There has been no evidence of positive short term financial results and virtually no evidence of success. So it's back to the drawing board for CMS and the industry. If we're going to test narrow concepts, there are many other narrow slices to be tested. This will delay hyper growth by several years.
The early results of the MHS indicate that we need much greater integration between DM service providers and those providing direct patient care. Another approach is a Medical Home model that includes a fee for providers to provide HU to patients in their home.
Vince has spent a fair amount of time trying to figure out what Google's doing – and it relates to personal health records. In fact, Vince asserted that personal health records could be a real sleeper in the HU market. There are two models for PHRs, a personal PHR that the patient completes and maintains themselves, and one that's tethered to an employer, health plan, or provider. The problem with a personal PHR is that the vast majority of patients are not motivated to actually complete and maintain a PHR. The problem with a tethered PHR is trust (of your employer or health plan), the quality of data (claims data is not clinical data), and interoperability (can you take your PHR with you?). The market here is very fragmented, and there are only about 2 to 2.5 million of patients with their own PHR.
The first generation of PHRs were thought of as an application, an on line repository of personal health information. The next generation is the PHR as platform rather than an application. This platform provides a repository of data combined with interoperability for other applications. The formulation of genetically specific drugs for a patient was one example of how data in a PHR (in this case genetic information) could be used by an outside application to create a result (documentation about the personalized drug) that goes back in the patient's PHR.
Google Health is the next generation of PHR. This is the result of Vince's detective work and reading of tea leaves (you can read more about Google on his blog, here and here; a related post on Medical Connectivity here). The current structure for your PHR is data that's scattered everywhere. Nor is that data in standardized formats suitable for a global information economy. Google Health's model is patient centered where consumers own their own personal health data – they have complete control, not physicians, payors or drug companies. Each patient will have their own personal health URL (e.g., http://health.google.com/timgee) Also needed are automated data mechanisms to gather and store PHI. They will go to drug stores, clinical labs, etc., and they'll aggregate this data for patients. [Later during cocktail hour, someone suggested a Google spider initiated by and authenticated to an individual that would have the permissions to automatically extract data from a myriad of sources - say prescription history from a PBM, or results from a regional reference lab.] They will use XML and the Continuity of Care Record (CCR) standard. They'll provide a user interface for patients, providers and payors to use. They'll also have to provide security and confidentiality. And ultimately, they'll create some value added service (hopefully something besides online Canadian drug stores or male enhancement ads).
If we had a platform like Google Health to plug into to support HU applications and products, this would hasten market development.
One of the biggest tipping points of all is in mobile health technology. Qualcomm and Partners are launching a private branded virtual wireless carrier to target wireless remote monitoring applications (more here and here). Health 2.0, or social internet applications and websites, are also likely to reach a tipping point in the near term. “Hospital at home” (HaH) is something that's been used a great deal in Europe and other countries. The key here is that current HU technology and applications begin to make HaH possible.
How do we know HaH is the biggest HU market of all? He offered the Willie Sutton theory of HaH – because that's were the money is. If projected 2014 annual hospital costs are estimated to be $1.14 trillion, and the projected HU market at 2015 is $34 billion, Vince suggested that we're underestimating the opportunity for HaH.
Our success in HU is tied at the hip to HIT interoperability and making PHI transportable. There needs to be integration with local care providers. He asked the question, “Are PHRs the best candidate for a common technology platform?” It's not whether, but when HU succeeds.
Vince encouraged attendees to support the Continuity of Care Record and to join Continua. The conventional medical device business model approach to the market should be abandoned (you know, those expensive proprietary end-to-end solutions) for one that leverages standards to provide interoperability and some level of commoditization to grow the market for everyone.
Pictured right is Vince Kuraitis, Mike Barrett and David Kibbe. Sorry I missed Jay Srini, I'll try to catch her tomorrow.
Be sure to check out other posts from this conference here.
Site Update
I arrived in San Francisco last night (July 15) for the Healthcare Unbound conference. The event's at the airport Marriott, which was a nice short shuttle bus ride away. We were dropped off at what appeared to be the rear entrance and were directed to an office in a trailer. Inside was the front desk (pictured right). There was only room for about 3 guests inside, the rest of us waited in line outside – it's San Francisco in July so it was only in the high 50s.
It turns out that the hotel's lobby was demolished a couple days before on July 14. Reportedly, they've been renovating the hotel for some time and the last area to go is the lobby. I can only imagine the surprise the organizers of the Healthcare Unbound conference experienced when they arrived!
In any event, it's all part of the adventure. Speaking of adventure, I spent most of last week recovering from a crashed hard drive and while trying to finish up a client project. What fun. Between back ups and disc recovery, I'm back up to speed. Anyway, I thought I'd explain the almost nonexistent posting last week – it's not like I planned to leave the post on Cisco up top for a full week.
UPDATE: My life has been cursed the last few weeks. I've gone almost 20 years without a hard drive failure – or computer failure of any kind (virus, physical damage, theft, etc.). I guess it's all catching up with me.
After restoring my files (at least most of them) on my laptop, I started writing posts to this blog. The posts were published via the RSS feed, but never went up on the actual web site. Then they disappeared from my blog software! While I restored my software (Userland Radio) properly, I learned after the fact that I needed to get a serial number from the vendor to restore full functionality. So, that's done and I hope all these technical issues are behind me.
Finally?
Okay, I think this blog is back. Since loosing my hard drive and restoring my system I had one last thing to do – get my content management software authenticated by the vendor. That took a while, and I got the code to enter into my system this morning.
Apparently all the posts that I've created since July ninth are lost – poof, into the bit bucket. Of course none of those posts appeared on the web site, but for some reason they did go out by RSS feed. Another reason to subscribe to the RSS feed.
If anyone has a copy of any of those lost posts, I would appreciate it if you would email them to me. Thanks.
Cisco Stumbles in Health Care
Cisco has aggressively marketed their “Medical Grade Network” that promotes the value of managing clinical data (especially from or between medical devices). Many have asked Cisco just what makes a network “medical grade.” When pressed, what was described to me was a mission critical network, which is fine for patient accounting, but inadequate for life critical data. From their web page (emphasis mine, links are Cisco’s):
The Cisco Medical-Grade Network is a scalable, end-to-end solution that simplifies operations and management and supports the necessary regulatory compliance.A Cisco Medical-Grade Network connects all stakeholders in the healthcare system to a single information and communications infrastructure. The network provides a resilient and reliable network infrastructure for Clinical Connection Suite, Connected Imaging, and Connected Electronic Health Records. A Medical-Grade Network Assessment can determine whether your network is medical grade.
Given that Cisco has no products with FDA approval, “regulatory compliance” must be that required for commercial products; nothing special here (even though it sounds special).
In the recent past their well intentioned marketing has included things like wireless VoIP phones as part of medical device alarm notification systems (complete with photos of ECG waveforms displayed on phones). Unfortunately, their good intentions ended with the marketing and their conventional mission critical solution was not demonstrated to assure safety and effectiveness in health care.
Cisco was warned that they were pushing the envelope, and indeed the FDA later informed Cisco that they were marketing a medical device. Cisco was told to cease and desist, or else. Well, that got their attention. Cisco has not been bragging on their Medical Grade Network lately, although at least some of their original claims are still on their web site (here and here); probably just an oversight.
Cisco has likely spent considerable time and money on health care since their run in with the FDA. But from the outside it appears to have all been spent on lawyering rather meeting the needs of health care. An example of lawyerly writing is found in the Cisco Unified Wireless IP Phone 7920 Administration Guide for Cisco Unified CallManager Release 4.2 and 5.0 (link), in the caution on page 4, which states:
This product is not intended for use with patient monitoring devices or other patient care devices. Do not use this product as the primary communications tool in health care environments, as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.
These two heavily laden sentences were obviously written by smart folks who have probably forgotten more about liability and the Food, Drug, and Cosmetic Act than I’ll ever know. Yet there is so much wrong with this cautionary statement. Let’s parse it bit by bit.
“This product is not intended for use…” Intended for use is code for FDA pre market approval, in which you must state the intended use of your medical device. Cisco is explicitly stating that the 7920 (and by inference, maybe the wireless LAN) is not a medical device.
“…with patient monitoring devices or other patient care devices.” Most extensions of a medical device, like remote surveillance or alarm notification, are by definition part of the medical device. This last bit of the first sentence clearly separates the 7920 from use with any medical device system, thus limiting Cisco’s liability and avoiding any nasty talk about injunctions or seizing adulterated product.
“Do not use this product as the primary communication tool in health care environments…” There is no distinction between “primary” or “secondary” anything in regards to medical device regulations. Communications here could mean voice or data, but probably refers to data. What’s left unsaid here, and could easily be implied, is that you could use the 7920 for secondary communications (if such a thing existed). The context here may be that other vendors (including Cisco partners) are selling alarm notification systems without pre market approval. The industry has created the term of art “secondary alarm notification” to provide a legal fig leaf for unregulated alarm notification systems (unfortunately, that’s most of them). (More on primary versus secondary alarm notification in a later post.)
“…as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.” This is beyond confusing, it is wrong. The FCC regulates the entire RF spectrum, including the ISM band used by the 7920; there must be some tortured logic here that is not apparent. To claim that 802.11a/b/g is unregulated is incredible. The ISM band is certainly more regulated than WMTS or MICS, two medical related bands. All wireless technologies, regardless of frequency, are susceptible to interference – yet many wireless medical devices are safe and effective, including those using the same frequencies (and similar if not identical technology) used by the 7920.
In this caution statement it is hard to separate the wireless LAN from the 7920. Would Cisco’s warning apply to another vendor’s handset on their network? Or does the warning apply to the network that supports the 7920, or any other handset?
Liability fears are a major factor in most non-health care companies lack of long term success in health care. You can’t really participate in a market unless you’re willing to accept and manage the inherent risks. If fact, medical device liability is very manageable. The role of attorneys (regulatory or otherwise) is to point out legal risk; it is management’s job to decide how much risk to assume and how to manage it. The irony is that getting pre market approval for alarm notification on the 7920 should not be that hard. Certainly Cisco has the money to do it themselves, or the clout to induce a partner to assume the regulatory burden. The obvious choice here is for Philips to put a 510(k) on an alarm notification solution using the Clinical Connection Suite (Emergin’s Integration Suite) and Cisco’s wireless LAN.
Medical device vendors are increasingly adopting 802.11a/b/g for wireless connectivity. Numerous patient monitoring systems and “smart” infusion pumps sport WiFi radios. Device vendors and third parties are adding external radio modules so various medical devices can run on enterprise wireless networks. Cisco knows all this (and is even working with many medical device vendors), yet claims, “This product is not intended for use with patient monitoring devices or other patient care devices.” So which is it? Is Cisco’s wireless LAN unsafe for supporting the core mission of patient care using medical devices, as their statement claims? Or are all the medical device vendors who are adopting WiFi correct? Creating cognitive dissonance in your target market is not a good marketing strategy.
According to discussions with Cisco folks, part of the problem here is Cisco’s insistence in forcing the health care market into the same vertical market framework Cisco remains focused on forcing health care into their common framework where Cisco combines third party products into complete solutions that Cisco markets as specific vertical market solutions. This is what Cisco has done with their Clinical Connection Suite and other health care solutions. The FDA’s insistence on a single vendor assuming regulatory responsibility for a medical device, and then only that vendor market their regulated product does not fit with Cisco’s marketing template for vertical markets.
Post-FDA run-in, Cisco’s position is that their wireless network should not be used for medical devices. Cisco has also indicated they would not support medical device applications on their network. Can you think of a wireless application that is more central to the delivery of hospital care – and Cisco doesn’t support it? Should a hospital install a vendor’s wireless network if they refuse to support medical devices? All of this seems to fly in the face of wireless devices that have FDA pre market approval like the infusion pumps from Cardinal and Hospira, or Draeger OneNet for patient monitoring and Welch Allyn’s wireless patient monitors and PDA-based surveillance and alarm notification. These companies have demonstrated for years that 802.11 is a safe and effective data transport for critical patient data – and there are studies to back up such cliams (pdf). Such a refusal by Cisco to support medical devices is short sighted.
Another reason that Cisco may be refusing to meet basic health care market requirements is more problematic. Implied in the 7920 caution are questions about Cisco’s wireless LAN. At a recent national conference, the CIO of a large provider organization – and Cisco shop – said that Cisco’s wireless LAN software could be divided into two categories. The software used to provide basic network features is rock solid and very reliable, however he noted that the software that provides the advanced features is very buggy and extremely unreliable. This would obviously be an issue for life critical applications.
The hospital wireless market has identified 4 key applications: wireless data applications like point of care charting and meds admin, wireless VoIP, indoor positioning for asset and staff/patient tracking, and wireless medical devices. Each of these applications has its own set of WLAN design criteria and the resulting network will only support the applications for which it was designed. In fairness to Cisco, many wireless LAN problems in hospitals are the result of poor planning by hospitals or poor execution by value added resellers.
Cisco appears to be having problems with LWAPP, especially dynamic channel allocation and dynamic power control. Some indications of the problems can be found in the Cisco support forum here. You can find a detailed explanation of dynamic channel allocation problems here and here. From the introduction (emphasis mine):
In its Unified Wireless Network architecture, Cisco has developed patent pending technology for dealing with interference detection and avoidance, dynamic channel assignment, dynamic power adjustment, coverage-hole detection and correction, rogue detection and client load balancing. This system is known as RRM or Radio Resource management. The stated goal of which is to avoid problems in the fixed ISM band of 802.11b/g where only 11 channels are available to U.S. WLANs. This system, though sound in theory, has problems when applied to large WLANs in urban areas or locales that have heavily deployed WLANs such as Metro WiFi, skyscrapers, hospitals, universities and businesses near residential neighborhoods.
As a consequence of this and other rumblings of problems with LWAPP, an increasing number of hospital CIOs are doing pilots where WiFi vendors demonstrate their ability to provide reliable connectivity – usually for the 4 key wireless applications noted above. This has resulted in sales for Meru and Aruba into Cisco sites.
This post is not meant as an indictment of Cisco – everyone stumbles once in while. But somehow Cisco, you’re losing your way in health care. Stated simply, medical device data (and the concomitant regulatory burden to ensure safety and effectiveness) is a core requirement of health care. Meet that requirement, or alternatively, there’s no dishonor in ceding those applications to other vendors. If there are other issues that limit your ability to support life critical applications, be up front about it. In most cases, customers will wait for things to shape up.
We’re an incestuous bunch in health care, and we talk, a lot. The first CIO who loses their job, or the first sentinel event (a nice way to say patient death) where Cisco appears to wash their hands of the situation (and I don’t mean you should accept liability, but work with the customer to determine root causes and ensure it doesn’t happen again) you can write off health care – at least the wireless market.
If you want to walk the walk in health care, lose the regulatory attorneys and create a team to get your health care business on track. And be prepared to accept that it will take more than marketing spin to really be a player in health care – lives are at stake.
If you’re a provider reading this, caveat emptor. Vendor standardization is an important tool in fulfilling the core mission of your institution – effective and safe patient care. Wireless medical devices are a fact of life in most hospitals already, and they will only get more life critical. If you can’t ensure patient safety, then vendor standardization is less than worthless, it is a liability.
Life critical means more than mission critical. Defining the right requirements and ensuring your WLAN meets those requirements entails work and expense – but it is still cheaper than the alternative of installing a separate life critical enterprise network for medical devices, or having to replace the one you bought from the wrong vendor.
Pictured right is the new Cisco 7921 VoIP handset that would make a great nurse-carried device for alarm notification – if only someone would do the regulatory work required.
UPDATE: Check out these following posts: Cisco Wireless LAN Technical Issues – Update, and More WLAN Problems.
Google Makes Splash in Health Care
Google announced the formation of a Health Advisory Council that includes an eclectic group of health care insiders. The result has been speculation on Google's plans ranging from an application for patients to store their medical information online to the acquisition of an EMR vendor.
The acquisition of an EMR vendor will render Google just another EMR vendor (admittedly with one with lots of money). What I wonder is how (or if) Google will go beyond their brand and Internet application platform to really differentiate and drive greater adoption of whatever vehicle the chose for the health care market.
A significant portion of the data that goes into an EMR (and that includes the whole alphabet soup of PHR and EHR) comes from medical devices. Device data is the most specific and exact data found in EMRs, and is the data that serves the bedrock for diagnosis and managing therapy. As a patient’s problem list or acuity increases (predominately due to chronic diseases) the amount of data generated by patient-attached medical devices increases exponentially. Manually entering medical device data into charting systems has the following problems:
- Data availability is delayed due to the lag between the reading and when the caregiver has a chance to enter it into the system (this lag is frequently measured in hours)
- Missing data results from readings that are taken, but never entered into the system
- Transposed data or typing errors – the analog to illegible entries in paper charts
- Selecting the wrong patient for correctly entered data – the analog to improper patient identification, a common patient safety problem
In hospitals the literature has reported the percent of data entered in error to range between the low teens and mid twenties. I’m not aware of studies looking at similar activities in physician practices or patient homes.
Medical device connectivity is a requirement with growing awareness. Last week Rob Kolodner gave the keynote at a conference on medical device connectivity (the Improving Patient Safety Through Medical Device Interoperability and High Confidence Software workshop in Boston). The FDA has signaled that they are looking at regulating medical device interfaces that write straight to an EMR’s database. And vendors continue to struggle with device connectivity – with vendors creating “open” interfaces that only work with their own medical device or EMR (think Welch Allyn or AllScripts). Retrospective connectivity via HL7 is easy to develop, but expensive to deploy (each installation must be configured); prospective “plug and play” connectivity is the easiest to deploy, but requires that competing vendors work together (something they are traditionally loath to do).
Google may well acquire an EMR vendor. Given their strengths they will probably stay as close to consumer as possible, launching a PHR and/or acquiring a practice based EMR (rather than a hospital EMR vendor). In any event, the patient populations who will benefit the most, and be Google’s greatest source of pressure to drive adoption, are those patients with chronic diseases. Care delivery for chronic disease is centered around medical device data – glucometers, non-invasive blood pressure monitors, weight scales, and more. Leaving patients to manually enter this data themselves will not work for most patients, and sending caregivers to the home to gather readings will be too expensive.
Google is uniquely positioned to provide plug and play connectivity for any site with an internet connection or even a mobile phone. Actually creating the connectivity is something they have no experience with, but they have plenty of resources and smart people – they can learn it the hard way, or use a connectologist to help. This is a potential differentiator and competitive barrier (because the industry’s not going to support more than one pervasive connectivity method) for whoever gets there first.
To be more than just “another EMR vendor,” Google will have to do something different. Medical device connectivity is the biggest unmet need on the patient side of the equation. (On the systems side, there is interoperability between EMRs and prescribing and between providers and payors – but there’s already a lot of work being done here.) Their ability to deploy web applications could be leveraged in important ways.
Pictured right is the Google holiday logo commemorating the 50th Anniversary of Understanding DNA – April 25, 2003.
[Hat tip: iHealthBeat]
