Besides patient safety, patient context also greatly impacts medical device workflow. (Medical device connectivity is workflow automation through the integration of medical devices and information systems.) How a vendor implements patient context can have a big impact on usability and customer acceptance.

Patient context requirements can vary, based on the type of medical device in question. What is not variable is the requirement to reliably establish and maintain context. Mobile applications (like smart pumps or patient monitoring) where the device may go in and out of network coverage while constantly in use present special challenges. This compares to a fixed or portable medical device, like a dialysis machine or diagnostic ultrasound, with an episodic use case during which neither the device or patient is moved. Another variable is whether the application is life-critical. Continuous patient monitoring and many alarms (e.g., smart pumps and ventilators) are life-critical applications with a higher threshold of requirements. This contrasts with connectivity for documentation like with point of care testing or spot vital signs capture. In all cases though, patient context must be safe and reliable. The above issues just help define how many hoops you have to jump through to be safe and reliable. (more…)

[…] Gregoire said she expects full public access to hospitals’ track
records to be done without extra cost to the state treasury. She said
she will introduce legislation giving consumers information about
“adverse events,” such as infections or patient deaths, at each
hospital.”With full disclosure, the health care system can
learn from its mistakes and prevent new ones,” Gregoire said in a
policy paper released by her office.

Such reporting could motivate hospitals to undertake difficult cultural changes and invest in products that will improve patient safety. The best run hospitals, with the appropriate technologies, could better compete with hospitals in their markets if prospective patients knew hospitals’ adverse event track records.

I’ve mentioned before (here, here and here for 3 recent examples) how transparency pressures will shine a bright light on adverse events through increased reporting. This won’t be an easy transition, but the industry will be better for it. I mean we’re here to save lives, right?

With the U.S. market in the midst of a hospital building boom, the environment at the point of care is changing. Variable acuity units (aka, universal beds or rooms), distributed nursing units, and other big changes are being adopted now. These changes will impact market requirements for both medical devices and health care IT.

You have been warned.

Is there a need to better track the use of medical devices? You bet. Besides tracking implantables for post market surveillance and recalls, tracking medical devices used at the point of care can reduce the risk of infections like methicillin-resistant Staphylococcus aureus (MSRA) through physical contact and cross contamination. There are no national hospital reporting requirements, and few state requirements for these infections. This story in the Baltimore Sun reports on a news study released by the CDC on MSRA infections:

“This is the first time that we’ve been able to measure the number of
infections,” said the study’s lead author, Dr. R. Monina Klevens, an
epidemiologist with the federal Centers for Disease Control and
Prevention. “We were surprised that the rates were so high. It’s a call
to action.”

Industry consultant Brad Sokol developed a Medical Device Pedigree for tracking the use of devices and related patient outcomes last year. You can get the low down on Sokol’s pedigree from this presentation (pdf) on the FDA web site.

His theory predicted 13,000 to 26,000 thousand deaths from infection caused by contaminated medical devices and instruments. In the new study, “Of those infected with MRSA, almost 1,600 died, about 18 percent of the total. Extrapolating those figures to the entire U.S.
population, researchers said some 94,000 people might be infected, with 19,0000 deaths.” It would seem that Sokol was right on target.

The paucity of quality and outcomes reporting by providers is slowly changing as hospital and physician data is published by CMS and other federal agencies, state governments, hospitals themselves, and others. But we have a long way to go.

Much of the debate about Unique Device Identification (what the industry refers to as “UID”) for medical devices is misdirected. There is too much talk about needing a unique identifier, as if the law did not already mandate one (see this, and here).

MDDI magazine ran a story that revealed the real UID agenda, From Information Silo to Bridge: The State of UDI. The real issue here is the need to track medical devices - especially implanted devices - to determine their performance. From the MDDI story:

When it comes to devices, comparisons with other products are inevitable. For example, the Advancing Patient Safety Coalition recently compared medical devices to peanut butter. Specifically, in a letter to congressional members dated June 18, 2007, the  coalition stated, “We can simply and quickly identify each and every jar of peanut butter that might have salmonella and remove them from store shelves in hours, but we cannot do that reliably today with potentially life-threatening defective medical devices.” Similarly,
during a 2006 CDRH public meeting, Larry Kessler said that the medical device industry is “probably a decade or more behind the grocery industry” in terms of product tracking.

By equating medical devices with peanut butter, the authors imply it is the device vendor who is responsible for this sorry state of affairs. In fact, the guilty party is the equivalent of the grocery industry, health care providers.

There is no doubt that better tracking of medical devices would improve recalls, provide better post-market surveillance to better reveal safety issues, and reduce avoidable infections. But we don’t need some new fangled UID standard affixed to medical devices to do it. Here’s what’s really missing:

1. A mandate that providers track, record, and report the use of all medical devices (and associated clinical outcomes data) without exception,
2. A repository where data is aggregated across providers, devices and device vendors, and
3. Someone to analyze this data and report it to the public, providers, patients, and vendors for appropriate responses and follow up actions.

This makes forcing device vendors to replace the currently mandated unique identification (you’ve probably heard of them, serial numbers) with a “new” and “improved” UID seem like the side show that it really is. Let’s assume that AdvaMed doesn’t muster the political leverage to forestall the UID, and in a few years some standards body promulgates a new UID standard. Okay, the easy part is done, now for the hard stuff.

• Who’s going to mandate that providers do all this tracking and reporting?
• Who pays for all the fancy new IT and labor required to track and report this data?
• What entity(s) will assume responsibility for maintaining this repository of medical device usage - and outcomes?
• Who will enforce the implementation and conformance of this reporting by providers - and what penalties will be incurred for non-compliance?
• Who’s going to manage the recall communications and follow up?
• Who’s going to assess post market surveillance data and issue recalls? (That’s pretty easy, the FDA would clearly handle this - but they’ll need more money.)
• What about patient privacy, who will be responsible for maintaining it, and will patients be able to opt out?

The scope of the UID system that’s required to achieve the benefits many have attributed to this “great leap forward” becomes more clear. In fact, you could implement all the tracking and gain the very same patient safety improvements using the industries current UID, vendor serial numbers.

I should also note that vendors are currently required to maintain device history records that would benefit greatly from data held by providers (patient data for implants, near miss events, outcomes data) that is currently unreported. A simple mandate requiring providers to report this data to device vendors, and an open source software project driven by a foundation or university is a more direct and efficient solution.

All this really doesn’t have much to do with a fancy new identification number, does it?

Pictured right are some blood transfusion ID labels from the UK Blood Transfusion & Tissue Transplantation Services web site. The tracking of blood products might serve as a benchmark for UDI efforts.

UPDATE: From iHealthBeat, “Sen. Edward Kennedy (D-Mass.) on Thursday sent a letter to HHS Secretary Mike Leavitt urging the agency to finalize rules to implement the Patient Safety and Quality Improvement Act of 2005, Health Data Management reports.”

And this from FierceHealthcare:

Over the past week or so, the mainstream news media have crackled with the news of staph infections (including MRSA) found in  community schools. Prompted by this, Rep. Tim Murphy (R-PA) has filed a bill tha would require all hospitals in the U.S. to report infection rates t HHS. Under the terms of the bill, HHS would make such information available publicly on its website.Such a measure would trump existing infection tracking underway in the states. Right now ninetee states require infection reporting, but not all make the information public. (Murphy’s home state of Pennsylvania does make hospital-acquired infection reports available at www.phc4.org.)

Yesterday I noted that the Biomed Listserv has moved to new digs. In addition to a new hosting service, there is a message limit of 450 words - sadly, only enough for one or two points for me. I learned about this limit when my message bounced, so I've posted it here.

James asked about RFID in hospitals: who's got it, what they're doing with it, recommended vendors, and problems people have had. The following are my two cents.

Besides infant abduction systems (which tend to rely on monitored choke points rather than positioning throughout the unit), there are only about 200 hospitals that have deployed active RFID in the US. Of that 200, most are pilot deployments - limited to specific areas or departments. There's currently about 10 to 20 house-wide RFID installations. This is not the rush to adoption that many (especially some of the vendors) expected.

There's been a bit of a shake up among RFID vendors over the past year, and some very interesting new vendors have come to market. One of these vendors, RadarFind, introduced their system at the last AAMI conference in Boston. (You can read a bit about them here.) All in all, the vendor situation is unsettled.

Things to keep in mind:

• Different applications require different levels of performance, especially positioning accuracy. Positioning accuracy varies considerably among the different RFID technologies on the market. A thorough needs assessment is necessary to identify positioning applications and requirements for each application is the first step to selecting the right vendor.
• The details around knowing where someone or something is at a given point of time vary with different applications. If you're looking for that Newport vent that just got recalled, knowing the general vicinity is fine. If you're trying to improve utilization in your operating rooms, location data is just the beginning - you need an application uses that location data to optimize a much bigger set of processes. Thus, the workflow to which your positioning data would be applied is also an important requirement to gather.

My view of current RFID offerings is that the technology has not matured to the point where you can treat RFID as a generic multipurpose piece of infrastructure that can be leveraged by most any application that uses positioning data.

Let me know if you'd like help with an analysis of vendors, needs assessment, or planning/vendor selection.

Pictured right is the back of an Awarepoint positioning receiver - they plug into 110 volt wall outlets.

Self proclaimed the, “oldest guy with a computer science degree,” John Rushby with SRI International started the second day with a presentation on Accidental Systems. Using aviation as a model, Rushby discussed interactive complexity and system failures. Exploring the causes of accidents, Rushby noted, “that sufficiently complex systems can produce accidents without a simple cause.” He related aviation failures to health care, noting that in many patient safety incidents, it is the system that fails rather than the clinician.

Aviation is a good model because the extensive reporting of both failures and incidents. Incidents are “near misses” rather than actual accidents. In aviation, because there was no crash, incidents are a rich source of reliability and failure data. He noted that the scarcity of near misses in health care (i.e., adverse events) makes similar analysis much more difficult.

Interactive complexity and tight coupling were noted as important factors to system safety. He then went through a number of failure scenarios in military aviation, demonstrating how complex systems can fail due to a lack of understanding interactions among various variables.

“Nearly all failure indications were not due to actual hardware failures, but to design oversights concerning unsynchronized computer operation.”

Rushby noted that we are pretty good at building and understanding components. But systems are about the interactions of components that manifests “emergent behavior.” We are not so good at understanding this because many interactions are unintended and unanticipated; only some are the result of component faults. There are often multiple and latent faults, and they can malfunction or exhibit an unintended function rather than a simple and obvious loss of function. Many failures are simply due to . . . complexity.

Unlike medical devices, the FAA certifies components only as part of an airplane or engine. That’s because it is not currently understood how to relate the behavior of a component in isolation to its possible behaviors in a system (i.e., in interaction with other components).

So, what are we doing in medical devices? We’re making components and plugging them together, creating “accidental systems.” These medical device systems are created without conscious design. The resulting interconnects produce desired behaviors – most of the time – but may promote unanticipated interactions leading to system failures or accidents.

The solution is simple; we just need to think it all through before we build it. There are two problems with this. First, it’s not known how to do this in general due to the complexity. Second, in health care we regulate components that are then assembled into accidental systems.

Rushby went on to describe some partial techniques for improving the safety of systems. Modes of interaction are key. Examples include interaction:

• Among computational components
• Through shared resources (e.g., the network)
• Through the controlled plant (the patient)
• Through human operators
• Through the larger environment

Computer scientists have worked out how to predict and verify the combined behavior of interacting systems – sometimes. One method is called “assume/guarantee reasoning.” This method and others can be employed as an informal method or formally. Other formal methods include automated theorem proving, model checking and static analysis.

A cool new technology is “assumption generation.” This is well suited to human physiology, which can be quite variable – unlike a radar or jet engine. Using this engine you can define the loosest set of variables. Assume/guarantee reasoning combines a model or specification of your component(s) that includes assumptions about its environment. The assumed environment can be made part of the component specification using techniques like interface automata. (Interface automata (IA) is a light-weight formalism used to describe the temporal interface behaviors of software components.) The IAs of various components can be combined to create a state machine that can verify that a collection of components satisfy each others IAs. Data types and a state machine are extracted from these assumptions with the goal of creating a high confidence in system operation across the assumed environmental range (the assumption guarantee).

He also offered some simple tips to reduce interactive complexity:

• Send sensor samples with use-by date rather than time stamp
• For sensor fusion, send intervals rather than point estimates
• Define data with respect to an ontology, not just basic types
  • E.g., raw output of blood pressure sensor vs. corrected for bed height
• Critical things should not depend on less critical things
  • E.g., intervention for low blood pressure depends on blood pressure which depends on bed height sensor
  • Consequently, the bed height sensor is as critical as the blood pressure intervention or alarm

A key challenge with medical devices lies in the need to integrate device systems with other information technology infrastructure to facilitate the communications and sharing of data. Interaction through shared resources becomes a major factor in safe and effective systems engineering. The concept of partitioning went to the heart of the trade off between specialized embedded systems and general purpose computing platforms – or to look at it another way, between a standalone system and a medical device system deployed on a shared enterprise infrastructure.

Assume/guarantee reasoning is about computational interactions and relies on there being no paths for interaction other than those intended and considered. But commodity operating systems and networks provide lots of additional and unintended paths – hard to model variability. Typically, A and B get disrupted because X has gone bad and the system did not contain its fault manifestations. So safety- and security-critical functions in airplanes, cars, military, nuclear power etc. don’t use Windows, Ethernet, CAN etc. Avionics and military high-reliability applications are highly partitioned using very specialized system software, architectures and rigorous verification and validation. These make the world safe for assume/guarantee reasoning but are too expensive (and overkill) for medical device interoperability.

Contention on shared resources is a classic example where assume/guarantee reasoning breakdowns. An approach to solving this problem is interaction through a controlled plant. In medical devices, the controlled plant is the patient’s body. Medical device development would involve controller and plant models. A plant model may include only a few physiological parameters. Different devices will have different plant models and may be ignorant of other devices’ parameters - yet will interact in actual use.

Obvious perils include normal but unmodeled interactions, especially in the presence of faults. But problems can also occur due to inferior outcomes from lack of beneficial interaction, e.g., a harmonic relation between heart and breathing rates (Buchman).

Rushby’s final interaction is human interaction, with humans as cognitive agents (users) rather than the plant (or patient). Many things attributed to human error are in fact gross design errors. Even safety interlocks can introduce errors if the operator does not understand why an action is or is not happening. These kinds of problems suggest we may not be able to rely on skilled human intervention once we introduce automation - unless we design it right.

Modeling mental models can minimize human error. Operators use mental models to guide their interaction with automated systems. Problems arise due to divergence between an operator’s mental model and the actual behavior of the device or system. Design engineers can represent plausible mental models as state machines, e.g., use the training manual, and then simplify using insights of Denis Javaux. Then compare all behaviors of the mental model against the actual automation (using model checking). Divergences between the mental model and actual operation represent your automation “surprises.”

Beyond specific interactions, there is the larger environment. The purpose of a system is to change some relationships in the environment external to the system. So requirements specification should focus on those changes. But changing intended relationships may also change unintended ones. Requirements engineering should focus on these issues where unintended relationships can result in failures. This can be done by building models of the environment and exploring interactions. Model checking and other formal methods allow exploration of all possible behaviors.

So, now we have these various sources of unintended interactions and suggested some ways to detect and avoid them. The next challenge is to provide assurance that we’ve detected and avoided unintended interactions. All assurance is based on arguments that purport to justify certain claims, based on documented evidence. There are two approaches to assurance: implicit (standards based), and explicit (goal-based).

Aviation and security use a standards-based approach to software certification. In this approach, the applicant follows a prescribed method (or processes) to deliver prescribed outputs like documented requirements, designs, analyses, tests and outcomes, traceability, etc. Standards usually define only the evidence to be produced. The claims and arguments are implicit. Hence, it is hard to tell whether given evidence meets the intended use. This approach works well in fields that are stable or change slowly. A standards-based methodology tends to institutionalize lessons learned and best practices, but is less suitable with novel problems, solutions, and methods – like medical device interoperability.

The goal-based approach involves the applicant developing an assurance case whose outline form may be specified by standards or regulation. This approach makes an explicit set of goals or claims, and provides supporting evidence for the claims and arguments that link the evidence to the claims. Underlying assumptions and judgments are explicitly and unambiguously stated. This approach should allow different viewpoints and levels of detail. In practice, the case is evaluated by independent assessors who evaluate claims, evidence, and argument.

So what should evidence look like? There are two types of relevant evidence, evidence about the process, organization, people, and evidence about the product. Certification reviews are based on human judgment and consensus, e.g., requirements inspections, code walk throughs. Analysis can be repeated and checked by others, and potentially by machine. Formal methods/static analysis and tests are also used.

The interesting opportunity is to create a science of certification. Certification is ultimately a judgment that a system is adequately safe/secure/whatever for a given application in a given environment. But the judgment should be based on as much explicit and credible evidence as possible. A Science of Certification would be about ways to develop that evidence.

The bottom line is that there is enough damage caused by the practice of medicine that the introduction of inherently flawed medical device systems provides a net improvement. Consequently, there is no immediate requirement to rush to implement the kind of systems engineering and certification used in aviation or other high reliability endeavors.

A worst case scenario is a medical device system that results in death or injury to multiple patients – like when all the passengers are lost in a catastrophic airplane failure. This could quickly shift the health care environment where aggressive safety engineering is required.

All of this flies in the face of current software licensing via the ubiquitous EULA. The typical EULA asserts extensive liability limitations. Software vendors need to start making specific claims and backing them up with evidence.

Questions:
Given the interactions discussed, how is criticality addressed? There is no simple answer to that – one way is to calculate all the paths that this could occur and ensure all the paths are workable. In the context of systems it’s really hard to know how to do these things.

A CANopen proponent witnessed to the gathered multitude about the use of CAN in high-reliability systems like helicopters, naval ships, etc. Rushby noted that this field is not without controversy, but noted that CAN is used but that he would prefer not to fly on an airplane using CAN.

A group has been working on an ICE standard on medical device interoperability. There is a requirement in the standard for the vendor to create a mental model, and a fall-back mode in the event of unanticipated failure. Tight coupling is inherent in close loop control. Adding slack into such a system may be advantageous in accommodating human operator variability.

What is the possible impact on medical devices of the sometimes draconian measures that aviation uses for time-sliced partitioning? This approach is very costly to developers, placing many constraints upon the engineer. The flexibility inherent in human physiology may be better served by an approach that is different from time-slicing partitioning.

How close do you think we are to the “science of certification?” Rushby said he thinks we’re far away from that. Much if this is due to the transformative change in the aviation industry. There is also much yet to be learned about controller-synthesis, and how it would roll up into a certification science.

Baxter just can't seem to get a break. Just 4 months after their Colleague pump comes off ship hold (more here), Baxter and the FDA announce new recalls.

The FDA upgraded Baxter's recall of the 3 channel Colleague pump to a Class I recall (the most serious) for a software bug. Here's Baxter's press release and the FDA's notice.

On top of all this, Baxter employees at a Phoenix service center have been caught falsifying records regarding the service and repair of 534 recalled Colleague and Flo-Gard pumps. From Baxter's home town paper, the Chicago Sun-Times:

Ouch. Pictured right is a Colleague triple-channel pump.

UPDATE: Here's the FDA recall notice for the pumps that had falsified repair, inspection & test data sheets mentioned above.

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.

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

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

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

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

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

According to a survey by CHIME, more hospitals are reducing restrictions on cell phones.

As I noted on the Biomed Listserv this week, RF interference is a fact of life and cell phones are but one contributor. Regarding RF interference risk, cell phone's will never be proven to be perfectly safe - but then neither will hair dryers, florescent light ballasts, microwaves, and elevator motors. The key is risk management.

Sadly there's no link to the actual report on CHIME's web site. (You'd think they could have found a corporate sponsor for the study, and then published it in support of their advocacy for effective use of IT in health care and as a service to the industry - that is why CHIME exists, isn't it?)