Monthly Archives: June 2009

Simulations and Public Access

Posted on by

Andrew Yates over at Think Gene has an interesting post suggesting  A Force Fix for Healthcare. The idea is a simple one – all third party healthcare payers (insurance companies) must expose a web service that allows the public to simulate any insurance coverage decision. You put in all the inputs, and you get out a yes or no answer.  He argues that since the decisions are being made by computers and algorithms anyway, there’s no reason that this couldn’t work.

I like the idea in principle – in general, I’m in favor of exposing decision making processes to consumers whenever possible, and enabling smart, motivated people to build tools that streamline complex systems for everyday users. Physicians would love it, too  – much less revenue at risk.

That being said, there are a couple of practical issues. I’m not sure I’d go as far as calling these problems, since they’re surmountable and wouldn’t kill the idea outright.  The core issue is that coverage decisions are not isolated. Take a doctor’s visit as an example. Most insurance companies, including Medicare, won’t cover more than one primary care office visit (for a routine checkup) within a certain time period.  So to simulate the coverage decision accurately for a particular patient, we need to know when their last reimbursed office visit was. With Medicare that information may not be available in real time, and I suspect other insurance systems face similiar problems. You can still simulate, but you have to provide a set of assumptions that will vary on a bill by bill basis.  Doing better may well require a rip-and-replace for Medicare’s systems.

The other issue is that coverage decisions aren’t deterministic, and there often is some medical thought that goes into it. Genetic testing is an excellent example. A few months ago I got to spend a day shadowing one of the attending physicians in the adult genetics clinic at one of the major Harvard hospitals. We spent a lot of time talking about the challenge of getting insurance companies to reimburse for some of these tests. It’s clear that, right now, there aren’t a lot of simple rules that can applied to reimbursement decisions at the cutting edge of medicine. Appropriateness of testing (and it’s expensive testing) is going to depend on a lot of factors, including the makeup of the patient’s extended family.  While I doubt the insurance companies are this sophisticated, a test might be appropriate for a 50 year old woman with three children, but not for a 50 year old with no children. For the former, the test could create intervention opportunities for the kids. For the latter, it may just be informational.

The bottom line: it’s an interesting idea, but I’m not sure if it can really be applied to all coverage decisions, and at a reasonable cost.

Microsoft Connected Health Conference

Posted on by

I spent all day yesterday at the Microsoft Connected Health Conference in Bellevue, Washington. I had to miss todays’ wrap-up sessions in order to attend a few other meetings, and was generally crippled through the whole event thanks to an airplane-acquired something-or-other, but it was still a very interesting day. One of the great things (if not the only great thing) about a sore throat is that it gives you an excuse to listen to other people.

The conference opened with a very nice panel, featuring Peter Neupert, Microsoft’s Corporate VP for the Health Solutions Group, Uwe Reinhardt of Princeton University, former Secretary of Health and Human Services Michael Leavitt, and David Kibbe of the AAFP. The topic was one that we’ve all rehashed dozens of times – how do we fix the US healthcare system, what role can Information Technology play, and if IT is valuable in the long term, what do we have to do to get it into place?

That’s an important distinction, by the way, that many events miss. Health IT adoption is not a goal in and of itself. The fact that my physician types rather than uses a pen is of no intrinsic value to me. The value comes in faster, more accurate, safer, cheaper and more effective healthcare.  That’s the goal – investments in Health IT are just one of several non-exclusive paths to a more functional healthcare system.

In the end, the panel concluded that it all comes down to Congress. When I was at HHS myself, we had all kinds of things we wanted to try, but we generally couldn’t – not enough money, or not enough Congressional authorization.  A great example of this phenomenon (which Leavitt mentioned in his remarks) was a recent program to require bidding for Medicare Durable Medical Equipment contracts. Congress actually authorized the program, which went into effect on July 1, 2008, and was projected to save the government about a billion dollars (and that from just ten products in ten regions). The DME industry went to Congress, and on July 17th the program was shut down. At CMS and on the AHIC Chronic Care workgroup we looked at trying to do a demonstration program for electronic patient visits, but were blocked because the Medicare telemedicine statutory restrictions are very, very tight.

Another point of (at least apparent) consensus on the panel was that while the Medicare reimbursement system was fundamentally flawed, its status as the 800 pound gorilla of the US healthcare system means that every hospital and small practice has to set themselves up around the Medicare fee for service model.  Fee for service payments are not good at aligning incentives between participants in a market. So what happens if (as some propose) we extend Medicare to the entire population? Will centralized ownership of risk lead to the kinds of preventive medicine programs and support for (appropriate) technology investment that will ultimately take cost out of the system? Or will the system ossify under Congressional supervision?

I offer no answers, of course. I’ll post some other thoughts on the conference later (paticularly around HealthVault and Amalga), but for now, I leave you with a great, if slightly paraphrased,  Leavitt quote from the keynote panel: “The problem isn’t a lack of political will. It’s an overabundance of political will. Whenever we get close to actually making a change people start unholstering their political will on each other.”

Sensible Certification

Posted on by

Sensible Certification is a new web site summarizing some of the key arguments against the rush for CCHIT certification. It’s not clear who runs it, but they make six points that I completely agree with (I’m not sure about Laika in point 4, but only because I’ve never used it). Here’s they are, verbatim:

  1. Slow down the certification definition process. There’s absolutely no hurry – the price of getting it wrong is far higher than any potential benefits of certification.
  2. Do not define certification language until meaningful use is fully defined. Meaningful use must drive certification and not the other way around.
  3. Certify the minimal things possible – focus on data, not software, technology, requirements, or functionality. Data sharing alone is the maximum that certification should go.
  4. Certification of data interoperability is good because information exchange is important. We should rally around NIST’s Laika tool as the maximum certification requirement and could be even less than that. Laika is open source, created by NIST and Mitre, approved by ONCHIT, and is supported by CCHIT.
  5. Certification of application functionality is very dangerous because it stifles innovation and writes into law software requirements that should be decided by the marketplace.
  6. If the full CCHIT certification requirements are written into the federal regulations it will mean the death of innovative healthcare information technology and will mean Physicians will end up paying for unneeded functionality and large, bloated systems.

I wish that – collectively, as an industry – we had the knowledge to say “yes, this is exactly what we need.” But we don’t, and we won’t. Certification has been historically successful  when you’re certifying something that can be effectively automated. Interoperability certification meets this criteria. Functionality and feature sets don’t.