Fred Trotter

I am saddened that the supreme court decided not to address the software patent problem with Bilski. They had an opportunity to abolish or at least reign-in software patents, which are an inherently bad idea. Instead they undid what little progress had been made in the Bilski precedent.

I think others have already more eloquently covered how the Open Source community lost in the final Bilski ruling.

Patents are damaging to Open Source healthcare information technology, and by proxy healthcare itself.  I believe it is time to tell you a story that I have been sitting on for more than 5 years, that serves as an excellent case in point. IANAL So understand that this is told from the perspective of a software developer, who, out of necessity has become familiar with patent, trademark and copyright law. As legal advise, this blog post is worth exactly what you are paying for it.

What must I, as an Open Source software developer, do to avoid being sued for patent infringement? The only semblance of protection against being sued is to make my defense so rock-solid that someone who might consider suing me would be worried that I could successfully counter-sue for anti-competitive business practices. So what are the defenses against patent infringement? I pulled these from my own experience, and articles like two most common defenses against patent infringement.

• Non-infringement: My code does not implement your patented method
• Your Patent expired: The time on your patent has already run out before I started making money from my selling or supporting my software
• I have patents too: and if I am infringing yours, then you are infringing mine.
• Have shallow pockets: I am relatively poor, that this lawsuit is pointless, you will never get any “real” money from me or anyone else I associate with.
• Invalid Patent: Your patent is invalid because
  • Prior Art existed: sufficient descriptions, or actual code already implemented or described your patented method before your patent was granted (this one works for me, the developer because I am able to search through sources of prior art myself)
  • Your patent was obvious: although no specific prior art existed that identically replicated your patented technique, your method was obvious based on what was published
  • Your patent process was flawed: You did something that you should not have during the patent process. (not helpful to me as a software developer since it focuses on a particular given patent)
  • Not patentable: Your patent covers something that is not suitable for patenting (also not helpful to me as a developer)

Obviously non-infringement is the best option, but here is the trick: If I do a search for patents that apply to my area of expertise, and I am later to found to infringe on a patent that I read, I might be liable for “willful infringement” which carries stiff penalties. So generally I cannot search for what is actually patented. This makes it somewhat difficult to avoid infringement. You only know when you are infringing because someone contacts you and says “you are infringing”.  This what Open Source developers refer to as the patent minefield problem. The only way to avoid the minefield is to merely replicate software techniques that for which you can find implementations that are more than twenty years old. Finding prior art is not enough, because you cannot know the dates of particular patents without searching for them. So basically, Open Source projects can safely implement any software technique that was in common use twenty years ago. That kind of sucks, because you cannot even improve them, because those improvements might be patented, you can only re-implement them. So the only way for an Open Source developer, like myself, to entirely avoid patent litigation is to stop innovating.

I hope that my readers, irrespective of their perspective on software patents, are already uncomfortable. This is not what the patent system was intended to accomplish. Just because my chosen method of profiting from my innovations is not the same as proprietary/patenting software companies, does not make my work less innovative or valuable in any way. But there is no way for me to make my “innovation process” safe from patent infringement lawsuits.

What options do I as an Open Source developer have? Basically, if I am actually doing something new and different, and I want to release it as Open Source, I just have to release the code and then pray that it is either A. Not a patented technique at all or that B. If it is patented, I can defend myself.

So it is really important to note that there is nothing, absolutely zero, that I could have done -in advance- to avoid implementing someone else’s patented technology.

The Shakedown

Several years ago, FreeB, an Open Source billing engine that I wrote was attacked by a patent troll. When I get the time I will publish the letters I got to chilling effects but for now I will just include snippets. First, I should clear up some confusion. I was contacted by BillingNetwork because I was the owner of the Freemed.org domain name. I was developing FreeB, the medical billing module that Freemed would briefly use, but Jeff Buchbinder was the lead developer of the Freemed project and I was merely a contributor. So I really had two hats, one as a Freemed user and contributor, and one as the primary developer of the billing module, FreeB, that any EHR could (and did) use to enable medical billing.

BillingNetwork is what I would consider a Patent Troll. My definition of that term is any company that makes vastly more money by suing from its patents, than it does from actually selling any product that implements the patented technology. Making good software, that does well in a competitive market is not easy. Most of the software that I have written will never be subject to market forces. Usually this is because the people who hire me to extend or create Open Source healthcare software do so without having a completely reliable business strategy. They just realize that a lack of software is impairing their entrepreneurial aspirations and hire me to fix that problem. Some of my software projects have been tremendously successful in the market, but most of them do not get off the ground from a business perspective, this is true of every software development company or individual that I know. When a software project finally is useful in the market it is usually because there we were several earlier iterations of the idea that were abandoned. Going to market with half-baked software inevitably dooms a software company to market irrelevance.

Patent Trolls, even ones who “market” their own products are usually totally irrelevant in the marketplace. They have not put in the work needed to make their patented idea into a “workable” innovation. The irony is that making software “workable” often means that you have to completely abandon your original design. What actually works in the software market is often dramatically different than any starting software designs. When a Patent Troll patents a software design, without having the ability or often even the intention to turn the design into a working product, they very often patent a very poor design. These patents are markedly different from patents from large companies, like IBM, Microsoft or Google, that create software patents as a side effect, and as side business, from making process of creating fully working products.

BillingNetwork just settled with Athenahealth, a company which has about 1000 times more market relevance than BillingNetwork ever will. Their patented design, as you will see below, is not a particularly good design. They qualify as a Patent Troll in my book.

Here is the relevant text from the letter that Billing Network sent me more than 5 years ago:

We are not charging you with infringement of the patent, but are bringing the patent to your attention so that you may consider entering into a .license agreement with BNC.

(The underlines are mine.) This is really interesting. Billing Network was offering to license me this patent without ever implying that I actually infringed the technology. If Billing Network was actually an “innovator” it was in the field of patent trolling. They would not only contact web-based EHR/PM vendors with letter like this, but they would also send letter to the customers of web-based EHR vendors! Even in these letters they would not actually say that the software actually infringed, only that it might be. If someone owns a patent, and they say to another company “hey you are infringing my patent” then they have to back that up in court. If the patent holder says it publicly while knowing (or should have known) that the claim of infringement was not true, they might be guilty of libel and slander against their target. But if the patent owner says you “might” be infringing, then they have no obligations, and if they say that directly to the users of software, rather than the developers who might be able to actually evaluate that claim, then they can earn “licensing” money from the FUD they create around their patent, and what it covers, without ever having to go to court and prove anything. This is important, because it allows BillingNetwork and other Patent Trolls to use a patent like a shotgun generally against any company in a given field (in this case web-based EHR that does medical billing), rather than merely those companies which actually infringe the patented methods!!

Even if you are against software patents, like I am, you have to marvel at the evil genius at work here!!

At this point I made the mistake of actually calling them and emailing them, as they requested, and explaining that I could not license the patent because that does not work for Open Source. At this time I foolishly assumed that contacting them was better than reading the patent to see if the patented technology was anything like what I had worked on. But this was foolish, once they have said “hey take a look at this patent you might be infringing” there was probably no way that I could have been held as a willing infringer by merely reading the patent.

In my communication to them, I included the link project pages for FreeB and Freemed which of course allowed for full download of the sourcecode in question. The letter that I got back was so contorted and confusing that I realized that I needed legal help, and so I contacted the FSF and EFF and they put me in touch with the Public Patent Foundation. Who helped me out from then on. They wrote a “please go away letter” for me, and after some back and forth, that was the end of it. Perhaps Billing Network sorted out that I although my billing software was in wide use, I was not making money on it. But for the present text I think it is important to show how belligerent they got, without ever actually implying that I infringed anything.

From the second letter:

We are eager to avoid a possible conflict and to resolve any legal issues amicably.
If you are interested in entering into license negotiations, we will have our intellectual property counsel forward proposed terms for a non-exclusive license. While we take our patent rights seriously, we are interested in resolving this matter quickly and believe that you will find our licensing terms to be quite reasonable.
As we indicated in our last letter, we are not charging you with infringement, but are merely offering you a non-exclusive license for the above identified patent.

From the third letter, after I foolishly talked to them:

We have reviewed your email to Dr. Krumholz, and it appears that your FreeB billing system may be covered by the ‘229 patent. Accordingly, you need a license from BNC under the ‘229 patent to continue using the system.

Note the powerful “Accordingly”, you ‘may’ infringe therefore you ‘need’ to get a license. Legal marketing at its best!!

The last letter is the part of the response to the PubPat letter… Specifically this is the part where we said that FreeMED and FreeB do not infringe on the patent in question.

Your letter indicates that you do not believe that the FreeMED system includes several elements of the claims of the ‘229 patent. However, you have included no documentation to support this assertion. We are reluctant to rely upon unsupported assertions by the attorney representing a potential licensee for obvious reasons. Accordingly, we request that you provide us with any documentation that supports your assertion.

Finally, we restate that we believe that a license agreement would be in the best interests of both parties…

(again underlines mine). Remember, I had provided them with a link to the sourcecode in question during our initial discussion. This is a critical issue. BillingNetwork viewed me providing full access to the sourcecode as “no documentation”. In short, from Patent Troll’s perspective, they needed to be given a guided tour of sourcecode that they already had access to, in order to accept our assertion that we were not infringing on their patent. Think about this from a business expense perspective, it is not enough for me to have read the BillingNetwork patent, and be sure that my software works differently, I have to determine which parts of my code -prove- my non-infringement, and then give the Patent Troll a guided tour.

Next we will actually talk about whether I infringed the patent. But for now lets take a stock of where we are:

• Jeff and I (and Open Source software developers generally) have no way to protect selves from this type attack. We could not review the patents the danger of becoming “willful infringers” (the patent minefield problem).
• The patent troll attacked us with the expectation that it was cheaper for us to pay to license the patent rather than even figure out if we infringed the patent. So they are not making money from their “innovation”, but rather the simple fact of having a patent for one design of the tens of thousands of designs that might work. Their patented design, is like an “idea tax” on the process of implementing any of the other designs.
• Thankfully Pubpat stepped forward to help us, but if they had not, we would have been on the hook for hiring lawyers to defend us. Without PubPat, I had no good choices: Go out of business hiring lawyers, or defend myself poorly. Did I mention that Pubpat is an organization that you should be supporting?
• The Patent Troll viewed it as our responsibility to prove that our openly published code did not infringe rather than their responsibility to look at the code and prove that it did infringe. This is the “guide tour” problem.

This is why this a “Troll”. The whole word picture here is that of a troll who charges a “toll” for a bridge. A bridge the Troll did not build. This is why software patents, no matter what you think of them, stifle Open Source innovation. So far we have not discussed if the patent is valid or if we actually infringed, but the expenses that I incurred and the time that I spent dealing with this prevented me from doing… that’s right folks… actually improving my software. Practically speaking this halted my development activity for probably three months in total, at different times.

Now what if I could show, conclusively, that either A: we did not infringe the patent, or B: to the degree that we did “infringe” we did so based on obvious prior art? That is what I will attempt to show next. But at this point I want you to see that even without considering actual infringement, BillingNetwork has a method to shake down any user of my Open Source project using carefully crafted FUD, and that they attempted to do this entirely independently of whether my code infringed or not. Because they have a patent on one design for the type of software that I develop, they have a free ticket to go after my entire market place, without regard for the actual content of the patent in question… This has nothing to do with “protecting” an innovation that BillingNetwork had, its all about using patents to legally extort the free market. I cannot help but quote that Wikipedia article on Extortion:

Refraining from doing harm is sometimes euphemistically called protection

How awesome is that quote?

Did we infringe BillingNetwork Patent 6374229?

note: I would recommend that if you develop healthcare software, Open Source or otherwise, you stop reading now. By reading this, you might become a willful infringer of the Billing Network patent. Although I do not think I give enough detail here to make you a willing infringer, the link to the patent certainly would. Be careful.

That question has two answers. One for my project, FreeB,  and one for Jeff’s project Freemed. But first lets look at the patent in question.

There are seven claims made in the patent:

Claims 2-5 are actually refinements of the first claim, that begins:

An integrated internet facilitated billing, data processing, and communication system comprising:a database server and a home page of a website

The sixth and seventh claims begin:

An integrated internet facilitated billing, data processing, and communication system comprising:a database server and a direct access server electronically interconnected between said database server and a plurality of direct access subscribers each of which gain secure thin client access into said direct access server via a modem and an internet service provider (ISP)

An internet based computer system for billing, data processing and communication for and between subscribers and said system, one type of subscriber being of the browser-based type and another type of subscriber being of the direct access type, said system comprising:

So the version of FreeB in question did not infringe. Why? There was no database, and there was no web interface. The first version of FreeB, and the only one originally written by me (the second version was originally built by the ClearHealth team) and the only one that existed during this letter writing, was designed as nothing more than a data pipe. You connected one end of the pipe into an EHR, and out the other side came properly formatted medical bills in paper and EDI formats. It was a software module and had no direct user interface at all, you configured it by editing text files. It remembered nothing from one run to the next. It was not a great design, but it certainly did not infringe the first five claims here. The claims are all mixes of “browser” and “database” requirements, and FreeB did none of that.

Of course, you could combine FreeB with another system, that could theoretically infringe the patent. In fact you could argue that FreeMED, which was an early attempt at creating a web-based EHR that could do billing might have infringed. But there is no way that FreeB itself, in the version that BillingNetwork said “accordingly” needed a patent license, could have infringed the patent. The sourcecode that was available to BillingNetwork as well as the developer documentation on FreeB available at the time made this perfectly clear. BillingNetworks implication that that FreeB “might” infringe their patent was based only on the fact that FreeB was software in the same field of endeavor (medical billing) as their patented technology.

But what about FreeMED or the combination of FreeMED and FreeB?

There is nothing in the patented claims that even early versions of FreeMED could not be made to do with mere configuration. Many of the things claimed in the patent were done in FreeMED out of the box, but then most of the things written in the patent are done by every web-based medical billing system on the planet. Of course, this is true of FreeMED today, as well as the far more popular ClearHealth and OpenEMR projects, as well as probably half a dozen lesser known web-based Open Source EHR projects that either support billing today or want to in the future.

But FreeMED is unique. As far as I know, it is the oldest Open Source web-based EHR/PM system. In fact, it is so old, that if it did infringe on the BillingNetwork patent, it has been infringing even before the patent was issued.

The date for filing of patent #6374229 is Oct 20, 1999

But FreeMED was already a working codebase at that time. I inherited the FreeMED.org domain name from other owners (sorry it is down right now… still working through a server migration…) but thankfully at the history of the site, and therefore the project itself can be found at the Internet Archive. Let me take you on a quick tour. The oldest version of FreeMED.org that has a snapshot is Nov 25, 1999 at that time, there was already a demo running. More importantly we find that the site itself has downloads of the FreeMED project starting as early as 05/27/1999 the latest of these is from 23-Jul-1999.

These links actually allow you to download FreeMED as it existed, at that time, three months before the Billing Network Patent was filed. But most importantly, are two files in that download. The CHANGELOG and TODO files. No matter how I might disagree with some of Jeff’s software design decisions, I have to admit that the man was a stickler for standard Open Source project conventions and that is paying off.

From the changelog take a look at the entry “19990709 –” which states in part:

a added structures for payment records (for checks, etc) to the admin
module. stupid db reinit — you go squish now.
a added prelim payment records module — working on addition function
now.
a added billing function from main menu with billing_functions module.
n these functions are not ready for prime-time yet. please do not wail
on them then complain that they don’t work -jeff

Even more relevant is the following section from the TODO file

19990708 ——————————————————-
* implement payments and billing databases, with structures
….
* insurance payments related dbs and tie-ins, possibly with API
revisions

This is an indication of where Jeff was going with the billing system. All of this either documented or actually coded at least three months before the BillingNetwork patent was filled.

I submit that by running a version of FreeMED that contained only what was coded or planned as of 10-1999, and mere configuration of Apache and the FreeMED configuration file, using the versions available in 1999 (i.e. redhat 6.0) you can easily implement every aspect of the BillingNetwork claims, or designs that are largely equivalent (like using php’s direct mysql connection rather than ODBC), all using mere configuration changes. Moreover, you could find using other php projects (like postnuke) that were popular at the time, examples of all the configuration changes needed to make the modes of operation described in the claims work.

I would submit that anything that Jeff was reading at the time, (i.e. the php CMS that he would use for other purposes for instance) would serve as a basis for what should be considered obvious art at the time. Essentially the BillingNetwork patent covers a particular configuration for a web-based billing system. Not even the most intelligent configuration given the software that was available at the time. Jeff’s default configuration was actually a better design than the configuration required to fully emulate the Billing Network patent. This goes back to the habit of Patent Trolls in patenting half-baked technology. No one could run a medical billing practice management service by merely correctly implementing the patent, it would not actually work. But broken technology does not stop a Patent Troll from profiting from a patent, and Billing Network is a perfect example of this.

If my readers demand it (leave comments) I will be happy to give a blow by blow of the simple configuration changes that would have allowed the FreeMED “stack” to emulate exactly the design put forward in the patent. But anyone who understands the basics of the php/apache/mysql/linux stack know that 98% percent of what the patents cover are automatically provided in the stack itself. This was already true in 1999, which was php version 3. Moreover I can list about ten ways that such a configuration is not actually the “right way to do it” but then again, no one in the patent office cares about what actually constitutes best practices or does not when they hand out a patent like this. Sadly amateur design is not what is in question… just “originality” as compared not with what people were doing publicly in the open source community at the time, but with regards to what has already been patented. I think now the patent office is a little better about seeking sources of prior art form the Open Source community, but not by much.

So does FreeMED serve as Prior Art that invalidates the BillingNetwork patent? I think so, but it does not really matter. What is important is that this gives a very specific path for Open Source projects to be immune from attack by this particular Patent Troll. It means that all of the plans that FreeMed made are a safe harbor. As long as we do it in the way that FreeMED was  there is no way that the BillingNetwork “protection” can impact you.

Defensive Patents

Several people in our community have started to consider defensive patents. There seem to be two approaches to this issue. Patent Pools and more recently Defensive Patent Licensing.

Both of these rely on some basic assumptions. If Open Source projects will apply for and get patents for the designs that they use, then they will be able to for the patent office to acknowledge that the methods they use are “innovative”. You might have the patent office reject parts of your patent because they were “obvious”. Showing that your merely implement your own patented method or something that is “obvious”, is one of the few novel defenses against someone who is is attacking with patents but does not have any real business of their own. The pooling method is also a good idea for defense against big businesses with patents. When several projects have patents, and are willing to pool them against people who sue for patent infringement. The “sue you back” tactic would only work against companies with software patents who are actually in business. But “sue you back” does help to defend the community against one kind of patent attack. But “sue you back” is ineffective against patent trolls, who very often have no business at all, so they do not “infringe” on any ideas that might be an Open Source Patent Pool, because they are not “doing” anything at all. This is the reason why I think “We use our own patented designs or obvious designs” might be a good avenue to pursue.

It is deeply frustrating that the Open Source community would need to patent ideas in order to ensure that they could be freely available without charge to users and developers. However, at this point I am simply at a lose as to how to proceed. I am considering pursuing defensive patent strategies like this, and I know that other are too.

Patents frustrate Open Source developers

Hope this helps people to understand why we resent software patents in Open Source. At every turn in this story, my time was taken up, not defending a legitimate claim of patent infringement, but simply jumping through the hoops that some group who had a “related” patent thought I owed them. As far as I can tell, from a non-lawyers understanding of patent law combined with a working knowledge of building web applications, I was utterly, extremely, completely, excessively, non-trivially and enthusiastically -not- infringing the Billing Network patent. But Billing Network made it abundantly clear, even after we told them that I was not infringing, that I should still pay them a toll, because that what a Troll will always say to anyone who wants it to go away. I guess it could be worse; they could have been threatening to go after my knee-caps with a baseball bat.

Joking aside…

If original, innovative Open Source health information software is in the best interests of society, then software patents, as currently implemented  are a serious problem.

-FT

People often do not get why I am so convinced that only GPL Software should be used in Medicine. I can understand why. Without understanding the nature of Healthcare, people assume that I am being religious about the issue. This is the furthest thing from the truth.

It has been a while since I have blogged over at GPLMedicine.org. In fact you can see that I still have some site maintenance to do. But recently more attention has been given to the issue of Open Source and Software Freedom in medicine.

The Software Freedom Law Center has just released a paper called Killed by Code: Software Transparency in Implantable Medical Devices

Awesome title. Even more awesome paper.

The form of the argument is so simple:

1. Hey you are putting hardware AND software in my body? yep.
2. I cannot look at the software? nope.
3. And the software is hackable? yep.
4. Well that kinda sucks.

Feels kinda icky don’t it?

One thing I love about people with pacemakers or other implantable medical devices, is that they know they are cyborgs. Most people living in modern countries are cyborgs, but unlike people with pacemakers, they do not see it that way, because they carry their electronics, rather than implanting them. Makes no difference. In fact lets play a variant of “You might be a redneck“: I call it “You might be a cyborg..”;

• If you leave your cell phone at home, and you -must- to leave work to go home and get it, you might be a cyborg.
• If you will sleep through the morning unless a machine wakes you up, you might be a cyborg.
• If your spouse is jealous of your cell phone, tablet, laptop, server or workstation, you might be a cyborg
• If not wearing a watch makes you uneasy, you might be a cyborg
• If you view any relationship you have with an online service as an addiction, you might be a cyborg
• If you try to avoid walking more than 100ft in favor of a segway, bicycle, golf cart, or automobile, you might be a cyborg
• If you try to avoid walking more than 100ft in favor of a lawn mower, you might be a cyborg and a redneck

Our relationship with technology is becoming more and more personal, and the operating system to your mobile phone, the software your medical devices uses and the EHR system that your doctor uses to track your health information make software freedom ethical issues into personal freedom ethical issues.

Today, its people with pacemakers, but tomorrow, there will things that people consider normal to do with their own bodies that will either use software that the user controls, or software that some random company controls.

Thanks to the Software Freedom Law Center, for helping to make this issue more personal.

-FT

I am utterly not surprised to hear that OpenMRS is shining in Haiti.

This reminds me of the tremendous reponse that the VA had to hurricane katrina using VistA. For fun you should ask those involved for the inside scoop of how VistA enabled an entire hospital to uproot and move over the course of a single week.

Sometimes people do not really understand why we need software freedom in healthcare. These are two perfect examples.

Can you imagine the headache that per-seat or per-doc or per-patient EHR licenses would have caused in -any- haiti clinic? Of course they could always -ask- the vendor for temporary seat licenses, and because the vendors are decent human beings they would probably give them to them. Of course that only works when the phones work or the Internet is up.

Emergencies highlight the fact that health software users may have -very- different needs than the software vendor’s vision or even their own understanding. I know that the OpenMRS project will change substancially in response to the earthquake in Haiti. More importantly those changes will spread to other areas of the world… but those other users of OpenMRS will get the haiti lessons -before- the mudslide/tsunami/earthquake/bombing happens in their area.

In fact I can just imagine and administrator setting up OpenMRS for the first time and wondering “Hmm why would you ever need that???” and ten years later, when those features make OpenMRS better able to handle a disaster in that area, the same administrator will say “Ohhh… that’s why….”

Everytime I hear about something like this from the OpenMRS project I feel again guilty that I am not more involved….

-FT

It looks like WorldVistA is, for now, holding fast to the GPL and AGPL for VistA licensing. I have been a vocal advocate for compromising with DSS and Open Health Tools around the LGPL. The LGPL would allow for some innovations to be licensed under the GPL, and others, in the core of VistA to be compatible to bundle with proprietary software.

Recently, Skip McGaughey was quoted in modernhealthcare as saying:

“I believe it’s all about community-building,” McGaughey said. “I believe people have focused too much on technology and licenses and they need to focus on the care of individuals. If we can switch the focus from licensing and technology—the VistA community has a tremendous opportunity to fundamentally alter care throughout the world.”

“They’re starting from a base that has a tremendous knowledge base, built by care providers, tested and modified over a long period of time,” McGaughey said. “So, the opportunity is tremendous. So what we have to do is change the focus and quit worrying about the individual ‘me’ and talk about the ‘we’ together,” he said.

“If we enable an environment for people to collaborate in building infrastructure that everybody can use, to share the expense, what we can do is build the integration and interoperability and build a collaborative spirit,” McGaughey said. “Then people can climb the value stack to provide added value that can make money.”

It should be noted that I was not at the talk and did not hear exactly what Skip said. I know Skip and I know that he is a good guy, I think he intended to bring a message of reconciliation regarding licensing which is very good.  I may actually agree with Skip’s position, but I cannot agree with this quote. While I am in favor of compromising with Open Health Tools, the position of WorldVistA on insisting on the full GPL is not unreasonable and it is certainly not anti-people.

Lets be clear, when you talk about proprietary friendly licenses in medicine, you are not talking about a way for people to “make money” or “earn a living”, you are talking about a mechanism that traps software consumers into a monopoly relationship with a software provider.  Proprietary software in healthcare is so famous for abusing this monopoly position to the detriment of its clients that the issue is being investigated by congress and is even the subject of in-depth lampooning.

To trivialize licensing and indicate that is about “people” is typical and insincere. The software license defines the basic power structure of a relationship between software developer and software consumer. Full copyleft ensures that the developer and the consumer are always equals. Proprietary licenses ensure that the software vendor is in control. Open Source licenses that allow for proprietarization are a grey area. If software consumers are careful only to use Open Source components, they can maintain a balance of power, but if they ever allow a proprietary module into their ecosystem, then the license for that module puts some vendor back in the drivers seat.

If there was an “open” movement in the prisons around the world so that all prisoners were limited to just one shackle, they would still remain prisoners. Similarly as long as one software vendor can dictate terms to a clinic or hospital, they have a problem. Proprietary vendors who do not abuse their clients are like kind wardens. Just because they are nice a prisoner, does not change the fundamental power dynamic in the relationship.

The LGPL is a compromise precisely because it allows people who value freedom to work with people who are willing to compromise with proprietary vendors.

When you start hearing people saying things like “value stack” and “let people make money”, you are hearing the argument that being trapped is sometimes OK, if what you get for it is worth it.

This kind of power dynamic is precisely what prevents communities from trusting each other and cooperating. If you want to create community, you better not ignore licensing concerns.

-FT

Who owns the health information?

• the patient to whom it refers?
• the health provider who created it?
• the IT specialist who has the greatest control over it?
• the researcher who aggregates it?
• the health 2.0 company that harvested it?

the notion of ownership is inadequate for health information. No one has an absolute right to destroy health information. But you can drive the car you own into a tree or into the ocean if you want to.

All of the groups above have a complex series of rights and responsibilities relating to health information that should never be trivialized into ownership.

But asking the question at all is a hash argument.

What is a hash argument?

Come to think of it, there’s a certain class of rhetoric I’m going to call the “one way hash” argument. Most modern cryptographic systems in wide use are based on a certain mathematical asymmetry: You can multiply a couple of large prime numbers much (much, much, much, much) more quickly than you can factor the product back into primes. A one-way hash is a kind of “fingerprint” for messages based on the same mathematical idea: It’s really easy to run the algorithm in one direction, but much harder and more time consuming to undo.  Certain bad arguments work the same way—skim online debates between biologists and earnest ID aficionados armed with talking points if you want a few examples: The talking point on one side is just complex enough that it’s both intelligible—even somewhat intuitive—to the layman and sounds as though it might qualify as some kind of insight… The rebuttal, by contrast, may require explaining a whole series of preliminary concepts before it’s really possible to explain why the talking point is wrong.

At some point I will modify this article to actually do the rebuttal. At this point it is enough to say that -even asking the question- who owns the data is creating a hash argument. The question presumes that the notion of ownership is valid and jettisons those foolish enough to try and answer the question into needless circular debate. Once you mistakenly assume that the question is answerable you cannot help but back an unintelligible position.

People asking this question at conferences is a pet peeve for me.

-FT

As many of you know, the CHIP/Indivo/Harvard guys (who I guess I should call the ITdotHealth guys) wrote an article in the NEJM saying that we needed something like the Iphone app store in Healthcare IT.

I wrote a rebuttal saying that, among other platforms, the Google android platform was a better fit. Frankly, I thought that would be the end of it. Most of the time I write a blog post, I get some hits, and maybe a comment if I am lucky. But mentioning the iphone is great for getting attention. Apparently, just saying the word iphone brought the readers out of the wood work. iphone iphone iphone <- (just to be sure…).

More than just getting some good comments I have just realized that Ben Adida (check out my blog roll) wrote a Knol that touched on my criticisms and argues convincingly that there needs to be some balance between openness and safety.

Though it is clear that Apple’s regulation of the iPhone apps market has gone far beyond malware prevention, the goalof malware prevention is certainly reasonable.

I think he is right on, and I look forward to talking about it with him in person tomorrow. I think now, the night before the conference, it might be a good time to drop my thoughts about what platform analogy would really be the best to reference as we move forward. I also take a moment towards the end of the post to concede some of the things that Apple really got right, since I do try to be fair.

If I had to pick one thing that best embodies the 10 principles that are being targeted here, I would pick yum. Yum is the update manager for Red Hat based operating systems. Here’s why:

1. Like the iphone app store, it is ”substitutable (first of the ten points). You can download like 10 different web browsers on the current Fedora.
2.  It built its own protocol. RPM was a lower-level standard, and yum was born as a meta-tool on that standard.
3. Yum allows for multiple platforms. It forms the basis for the software packaging for just about every Red Hat/Fedora based operating systems, of which there are several.
4. The API for yum is open, which is what lets things like yumex happen.
5. The programs installed by yum never have direct control over yum (unless that is the point of the program, and that is what the user wants to do).
6. Application install is as pointy-clicky and as user friendly as it gets BUT you do not lose the power of command line script-ability. Talk about walking the fine line!!
7. Separation between the copyright/patent/trademark of applications and the platform is totally there! You can point your yum to a proprietary repository, for instance to download Adobe flash… no problem.
8. Unfortunately it does not make any sense to say that you can remove everything from yum and still have a platform. So I guess it strikes out on that one. Of course, I am not sure why the platform itself should -not- be considered a package on the platform… Ill have to ask about that tomorrow…
9. Yum is really really efficient. You can update applications very quickly, and you can even install a special yum module that will find the fastest download servers, ensuring the best experience for downloads.
10. The certification is as minimal as can be. The packages -can- (not required to be) signed by the people who set up a repository, and you simply do or do no trust that signature.

Someone will point out, someday, in comments that apt-get is just as good and does all the same things. To that future commenter I fully admit that you are 100% correct. I am a long time Red Hat guy and I am letting my colors show, for the record I am trying Ubuntu on my desktop for now….

Now let me point out a couple of cool things about yum that are not on the “big ten” but that I think are worth emulating:

1. Yum is actually an upgrade to a previous platform, Yup. Yup was good, but users forked it and made it much better… then the original yup developers adopted yum. That’s the virtuous cycle of Open Source in action if I have ever seen it.
2. Yum handles “trust” in the system, by getting out of the way. A “default” repository is trusted to get the system off the ground. But you can “trust” other repositories to get upgrade versions of the software you are currently using, to get substitutionsfor the programs you were currently using, or to get new software that is found nowhere else. It automatically find the balance betwen openness and security. Users make the decision about how to trust, and the system does not auto-branch beyond those decisions.
3. Although yum violates principle 8,  you get the benefits of being able to use the platform to upgrade the platform. You can upgrade a late-generation yum operating system while it is running.
4. The yum platform was central making a larger community effort. Remember when Red Hat stopped doing Red Hat Linux, instead creating the Fedora project and RHEL? Fedora existed before that, as a high-quality repository of Red Hat packages! yum was an important new feature of Fedora Core 1. The yum platform helped move the whole community forward.

So I think the yum project and the way that Red Hat made into a software distribution network is a pretty good model to follow.

Even I, however, get why they original authors chose to use the iphone as an analogy. Not assuming that these points are original, I want to point out some things that Apple did right, that other systems have failed at.

1. Apple enforced simplicity. They refused to allow programs to run in the background. They refused to allow many other things that a developer for Windows CE might have expected. They made the core interface as simple as possible. They even excluded cut and paste initially to make the system simpler. Apple put these restraints in place because by making the applications simpler, they made the user experience vastly more intuitive.  I have used countless “modular” or “substitutable” platforms that miss this.  It is the platforms responsibility to protect the overall user experience, -not- the application developers. That means knowing when to say no. Ignore this one at your peril.
2. Apple built a meritocracy at the level of the end user. When you see an application on the iphone that has been used by 5000 users, and they have all rated it 5 stars, you can be pretty sure it is good. That rating stands front and center in the platform, and more importantly, the platform itself constantly promotes and rewards its star performers. On other modular systems, I usually spend a lot of time trying to sort out what modules are reliable. The Firefox module system has also done a good job of this.
3. Despite its habit of blessing particular development groups with special privileges, Apple also made it easy for the individual developer to become a super star on the platform. It did that by giving people pretty substantial development tools and a robust development environment.  If you want to get rock star developers you have to give them their version of the red carpet. That means awesome documentation, video tutorials and lots and lots of working examples.

I figured I would jot down these thoughts before the conference, so that I can have the most fun while there. Apparently, some of these people are actually reading this… so its a very efficient way of making points as opposed to taking the whole conference to dinner with a Fred-monologue.

-FT

Recently, someone contributed a library to help with the webification (<- clearly this is a real word) of VA VistA. In a recent HardHats thread, he expressed his discouragement. I responded and I thought it might help other discouraged developers out there to read me reply. Sometimes the Open Source community just does not respond to good contributions. Here is some of what he wrote:

Jim,

Working with the FOSS health community can be very trying. I fully understand how you feel. I felt that way in the early days of FreeB, which has still not been adopted by the VistA community.

Here are some basic insights about how to get things done in the FOSS Health IT community.

1. You have to be prepared to fully ignore the peanut gallery. There will always be people who have no idea what it means to develop making comments as though they were developers. This is actually a negative side-effect of something positive: this community basically treats clinical users and software administrators as equals. That is a wonderful thing but it means that contributors like you have to learn to ignore people who are not really in your target audience.
2. Your audience is developers, a small subset of this community. Developers are typically very circumspect group and are often lurkers on Hardhats and elsewhere (I am a notable exception to that rule).
3. Developers never have any spare time, we always have something worthwhile that we are working on. That means for your software to get attention, it must win out over other interesting projects for any given developer.

Without presuming to speak for the rest of the development community here, I personally cannot afford to spend time on time-sink projects. Frankly, until Astronaut arrived -as a shared development environment- VistA as whole fell into this category for me. Once you get EWD working in Astronaut then it will be a different ball-game. Then a developer like me, who has very little time, can still afford to evaluate your library for potential projects. If you want an even wider audience, you should try to get EWD included, fully working, out-of-the-box in OpenVistA. Not every developer feels this way, some of them are entranced with the hard way, preferring to compile everything they can themselves from scratch just to be able to say they did.

For VA VistA there are two phases of adoption, first the VistA platforms, and then the developers who rely on those platforms. You are still at the first stage, and you should expect that only the VistA Demigods will even look at your stuff before the platforms adopt it. There are very very few VistA Demigods, which explains the reaction that you are seeing. Once the platforms have adopted your code, mere mortals like myself will consider using it for various projects. There are lots of mere mortals in the FOSS Health community. Do not get discouraged about how things are going now. You should only be discouraged after about a year of inactivity -after- the VistA platforms include your code. At that point I would assume that some other webify-VistA strategy had won out.

This is -not- a criticism or meant to imply that you have failed at anything. You have done some great work, and that is true if your code becomes popular or not. Sadly, the best code does not always make the most popular projects or vice-versa. FreeB eventually became popular, but it was certainly not because it was good code. Success in Open Source is very often an accident of history. Your code might not take off the way other code has. But no one has control over that. Even people with successful projects did not -know- that they would be successful. Everyone has to do just what you did, put your code out there and see what happens.

For my part, I have as much respect for you as I do for the pioneers of our movement. People like Torvalds, Larry Wall, Stallman, and that ilk. It is worth keeping in mind that they got famous because their technical approaches -happened- to win out. But when they started they had to stick there necks out there just like you are. I will not lie and tell you that the reputation gains that you will get will ever approach the benefits that those people enjoy. Even if you are a success in the FOSS Health community the best you can hope for reputation wise in the FOSS Health movement is a LinuxMedNews award, and even that will probably not happen unless your project succeeds. For every project that “wins” in Open Source there are ten or perhaps even more that die on the vine (take a look at the stats on sourceforge) do not be offended if that happens to you, it means nothing.

Community members who have a clue about this will still give you plenty of credit for your work, and you will be surprised how loyal even a small group of users can be. You may have people seeking you out for years to get consulting on your project, even if it never really gets off the ground! In any case, those of us who have gone through what you are going through will always be quick to recognize a fellow contributer and give you the respect and appreciation that your work deserves. We do this because we recognize that your actions take courage, and unless lots of people continuously find the courage to risk what you have, our community will begin to rot.

To sum up: Do not let the turkeys get you down, be patient, and if your project ultimately fails remember to make like Obi-Wan Kenobi.

-FT

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

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

.
.
.
.
.
.
.
.
.

Hi,

Currently, in Texas,  one is required to take Physics I and II and Calculus I (or equivalent stats class) to apply for Medical School. That is not all, of course, but they are requirements.

So far, I have never meet a Medical Doctor who needed to use calculus. In fact the only ones that might need to really understand the subject are those who are doing high-level mathematical modeling for Bio-Informatics. For these researchers Calculus is not enough. Your average primary care doctor, *never* uses calculus. They also *never* use Physics! Of course they have all kinds of systems that obey the laws of physics, including blood pressure, syringes etc. But they never treat a patient and think “hmm.. what was the relationship between volume and temperature of a gas….”. They think in higher level abstractions like “When blood pressure is high that could mean X, or Y or Z depending on….”

The real benefit of Physics and Calculus is that they introduce you to new ways of thinking. That new way of thinking makes it easier to understand higher level concepts that you *will* use everyday as a doctor.

I recently had a conversation with a clinician about some work that I am doing on the NPI database which lists every doctor (that prescribes medicine) in the United States. The conversation went like this.

Fred: “I need to munge the data, I need to process the data in a different way than it is listed (a flat CVS file), I need to turn into a real normalized database before I am going to be able to use it effectively”

Clinician: “Wow… Ok… How long will that take you”

Fred: “Well you do not want me to work on this full-time do you? I only have about 5 hours a week I can work on this in my current schedule..”

Clinician: “Yea.. but your other projects are pretty important… given only 5 hours a week, how long would this take?”

Fred: “three months.”

Clinician: “Boy… that’s a long time… I know! Why don’t you just create a database with Texas doctors, instead of all the doctors in the United States! How long will that take?”

Fred: “three months.”

Clinician: “That makes no sense at all. How can that be possible?”

Fred: “Well making the database smaller does not really help me at all, that is the part of the problem that the computer takes care of, not me”

Clincian: “Cmon. A smaller database should mean a shorter time, this seems almost obvious to me. You should be able to do it faster than that. ”

Fred: “Ok.”

Clincian: “Ok, so how long for just a Texas-only database?”

Fred: “three months”

and so on…

Now lets point out… first of all… that this Clinician is not stupid. He was ignorant of how computers, and more importantly of the process of programming computers. This issue is worth discussing in detail because it really illustrates the thought gap between someone who knows how programming works, and someone who does not.

There are many NPI records, specifically in a recent (May 2008) release of the database there were 2,557,650  lines in the comma delimited file as revealed by “wc -l” (subtracting one to account for the first line in the file, which is full of labels… not a real NPI record)

The changes that I need to make to fix the NPI database are pretty complex (fodder for another post) but for now, I will just say that it is a “Complex Reordering of each Record”. Here is how my process for approaching this problem looks:

First I need how to process a single record. So I write a function to do that. For the sake of prose, I will call that function

complexReorderingOfEachRecord( $Record )

I will look at the one Record in the NPI database and then try to pass that Record into the function and see if it does the right thing. The complexReorderingOfEachRecord is a long function, it does lots of really complex things. So complex in fact that I really cannot keep all of its functionality in my head at one time. I use various ways of abstracting the problem so that I can think about the problem in useful chunks, and figure out if each chunk is working.

I am going to actually include some psuedocode in this post.  Psudeocode is code that is not exact enough for a computer to execute, but is clear enough that a human can read it and understand what it does. Programs are like recipies, they are simply exact  instructions that the computer will follow. I will use some basic programming elements in my examples (Note to programmers: this blog is also for clinicians… so you can safely skip this…)

• Sequential execution – Each line of code is read and executed by the computer before moving down to the next line
• Variables – a variable is a changing placeholder for information. Each time a program is run, it is possible that the variables will contain different values. I use php, so I mark my variables with dollar signs “$”. This ends of working alot like the “x” in an algebra problem, it can have different values depending…
• Functions – It is often useful to merge many simple lines of code into a single function. Later you can execute all of the code inside the function by calling the function name and passing data to the function by putting inside the parens “()” after the function. It is basically a way to group useful bits of commands together.
• If/Else statements – when the computer reaches an IF statment it looks at the contents of the paranthesis “()”beside the if statment. If the contents are “true” then the code inside the braket symbols “{}” following the if statement is run. If the statement in the parens “()” is “false” then the code in brackets “{}” following the ELSE statement is followed.

So the inside of the complexReordingOfEachRecord looks like this

function complexReorderingOfEachRecord( $Record){

                 reorderingStepOne($Record);

                 reorderingStepTwo($Record);

                 reorderingStepThree($Record);

 }

(Note to Programmers: I am actually using an OOP design for my project, so in reality these would be function calls on objects, but I want to keep this on a procedural level to make my point)

complexReordingOfEachRecord, reordingStepOne,  reordingStepTwo, reordingStepThree are all functions. The contents of recordingStepOne are not shown, but they are custom functions, meaning that I wrote them. $Record is a variable. There are no IF statements yet.

Ok.. I write this code, test it, debug it about 15 times before it works to import 1 record. But then I run the code on the first 10 records my system blows up! Some NPI records are not for Doctors at all, they are for organizations that provide healthcare: Doh! I need to run the program differently for people vs organizations!

So I modify my function to look like this:

function complexReorderingOfEachRecord( $Record){

                 reorderingStepOne($Record);

                 reorderingStepTwo($Record);

                 $isAPerson = reorderingStepThree($Record);

                if($isAPerson){

                          doOneThing($Record);

                }else{

                          doAnother($Record);

                }

 }

Now the function has one IF statement that looks in the variable isAPerson and then executes either doOneThing or doAnother based on the contents of $isAPerson.

I have to code, test and debug this another 30 times to get it working. I have to test it more times because the new function calls doOneThing and doAnother do not work without modifications to reorderingStepOne and reorderingStepTwo. I have to switch between thinking about different part of the problem very quickly to make sure it works. To start, everything breaks, but as I discover why, by running the program again and again, I make small changes that eventually make the whole process work correctly. The shorthand for this process is code, test, debug, repeat.

As I am working I start to run the program on the first 100 records. I notice that often the person in the record is not an M.D., there are also dentists and other clinicians who are in the database ! But my work is focused only on M.Ds. So I modify the code again:

function complexReorderingOfEachRecord( $Record){

                 reorderingStepOne($Record);

                 reorderingStepTwo($Record);

                 $isAPerson = reorderingStepThree($Record);

                if($isAPerson){

                          $isAnMD = doOneThing($Record);

                          if($isAnMD){

                                       processMD($Record);

                          }else{

                                      processNonMD($Record);

                          }

                }else{

                          doAnother($Record);

                }

 }

Now I have a “nested” IF statement, an IF statement that exists in another IF statement.

As before all of the other functions must be modified to make my two new functions processMD and processNonMD work correctly. This requires 50 repetitions of code, test and debug. Sometimes one code, test and debug cycle takes 30 seconds. Usually it takes about 5 minutes. Sometimes it takes as much as 15 hours.

Now I am testing against 1000 rows of the NPI database, and it works perfectly! I have put in about 40-50 hours (or about 3 months at 5 hours a week)

But now what! I have only imported only 1000 rows of the database. Now I will explain how I ran the code on one row, 100 rows and then 1000 rows. I will introduce the WHILE statement to my simple psuedo code.

$i = 1

while($i < 1000){

            $Record = getANewRecord()

            complexReorderingOfEachRecord($Record);

            $i = $i + 1

}

The “while”is just like an if statement, except that when the contents of the curly brackets “{}” are done, then the contents in the parens “()” are re-evaluated. If they are still true, then the contents of the “{}” are run again. The $i variable starts at 1, and then grows by one every time the contents of the curly braces are run “{}”

So how do I import the whole NPI database? I change to code to look like this:

$i = 1

while($i < 2557650){

            $Record = getANewRecord()

            complexReorderingOfEachRecord($Record);

            $i = $i + 1

}

Then I start the program and go to sleep. In the morning, all 2,557,650 records are correctly processed.

Once I had done the work to determine “How to change an NPI record” the computer simply repeated that process for as long as I wanted. Computers are so fast now, that even very very complex processes can be repeated very quickly.

You see *I* never import any data. The computer does that part. *I* the programmer tell it *how* to import that data. Like doctors, when programmers have a simple concept with big implications, we create an important sounding word for it. The important word for *how* to do an information task is “algorithm“.

If you get an algorithm right, computers do just what you want. If you get the algorithm wrong… computers do other things. If you get the algorithm badly wrong… God help you.  This is why computers often seem to have a “mind of their own”; when programmers tell them to do the right thing, they do exactly that. When programmers tell the computer to do the wrong thing… they do exactly that.

Any programmer reading this is likely going blind with boredom. But someone who has not programmed might likely be asking “Wait… what’s a function?” This is actually a pretty terrible introduction to programming. For something more real, I suggest you start here.

My point is this, computers make some types of tasks really easy. Getting to them to do those tasks, without making a serious mistake, is pretty difficult and time-consuming work. If you, as a clinician, do not understand what tasks are hard, and what tasks are easy, then it is almost impossible to evaluate the software you are using. I cannot tell how many times a clinician has requested a “simple change” that has taken me three weeks of programming. On the other hand, I cannot tell you how many times I have seen clinicians (or more often clinicians staff members) subject them selves to terrible software designs that would be trivial to fix.

To create an algorithm you need to understand two things:

• What the computer can do
• What the computer should do

There are some people, like my friend Ignacio Valdes, who have been extensively trained in Computer Science and Medicine. These people are amazing, because you can watch them switching back and forth between one part of healthcare IT (Clinical know-how) and the other (Computer Science know-how). But even these few gems (rare as hens teeth), cannot actually hold the complexity of even a single clinical IT problem in their head at one time. That is just not the way that programming, clinical care or anything truly complex works! Programmers must ignore parts of a program to improve on any given part. Clinicians must ignore parts of a patients body to address a problem with one part. (Most heart surgeons, for instance, remain unconcerned about the flaky skin problem while their patients are in open heart surgery.) Knowing what to ignore, and what deserves attention is often the true test of expertise.

The only way to deal with Healthcare IT is to create teams of people to manage the complexity together. The problem with that is that for any given problem domain, there is a danger that the communication cost will grow exponentially in relation to the number of participants. It is common for the communication costs to totally destroy all productivity in a given group. But at the same time, it is simply not possible for a single person to correctly navigate the complexity of even a simple Health IT software project.

The solution to this problem is found in the VA VistA development model. Here are the rules:

1. You do not work on “the system”, you work on part of the system. VistA is actually hundreds of programs that work together.
2. Whenever possible you work in pairs. Any more gets unmanageable.
3. One person must understand everything they need to about the programming of the clinical issue. We can call this person the Programmer. (In the VA this is a Programmer or a CAC)
4. It helps if the Programmer has a basic healthcare vocabulary.
5. Another person must understand everything they need to about the clinical problem itself. We can call this person the Clinician.
6. It helps if the Clinician understands, basically, what is easy, what is hard, what is possible and what is impossible with computers.
7. You rely on other pairs to address other clinical problems.
8. You intentionally have redundant “programming pairs” so that you are forced to compete to make better solutions.
9. When another pair makes a better solution to your problem, you celebrate that and adopt their code as the new starting point.

Its number 6 that this article is focused on. It would be really helpful if Physicians in particular were required to know what a “for loop” meant. Just like calculus and physics they will rarely, if ever, use that information. But for the time being, the fundamental lack of understanding of computer science in clinicians is holding healthcare back. Can you imagine speaking to your doctor if he or she had no idea what the word “pressure” meant in the phrase “blood pressure”. As it stands, most doctors do not really understand what the implications of the word “Information” in the phrase “Health Information Systems”.

What scares the hell out of me is not that the clinician above did not know how the programming process worked. Ignorance has a simple cure: learning. What scares me is that he was willing to pressure me to speed up the schedule, even after I explained how things worked. Trying to force a programmer to take short-cuts to make a deadline is a very very bad idea (see point number 4 here). Doctors, like military officers, often fail to recognize that in “being in charge” is contextual. It does not matter if a Doctor is right about a clinical issue, if they are wrong about a software design issue. The resulting software will fail to perform, despite its clinical correctness. Doctors cannot “be in charge” in software design the way they can in an operating room or in clinical practice. That does not mean they are not vital, it just means they should not be in charge. The programmers should not be “in charge” either. The “Clinical Pair Programming” that I am describing above is a description of the peer thinking that is required to solve these problems. When someone is “the boss”, (meaningly the actively back only their own agenda) the system breaks.

The irony is that the few Doctors I know who are my peers with regards to computer science education, are often more hesitant to challenge me regarding my information systems opinions. Do not get me wrong; they often disagree with me, but not more than any programmer would disagree with any other programmer.

This is why I support an undergraduate computer science prerequisite for medical school.

-FT