CCHIT and EHRs, again

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

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

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.

Barbershop

I really should be writing a lengthy post about a number of important subjects that have come up recently – meaningful use, closed standards, and so forth. Unfortunately I’ve just recovered from a week of fairly aggressive, although not pig related, respiratory illness and so instead I’m going to post a music video about Health IT interoperability. The payoff is at the end.

It’s somewhat amusing to note that I first met Ross on New Year’s Eve, 1999, which happened to be the day he proposed to his wife. We then completely avoided crossing each other’s paths until 2006, when I was at CMS and he was at Pfizer and representing the industry on the AHIC Consumer Empowerment workgroup. We’ve had the opportunity to do some (non-musical) together since, which has been quite a lot of fun.

But if you read this far, one more thing to think about – HITECH has a few billion dollars in stimulus for HIT adoption. It has vastly more in penalties. The math is not uninteresting, and I’m going to do some of it this weekend.

Disputing Medical Data

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.

Get Microsoft’s PDF add-on now

I use a set of sketchy Visio stencils to create mockups for the web applications we build here, and there have been two practical pitfalls to the sketchy stencil strategy.  First, the sketchy stencils created larger than expected print jobs — I’ve had a few close calls, nervously hovering over the color printer before a client meeting, waiting for my mockups to emerge.  Second, when exporting the mockups to PDF (through Adobe’s PDFMaker add-on), the PDF files tend to be large, and printing from the PDFs takes even longer.

I learned recently that Microsoft provides its own Save as PDF add-on for Office 2007, so I tried it out, and was very pleasantly surprised.  Microsoft’s PDF generator:

  • is free (unlike Acrobat)
  • generates PDFs in the blink of an eye (rather than a minute or so with Acrobat)
  • PDFs are 1/2 to 1/4 the size (based on my casual observations)
  • printing from the Microsoft-made PDFs is incredibly fast

That last printing point is a big one, since it allows me to circumvent Visio’s embarassing inability to perform simple print functions, like collating multiple copies.  (Rather than print in Visio, I can make a PDF and print from Acrobat Reader with ease.)

Wordle for the Blog

I’m actually not that big on visualizing data. Some people are textual thinkers, and that’s the category I tend to fall into.  But good visualizations are powerful things, and that’s one reason I like tag clouds – words made into a picture. Everybody’s happy.

Which is why I spent a little too much time last night playing with Wordle, a service that lets you take a bunch of text and make a cloud out of it. Here’s one I made using the RSS feed for the blog:

The info.rmatics wordle

It looks like we’re pretty interested in open source development, health, and Twitter.

The Whiteside Rules for Biotech Entrepreneurs

On Thursday Evan and I spent the afternoon at the first session of the Harvard Medical School Dean’s Symposium. The topic was “Challenges to Successful Innovation and Translation” of medical research, and the highlight was a talk by Professor George Whitesides.  Dr. Whitesides is one of those very interesting products of Cambridge, MA – he’s written over 950 papers, and co-founded twelve companies, including Geltex (which was sold a few years ago for $1.3 billion) and a little biotech named Genzyme. So when he talks, it’s worth listening.

After his talk I asked him if it would be all right if I shared “Whitesides’ Rules” on this blog. He agreed, provided that I referred to them as “Uncle George’s Homey Rules for Entrepreneurs.”  So here’s Uncle George’s homespun advice for entrepreneurs. I’ve refrained from adding my own commentary, other than to type up my notes from the talk (and thus take no credit for various homey aphorisms):

  1. There are three strategies for entrepreneurship. You can solve a problem, you can develop a technology, or you can imitate or improve on something that already exists. Solving a problem is best, and keep in mind the difference between wants and needs in mind when you select that problem. A cure for Alzheimer’s is a need. A new car, less so.
  2. Radically new ideas are much harder than a “me too.” And they may or may not be more profitable and important. Genetic engineering was going to change drug development thirty years ago. It’s only now beginning to have a real impact.
  3. Finish the science before you start the company. Ideally, prototype the product and try selling it.  It’s easy to do engineering on a budget and on a schedule. Science is a little trickier.
  4. A customer is someone who will pay you money, and product is what s/he will pay you for. The most intimate, shared human experience is writing a check.
  5. Spend time as an apprentice. Learn from people who know – and have already made many expensive mistakes.
  6. Use Venture Capital as little as possible. Venture advice can sometimes be very helpful, but remember the overvaluation of capital. VCs get most of the money.
  7. Make simplicity an explicit strategy. But don’t go overboard. Start as simple as possible, then make it simpler.
  8. Remember the Money. If research is $1, development is $10-$100 and manufacturing is $100-1000.
  9. Technical development and market development are inseparable. Most scientists aren’t socially acceptable. Take them to the meeting, but use duct tape.
  10. Regulatory agencies are motivated to avoid risk. Nobody ever lost their job for not approving a product.
  11. Cash may rule, but time and risk discounted cash flow decides. Slow and uncertain are both bad.
  12. Cost of capital differentiates. Small companies are creative and have a high cost of capital. Large companies aren’t creative, but have a lot of cheap money. Synergy would be ideal.
  13. Learn elementary accounting. DCF, RONA, ROI, EBIT(DA) and CAPEX. Otherwise the business people will see you as shark food.
  14. Right now, and for 3-5 years or more, IPOs will be difficult or impossible. Plausible exit strategies are eveloping a company that sells stuff, or selling the company.

And that is what Dr. Whitesides thinks bioentrepreneurs should know.  Not all of these apply to Health IT, regular IT, and entrepreneurial activities that don’t have a science component. But most of them do.