Mirth-appliance

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.