New Infrared RTLS Vendor
Well, new to me anyway. The company is CenTrak, located in Newtown, PA, South Korea and Chennai, India. The company, a consumer electronics company years earlier, launched an active RFID real time location system (RTLS) called TagAlert in 2005. Following the release of TagAlert, the company developed InTouch, an indoor positioning system targeting hospitals, long-term care and commercial facilities.
InTouch is is a zone based system – tag position is determined by the tag being within the presence of a receiver, or having just passed a receiver. Unlike a computational based system, where location is computed from the signal received at multiple receivers, the InTouch system uses receivers laid out in specific locations that act as gateways or choke points. When the presence of a tag is sensed by the receiver in a patient room, the system “locates” the tag in that room. Other zone based systems include Sonitor and RF Code. Some systems like AeroScout use both computational and zone methods to determine location
It is interesting to note that two vendors who previously touted infrared, Versus and Radianse, have downplayed the use of that technology. Rumors that another RTLS player was going to launch an infrared based RTLS remain just that – rumors.
What’s really interesting about InTouch is that the receivers are battery powered and wireless. This design feature joints Awarepoint and RadarFind as solutions that drastically reduce RTLS installation costs. Vendors with wired receivers require power and a network connection routed to each receiver, an expensive and trouble some proposition in most hospitals.
Pictured right is the InTouch Spider, their wireless battery powered infrared receiver.
Pressure to Increase Hospital Patient Safety Reporting Grows
Washington state governor, Christine Gregoire, has proposed legislation mandating hospital reporting of all adverse events. From the Seattle Post Intelligencer:
[...] 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?
RHIOs Have Got It Wrong, Health Affairs Study Shows
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.
Effect of Environmental Design on Reducing Nursing and Medication Errors
Are you at a hospital that is planning new construction or renovation? Are you a vendor with a product or service that’s used at the point of care in hospitals? You should check out the latest survey from The Center for Healthcare Design, the Effect of Environmental Design on Reducing Nursing Errors in Acute Care Settings. You can get your copy for $35.
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.
The New Enterprise Application – Medical Devices
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.
