Trisano is in the running for a sourceforge community award for best government project.
(Update 08-13-09 I have already presented this to NCVHS)
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.
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.
- Develop Software at one clinic/hospital solve that organizations problem
- Start selling it in other places
- Start meeting new requirements from new customers
- Recognize that the current codebase is becoming unmanageable spaghetti
- Have big meeting where we all agree that the now we really ‘know what the software should look like’
- Write a new spec based on lessons learned from previous version
- Go code to new spec
- Release 2.0 version.
- Users hate it they all want previous version back.
- Developers scramble to make latest version work as well as previous version
- 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
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.
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.
I have no idea.
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.
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/
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.
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.
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.
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.
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.
Today the Boston Globe has published an article about Dave deBronkart’s problem with claim data in his Google Health PHR. I think it is awesome that the main stream press is picking up on the problem of using billing data for clinical work!
A little digging reveals that there is an much better post over at e-patients.net that details exactly what his experience is.
I have been aware of this problem for some time. For me it all started when CVS Minuteclinic imported a ‘condition’ of ‘Blood Pressure Screening’ as ‘Active’ condition onto my record.
Why did they do this? Because their system must have an ICD code for the purposes of billing for my procedure, even though I payed in cash.
One of the best things about being deeply involved in both FOSS Health IT and a blogger, is that when something hits the main stream press, I get to prove that ‘I told you so’ with reference to posts that are months or even years old. Heck, I bet that ‘I told you so’ feelings are a full 25% of my motivation to blog! That puts it way ahead of ‘joy of shameless self promotion’ and ‘muuust raaannt’ as motivation components!
The problem here is that the current diagnosis onotology system in the United States is based on billing data. With the migration to ICD 10, this problem will only get worse. Most doctors do not really understand how to use ICD 9, and ICD 10 is muuuch bigger.
I got wind of this article from the Modern Healthcare Health IT Strategist.
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.
MOSS (Misys Open Source Solutions) has come into it’s own as a force both within FOSS and within it’s chosen domain of interoperability.
MOSS is led by Tim Elwell and Alesha Adamson, they could often be found at the interoperability showcase where they performed as one of the few PIX/PDQ services.
At this conference especially Tim was instrumental in helping the FOSS community communicate it’s concerns to CCHIT. This speaks volumes about the transition of Misys as an suspect outsider to not merely acceptance as a legitimate FOSS community member but a leadership role within health IT FOSS. .
The MOSS implementation is probably the most mature available under a FOSS license, and will soon be in the running for the title of best under any license. I can say that if they are overtaken it will only be another FOSS project that could catch them and there are several good projects who might.
Probably the most significant evidence of this dominate role was the muted announcement by the CCHIT Laika project that the MOSS project, along with Mirth, was selected as one of the testing tools for coming interoperability tests.
MOSS is also formalizing it’s offering for those organizations who are attempting to do serious clinical data interchange. I regularly use Alesha for informal sanity checks for my own HIE ideas, and every time I do I regret that we do not have the budget to bring MOSS in to provide a more formal structure. Compared to other HIEs I usually feel efficient but when I hear about the MOSS offerings I feel like I am doing all of the right things but flying by the seat of my pants.
Hopefully I will get Tim to let me replicate some of the graphics from his handout about the MOSS CobIT-based offering.. and here it is!! MOSS HIMSS 09 handout…
In the meantime here is a shot of Alesha at the Allscripts booth at the interoperability showcase.