Incentive to Innovate: Giving Health Reform a Rocket Boost

I am participating in the health X-Prize blog rally. If the post below sounds a little reptitive, it is only because you might have read a version of it on several other sites.

-FT

We are entering an unprecedented season of change for the United States health care system. Americans are united by their desire to fundamentally reform our current system into one that delivers on the promise of freedom, equity, and best outcomes for best value. In this season of reform, we will see all kinds of ideas presented from all across the political spectrum. Many of these ideas will be prescriptive, and don’t harness the power of innovation to create the dramatic breakthroughs required to create a next generation health system.

We believe there is a better way.

This belief is founded in the idea that aligned incentives can be a powerful way to spur innovation and seek breakthrough ideas from the most unlikely sources. Many of the reform ideas being put forward may not include some of the best thinking, the collective experience, and the most meaningful ways to truly implement change. To address this issue, the X PRIZE Foundation, along with WellPoint Inc and WellPoint Foundation as sponsor, has introduced a $10MM prize for health care innovators to implement a new model of health. The focus of the prize is to increase health care value by 50% in a 10,000 person community over a three year period.

The Healthcare X PRIZE team has released an Initial Prize Design and is actively seeking public comment. We are hoping, and encouraging everyone at every opportunity, to engage in this effort to help design a system of care that can produce dramatic breakthroughs at both an individual vitality and community health level.

Here is your opportunity to contribute:

  1. Download the Initial Prize Design
  2. Share you comments regarding the prize concept, the measurement framework, and the likelihood of this prize to impact health and health care reform.
  3. Share the Initial Prize Design document with as many of your health, innovation, design, technology, academic, business, political, and patient friends as you can to provide an opportunity for their participation

We hope this blog rally amplifyies our efforts to solicit feedback from every source possible as we understand that innovation does not always have a corporate address. We hope your engagement starts a viral movement of interest driven by individual people who realize their voice can and must be included. Let’s ensure that all of us – and the people we love – can have a health system that aligns health finance, care delivery, and individual incentives in a way that optimizes individual vitality and community health. Together, we can ensure the best ideas are able to come forward in a transparent competition designed to accelerate health innovation. We look forward to your participation.

This post was written by Scott Shreeve, MD in behalf of the X PRIZE Foundation. Special thanks to Paul Levy for both demonstrating the value of collaborative effort and suggesting we utilize a blog rally for this crowdsourcing effort.

Can somebody look at Medscribbler

Hi,

A few days ago, medscribbler decided to do an Open Source release. The release appears legit. They have the sourcecode available from the sourceforge medscribbler svn repository. The license is clearly labeled as GPL v3.

Sadly, I do not have the time to download this and see if it is worthwhile. However, theoretically, it should be a tablet-oriented EHR interface system that could be quite valuable code.

Not so found of the .NET server, but the tablet-side code could be important.

Can somebody download this and do a write-up? Let me know.

-FT

A geek in the ER

Recently someone turned me on to a post by data expert Joe Bugajski entitled the Data Model that Nearly Killed Me.

The article is marvelously written, and meticiously detailed. He actually has a chart where he chronicals his pain level, repeated histories, medications and location.

I am always impressed by the level of analysis that the average geek can bring to a healthcare IT situation.

The problem is that while Joe is familiar with Data Models, he is not familiar with Healthcare IT. I can tell you that none of his recommendations are actually practical. Mostly because they are top-down oriented, which is the right way to view a data model, but the wrong way to think about Health IT.

Joe has not yet familiar with the under-water portion of the iceburg that he has run into. I have been trying to fix the problems he is experiencing for years and I can assure you, they are much harder than even he thinks. However, most of the problems are not technical, but political in nature.

Joes take makes a good read.

-FT

MUMPS is modern

NextGov has an article that implies that the VA and DOD should compile MUMPS code to Java code.

Before we get into this discussion I would like to point out the fundamental flaw with implying that MUMPS is not a modern system. People who say things like this are usually ignorant, arrogant, biased or a healthy mix of all three. MUMPS engines have evolved and improved just like other systems that were developed in the same time frame. No one would consider calling C, (which powers the iPhone as Objective C) SQL, (which underlies ORACLE, and MySQL) or Unix (which is the design paradigm for Linux) antiquated. Unless you can detail exactly what ‘modern things’ MUMPS cannot do you have no business calling it old or implying that it is not modern.

Doing so merely serves to show that you are purveyor of second-hand technical knowledge. If you do not like MUMPS and have some legitimate reasons to avoid it, please take a page from David Uhlmans playbook:

I do not in any way want to offer
a general commentary on why some people want to use MUMPS or don’t
want to, or X language is better than Y, I am not looking to instigate
a flame war or really say that what we are doing is a better or worse
approach from a technical standpoint than anything else. It is the
right approach for us.

There are good reasons to get away from MUMPS, and there are good reasons to stay with MUMPS. Please do not use propaganda to make it seem like it is obvious in either direction.

Now… on to the idea of compiling MUMPS:

That is a seriously problematic idea. But it is hardly original at this stage. This is similar to the strategy that ClearHealth Inc. is following with WebVistA. ClearHealth has described the WebVistA technology strategy here and discussed it briefly on Hardhats. However, the basic strategy that I have taken away from talking directly to David Uhlman is that they compile MUMPS to C code, and then the C code to PHP modules, which they then use to build a web interface to VistA.

This much better than the idea of compiling to Java, because:

  • It works now. Not after 2 years and millions of dollars.
  • It jumps all the way to a web-environment.

But there is one basic problems with any ‘compile MUMPS’ technical strategy.

It is not clear where or how you edit the code.

If you edit in MUMPS then, you are not really getting away from MUMPS at all. Further the compile times for ‘all of VistA’  take days or weeks. That does not work for the write, compile, test, debug, write… software development method. But the C code that results is essentially just a pre-cursor to machine code. You might as well just modify the assembly code directly. You cannot really edit at the PHP level, because you are dealing with binaries at that point. But it is even more problematic that you could code modifications in MUMPS -and- C, but what would that mean? In short, this seems like a recipe for unmaintainable code.

Be assured, ‘migrating’ or ‘converting’ from MUMPS to anything will result in a lose of meaning. The Java compile methods that are mentioned in the NextGov article are just as problematic as the ones ClearHealth is using with WebVistA, and for the same reasons.

This does not mean that the compilation method will not work. But it does mean that we should be dubious about any strategy that suggests this method until they have been proven to work. At least David Uhlman is basically saying, ‘hey look, this seems to be working for me, let me get the kinks out and I will show you’, rather than the arrogant position of: MUMPS is not modern, I have done this in the lab, please give me many millions of dollars and several years and I will be able to change this all to unreadable and unmaintanable Java. Please. It is hard to imagine how little I think of this idea. If this happens to be an idea that you support…. I hereby fart in your general direction.

-FT

CCHIT Feature bucket

A central problem with CCHIT is the feature bucket.

CCHIT certification represents compliance with a list of hundreds of functional requirements. This would be great if that list of features were 100% a good idea, but the reality is far from the truth. From the FOSS perspective we feel that there is a considerable dumbing-down effect that the certification brings. It prevents us from maintaining meritocracy.

I want to focus on one CCHIT issue that serves to illustrate this issue: Passwords.

Here is item SC 03.10

When passwords are used, the system shall support case-sensitive passwords that contain typeable alpha-numeric characters in support of ISO-646/ECMA-6 (aka US ASCII).

The problem, VistA supports three user ids, one that is equivalent to a username, and two that are similar to passwords. Without getting over my head on the details, there are two possible password types so that you can have one that your admin user can know and reset for you, and one that no one knows but you. There are all kind of administrator abuse scenarios that this addresses, but the VistA username/password/password system is not certifiable out of the box because it does not support case sensitivity. Which, as you can see, is a requirement. Most people are only aware of the CPRS client for VA VistA but in reality there are several clients, all of which support the username/password/password mechanism.

So when any VistA-based EHR goes and gets CCHIT certified it has to make the password system -act- dumber (in compliance with SC 03.09), and add case sensitivity.

Then lets look at the ClearHealth Inc. projects opinion on the value of hashing passwords. They believe, essentially that it give a false sense of security and an admin overhead that should be avoided. I disagree with them, but I can see where they are coming from. This however is in contradiction with the following rule: SC 03.11

When passwords are used, the system shall use either  standards-based encryption, e.g., 3DES, AES, or standards-based hashing, e.g., SHA1 to store or transport passwords.

So one simple issue, we have considerable debate in FOSS systems about whether this is actually the right design at all. But CCHIT takes the position that their way is the ‘right’ way and will not certify a system designed in a different way.

I hope that this is helpful in understanding why the ‘feature bucket’ is a problem for FOSS. It is directly contradictory to the notion of meritocracy that rules our culture. The -best- ideas win, not the ideas that come from a vote of the committee.

What we need from CCHIT is to identify the boundaries of an EHR system, not the contents. This is an idea that I have heard so many times and from so many different people, the only thing I can be sure of is that it is not mine:

There are three obvious edges to an EHR system:

  • The ability to report on quality metrics
  • The ability to interoperate with other HIT systems
  • The ability to monitor and track access (security)

There are published standards available for all of these that can be tested in an automated way. That defines what an EHR needs to be able to show the world, but not define -how- it needs to provide those services. Frankly, if a system is capable of improving the quality of the delivery of healthcare, sharing its data, and can limit access to private data, the implementation details are not as important.

While those details are still important and should still be subject to scrutiny and respect the freedom of users, they can become the subject of debate of people like me who obsess about these kinds of issues.

What are the advantages of this model?

  • We do not need expensive juries, instead we can fully automate testing and make the certification cheaper for everyone.
  • We allow for freedom to implement ideas differently as long as the results are the same.
  • It is not biases against FOSS, proprietary or (for that matter) paper or other low-tech systems.

Just some thoughts.

Towards fair EHR certification

The meeting with CCHIT worked. The FOSS community, to the degree that such a thing is possible, had authorized me to go nuclear on the issue before the meeting. I had been given assurance that the community has been so frustrated with dealing with CCHIT that if they did not work with us that if I started an alternative certification program that I would be backed up with the dollars and brains from the community needed to make an alternative certification go.

At this time it appears that such dramatic actions will be unnecessary. Mark Leavitt and Dennis Wilson were willing to consider the profound practical and cultural implications of the ‘rules’ of the FOSS. These implications are difficult enough for FOSS insiders like me to fully grasp that I realized during the meeting that there is still work for me to do make these problems accessible.

CCHIT has recorded the talk and published it here on their website. I have converted the file to an ogg, for those who care about patent issues in audio files. Contact me if you would like a copy. (its too big to host from this server)

So let’s take a 10,000 foot view of FOSS + Health IT + Certification of any kind.

The first thing to understand is that ‘ownership’ of FOSS projects is spread across all of the users and developers of a FOSS system. The true owner of the copyright involved is usually irrelevant and often impossible to calculate. ClearHealth for instance is a high level LAMP (Linux Apache MySQL PHP) application. Besides needing the considerable portions of LAMP, ClearHealth also makes use of tens or hundreds of sub-projects like smarty, phpgacl, scriptalicious, and adodb.

More importantly ClearHealth contains contributions from probably hundreds of people who have contributed bug fixes, clinical templates or modules. In the case of ClearHealth one company, which wisely has chosen the same name as the project, produces 99% of the core. While ClearHealth Inc. produces the vast majority of the code, there are several other companies, (including my own <- shameless plug) that support the same codebase.

It is not really possible to determine in any consistent way who is responsible for a codebase. Often ClearHealth Inc. employees will take code that I and others contribute on the forums and copy into the code repository in such a way that it appears that a ClearHealth developer wrote the code. The contributors do not care and ClearHealth Inc. does not care. My contributions are meaningless outside of what the ClearHealth Inc. team has given to me, and the license requires that my contribution falls under the GPL. There is no way to determine who truly responsible for a codebase, only to make good guesses.

Under the current certification model I could wait for ClearHealth Inc. to figure out how to pass the current CCHIT tests, and then republish the changes to the current ClearHealth codebase required to pass CCHIT. ThenI could apply for CCHIT certification with my friendly fork of ClearHealth. The real cost of doing the certification is the preparation, which is essentially an annual cost (You do not have to do it annually, but your are at a competitive disadvantage if you do not) of about 300k and which will probably be going up.

So I would be getting a certification for about 1/10th the price that ClearHealth pays.

The problem that is that while we collaborate extensively, ClearHealth Inc. and I still compete for customers. If I can offer support for my certified, re-branded version of ClearHealth without participating in the practical price of certification I would be able consistently undercut the support rates of ClearHealth Inc. This represents a disincentive for ClearHealth Inc. to pursue CCHIT certification.

Now consider the OpenEMR project. This project is made up of about 10 major contributors who all share the development duties. There is no single benevolent dictator and there are several companies with developer commit access. Like WorldVista there is a central non-profit that serves as a focal point for community issues for that project. Both of these non-profits will have trouble coming up with 200k a year for continued re-certification and no participating company is large enough to easily take that role.

The lesson here is that in the FOSS community everyone benefits from good code, not just the original developers. If the ‘Tax’ of certification falls to any one party in the community usually it becomes too great a burden for that party.

Practically, it is also impossible to allow a costless download of a CCHIT certified open source EHR. CCHIT requires CPT codes, (which it should not) and CPT codes are owned by the AMA. It is not possible to distribute CPT codes for no cost without violating AMA copyright.

Take away lessons:

  • Under the current model it is difficult to have the cost and benefit of the certification evenly distributed.
  • There is no way to easily ‘share’ the certification
  • There is no maintainable benefit to being the organization that sacrifices to get a certification for a particular FOSS codebase.
  • It is not possible to prevent other organizations to certify a system that has already been certified.
  • proprietary ontologies, like CPT, are a problem for the distribution of FOSS EHR systems.

Most of these issues were brought up in the meeting, and CCHIT is listening to everyone. I just wanted to put down these issues all in one place for reference. Feel free to comment on this post with other issues that you feel are central to the problem with certifying FOSS EHR projects.

-FT

Medsphere bus

This is simply the -best- publicity stunt that any FOSS EHR vendor has done yet.

Last year Cerner decided not to return to the HIMSS show-room floor. Instead they decided to subversively bring in thier massive traveling booth. This is a converted semi truck that obviously cost a small fortune. It is obvious that the pricetag on this thing has got to be into the hundreds of thousands, if not millions. Anyone who has been to the showroom floor at HIMSS can quickly recognize that this is merely another chapter in the book of excess that is the proprietary EHR vendor community. This kind of spending speaks to one thing: massive profit margins sustained by vendor lock-in.

Medsphere heard about this, and decided to pull a little stunt. They found an old VW bus and turned into a symbol of their company and to a great extent our community as a whole! They spent a modest sum refurbishing their bus, which was already a symbol of everyman freedom! Then they drove it to HIMSS and tried to find a place that they could show thier bus next to the Cerner bus.

The pictures that result are a fitting visual analogy between the basic mindset and philosophy of the FOSS commercial EHR community and the proprietary EHR vendors.

Enough preface… have a look!!

A lesson in visual philosophy
A lesson in visual philosophy

CCHIT vs FOSS pre-meeting issues

I am preparing for the meeting tomorrow with CCHIT and FOSS. I had previously used Google Moderator to get a feel for what my communities position on this issue is. Moderator allows for the same question to get posted again and again, so often the same idea was represented twice. So ignoring duplicates and ideas that got less than 12 votes (arbitrary), here are the positions that garnered the most support:

“To avoid data lock-in (FOSS or proprietary) CCHIT should provide a focus on interoperability.”
Tim Cook, Brazil/US

“CCHIT should drastically lower the costs for the certification of FOSS Health IT systems in recognition of their status as a public good.”
Fred Trotter, Houston

“CCHIT must find a way to protect the interests of the “original developer”. If an individual contributes/creates a FOSS EHR, and then a second party gets that codebase CCHIT certified, under the current system, only the second party benefits.”
Fred Trotter, Houston

“CCHIT should certify FOSS projects. Multiple companies could pool resources for certification purposes, and all the users of the project would benefit from the certified status, as long as they used the tested codebase.”
Fred Trotter, Houston

“CCHIT should move towards higher level certification mechanisms that do not focus on black-box certification.”
Fred Trotter, Houston

“FOSS licenses provide a “right to modify” to the end user. This is fundamentally incompatible with the idea that a certain codebase is “certified” in the way that CCHIT currently understands it.”
Fred Trotter, Houston

“Create a separate-but-equal CCHIT certification for FOSS Health IT software. It should be much cheaper and recognize the differences in the FOSS model. It should be much less expensive.”
Fred Trotter, Houston

“CCHIT charges should be based on an ability to pay. Smaller companies &/or community projects (i.e OS) should not disadvantaged and innovation should not be discouraged because of cost.”
Tim Elwell, New York

“Under the current model, CCHIT certification cannot jump vendors, so if a FOSS EHR user uses the “right to fire” implied in a FOSS license, they would lose CCHIT certification during that process. Thus certification is currently a lock-in mechanism.”
Fred Trotter, Houston

“CCHIT should re-publish the software licenses of the CCHIT software. Proprietary or otherwise. Further, the practice of removing bankrupt EHR companies from the list must be halted, they should be listed with a license status of defunct.”
Fred Trotter, Houston

“CCHIT should certify application modules. If it can be proven that the certified module’s software code base has not changed, others may incorporate the certified component in their application – license permitting – without recertification.”
Tim Elwell, New York

“CCHIT should consider releasing the certification criteria themselves under Creative Commons or GNU Documentation license. This would allow the FOSS community to develop our own certification methods and systems based on CCHIT standards”
Fred Trotter, Houston

“CCHIT should allow for automated testing of FOSS codebases. For instance a mechanism to prevent the re-testing of FOSS EHRs whose sourcecode had not changed, when the relevant criteria had not changed.”
Fred Trotter, Houston

“Successful FOSS projects share revenue with 3rd party companies who resell the software More companies make for a better supported and longer lasting product. CCHIT should charge each a smaller % of cert fees to support this business model.”
Greg Caulton , Boston

HIMSS09 day 2: Interview with Vish Sankaran

Today I meet with Vish Sankaran, whose official title is ‘Program Director Federal Health Architecture’ from what I can tell, that post is just as important as it sounds. Vish was, along with representatives of several major federal agencies, presenting the new NHIN open source infrastructure project called Connect. We have been waiting patiently to see code drop, and according to Vish, that should happen at connectopensource.org tomorrow!

I first heard about this project when Harris Corporation announced that they had won the NHIN contract. Harris is a big government contract shop and had apparently little experience with either FOSS or Health IT. I was please to be later proven wrong when they found that they did have considerable VistA talent on-board.

I was befuddled about how a company could announce that a product would be both public domain AND open source, seeing as how those terms have very different meanings. After my initial contact with them, it was obvious that they did not really understand the FOSS culture or community, (they actually asked a FOSS development group to sign an NDA to reveal more details of the project) and after hearing my less-than-flattering comments regarding their announcement, they made it clear that they would simply put their heads down and code until they had a product… then they would let the Office of National Coordinator sort out how to interface with the community.

I am not sure when or how Sun became involved in the project. But I was relieved to hear it. Sun has much more experience with the FOSS community, and from what I can tell Sun has bet the farm on FOSS. I have already had a conversation with some representatives from the Sun team about the release, but they were necessarily tight lipped about important details like licensing and project structure ahead of the official announcement. I hope to arrange a podcast with them soon, now that they can speak more freely.

Which brings us to today. Today Vish and his panel were discussing what they had working and what they had planned with regards to both the NHIN and Connect projects. More importantly, Vish was willing to do a brief podcast with me. My audio seemed pretty broken up… but keep listening because he sounds fine.

Vish Sankaran Interview (in ogg)

Vish Sankaran Interview (in mp3)

P.S. I am not the first person to record Vish