Embracing the new CCHIT certifications

A few months ago, CCHIT suffered from what I like to call “angry letter round 1”.

This is were I send a very pointed, ultimatum letter to an organization of the general form “your are hurting my community, stop it or else”. Personally I find that about %50 of organizations respond positively and about %50 do not.

I am happy to say that Mark, Dennis and the other members of the CCHIT team have won my respect and appreciation with how they have taken a 90 degree turn from being an organization that was largely ignorant regarding the health FOSS movement to one that listened and engaged carefully, and has now come back with a plan for certification that I personally, and from what I can tell the FOSS community generally, can embrace.

This post is me doing that. At this stage I am comfortable recommending (to whoever is making the decision) that CCHIT be allowed to be one organization allowed to certify for ARRA funding, under their new EHR-C/EHR-M/EHR-S certification model.

Specifically, I am talking about the new site level certification program. Here is a cut and paste from the CCHIT townhall pdf regarding EHR-S site certification.

Certification Program Concepts for EHR Sites (EHR-S)

  • Definition: Certified EHR-S sites have developed or assembled EHR technologies that comply with Federal standards and enable them to meet all Meaningful Use Objectives.
  • Provider applicability: Any physician office, clinic, hospital, other facility or network that has self-developed or assembled an EHR from various sources and wishes to apply to ARRA incentives.
  • Certification requirements: Functionality available (regardless of deployment model) that enables providers to comply with applicable Federal standards, implement adequate security practices, and meet Meaningful Use Objectives.
  • Inspection methods: Virtual Site Visit technology with offline inspector review and follow-up correspondence.
  • Cost range: ~$150 – 300 per licensed provider (ambulatory); hospital pricing model TBD. Scholarships for eligible providers (FQHC, underserved population, critical access, etc) if grants can be obtained.

This along with the fact that all of the new certification programs will not require re-certification for minor software revisions, means that there is a clear path for FOSS adoption along with ARRA funding assuming CCHIT certification is endorsed.

Of course, as Dr. Billings points out, there are a lot of details to work out. However, unlike other critics of CCHIT, I have never felt CCHIT to  be duplicitous, rather they were one of the many groups who were trapped in a way of thinking that I disagree with.  Now that CCHIT understands how our community frames the EHR problem, they have done a good job creating a certification that can work for us.

This is a huge relief. I was afraid that our small community 501c3 Liberty Health Software Foundation, (LibertyHSF)was going to need to learn how to certify, create a standard to certify against and then get ourselves approved by the ARRA powers before the end of the year. Not good.

I would like to thank the FOSS community members who helped make this possible, especially Dennis Wilson, who served as a bridge between us and CCHIT. Thanks to Mark and everyone else at CCHIT who made such drastic rethinking of your core business in such a short time, we appreciate it!

I am now serving in the role as the director of LibertyHSF, and I need to start being careful to note that this is my personal opinion, and not the official opinion of LibertyHSF. I think LibertyHSF will probably have the same position, but I need to have a community vote on that before we will put something up on libertyhsf.org. That process takes a little more time to arrange. Still I personally have been one of the most vocal critics of CCHIT on this blog and I thought it appropriate to note that I approve of CCHIT’s most recent actions. (UPDATE 7-13-09 CCHIT has blogged about this post)

Regards,

-FT

Can CCHIT move beyond PROBLEM EHR certification?

Recently CCHIT has come under fire for being too focused on large proprietary vendors and specifically, its association with HIMSS.

These attacks have gotten so bad that Mark Leavitt has posted a rebuttal, which has generated a tremendous amount of attention over at THCB ( a blog well worth adding to your RSS feed)

Mark raises several good points in defence of his organization, including:

  • There is currently no financial relationship between HIMSS and CCHIT
  • Vendors who are involved at CCHIT are limited in what seats that can hold and what votes they can make
  • CCHIT takes great pains to ensure that it is not biased by vendor ties.
  • There is a strict conflict of interest policy in place

Mark is right to point these out, but this misses the heart of the criticisms coming from FOSS and other places.

The problem is not that there ‘sneaky’ influences from HIMSS and Vendors, but rather a simple self-selection bias.

CCHIT is and always has been a monolithic check-list for a Proprietary, Rigid, Overweight, Bloated, Loaded, Expensive, and Massive  (or PROBLEM for short) EHR products that allowed out-patient doctors to effectively track and monitor the healthcare of their patients. Most of the ‘founding fathers’ of CCHIT were either vendors with a PROBLEM EHRs or EHR users who had already bought in to the PROBLEM EHR model.

The CCHIT process -is- open to all, it -is- democratic and it does seek to balance the interests of vendor and non-vendor participants. Everything Mark is claiming is right on and it does not matter at all. The participants in CCHIT have all bought into the PROBLEM model. Those of us who have always thought differently than CCHIT have stayed away because it was obvious from the get-go that the certification model put forward by CCHIT was incompatible with our goals.

Right now, CCHIT is taking it from all sides because there are so many people who disagree with some aspect of the PROBLEM model. Practice Fusion wants to see really cheap EHR services like the one that they offer be certified. The ‘Clinical Groupware‘ people want to see the certification of a suite of technologies that may or may not add up to a traditional EHR. The EMR-lite people want to see faster and lighter tools. The PHR people and consumer advocates want EHR systems that empower the patient instead of the provider. The Health 2.0 people want to see completely different models of finance and care become possible. Of course, the FOSS people (like me) want FOSS EHRs to get equal footing.

In defense of CCHIT, Mark and the other members of CCHIT that I have met have bent over backwards to try and see things from the FOSS perspective. They have truly listened and they are starting to understand how different our community really is. I would encourage the members of the other communities to consider working with CCHIT before discounting them. CCHIT needs to be given the opportunity to re-invent itself before it is discounted. The recent press release from CCHIT indicates that it will be establishing town hall meetings for the FOSS community. I am not confident that this will work, but it is an indication that CCHIT is willing to try and see things from a different vantage point.

However, it may be difficult for CCHIT to reinvent itself. Realistically, the PROBLEM EHR vendors and users do not want to see CCHIT supporting very different models then their own. If CCHIT appeases the crazies like me too much, it stands to loose its ‘base’. This is why I believe it is critical that ONC leave the door open to sources of certification other than CCHIT. Doing so keeps the pressure on CCHIT to broaden its certification systems to include very different philophies of Health IT. Without that extra pressure, there is no way for CCHIT to act in a way that is not in the direct interests of its current PROBLEM membership.

-FT

(update 6-03-09 Dr. Kibbe pointed out to me that the proper term was ‘clinical groupware’ and not health groupware. He also pointed me to an excellent post by Adam Bosworth defending exactly that perspective, so I linked it in. Also correct some spelling errors)

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