Why so many non-profits?

When I get a good question from a conference or email, I like to answer it in a blog post so that I can just link it in when others ask me the same thing in the future.

One of the good questions I got was:

Why are there so many “Open Source Health Care” non-profits, yet few seem to have much activity?  I see OpenVista, OpenHealthTools, WorldVista, and yours (Liberty Health) just to name a few.  Just to ask the awkward question, are the differences between them worth it?  What Apache and Mozilla prove is that there is power in scale even in non-profits – to be able to talk as one really helped people figure out who to pay attention to. We wouldn’t have really been able to negotiate with Sun over the open sourcing of Java, for example, if we were speaking as a bunch of separate orgs.  Thoughts?

So here is the downlow on the organizations issue.

There is no OpenVistA non-profit (that I know of) but if there is one, it would be exclusively focused on the Medsphere version of VistA called OpenVistA. In fact there are several projects that have non-profits focused exclusively on that particular project. FreeMED and OpenEMR (oemr.org) both have their own foundations. WorldVistA also has a project, called WorldVistA EHR, but its mission is more generally supportive of different versions of VistA. WorldVistA balances between being both a single project and focused on supporting VistA generally as a meta-project organization. With that said, WorldVistA is exclusively focused on VistA, it certainly cares about certain other projects, like Mirth, but only because Mirth can be used to make VistA better. Probably the most successful accomplishment of WorldVistA is that they were the first FOSS licensed project to achieve CCHIT certification and they have regular, well-attended meetings that have good attendance from almost all of the VistA community. In terms of numbers of bodies in the real-world, WorldVistA has the largest and most active community.

There is also an group representing the VistA vendors called the VistA Software Alliance. The are not formally associated with WorldVistA and also support VistA vendors who choose to make VistA into a proprietary product (DSS, for instance, still does this in some cases). So there are organization who support VistA without explicitly endorsing Open Source or Freedom.

Open Health Tools is another story altogether, it historically, has been focused on interoperability tools: from its FAQ

….to create a common health interoperability framework, exemplary tools and reference applications to support health information interoperability.

Given this it came as a surprise that Open Health Tools worked with DSS on the release of portions of vxVistA under the EPL. While that release was significant, bringing the number of major rollups of VistA at the time to 3 (now there are 4), Open Health Tools counseled DSS into using the EPL, which is relatively unpopular with the VistA community, which have generally settled on the FSF licenses (all three of the other rollups use a GPL variant). If Open Health Tools had used the LGPL, or even Apache which strives for GPL compatibility, it might have been possible to have cross pollination between all of the major development instances of VistA. So there is a small licensing debate that is going on between the traditional VistA crowd and the Open Health Tools (there some are indications that this might be resolved soon)

In any case, Open Health Tools is designed to be a Forge site, attracting developers and providing collaboration facilities for several major projects at once. It has major industry backing and is an important force in our community. If you want to see where Open Health Tools shine, you should attend a connectathon, where many vendors, including proprietary ones, use OHT toolkits to achieve phenomenal scores. If connectathon was a competition, OHT would be winning, by a large margin. Although DSS has gotten lots of attention as an OHT contributor, the most significant contributor is actually Misys Open Source Solutions (MOSS). MOSS uses the OHT forge for development and is releasing their considerable tool set through OHT. Laika (the CCHIT interoperability compliance tool) uses OHT hosted MOSS components in its tool chain. Even if CCHIT is not chosen as the certifying body for ARRA, Laika will likely form the basis of interoperability testing in the US for the foreseeable future.

Probably one of the oldest organizations in the FOSS healthcare space is OSCHA (as of the writing, the website looks down) . OSCHA was active about a decade ago and then went dormant. It was rehabilitated by an international group and has now started having conferences again. This group has largely been tainted by the relelation that the project pushed by the founding president of OSCHA was not actually available to anyone under a FOSS license. The current OSCHA organization might be rehabilitated and the international focus of the new group is admirable, but for now the organizations future is in question. (OSCHA section added July 10 2009 in reponse to a comment)

Finally, Liberty Health Software Foundation, which I helped start and which I am currently serving as the director of, is devoted to the general advancement of FOSS in healthcare. Personally I view the organization as a kind of cleanup organization, taking those roles that require a non-profit, but that have and cannot be addressed by other non-profits. Here are several points of our strategy that set us apart.

  • We are project neutral, VistA is important but there are many other solid EHR projects out there that deserve support.
  • We are license neutral. We will support any FOSS license, and generally want to avoid getting into the ‘Free’ vs. ‘Open Source’ licensing debate.
  • We are not concerned with the ‘category’ of software, but rather its relevance. If something does not fit neatly into the current terminology of EHR, PHR, Integration and other, we will still happily work to advance the project if it might make an impact.
  • We will try to focus our development on: the boring (like documentation) that for-profit companies view as a last-priority, and development that could spawn new development. We will not be a Forge project, instead relying on other projects (like Open Health Tools) to provide a collaboration platforms.
  • We will be supporting smaller projects by providing them space at conferences.
  • We will be promoting FOSS conferences, like SCALE, and creating our own, like FOSShealth.
  • We will do -very- limited lobbying in support of FOSS.
  • We will provide an industry trade group made up of FOSS vendors, hybrid vendors, and proprietary-but-FOSS-friendly vendors.
  • Where possible to promote obviously legitimate projects as alternatives to proprietary systems, to whoever will listen.

Obviously Liberty has lots of overlap with the other meta-project groups like WorldVista and Open Health Tools especially, but we are the first organization designed intentionally to embrace everyone in the Healthcare FOSS community. I hope that by creating a central organization, that seeks support not from companies like Oracle and Microsoft, but by companies like Mirth, ClearHealth, Misys, Medsphere, DSS and Akaza Research (not a comprehensive list by any means). Companies that obviously have a significant financial interest in our movement as a whole succeeding. Also we want support from the project or multi-project specific non-profits like Open Health Tools, WorldVistA and the OpenEMR Foundation.

It is worth noting that our community is simply never going to organize itself exactly the same as the wider FOSS movement. Liberty will typically be taking roles that normally, OSI, EFF or FSF might fill in the broader space. Open Health Tools will typically be operating more like the Apache, Eclipse or Mozilla foundations with a specific development focus. However, I hope and expect that we will get frequent role reversals and overlap. Why? Because we are still a very very small community in terms of devoted developers. I would expect that there are less than 1000 people who are devoted to developing FOSS licensed healthcare applications full time. There is way more activating, advocating and forging to get done than any organization could accomplish. Unless Liberty, WorldVistA and Open Health Tools each continue to fulfill their ‘part’, we are in trouble! It would take years for another non-profit to step in the gap left by any of these three meta-project organizations.

So, for today, that is how the non-profit space in FOSS healthcare breaks down.

HTH

-FT

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

Hack the Road

If you have not heard of Paul Levy yet, then you are obviously new to the world of Health IT blogging. This is a CEO of a major Boston hospital that has commited to blog about his day to day dealings as the top administrator of a hospital. I have already gained many fundamental insights from reading his regular blog. He also sometimes blogs at THCB, which I follow.

Recently, he blogged about something off-topic for his typical subject. He blogged about infrastructure, specifically his efforts to get a road fixed. Here is the original post, but I am borrowing the relevant parts here.

A faculty member had complained to him that a bridge she used to get to work was covered in potholes:

Actually, I knew that I could do nothing, at least within a normal human lifespan. That bridge is a jurisdictional nightmare. It is at the border of two municipalities (Boston and Brookline), spans a transit line (MBTA), and also goes over a state park (owned at that time by the Metropolitan District Commission). Just figuring out who would be responsible for the road paving would take decades, much less getting the right person to order a repair.

So, I called Rick Shea, who was the President of MASCO, our non-profit planning and service entity for the schools and hospitals in the Longwood Area. The next day, Connie called to thank me for getting the potholes filled and a new, smooth surface on the bridge. “My pleasure,” I replied, wondering what happened.

I called Rick and he said, “I knew it would be impossible to find someone of authority to make this repair, so I just hired an asphalt firm and had the work done. Each jurisdiction — if they noticed — probably thought it was the responsibility of another. Therefore, no complaints. Job accomplished. Happy to help.”

This is ironic because this exactly what I believe Open Source software can do for Healthcare generally. By providing low-cost, excellent software, we can ‘just fix’ major problems in Healthcare that are intractable otherwise. Not that this ‘hack’ has two components: It was a technological/deployment issue of actually paving the road, along with the political insight that the mere deployment of the technology would work in the given political environment.

Here are a few things that are mired in power struggles just like this bridge.

  • Quality – how to measure if a doctor is doing a good job, and to help him/her to be a better doctor.
  • Patient empowerment – how to make a reactive patient into a proactive patient.
  • Interoperability – how to get healthcare data to usefully move.
  • Continuity of care – how to ensure that the ‘ball is not dropped’ as the patient moves around in the healthcare system.

-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.

Microsoft may allow FOSS implementations of HealthVault API

Sean Nolan has announced that Microsoft has placed the HealthVault API specification, under the Microsoft Community Promise (CP) at the time of the writing, this page has not been updated to list the HealthVault API, but the text is provided in the specification download. This may allow for FOSS implementations of HealthVault.

The Microsoft CP is not the same as Microsofts Open Specification Promise (OSP). That is problematic because the Open Specification Promise is already doubted by the larger FOSS community,  and the CP seems even more limiting.

Most notably the CP is different from the OS (from the CP FAQ):

The CP requires that implementations conform to all of required parts of the mandatory portions of the specification. Also, in specified cases (such as where the specifications have uses that exceed those needed to achieve the interoperability needs for which the release under the CP is being made), the CP may have special terms concerning what kinds of implementations are covered.

and

The CP applies only if the implementation conforms fully to required portions of the specification. Partial implementations are not covered.

The CP for Healthvault does have special terms (from the specification download)

Community Promise Restrictions on the Field of Use for the HealthVault Service Specification

HealthVault Service Specification is intended to support personalized healthcare. This technology is designed to be used by individuals to manage their health information, and is not intended to be provider-centric or health enterprise-centric.

That is a problem for projects like Tolven, which is a combined PHR/EHR system. If the PHR component of Tolven were to implement the HealthVault API,would the CP still be ineffect? In Tolvens architecture, the PHR and EHR are based on the same database. While Tolvens PHR is patient centric, the EHR is user centric.

Further it is not defined, as far as I can tell, what a ‘full’ vs. ‘partial’  implementation means. I could create an implementation of the web service calls for HealthVault over a long weekend, by stubbing everything. Now, my system would be a complete implementation from the protocol perspective, every call made to HealthVault would also work on my system, but nothing my system did would have any meaning. It would be much harder to implement things so that they conformed to the specification and actually worked (as opposed to merely appearing to). We might call an implementation that had no stubs and instead contained attempts at real working parts a ‘robust implementation’. But even a robust implementation would have bugs. It would typically work just like HealthVault, but sometimes it would behave differently, mysteriously.

Those ‘differences’ are what programmers like me might call a  ‘bug’. But would an implementation with bugs fall under the Microsoft CP?

More importantly, who decides if an implementation is buggy? HealthVault is still labelled as ‘beta’ and it is entirely possible that if HealthVault and a FOSS implementation of the HealthVault API worked differently, it would be because HealthVault had moved past its own specification.

At this point, I cannot recommend that anyone implement this API. There are too many unanswered questions here.

Having said that, Microsoft is  obviously trying to open up with HealthVault. I hope to convice them that the OSP is a better vehicle, but this is a step in the right direction. So far Google has released no information on the rules for re-implementing the Google Health API. At this point, Microsoft is (surprisingly) more open than Google.

-FT

ICW and Open eHealth at HIMSS 09

At this years HIMSS the Connect project kind of stole the spotlight. However, I think it is also important to remember the work of the Open eHealth Foundation which has been steadily progressing since it was announced a HIMSS 08.

One of the most important members of the eHealth Foundation group is ICW, who sent me a summary of the current Open eHealth progress. Here is another link to regarding the new eHealth Framework.

-FT

NCVHS Testimony on Meaningful Use

(Update 08-13-09 I have already presented this to NCVHS)

Introduction

I represent a community of health software developers and clinical users that respect software freedom. This community operates in the legacy of the VA VistA underground railroad. There are several important commercial EHR vendors that respect software freedom they are an important part of our community but they are only a part and certainly not a majority. I hope to convince you today that the notion of ‘vendors’ is too small for the task of computerizing healthcare. I hope to convince you that we need an open software community to solve this problem. I believe this because this is the only thing that has substantially worked so far and that given the magnitude of this problem, this is the only thing that has any chance of working in the future. Before we can move into that future, we need to have a candid dialog about the failure that typifies current health IT.

Relevant Biography

I appreciate the opportunity to testify today. More importantly I am thankful that you have chosen to invite a person from our community to speak to you. I must discuss why I am qualified to be a representative of my community. This important because legitimacy here is not earned with degrees or certifications. The FOSS community respects me because I have made substantial code and documentation contributions under FOSS licenses. I am the original author of FreeB (http://freeb.org) which is the first billing engine that supports both paper formats and X12 available under the GPL. Several projects adopted FreeB, and although few projects still use the original version, almost all of the second generation FOSS billing systems have been built in response to FreeB. Because of FreeB, at one time code that I had written was accepted into more projects than another single FOSS contributer (although that accolade now goes to members of the Mirth project). I won the 2004 LinuxMedNews innovator of the year award for my work on FreeB. I am also the primary author of the WorldVistA ‘What is VistA Really‘ vistapedia article. I developed mutual respect for many different FOSS EHR projects through my FreeB work. Since that time I have tried remain nuetral to any given project or codebase, instead working to further the community as a whole. I no longer have a leadership role on any given project, though I professionally support several codebases. Currently I am the Chief Architect of the HealthQuilt project hosted at the University of Texas School of Health Information Sciences. HealthQuilt is focused on the use of FOSS interoperability software for the purposes of Health Information Exchange in Houston, T.X. and is funded be the Cullen Trust for Healthcare. This testimony would have been impossible to arrange without the help of the UT system folks here in Washington D.C. and the U.T. SHIS people back in Houston. Thanks!

I say these things not to impress the executive subcommittee, you already think I know something or you would not have invited me. I say this to communicate to the larger FOSS community why I am qualified to speak for the clinicians and programmers in the health FOSS movement. I must do this to offset the hubris of merely presuming that one can represent an entire community, whose opinions and priorities differ significantly. I hope my testimony is representative of the many emails and conversations I have had about this over the previous few days. I should note that Dr. Ignacio Valdes (of LinuxMedNews) and Will Ross (of Medocino Informatics) have both maintained similar project neutrality and I have relied on their council heavily.

I am a Hacktivist, which is in itself a controversial title and deserves explanation. The ‘Hacker‘ part of what I do has nothing to do with breaking into computers. That is called Cracking and true Hackers have little respect for it. The difference between a Hacker and a Cracker is similar to the difference between a graffiti artist and a simple vandal. A Hacker (for our purposes) is a person who solves complex software problems with panache. (http://www.catb.org/~esr/faqs/hacker-howto.html#what_is)

A Hacktivist is a person who Hacks for social change. I am also an entrepreneur and I charge for services and support of FOSS health software, including EHR systems. I see no contradiction between having a purpose of promoting social change and a profession of software consulting. One way to formalize this pairing is with the concept of a not-only-for-profit businesses.

Why are we here?

Of course I do not mean in this question in the global sense, but rather why is the United States government proposing that we fund EHR systems in this manner? Every other major industry computerized themselves decades ago. Why didn’t healthcare follow suit? It might be helpful to consider for a moment what was -not- the problem. Technology was not the problem. Thirty years ago, we had SQL database systems driving complex OOP applications. We had the ability to do thin clients, and thick clients, distributed software architectures and just about every other technology that drives modern EHR applications. Do not get me wrong, I love web 2.0 technologies, super-thin browser clients, Aspect Oriented Programming and Service Oriented Architectures, but those kind of recent innovations make the development and deployment of EHR applications ‘easier’, rather than ‘possible’. Technologically we had everything we needed to computerize this industry thirty years ago. Why didn’t it happen?

The problems in Health IT are political, not technical. By political I mean that the problem lies in the relationships between organizations and individuals involved in the delivery of healthcare.

Doctors, so far, have been reluctant buyers of EHR software. For good reason. EHRs slow doctors down and doctors are incented to see as many patients in a day as possible. EHRs get in the way of that, and so doctors have hesitated to adopt them. Generally, the way doctors are paid discourages them from using technology to improve the quality of their care. This funding should change that temporarily at least, which is a good thing.

The other side of that coin is that proprietary Healthcare IT vendors have been unsuccessful at selling anything that is not directly related to improving coding to doctors. Many modern proprietary EHR systems are little more than ‘coding justifiers’, they are not designed to improve the quality of care but to substantiate the increased code complexity of a given procedure. Even these EHR systems are woefully under-adopted.

We are funding EHRs because we have experienced massive, and unprecedented market failure. No proprietary EHR company has approached the market dominance that is typical in other software industries. Microsoft has about 80% market share of the desktop computing space. All of the other desktop operating system vendors combined split the remaining 20% market share. Why is there not Microsoft in medicine? Heck even Microsoft, would like to be “the Microsoft of medicine” and regularly fails in this endeavor. The largest Health IT vendors barely make it to double digit market footprint and those few that do achieved that status do so through mergers and acquisitions rather than dynamic growth. In the EHR space 1% of the market makes you a big player.

Why is there no ‘Microsoft of Medicine’?

The reason that there is no Microsoft of Medicine is that generally, healthcare does not have the same dynamics as the operating systems. When Microsoft software developers code operating systems they are essentially negotiating the requirements from other technologists, the engineers who designed the microchips in computers. There is alot of complexity in making an operating system, but there is also a very specific set of requirements that is totally and accurately defined.

Most proprietary EHR development follows a tragic pattern of ‘spec seeking bloat’. The basic development process typically looks like this.

  1. Develop Software at one clinic/hospital solve that organizations problem
  2. Start selling it in other places
  3. Start meeting new requirements from new customers
  4. Recognize that the current codebase is becoming unmanageable spaghetti
  5. Have big meeting where we all agree that the now we really ‘know what the software should look like’
  6. Write a new spec based on lessons learned from previous version
  7. Go code to new spec
  8. Release 2.0 version.
  9. Users hate it they all want previous version back.
  10. Developers scramble to make latest version work as well as previous version
  11. Return to step 3 and repeat until spec is so large that it is not possible to even consider implementing it

This is the reason that ‘mature’ proprietary EHR systems seem so bloated. An EHR is impossible to top-down architect. The product must be modified so much ‘on the ground’ that the higher level organization becomes meaningless.

It is impossible to create a ‘spec’ for an EHR system that is sufficiently complex. Trying to do this is the constant ongoing attempt to make healthcare work the way a microchip does. This is the reason why the current CCHIT ‘feature bucket’ certification is met with such resistance within the FOSS community, it is simply wrong way to approach the problem.

About Medical Manager wasting away

Most of the following information is pulled from a page that I maintain on the History of Medical Manager. http://docs.mirrormed.org/index.php/Medical_Manager_History

In the 1980’s it was estimated that 80% of all doctors using practice management systems used medical manager. If there was a company that had the opportunity to become the Microsoft of Medicine, it was Medical Manager. During the dot- com boom and bust Medical Manager was sold several times. Each time the software ownership was sold Medical Manager support staff were layed off to increase profits. Medical manager is now a ghost. It’s market share has been gutted. Its dominance has been regulated to a footnote in Health IT history. Medical Manager is important because it shows the basic temptation of with proprietary systems.

First a proprietary company releases a well-designed software system. The proprietary company supports their customers with passion. Soon their user base and adoption grows. Then the company is sold. The new management must take the same asset and now make more money on it. How do they do that? They decrease the number of support staff and attempt to force expensive upgrades on their customers. This process or variations on it, are the inevitable results of vendor lock-in, and this pattern is generally predicted by the economic models of vendor lock-in. (If anyone from SAGE is listening please consider releasing Medical Manager under the GPL, it would breath new life into the product. If you would like to try this, let me know and I will do what I can to help)

Sometimes proprietary software companies waste away and sometimes it dies of a stroke.

About AcerMed’s massive stroke

When someone discusses the process for selecting a proprietary EHR vendor, they typically recommend a product similar to AcerMed. AcerMed was CCHIT certified, and rated as best in Klas. They had enthusiastic users and capable software engineers. I have no evidence that AcerMed was anything other than an honest company. However, they were sued out of existence. Hundreds of AcerMed customers had to scramble to find new software.

Kept Honest ClearHealth vs. MirrorMed

I support the ClearHealth codebase under the trademark MirrorMed. The codebase is 95% the same, but I can support a ClearHealth instance, and ClearHealth Inc. can easily support a MirrorMed instance.

ClearHealth Inc cannot charge too much for its software, or I would undercut them. I cannot charge to much, or they would undercut me. If I am not responsive in my support my clients will go to ClearHealth Inc. If ClearHealth is not responsive… you get the idea.

Because ClearHealth and I are sharing code under the GPL, neither of us can get away with the shennigans that are common in the proprietary industry. Hard things are expensive, but easy things are cheap. If either I or ClearHealth Inc. go out of business, our clients would not be trapped or abandoned. The GPL insulates clients from the kind of corporate failure that AcerMed experiences. If Medsphere went out of business tomorrow, OpenVistA would be just fine.

If Medical Manager was available under the GPL, Medical Manager would never have tried any of the shennigans that they did. Ironically, if Medical Manager had been available under the GPL, SAGE would currently have deeper market penetration than it does now.

About VA VistA

Most of the following information is pulled from the pages that I maintain on the What is VistA Really and Why is VistA Good?

Almost everyone can admit that VistA is an excellent EHR system. Recent research shows that VA VistA operating at VA hospitals accounts for more than half of the advanced hospital EHR systems deployed in the United States.

What is not commonly understood is ‘why’ it is so good. How did it happen that a system developed by federal employees leads the way as the most widely deployed advanced EHR system in the United States? The reason is that VistA, unlike proprietary EHR systems, evolves.

From Evolutionary Dynamics: Exploring the Equations of Life by Martin A. Nowak http://www.ped.fas.harvard.edu/people/faculty/

The main ingredients of evolutionary dynamics are reproduction, mutation,
selection, random drift, and spatial movement. Always keep in mind that
the population is the fundamental basis of any evolution. Individuals, genes,
or ideas can change over time, but only populations evolve.

Each VA hospital employs its own VistA programmers to solve the problems of the local hospital. That makes each hospitals instance of VistA an ‘individual’. The VistA instances at all of the hospitals combine to form the required population. The mechanism for reproduction is the ability to copy source code. The mechanism for positive mutations is the ability of each local VistA programmer/clinician pairs to improve the VistA source code. The process of selection is the ability for V.A. clinicians and administrators to recognize superior work at another hospital and ‘kill’ the local programming effort in that area in favor of adopting the foreign code.

This is not some abstract plan. Medication barcoding was developed at a local VA hospital and then taken nationwide. This is a high-profile example of a process that is constantly repeated across the VA institutions (or it used to be).

Competing, decentralized, collaborative software development are both hallmarks of FOSS development and requirements for software to evolve. This stands in stark contrast to the recent decision to integrate a proprietary lab system into VistA. That proprietary system is incapable of evolving precisely because it cannot be freely copied. This is the reason that the VistA community was upset about this http://www.modernhealthcare.com/article/20090203/REG/302039997

I was surprised to hear that the bureaucrat that decided to go with a proprietary, static lab component defended the decision by saying ‘ we are taking an evolutionary approach’. People like this are very dangerous to the VA VistA community. They have learned to speak our language without respecting our values. They are pharisees who embrace the form, but not the spirit of our community. Because of these kinds of decisions, the majority of major VistA innovations over the last two years have been outside the VA.

There is a small chance, that someone from a congressman or senator’s office might read this. You should know that unless you are getting VistA advice from a card carrying member of the underground railroad, you are getting bad VistA advice. Personally I am a VistA novice, but I now know enough to know that the majority of VA bureaucrats are either making good decisions because A. they are listening to railroad card holders or B. they -are- a card carrying underground railroad member or C. sheer dumb luck. It is painfully obvious to those of use in the community that most VA bureaucrats typically have no idea what they are babbling about. Read my VistA articles above and then find yourself someone who actually codes in MUMPS to advise you directly. Once you get it, never ever let go of that direct programmer contact. Remember that VistA happened as a rebellion by clinicians and programmers against the VA bureaucracy. I also find that Roger Maduro and the board members of WorldVistA tend to be informed and right-headed when it comes to VA VistA.

Seven Generations

My grandmother took a drug while she was pregnant with my mother than predisposed my mother to ovarian cancer. My mother died from ovarian cancer. I will pass my mothers genes to my daughters and granddaughters. As my grand-daughters consider their predisposition to ovarian cancer they will need to consider the contents of my grandmothers medical record as well as their genetic inheritance. The content of my grandmothers medical record could easily be relevant for a period of over 150 years.

The notion that a proprietary software vendor can be trusted with the responsiblity of upgrading my grandmothers paper medical records into an electronic format that will be relevant to my grandchildren is like pre-selecting the East India Trading Company to provide the technology for the Apollo Space Missions. It should immediately strike anyone who considers the problem as a farce. Companies simply do not last for 150 years.

Making a laundry list of what an EHR should do is a little silly. It is equivalent to saying ‘We should encode both modern and future medical principles and make the computer do that’. We have only a vague idea what an EHR should do now, much less what it will need to do in the future.

I have extensively covered this in my article which covers the concept of the seven generation test, some of which I covered here. http://www.fredtrotter.com/2007/10/19/healthvault-failing-the-seven-generations-test/

Get out of the way. please.

I hope I have argued effectively that the proprietary vendor model will never delve true EHR requirements. I hope I have encouraged you to take a very-long term perspective on this problem. I hope I have shown you how dangerous proprietary licenses are to clinicians. But I do not need you to agree with me on these issues. (or for that matter to publicly admit that, secretly, you agree with me)

What I do need you to do is not create barriers to the commercialization of the evolutionary ‘VistA’ development model and ideals with your funding systems, or with your definitions of ‘meaningful use’. Please do not allow yourselves to get caught up in proprietary thinking. Here are some general rules.

Tolls are not OK. To quote from ClearHealth CEO David Uhlman.

If “Meaningfule Use” ends up requiring the American Medical Association’s Current Procedure Terminology (CPT), proprietary editions of ICD9/ICD10 codes, direct electronic transmittal of prescriptions (after the RXHUB/SureScripts merger only one company provides this), then they are precluding a completely Open Source offering for healthcare.

These kind of proprietary systems cannot be freely redistributed and that is a requirement under FOSS licenses.

Expensive, feature bucket certifications are designed for black box systems and will not work for the FOSS community. VistA is waaaay beyond CCHIT standards and has to be ‘dumbed down’ to meet the certification requirements. The FOSS community has been working with CCHIT and they have been very responsive over the last two months. But they were unresponsive for the two years before that. If you make CCHIT the only way to get certified they will have no motivation to work with us. Give us the option to create an alternative certification body. If you give the FOSS community that option, I fully expect that CCHIT will work with the community to create a separate-but-equal certification method that works for FOSS but is still ‘fair’ to proprietary vendors.

Answers to specific questions

What is the “time to market” cycle from adoption of standards to installation across the client base?

This is impossible to answer. It depends on the standard and depends on the individual who is in control of an instance of a FOSS EHR. The vendors cannot control our clients the way proprietary vendors do. I can tell you that bad standards will be adopted more slowly than good ones.

How does that enable or constrain criteria for 2011 for eligible professionals?

I have no idea.

Hospitals?

I have no idea.

Later years?

Only FOSS EHR systems are going to be able to adopt to far-future standards. Not sure I can say more than that.

What are vendors’ expectations with respect to increased product demand in 2011 and after, and how do they expect to meet it?

This is actually a question for the community and not the vendors. The existing vendors would say that they will scale their operations, and they will be able to that as well or better than any proprietary vendor. However, if the current vendors are unable to meet demand, the community will spawn new vendors to support existing projects. This is only possible with FOSS EHR systems.

From a technical perspective all of the FOSS EHR vendors I know of can scale with the ‘cloud’. (the ‘cloud’ is another technology that is impossible without FOSS). Using that technology our vendors can easily provide an EHR instance for every provider in the country. So the technology scales all the way to a national level smoothly. If our community was exclusively chosen to deploy every EHR in the country we would need to scale our support staff for things like phone support, and that would take a year or two. Even this is 10 times faster than proprietary alternatives.

What are potential risks (for example, need for additional technical support to assure successful implementations) and how can they be mitigated?

With freedom comes responsibility. FOSS EHR users have the right to shoot themselves in the foot. We cannot give our clients true freedom and, at the same time, ensure that they will always do the right thing. The best FOSS EHR vendors will be those that develop a collaborative relationship with clients that make good decisions more likely. But no vendor can control a client. Thats against the rules.

I think there is a danger that the single/small group practitioner(s) will be unfairly hurt by these technology requirements. I hope that our community will be able to address the specific cost and technology requirements that this user group has. I am afraid that technology requirements will force small practices into larger groups, which may not be the best way for those clinicians to provide care. I am advocating for a ‘simple as a toaster’ sub-projects within the FOSS community to help prevent this.

How will vendors need to adapt their product development and upgrade cycles to synchronize with progress toward increasingly robust requirements for meaningful use, information exchange, and quality reporting?

VistA is already way ahead of everyone. Other projects like ClearHealth/MirrorMed, OpenEMR, OpenMRS, Tolven, etc etc will have to catch up. Even with the other projects playing catchup, the limiting factor here will be how much technology a client can implement in a short period of time. Please read David Uhlman’s blog post below for more insights on this issue.
What changes are anticipated in the vendor marketplace between now and 2016 as a result of the incentives?

The incentives are going creating an ‘political environment’ that could replicate the focus on quality that is already found in the VA. This will replace the procedure farming that currently the most profitable clinical business tactic. Once that happens the basic ‘evolvability’ of FOSS will cause a blossoming of different systems designed to increase quality. Essentially the VistA programmer/clinician pair programming model will spread like wildfire outside the VA, even as it continues to be killed off inside the VA.

Vendors that currently have investments in VistA or other mature projects like ClearHealth, OpenEMR, OpenMRS, or Tolven will have a considerable advantage over newer FOSS vendors and proprietary vendors.

Over the next 50 years, it will become increasingly difficult to compete as a proprietary vendor. Only those who can achieve and sustain Microsoft-like development savvy will be able to compete. FOSS EHRs will provide a floor and without substantial advantages, no one will consider using proprietary systems.

The value will move away from the code itself and into higher level processes like data mining for clinical rules. This will be just in time however, because without this kind of adaptability it will be impossible to cope with the coming deluge of genetics and protenomics information.

References

I have used information and ideas from the following resources extensively.

Free and Open Source Software in Healthcare AMIA Open Source Working Group White Paper (Dr. Ignacio Valdes) http://www.amia.org/files/Final-OS-WG%20White%20Paper_11_19_08.pdf

David Uhlmans ClearHealth CEO blog post on Meaningful Use http://health365.wordpress.com/2009/04/26/idea-67-for-april-26th-2009-not-shooting-ourselves-in-the-foot-or-the-meaning-of-meaningful-use/

Dr. Edmund Billings Medsphere CMO file posts to the Open eHealth Collaborative http://groups.google.com/group/open-ehealth-collaborative/web

OpenHealth Mailing List http://tech.groups.yahoo.com/group/openhealth/

LinuxMedNews.com http://linuxmednews.com/

Webinars and papers from Mendocino Informatics http://www.minformatics.com/

HardHats (VistA support list) http://groups.google.com/group/Hardhats

I would also like to thank the folks from MOSS, Dr David Kibbe, WorldVistA and the folks from U.T. SHIS for help and advice.

.
.
.
.
.
.
.
.
.