Can somebody look at Medscribbler


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.


A geek in the ER

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

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

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

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

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

Joes take makes a good read.


MUMPS is modern

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

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

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

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

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

Now… on to the idea of compiling MUMPS:

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

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

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

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

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

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

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

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


CCHIT Feature bucket

A central problem with CCHIT is the feature bucket.

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

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

Here is item SC 03.10

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

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

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

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

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

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

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

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

There are three obvious edges to an EHR system:

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

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

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

What are the advantages of this model?

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

Just some thoughts.

Claims data in PHRs

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


Towards fair EHR certification

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

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

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

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

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

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

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

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

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

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

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

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

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

Take away lessons:

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

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


MOSS Misys Open Source Solutions

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.

Codapedia launched

I heard about codapedia during my annual tour of the floor looking for FOSS-related projects that I had not heard about before. is among a new breed of ‘medical wikis’, designed to support the concepts of group editing like a standard wiki, but also to be more reliable and authoritative. The corelations to medpedia are obvious. Like medpedia, there is some vetting that goes on before an article is posted, in this respect it is similar to the Google concept of a knol. The content of the site is licensed using the GNU free document license.

The site was setup by greenbranch publishing which is the main publisher of the paper resource Journal of Medical Practice Management. They sell books, journals and audio content. This is not the organizations first foray into new media, they have run a podcast site since 2005 called

Rather than go into further details I will just let you listen to the podcast I did with Nancy Collins, but most of links that she mentions are encoded above.

Codapedia launch interview Nancy Collins (mp3)

Codapedia launch interview Nancy Collins (in ogg)

Here is a shot of the codapedia booth, Nancy is on the left, it would be nice if someone could leave the name of the woman on the right in the comments… (I forgot to ask)

Medsphere bus

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

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

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

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

Enough preface… have a look!!

A lesson in visual philosophy
A lesson in visual philosophy

CCHIT vs FOSS pre-meeting issues

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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