I am also quoted in a Forbes article about Google Health. Busy week.
Not sure why this was not formally annouced, but I was just doing some last minute fact-checking on my new health IT book, and I discovered that WorldVista EHR is a meaningful use certified product.
This is quite an accomplishment, and I am somewhat surprised that WorldVistA has not had an announcement about this. This is really important news and have broad implications. WorldVistA, unlike ClearHealth and Medsphere, is a non-profit organization.
Medsphere and ClearHealth provide only “pro” customers with the benifit of certification. How will WorldVistA handle this?
It is not clear to me if this could be the first completely available (sans proprietary ontologies of course) meaningful use certified Open Source EHR that you do not have to pay for support for. To make an analogy its like the difference between Fedora getting a certification vs RedHat Enterprise Linux getting a certification. Both are Open Source, but the latter is expensive
The other Open Source options as I understand them:
I am happy to announce that my new article on healthcare privacy and interoperability has been accepted in the Journal of Participatory Medicine.
I am not against privacy in healthcare, but I am against the notion that privacy concerns should trump issues relating to good healthcare.
You can read the full article here:
I guess this is better, though, than having Google Health shut down just -after- I finished writing my book.
Of course, I am going to have to change lots of content in the book, but Google Health will still be there.
For a project that no longer exists, it will end up being one of the most influential Health IT projects of our era. Google Health, and for that matter Google generally, has always been willing to make strong statements when they evaluate technology and technology protocols. In fact, Google has made two controversial technology picks and the opening and closing of Google Health.
At the opening Google decided that they would support CCR (Continuity of Care Record) from ASTM and AFFP rather than the much more complex CDA/CCD from HL7. The CCR vs CCD debate has been one of the most controversial and long-standing arguments in Health IT. HealthVault, the Microsoft product which survives Google Health has always elected to support both standards. But Google insisted that the CCD standard was too complex, and not only insisted on CCR, but a smaller subset of that standard.
Now, as the end support for Google Health, Google is choosing to allow export under the Direct Protocol. Again this is the simpler of the two protocols that is supported by ONC to be part of the NWHIN (the precursor to the Health Internet). The other protocol, IHE, is getting no love from Google Health.
Goodbye Google Health, whatever else I may have said about you, I must admit that you made some ballsy technical stands.
Recently, Google announce that the Google Health PHR will be retiring.
I posted the announcement to the Society for Participatory Medicine mailing list, and there has been alot of discussion about this, there. There are several issues that lots of people do not seem to understand, and some implications of this that have been missed.
Let me be perfectly clear. If you trusted Google Health with your healthcare data you are screwed, unless the Microsoft HealthVault team rescues you. Even then, you are likely screwed anyways.
The whole point of Google Health was that it was more than a mere store of your XML patient data. It was a network of providers, like pharmacies, drug companies, non-profits and countless other service providers who added value to your health record.
I love the Direct Project but it only makes health data mobile, it is another matter altogether to make your health data semantically useful again. There is no way that the HealthVault team will be able to replicate 100% of the value that Google Health was providing based merely on the XML output from Google Health. As service providers and patients themselves added to their Google Health record, it made those records more complex than HealthVault, or any other PHR system, can easily understand. This is called Lossy Data Conversion.
The patients who will lose the most useful data, are those patients who leveraged Google Health the most. The more you invested in Google Health, the more screwed you are now. Of course, the other group who is going to be really screwed are the people who do not pay attention to announcements like this at all, (and ignore or filter email warnings) who will try to find data they stored in Google Health four years from now, only to discover that the deadline for data download had passed, and their data is gone. Ironically, the people who this is most likely to happen to are older people, who are not terribly tech savvy -and- who might have stored data in Google Health precisely so that they could ensure it would be available as they aged. Again the more they invested, (seemed like a good idea at the time), the more screwed they are today. Not good.
Probably the most important lesson to take away from all of this is that trusting proprietary health software vendors or services with critical health data is a bad idea. But sadly, that will not likely be a lesson learned here.
Second, there is the implications for PHR vendors. It does not look good for you. Google is in a unique position as a company. It is capable of making money giving away very valuable services, because it makes more money on advertising when someone merely uses the site. The business plan on Google Health was, essentially
“Lets spend a few 10’s of millions on this, and then make it back because a few million people will click on ads, after leaving Google Health to do a web search of some kind.”
Your average PHR company cannot make that kind of play. Most companies do not have a way to translate mass visitors into dollars. That is what makes the gmail service work for Google. Enough people click on ads through the service to pay for the entire thing for everyone. Google specifically admitted this problem in the post above with:
But we haven’t found a way to translate that limited usage into widespread adoption in the daily health routines of millions of people. That’s why we’ve made the difficult decision to discontinue the Google Health service
So if you are trying to start a PHR business and you cannot afford to give away a product you spent millions developing for years… this spells trouble. Google Health and Microsoft Healthvault together spelled the end of the still languishing dot-com bubble PHR services. I cannot imagine an investor in their right mind who would touch this space with a business model anything like Google Health.
Here is the basic takeaway from Google Health PHR:
People are not willing to use a good stand-alone PHR, even if it is free.
That word “stand-alone” is critical.
I have been wondering, as a right this, if I should be a winner or a loser on this one. I get to say “I told you so” to everyone I warned not to invest in a proprietary platform… which is fun. But I also now have to almost entirely re-write a chapter in my new book.
I (along with intrepid David Uhlman) am writing the first book on Health IT for O’Reilly media, called “Getting to Meaningful Use and Beyond“. I wrote the chapter on patient-facing software, and I featured Google Health extensively. After all, it was relevant, last week. I felt reassured after I asked Roni Zeiger a month or two ago if Google Health would survive? After all, I had heard rumors. He told me not to listen to gossip and I left feeling like my chapter would be published intact.
So much for meeting my deadline.
As Google Health dies it is giving a ringing endorsement to the Direct Project (of which I am a contributor). Hopefully this will raise some awareness regarding Direct as the foundation for the first generation of the Health Internet.
Most of the industry pundits, like myself, have recognized for years that the “build the platform” business model that worked for Facebook and Itunes, was not going to work for Personal Health Records. Why? No “killer app”. Itunes+Ipod was the killer app for the Iphone platform, for Xbox it was the original Halo. For Facebook it was your ‘wall’, or perhaps (shudder) FarmVille.
The killer app for a PHR is dead simple: Healthcare. The two most widely used and successful PHR deployments in the country are the Kaiser Permanente and the VA’s My Healthevet. Why? You can get a message to your doctor through them, and receive replies back. They are a component of your actual healthcare. You do not have to type data into them, its just there. If you want to schedule an appointment or view your lab results you can do that. If you want to renew a prescription, the PHR can help. In short, the PHR is a workhorse in your actual healthcare process.
The Microsoft Healthvault team gets this. That is why they have been working on the Direct Project for months. They know that the Direct Project is the only way that they can have their PHR connect to -all- doctors the same way that Kaiser and the VA connect to their doctors.
Moreover, HealthVault has the only working mass-scale Direct beta in deployment: It is very likely that the only place you will be able to transfer Google Health records will be directly into HealthVault, for the foreseeable future.
HealthVault just became the 800 gorilla in the space.
My only question is why didn’t the Google leadership see the strategic significance of the Direct Project? They were obviously aware of it technically, and they usually do a good job translating technical understanding into strategic understanding.
Seems pretty simple to me. PHR usage is high -only- in systems where you can communicate with your healthcare provider in various ways. Google was disappointed by how few people were using their PHR. Direct is the only chance in hell that you have to reach every healthcare provider in the United States in the next five years. When you put it like that, Microsoft’s strategy seems pretty obvious… why didn’t the Google leadership catch on? Probably the Direct opportunity was too little too late for the internal political process at Google.
Indivo X has almost all of the same benefits as HealthVault (they are little behind on the Direct implementation and beta deployment), but if you actually want to avoid a repeat of the Google Health fiasco, this is the way to go. If you import your Google Health record into an Indivo X instance, you are not locked-in again.
Indivo X is Open Source, you can run your own instance if you want..
From now on, people will regard Indivo X as the safe option for PHR deployment, and rightly so, it is the only safe option. Until I can convince Sean and the rest of the HealthVault team to go full kimono, Indivo X is by far the most mature Open Source option available.
If Google drops code for Google Health, thats cool and I would take a look… but I am not going to hold my breath.
Its pretty simple; Indivo was Open Source and available before Google Health launched. Some people believe that Google Health, like Dossia, is actually a long-ago fork of Indivo.
Indivo has moved on to bigger and better things. Indivo X, the current version of Indivo already has substantial functionality that Google Health is missing. It is already a mature codebase, with a community, and is generally operating openly as an Open Source project should. The Indivo project is not perfect, but they have steam.
Steam, motion, community, these are the things that make the Open Source garden grow.
Google Health would not actually help the Open Source community that much. We already have a better PHR project, and anything coming out of Google would compete for developers and attention with Indivo X.
Even if they wanted to, I am not sure that Google could usefully Open Source the whole Google Health codebase. Google projects often run on Googles custom, and proprietary database and network services. It is entirely possible that Google Health would be useless without that back end.
What -would- help is for Google Health to release any components that Indivo X is missing. If they have an interesting Blue Button parser (which I happen to know they do) for instance, or some generalizable code for managing CCRs (that CCR-in-a-feed thing was a nice trick for instance…) then those components would be very useful.
Moreover, any components that would help people to parse their own Google Health data would be very welcome.
Probably the most important thing that they can do is license their API under several Open Source licenses. This way, Indivo X and HealthVault would be able to write a bridge that would allow currently existing Google partners to interface with Indivo X, without re-writing code. That would be pretty cool.
The Electronic Preventative Services Selector or ePSS from AHRQ is now available as an HTML widget that you can embed in any webpage.
Including this one!!
I am often surprised to meet people at conferences who say “I read your blog”. I mean, I know you read… because I have server logs to prove it…. but actually meeting someone kind of blows my mind.
So if you read my blog, and you enjoy it, please take a moment to read the first chapters of my book and give me some feedback on it.
I would especially like feedback on the Introduction. I was the primary author on that part (although that chapter especially had help from both co-author David Uhlman and my editor Andy Oram). Getting that chapter right is really important to me, because it is really sets the tone for the whole book. It details how Health IT is really different from normal IT.
If you are a regular reader, please, take a look.
At first blush, this news was not concerning. I am only peripherally involved in the VistA community, and there are lots of solid VistA-related contracting companies that I do not know of. It was a little surprising I must admit, I was expecting this to go to Perot Systems (now Dell), or DSS, both of which have deep VistA pedigree. My second guess would have been a big contractor like IBM or CSC.
But I have done a little analysis and now I am pretty concerned about this.
First I used Google to do a site search for the term “VistA” on the Tiag website. The syntax for that is “site:http://tiag.net VistA”
Ok, but even though there website does not list anything about VistA, maybe the leadership is invested in the VistA community. Its pretty easy to sort participation in VistA community, it all happens across the Hardhats mailing list. So I did a search on the hardhats mailing list for the proper names of each of the people listed under the Leadership Bios on the hardhats mailing list. Here is a sample for Tiag CEO Dalita Harmon. Nothing.
Ok, the Tiag leadership is not participating in the VistA development community, but perhaps they have “underling involvement”. I search on the hardhats mailing list for anything coming from tiag.net returns nothing. (it might return a thread I started about them now….)
Maybe they prefer to participate in person, attending WorldVistA meetings? Nope.
Maybe the organization is just deeply skilled in health IT. It looks like they have some military health IT experience, which is not at all the same as VA health IT. The resume of the Tiag CEO shows that she is not a computer scientist, or a self-taught developer. This is pretty important, because Tiag is registered as a small business. The CEO will probably be making significant decisions about this project, and she is not a software developer. Moreover her resume speaks to industry-hopping with “leadership experience” as the result. Given that background, there is a very real danger that she might be confident without being competent regarding VistA.
Perhaps, they have experience with Open Source? Nope.
How about experience with MUMPS? Nope.
Are these google searches working at all? Perhaps Google has not indexed tiag.net. Nope, a search for the CEOs name returns lots of pages. Including this one, which details the history and philosophy of the company, from that page:
one of our core differences is going against the industry standard of treating people like commodities. tiag hires the best talent out there and treats them like talent
This is kind of troubling, because VistA, in my experience is one of the most complex and difficult technical arenas in health IT. The system is amazing, but making VistA go is a dark art, and experience really matters here. From what I can tell, they have no VistA experience to speak of. This, and the generally buzz-word compliant and beautiful tone of the website lead to a dangerous potential conclusion: This is an organization that has expertise in writing beautiful proposals, rather than any kind of industry experience. What if this is yet another “beltway bandit” with a limited, “across the fence” understanding of the VistA community inside the VA and no concept of the VistA community outside the VA.
At this point, I am going to put out the soft feelers to the VistA community, for indications that my research is wrong. But at first blush, it appears that the VA has chosen VistA-outsiders for this role. There a several ways that this analysis could be wrong, for instance, if they had just hired George Timson, or perhaps partnered with someone like Open Health Tools, and they have not yet updated their website. So these concerns could be simply irrelevant. So first, I hope I am wrong in this analysis. Second, I can only hope that choosing a VistA-outsider was intentional on the part of the VA.
-if- it was intentional, it might not be a bad thing.
It appears, at first blush, that these guys are all going to be VistA newbies. The first thing they need to understand is that they are in fact newbies. I know a lot about Health IT, but knowing VistA… thats something else. Understanding what VistA appears to be, and understanding it at the level of a CAC or VistA programmer… thats something else entirely. It also appears that they are newbies to Open Source generally. I would have loved to see some Linux Foundation/Apache Foundation/Mozilla Foundation type credentials. I do not see that here either.
While I was initially investigating VistA, I wrote the WorldVistA wiki page “What is VistA really?“. Its a chronicle of a health IT outsider becoming a VistA insider (remember I said “insider” not “expert”). Nothing written in that article would come as a surprise to a VistA insider, but if you read it… and you are surprised by anything there, then that is a pretty good indicator that you are a VistA newbie.
Being a VistA newbie is fine, as long as you understand that you are a VistA newbie.
If this “Open Source VistA” thing is going to work, then the people leading that effort are going to have to be deeply aware of what “Open Source” and “VistA” really mean, -or- they are going to have to have a lot of humility.
In Open Source, reputation and leadership are the same thing. If Tiag is as unknown to the rest of the VistA community as they are to me, they have a long way to go. This does not mean they will do a bad job, Harris Corp was pretty inexperienced with Open Source, but they ended up doing a pretty good job on CONNECT. In the end, they earned a good reputation. I was pretty freaked out when that contract went to Open Source novices, but it turned out O.K. in the end.
Of course, Harris had a stellar technical team. They really understood what they were getting into from a technology standpoint. Does Tiag? One of the critical issues around an Open Source VistA process is that normal version control does not work on VistA. This has to do with the quasi-versioning capability of the KIDS system. Updates in VistA often come in the form of KIDS packages that inject code directly into the VistA database. That code, living in the database, and not on the filesystem, makes tracking VistA with traditional version control impossible. Can you imagine trying to create an Open Source governance structure without the presumption of an underlying version control system in place? The governance of most projects translates to “the process by which we decide who gets access to subversion/git/whatever”. This is just one example of how VistA context is going to be critical for any kind of workable governance. My proposals for VistA governance, are some of the oldest and complete writing on the subject. They date from 2008, which is something like 21 years ago in Internet years (which are, as everyone knows, roughly compatible with dog-years). So I am something of an “expert” on the subject of VistA governance.
There are three working definitions of ‘expert':
I am, at least, solidly in the first category.
If “What is VistA really?” serves as a good introduction to VistA, this post will serve as a good introduction to Open Source values. What matters in Open Source is “being right” and being right comes from evidence. The evidence in this case (a bunch of Google searches) suggests that Tiag is inexperienced and over their heads on this one. The difference between Open Source developers and other developers is that we talk openly about these types of issues, and criticism, when backed by evidence, needs rebutting. Participating in community discussion and responding to community criticism is what “participating” in Open Source community means. We have lots of heated arguments, and its never personal. Its always about what the right thing is for the sake of the project in question. If Tiag thinks this post is critical, they are in for a whirlwind.
At this point I am pretty nervous. The future of VistA depends greatly on Tiag not screwing this up, and I see no evidence that they have any experience in Open Source, licensing, governance or VistA and its unique development process. There are thousand ways to make a train-wreck here and only a few ways to do this right.
I will try an update this article with more information regarding Tiag’s qualifications.
I really hope Tiag has what it takes.
Once a persons record has gone electronic, it really should never go back.
A paper printout of an Electronic Health Record is often huge and unwieldy. If it is printed out or faxed it creates something so huge that it is pretty impossible to be useful in a paper record.
This is the reason why need electronic interoperability solutions like the Direct Project. Without it, when a patient leaves one doctor, they have to print out an electronic record, take it to the next doctor, and then have that doctor scan the record in.
That doesn’t sound too bad until you realize that a patients printed EHR record often looks like this:
This image was provided to me by Jodi Sperber and Dr. Eliza Shulman, who generously agreed to share the photo under a Creative Commons license. Here is the full description from Flickr, which provides greater context.
An example of why interoperability is as important as the electronic health record itself.
The story behind this photo: This is a printout of a patient’s medical record, sent from one office to another as the patient was changing primary care providers. An EHR was in place in both offices. Additionally, the EHR in both offices was created by the same vendor (a major vendor); each health organization had a customized version. Without base standards the systems are incompatible. Instead, the printouts had to be scanned into the new record, making them less searchable and less useful.
Note that this was not the entirety of the patient’s medical record… Just the first batch received.
I have been on a quest to be a able to spray-paint QR codes, in mass production. I recently demoed my QR code stencil work at Maker Faire.
The secret, in short, is chicken wire and caulk.
I tried the following methods unsuccessfully:
The first thing that I got working is using very small chicken wire, and using caulk to bridge the gaps between the parts of the wire required to block the spray. This seems to work. A picture, as they say, is worth a thousand words.
Pretty simple see! Now, once you have created that stencil, you can use black spray paint to create a readable QR code on anything you -own-
Tips for creating the stencil:
Suppose you do not own the thing in question. There is still hope. To create somewhat more legal QR code graffiti, you can create a reverse stencil (i.e. instead of putting caulk to block black spray paint, you use a negative stencil to block white spray paint). Then you can use white chalk spray paint against a dark surface. Remember that the QR code standard requires a “field of white” around the QR code, so using a reverse stencil you have to be careful to spray generously around the QR code too.
While at Maker Faire, I bought a hoodie and used this method to spray paint chalk on it. You can see the results below.. it still scans!!
For those who prefer to watch the action first hand…
Here is a video of how the reverse chalk spray works on asphalt
Here is a video I made b/c I was losing my voice that basically shows what I was doing with QR codes at Maker Faire.