Category Archives: Health Policy

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.

CCHIT and EHRs, again

Posted on by

John Moore has a good summary of the ongoing debate about CCHIT, its relationship with the HIMSS trade group, and the challenge for “meaningful use.”

In summary (and I completely agree with John) – one outside, independent organization should NOT be the controlling gate for all HIT investment over the next ten years. CCHIT would like to be that organization, and who can blame them? But I’d be worried even if there wasn’t any relationship to a trade group at all.

iPhone Barriers to Mobile Health

Posted on by

Just saw a bit of a rant by M.G. Siegler on TechCrunch about Apple’s review process for iPhone applications. Apple has banned a variety of applications from the iPhone Apps Store, sometimes while allowing very similar applications through. Even for applications that don’t trigger arguments over appropriateness of content, the review process itself is lengthy and unpredictable. I can think of few other industries where the final step of the production process – putting the product into the hands of users – is held up for an indefinite period of time by an organization who has final say on the matter, doesn’t post the rules, and provides no guidance during the development process.

Here’s Siegler’s piece:

Let’s Stop Picking On Those iPhone App Reviewers. Actually, Let’s Not..

I mention it on this blog because I had an idea for an iPhone healthcare application that we’ve decided not to pursue because we’d have to go through the App Store approval process. The content wouldn’t have been objectionable, but we would have had to develop quite a few variations on the application for different projects, and the 1-4 week (or more) delay on approvals before we could push the app to real users made the whole thing seem a little less than viable. And I don’t think I’m the only one – a tremendous amount of the value in mobile health tools would come from very customized apps, designed for a particular clinical trial, a particular hospital, a particular quality improvement program, etc. As of today, Apple doesn’t make that possible.

That’s worth re-iterating: the Mobile Health applications that will have a real impact are going to be the little ones customized to particular projects across the whole healthcare value chain. Small contributions individually, but huge in aggregate.

Windows Mobile supports this model a bit more cleanly, but the hardware and software platform just isn’t as good (and I carry a top-of-the-line HTC Windows Mobile Touch Pro from Sprint, which is about as good as it gets if you need a keyboard).  I have things I want to deploy to patients and clinical investigators on iPhones and iPod Touches, and as of right now the logistics are making that impossible.

Maybe version 3.0 of the iPhone software will help out here. Come on, Apple.

Trusera Closes Shop

Posted on by

Trusera was one of the first “Health 2.0″ sites, and now it’s shutting down.  I never used the site, so I have no idea about the quality of the offering. What I do know is that it was generally well regarded for what it was, and had a founding/managing team that was responsible for taking Amazon.com and Starbucks from small startups to the behemoths they are today. Both could presumably have put in the funding to keep things going indefinitely – even if it was just paying the hosting bills.

The fact that they were unable to raise outside money and unwilling to fund it themselves implies that the fundamentals must have been pretty bad. And I suspect that extends to quite a few other attempts to reinvent healthcare.

Trusera | Billy’s Journal | FAQ on Trusera’s Closure on May 27, 2009.

Disputing Medical Data

Posted on by

John Halamka has posted a few thoughts from a meeting on dispute resolution in healthcare:

Life as a Healthcare CIO: Followup on Dispute Resolution

The key insight, which followed from the “ePatient Dave” data kerfuffle, is that we need to find a way to web-enable dispute resolution in healthcare. There’s not too much to add to that, except to reinforce that he’s absolutely right, and perhaps to suggest that it’s a broader issue than just PHR data disputes. In general, civilization benefits when we have more APIs to mediate our interactions with large, impersonal agencies. Two principles:

  1. Personal Health Record platforms, like Google Health and HealthVault, need to incorporate a dispute resolution workflow into their core APIs. This makes implementation a little harder, but it also removes one of the major objects institutions may have to sharing data with consumers by way of a PHR. The institution can implement the back-end portion of the dispute any way they want.
  2. Some percentage – unknown but likely high – of institution to PHR data exchanges will be flawed. Some percentage of those flawed transactions – unknown but likely low – will be caught by savvy patients. The rest will flow through and be discovered later, if at all. At the minimum, this means dispute resolution will have to be implemented for any data held in the PHR – allowing disputation at the time of data acquisition is insufficient. And as patient data is relied upon more widely, we’ll likely need more ways to validate its integrity.

If we can’t rely on the consumer to spot all the errors (and we can’t), automated tools may be able to fill a small part of the gap by looking for logical inconsistencies. This needs to be approached with care – too many unnecessary queries to hospitals will impose too much of a burden, and “Are you sure  you have this? Because if you did you’d probably be dead.” is probably not a question that the average patient wants to be asked.

Fed Sponsored, Open Source EHR

Posted on by

Senator Jay Rockefeller (D-WV) has introduced legislation calling for universal adoption of Electronic Health Records. The law would create a “public utility” board within the Office of the National Coordinator for Health IT, and the board would be responsible for coordinating the development of an open source EHR solution. There would also be additional funding (presumably over and above current stimulus dollars) for safety-net providers to cover the full cost of implementation and maintenance for a five year period.

That could be a lot of money. I’m working off the press release here, since I can’t find the text of the proposed legislation online – but I could see that being interpreted as paying for a substantial portion of a provider’s IT budget. There’s no question this would drive adoption for Health IT! It’s unclear that the open source condition would really effect the overall cost of the plan, as software licensing fees, while not trivial, are not the largest component of a hospital or small-office Health IT roll-out. If the goal is an EHR roll-out, why not let the provider pay for Epic with its own budget, and then subsidize the implementation costs (since they’re proposing to do that anyway.) But I digress.

My real question is the efficacy of the “public utility board” for shepherding the open source process. The bill calls for facilitating ongoing communication with the open source community to incorporate improvements and innovations into the “core programs.” I could see this going very badly indeed – I’ve been looking for last night hand haven’t come up with any large scale examples of large-scale government engagement with open source. VistA, the VA EHR system that is often exhibit A when talking about government support for open source, is very much accidental software, as the open source release was the result of a Freedom of Information Act request, and the VA has not exactly taken a leading role in facilitating the VistA open source community.

Open source development “managed” by the federal government sounds like a Bad Thing. A federal grant program for creating and maintaining open source healthcare applications, on the other hand, could be a very good idea – if encouraging an open source alternative to commercial EHRs is a seen as a public good, there’s an opportunity to fund companies to build those open source interoperability components, to support CCHIT certification of open source projects, etc. Many of my reservations about CCHIT would be dramatically reduced if they had a financial incentive to certify as many open source applications as possible – or if the certification of “meaningful use” was contingent on the availability of multiple certified open source alternatives.

The Rockefeller Bill is just a proposal, and if history is any guide it’s not going to move forward, at least in its present form. But this is as good a time as any to start thinking about ways the government can, productively, support the development of open source options for physicians.

(For further reading: Fred Trotter’s really excellent NCVHS testimony on open source EHRs.)

The Patient is the Platform

Posted on by

Doc Searls invented the Internet. Ok, not really – but he was one of the co-authors of the Cluetrain Manifesto, which did as good a job as anybody, and better than most, at predicting the degree to which the Internet would facilitate conversations, rather than just transactions, companies and their customers.

Anyway, Doc is now a fellow at the Berkman Center at Harvard Law, and for the last year or so has been thinking about healthcare:

Doc Searls Weblog · Getting real about fixing health care.

What he’s done here is coined a really nice, pithy term: “the patient is the platform.” I’ve been trying to say the same thing for a couple of years, usually with a variation on the phrase “the only person who knows where all my healthcare data is hidden is me”. We even ran an entire conference on the PHR as a platform in 2007 (and there’s some great video on the web site). I like Doc’s version better, and I’m going to steal it.

On the subject of pithy one liners, at HealthCamp Boston yesterday, John Moore and I ran a session on Consumer and Clinician engagement in healthcare IT. John did a nice job of keeping the discussion focused on human factors (I only dragged it down one rabbit hole when I decided we really needed to talk about microformats), and in the follow-up conversation we came up with another Internet analogy:

The PHR is a patch.

In other words – the health system is broken. Lack of coordination and information sharing is one part of the system failure. Personally Controlled Health Records promise (they have yet to really deliver) to bring disparate parts of the healthcare system together, via the agency of the one actor who actually touches most of them: the patient. But PHRs, and even EHRs, are not healthcare reform. They’re a bridging measure.

How the codes versus clinical story ended up…

Posted on by

The big topic on the Health IT blogosphere was Dave deBronkart’s misleading administrative data in Google Health.  One of the really nice things about Web 2.0 – and responsive organizations – is that learning can be rapid, and lessons quickly applied. Here’s a post by John Halamka, the CIO of Beth Israel Deaconess, Dave’s hospital, outlining the changes they’ve made to their Google Health integration:

Life as a Healthcare CIO: Lessons Learned from e-Patient Dave.

Should some of this stuff have been figured out earlier? Probably yes, but virtually everybody in the PHR industry has been using claims data for years, since it’s all that most organizations have access to. So there’s not much point in singling out Beth Israel for having included it.

The upshot is that there’s been a change in how at least one hospital is dealing with this data, and there’s been some useful discussion about how difficult this whole data liquidity project actually is. More broadly, the use of claims data for consumer-level health records has taken a hit, although not a fatal one. Claims are often very useful for broad, population level analysis – not in the least because inaccuracies and inconsistencies tend to come out in the wash. As various commentators have noted, they were never intended as an instrument to actually provide healthcare.

The FTC and PHR Breach Disclosure

Posted on by

The Federal Trade Commission has issued a draft rule that outlines how PHR providers must notify consumers in the event of security breaches (warning, PDF!). The rule includes platforms like HealthVault and Google Health along with individual PHR vendors like WebMD and ActiveHealth.  Comments can be submitted here, and are due by June 1st. This does NOT affect HIPAA covered entities such as hospitals and insurance companies, although the Department of Health and Human Services will be issuing one soon, and the content is expected to be quite similar.

The Recovery Act contained temporary requirements, which will remain in effect until Congress passes new legislation based on a report currently in development by HHS and the FTC. The report is due in a year, and legislation takes a long time, so these “interim” requirements will almost certainly be in force until 2010, and possibly longer. Interim rules that hang around long enough tend to be the basis of permanent rules.

Here’s a summary of who is affected and under what circumstances:

  • A “breach of security” is defined as the acquisition of identifiable health information of an individual, from a PHR, without authorization.
  • The rule also contains the word “unsecured.” This means encryption – if a laptop containing appropriately encrypted data is stolen, that doesn’t count as a breach for notification purposes.  HHS is responsible for issuing a guidance on acceptable security policies, to be updated annually.
  • Access is not the same as acquisition. Employees looking up records about friends and celebrities is a breach. An employee inadvertently loading the wrong record in the EHR is not.
  • The “fact of having an account with a vendor of personal health records” is itself considered sensitive information. The obvious example (used in the notice) would be releasing a list of names by a company that provides PHR services for AIDS patients.
  • De-identified information, according to the existing HIPAA de-identification rules, fall outside the scope of the rule.
  • “PHR related entities”  are what the platform vendors call “Personal Health Applications”. It’s a broad net, and the examples include websites offering medication management applications and bricks-and-mortar companies advertising dietary supplements online, as long as the interaction with these companies is through a PHR or PHR platform.  The definition also includes organizations that “access information in a personal health record or send information to a personal health record.”

The breach notification requirement itself has a few components:

  • Third party service providers must notify their customers (vendors of PHRs and PHAs) following the discovery of a breach. The individuals affected must be explicitly identified.
  • Notice must be received by a “senior official” of the PHR vendor or PHR related entity.
  • There is a “reasonably should have known” clause that sets an expectation of reasonable security measures. You can be in violation of the rule if you didn’t detect the breach in time. But since some breaches are hard to detect, you’re not always in violation if you discover something belatedly.
  • Notifications to individuals must be made “without unreasonable delay” and always within 60 days.
  • Notice must be by first-class mail, or by email if the individual consents (which must be “affirmative” consent, not something buried in an end user license agreement).  There is no obligation to provide notification by mail (although if the customer doesn’t consent to email notifications, you can’t provide them with service otherwise).
  • If ten or more individuals can’t be reached, a substitute notice must be posted – a large link on the home page for six months, or through a media campaign.
  • The FTC must be notified in five business days if 500 or more people are involved. If fewer than 500 people are involved, reports may be submitted annually.

That’s not all there is to it – the rule also describes the content of breach notices and the supporting document includes an economic impact assessment. I wrote some similar impact analysis documents when I was at CMS – it’s always a challenge to get it right.

My quick reaction: it’s not bad. We’ll see every PHR vendor race to add that “email notification” permission to their products. The cost of compliance shouldn’t be that burdensome, although it’s certainly non-zero, and that’s really the point – organizations need to take security seriously, and making breaches costly and embarrassing is a good way to do that.

Claims Data and PHRs

Posted on by

The Boston Globe ran a piece this morning about the challenges of using insurance claims data to populate PHRs. It’s nicely done, and highlights what a shame it is that the Boston Globe is teetering on the verge of bankruptcy.

Electronic health records raise doubt – The Boston Globe.

Dave deBronkart, the patient involved, has been an active blogger for several years at e-Patient Dave.

Claims data is very challenging – it’s messy and not particularly precise.  I always envisioned claims information as being useful primarily as a directory, rather than a source of actual content for PHRs. The insurance company knows where you’ve gotten treatment, and that information can be used by a PHR platform to seek out information from clinical systems. Of course, that requires a lot more interoperability in the entire system than we have today.

Another approach is to work backwards – rather than including every claim from an insurance company in the PHR, only include the unambigous subset. A flu shot is a flu shot. But some data is just ambigous – like the cancer in the story, which seems tohave used a broad billing code. And some, of course, is intentional – physicians who file a misleading diagnosis so that a patient can be reimbursed for an off-label use of an expensive drug.  So for these cases – give the user an interface that allows them to review potentially problematic data, and explain clearly that some of it might not be entirely accurate, and there’s a good reason for that.

Finally, consumer controlled health records require very clear statements of data provenance. This was something our group paid a lot of attention to back when we were working on active development in the area, and Microsoft does a pretty nice job in HealthVault as well. I don’t know what Google’s design rationale was in not choosing to surface this information more prominently, but to my mind it was a mistake. Ten years from now we may have clinical data flowing so effortlessly that we can simply sit back and trust in the validity of any automatically sourced data. But that day is not today.