In celebration of the 40th anniversary of the moon landing, the best New York Times correction I’ve ever read, from the July 20, 1969 issue:
Monthly Archives: July 2009
Boston Globe Says Boston Rocks (in Health IT)
Nice article in the Boston Globe on Massachusetts’ leadership role in the Health IT community. “The Silicon Valley of Health IT.” And it’s true, too – more HIT innovation, both academic and corporate, has come out of the area inside Route 495 than anywhere else in the country. Even the big out of state players (Epic, Cerner) and the new entrants (Google, Microsoft) have at least some technological roots here.
So good for us.
Chrome OS has nothing to do with PHRs
I usually don’t bother picking on other people’s editorials. But this one, from FierceHealth IT (which I usually like, incidentally – it’s a nice roundup of daily HIT stories) just struck me as trying to fill space:
Google’s Chrome OS may heat up PHR competition with Microsoft – FierceHealthIT.
Google’s Chrome OS has nothing to do with healthcare. This is not a signal of the shift to cloud computing – that signal flare went up several years ago. Google won’t “tightly couple” Google Health to Chrome OS. HealthVault is just as web based and interactive as Google Health (admittedly, a little more complex to use, but you get more out of it). Both systems have all kinds of big, enterprise-class integrations behind them. Chrome OS is about Netbooks – they’ll ship a few million units on cheap hardware, and it will be easier for us to sit in front of the TV at night checking email. I won’t say it will never be a competitive desktop operating system, but that would be many years and several paradigm shifts down the road. A new version of Google Calendar would be more significant – at least you could integrate that with appointment reminders somehow.
The last sentence kind of sums it up:
I don’t pretend to have any kind of crystal ball here. But I do think it’s hard to argue that the PHR world is a lot more interesting with the Chrome OS in it.
That’s verbatim. And I agree – it is VERY hard to argue the proposition that Chrome OS makes any kind of difference whatsoever.
Android, by the way, is a different story – while it’s also too early to say, Google’s OTHER OS project, intended at the moment for cell phones, could enable a range of interesting healthcare applications. Since it doesn’t require always-on connectivity, Android could form the base of a handheld computing ecosystem in healthcare. Apple’s iPhone OS could do the same thing, and if Apple brings out a tablet, as they’re now expected to, I’d look for a wave of innovation coming off that platform. Local storage coupled with intuitive interfaces and great performance? That matters.
EHR Challenges in the Netherlands
My friend FJ, who blogs at TechSocioTech, sent me a link to a news article from a Dutch newspaper, covering the results of a survey of 1800 patients by the Dutch Patient Consumer Federation. Since my Dutch is poor, he kindly provided me with a quick translation (probably not intended for blog publication, but it’s a lot cleaner than Google translate!). It speaks for itself:
AMSTERDAM – Medical records are often full of errors and incomplete. Almost 60 percent of the people who responded to a campaign to notify the Dutch Patient Consumer Federation (NPCF) had to correct or supply missing information to caregivers because insufficient information was available.
Moreover, participants regularly noted egregious mistakes.Therefore a large majority has a negative attitude towards digital medical records. The case files of one in five patients were even lost at one point or another, a spokesperson said.
Most people who are already worried about the medical data are therefore also skeptical about the safety of the SPD. While they worried, two thirds believe that digital exchange of patient data is helpful in case of emergency, medication, and clinical insights. 1800 people took part in the campaign of NPCF. (ANP)
I’ve been trying to find an English copy of the press release, but no success so far. Do we have an entire country of ePatient Daves? This reinforces a simple observation about EHRs in general – they probably won’t be widely accepted until the data quality reaches a sufficiently high level, and that just hasn’t happened yet. Right now consumers expect that EHR data is both more widely available than it actually is, and over higher quality. What happens when they find out?
Porter on Healthcare Reform
In the current issue of the New England Journal of Medicine, Michael Porter, the Strategy Czar from Harvard Business School, has a very interesting manifesto on how to fix the healthcare system. Since it’s a Perspective, the NEJM is letting you read the whole thing for free. For what it’s worth, I’m pretty much in agreement with Porter’s vision on the end-state of healthcare reform. We need to fix payment by bringing everyone into the system (and yes, that more or less means universal coverage, whether by government administration or simple mandate) and we need to restructure the delivery system in a way that creates powerful incentives for care coordination and health maintenance.
Porter suggests we have to start all these changes at the same time, because they’re self-reinforcing. And as I think about it, I have to – perhaps a bit reluctantly – agree. Anybody who has been seriously interested in healthcare reform for any amount of time has invested quite a bit of thought into “process patches” on the existing healthcare system. Personal Health Records are one such, but as promising as it is, consumer controlled healthcare information isn’t going to do more than create some small efficiencies. That may still add up to billion dollar sums, but against a $2 trillion backdrop even the odd billion doesn’t go as far as it used to. There just aren’t enough little fixes to add up to one big fix.
Since this is nominally an informatics blog, I’ll call out Porter’s very sound observation on the role of EHRs:
Sixth, electronic medical records will enable value improvement, but only if they support integrated care and outcome measurement. Simply automating current delivery practices will be a hugely expensive exercise in futility. Among our highest near-term priorities is to finalize and then continuously update health information technology (HIT) standards that include precise data definitions (for diagnoses and treatments, for example), an architecture for aggregating data for each patient over time and across providers, and protocols for seamless communication among systems.
Aggregating data across time and providers may sound scary to anyone concerned with patient privacy, and Porter doesn’t mention that part of the equation at all. If there is going to be systematic reform, the average citizen is going to wonder about its implications for medical confidentiality. One nice thing about universal coverage is that it dramatically reduces “breach consequences” for medical privacy. It doesn’t eliminate them – there will always be conditions that create social awkwardness or worse – but the big threat, loss of health coverage, no longer applies. I’m surprised that isn’t pointed out more often.
The Tories and HealthVault
The Google froth turned up an interesting op-ed from the Guardian newspaper in London. Apparently the Conservative party has started agitating for use of systems like HealthVault and Google Health to replace the large, centralized National Health Services databases. Certainly fits the small-government agenda, but as the article correctly points out there’s a lot more in a real EHR than you’re going to find in HealthVault. Patients do need their records – but so do physicians.
The Guardian: Don’t ask the public to care for its data.
To be fair, the proposal only came from a think tank, and they weren’t really focusing on healthcare per-se; they were focusing on large government programs. But still, I’ve heard the same question come up from very educated sources outside the health and health IT areas.
Introducing Clickframes!
I’m sure at least a few people have been wondering where we’ve been the last few weeks. We’ve been busy on a number of products, and we released one of them at the end of June. It’s called Clickframes, and it’s a set of frameworks for building usable, reliable, scalable software faster, better and cheaper. The original Clickframes concept was based on three observations:
- Good software requirements can be very useful.
- Most software requirements aren’t very good.
- Even when requirements are well thought out, they’re generally created in a format that limits their usefulness.
At ISG, we develop software using a design methodology that focuses on understanding user needs through interviews, observations and deep research. We learn as much about the problem space up-front, do as much work as possible to validate our designs with real users, and only then proceed with the implementation. This approach works very well for us (and the one time we allowed ourselves to be persuaded to approach a problem differently the results were a lot more typical for the industry), but it requires a lot of agility. Clickframes helps give us that agility by turning static software requirements into a dynamic specification of how the application should work.
Here’s how it works: at some point during the design process we start building an application specification (or “appspec”), which is a description of the web application we want to build. The early iterations can be very schematic – identifying a couple of pages, perhaps a form or two, and a few buttons. As we learn more about the application we can extend the appspec to include additional detail, including specific requirements, security, and flows between different pages in the application.
That’s actually all pretty standard, so here’s where things get a little different. The appspec isn’t a Microsoft Word document, or a stack of index cards, or a drawing on a wall. It’s an XML file, and it’s maintained by the application’s lead designer. By managing requirements in XML, we can generate a whole range of useful artifacts on the fly. The most important is the Clickframes Interactive Preview (click the link for a sample from our Issue Tracker demo), which provides an easy to navigate HTML representation of the application. As requirements change the CLIPs can be easily regenerated. Clickframes also provides generators for conventional requirements documents (the system shall…) and a visualization tool that generates interaction maps of the application. Here’s the Issue Tracker example, generated from the same appspec as the CLIPs linked to above:
Once the design stabilizes, we move on to implementing the software itself. Clickframes helps here too. We’ve built code generators for three different web architectures – PHP, JBoss Seam, and Spring WebFlow (the latter two, for the non-technical reader who has stuck it out this far, are Enterprise Java platforms, and the first is a very common scripting language for web applications). This is an area where conventional prototyping tools break down – they don’t provide a bridge to development. With Clickframes, the plugins give us a skeleton of the application immediately, and our developers and designers can go in and immediately start creating content and the final look and feel, rather than worrying about details like implementing edit checks on form fields. If you want to see the Clickframes Issue Tracker demo, just click on the link (to log in, enter anything for the username and password). This isn’t a complete application, by the way – it’s just the generated code, before being customized by a programmer.
We’ve spent a lot of time on the Clickframes code generators and on the architecture of the underlying applications. We’ve implemented a range of features we call “CodeSync” that allow us to regenerate applications even after the development team has started to customize them. This is critically important, because it keeps the requirements from becoming out of date. If a business user, or a a designer, wants a change made, they can have the appspec updated and the programmer can re-run the code generator. It creates a feedback loop that’s often missing.
The final step in the Clickframes project lifecyle is testing. Since we have a version of the software requirements that a computer can understand, we can use it to generate a suite of automated tests, as well as templates for test strategies and manual test scripts. It’s not magic – the quality assurance team still has to do some work, and we can’t automatically generate every single test, but we can save a tremendous amount of up-front work. And developers can have access to automated tests of the final application almost from the first day of development. It saves a tremendous amount of time.
Clickframes is software to streamline development of enterprise applications. So how much would you pay? Don’t answer, because it’s free – we’re releasing Clickframes as Open Source Software under the LGPL. You can download Preview Release 1, sign up for the mailing lists, and see some demo screencasts at www.clickframes.org, and you can find a lot of documentation on The Clickframes Wiki, including instructions on how to get started without downloading anything. The Preview Release is out there to gather feedback – we’ll be releasing new versions at a pretty rapid clip over the next two months, with a goal of 1.0 by the end of the summer. We’re also rolling out some new web site features in July that will make it easier to explore the Clickframes model.
This has been a long road for all of us – we started working on Clickframes back in May of 2008, so it’s been over a year to get to this point. So give it a try and let us know what you think!
(And if you like it, or like what we build, give us a call – we’re always looking for interesting new projects).