Novice EHR Development is now unethical

The original Hipoocratic Oath states:

I will not use the knife, not even on sufferers from stone, but will withdraw in favor of such men as are engaged in this work.

One modern version reads:

I will not be ashamed to say “I know not,” nor will I fail to call in my colleagues when the skills of another are needed for a patient’s recovery.

The idea here is that a doctor needs to recognize when another practitioner has a skill that they do not, and that they must refrain from “practice” when another person has demonstrable expertise in that area of practice.

It is now 2013. It is time for doctors to stop “writing their own EHR” from scratch. They need to bow out of this in favor of people who have developed expertise in the area.

I just found out about another doctor who has decided to write his own EHR, because he has not been able to find one that supports his new direct pay business model adequately. In the distant past I encountered a doctor who believed that his “Microsoft Word Templates” qualified as an EHR system. This is a letter to any doctor who feels like they are comfortable starting from-scratch software development for an EHR in 2013 or later.

You might believe yourself to be an EHR expert.

Are you sure about that? Are you sure that you are not just an EHR expert user?

This difference is not unlike your relationship with your favorite thoracic surgeon. Or for that matter, your relationship with the person who built your car. The fact that you are capable of expertly evaluating and using EHR products does not mean you are qualified to build one. Just like the fact that you are qualified to treat a patient who has recently had heart surgery or to discern when a patient might need heart surgery does not make you qualified to perform that heart surgery. Similarly, the fact that you can drive, or even repair your automobile, does not provide you with the expertise you need to build a car from scratch.

The ethical situation that you are putting yourself in by developing your own EHR is fairly tenuous. Performing heart surgery without being a heart surgeon, building and driving your own car without being an automotive engineer and a doctor coding their own EHR system from scratch all have the same fundamental problem: You might be smart enough to pull it off, but if you don’t you can really mess up another person’s life. Make no mistake, you can kill someone with a shoddy EHR just as easily as by performing medical procedures that you are not qualified for or by driving a car that is not road-safe.

It is not that heart surgeons, automotive engineers and EHR developers are not going to kill people with faulty performance. All experts are fallible. But they will kill far fewer people than you would, performing outside your expertise.

I can understand your feelings of frustration. You likely have totally different goals in mind than the average third-party-payer oriented EHR system has. You are right to be frustrated with the shackles that those systems have placed on you. But you are very wrong to presume that it is ethical for you to do “amateur hour” on your own.

You presume that because you can see the problems with EHR developer performance, that this makes you qualified to build a better EHR. You are utterly and unequivocally wrong about this. Sometimes, EHRs have features that are designed for clinical CYA, basically over-documentation for the sake of unethical defensive medicine. Sometimes EHR systems are designed to be glorified practice management systems, designed mostly to ensure that doctors maximize their paycheck at the expense of patient care. Sometimes EHR design decisions have no rational behind them at all… they are frequently the result of original design whims that are hard to correct in subsequent editions of an EHR product.

But sometimes a feature that frustrates you is precisely what makes that EHR safe for patients. I can promise you that you cannot tell the difference between flaws and features without looking carefully at both the internals of the EHR system and all of the clinical workflows it is exercised in. What you think of as a flaw might be a software crumple zone.

Happily, you get to have your cake and eat it too. There are several Open Source EHR systems that are already meaningful use certified. You can use these Open Source EHR systems for nothing, and for very little money you can even get Meaningful Use credit for using these systems. Given this, you have no excuse to continue to develop an new EHR.

Open Source gives you the right to change what you need to, in order to get the functionality that you want.. and more importantly can connect you with experienced health IT developers, who can serve as a gut check for you as you consider how to implement the features that you need for whatever clinical variation you are interested in implementing.

This is very like the person who orders a “kit car” to build in their garage. They get to -feel- like they are building the car, and indeed they get lots of options normal car owners do not. But in the end, they are able to build a car safely because someone else, someone with specific expertise, has made sure that design of the kit car is fundamentally sound.  You can always shoot yourself in the foot with kit cars and Open Source.. but you have the power you need without being in over your head.

The development of mature EHR systems has been very similar to the development of surgical methods. Primitive EHR systems and primitive surgical procedures were both deadly. In both cases, medical science has already sacrificed thousands of people to the “cause” of learning how to do these things right. In 1850, it would have been entirely appropriate for any doctor to “dabble” with creating their own surgical methods. Even as recently as 2000, it would have been appropriate for you to “dabble” with the creation of your own EHR system. (eMDs was started by a doctor dabbling in 1996. eClinicalWorks was started in a similar fashion in 1999). But those days are over.

A doctor developing a new EHR system from scratch, by themselves, without extensive Health IT programming experience is in over their head. If they continue to develop an EHR, even after being warned of the dangers here, then this is hubris.

Ask yourself: Are you absolutely sure that this action is not a fundamental violation of the oath that you took when you became a doctor?

I want to be clear, I have worked on or around the development of EHR systems for more than a decade, and I would not presume to write a new EHR system without a team of programmers and years of funding. Its not that I think that “a doctor” is not qualified to undertake this task. No single person is.

I wrote a book designed to ensure that novice programmers had basic training in complex Health IT principles. Programmers can be guilty of hubris too, and I consistently advocate for a “clinical pair programming” approach. David Uhlman (my co-author) and I wrote the book because too many people assume that Health IT is easy, and they wonder why things in the industry are so “primitive”. The book is intended to teach clinicians and programmers alike humility when approaching clinical information systems, both as users and as developers. FSM knows that I have been dangerously arrogant regarding clinical information systems, and I have and will make serious mistakes. But there comes a point where making the same mistakes that others have made, and written about, becomes unethical. I think we have reached this point with EHR systems.

Some people took offense that I should link to my own book at the end of this article, so instead I have included some of the reference materials that I use frequently. This is a good sampling of the kind of context that really should be required of any modern Health IT developer.

Begin with Information and Medicine by Marsden S Blois. Then move on to Principles of Health Interoperability HL7 and SNOMED by Tim Benson and The CDA Book by Keith Boone. Finally, you should read about what can go wrong in Health IT by studying EHR generated errors with Clinical Information Systems, Overcoming Adverse Consequences by Dean E Sittig and Joan S. Ash.

These are the books that I refer to when I get stuck on something. I wish I could just hold it all in my head, and in many ways my book is just the cliff notes I need for myself. If you know of other books that should be on the “Health IT required reading list” please leave them in the comments…

-FT

Medsphere OpenVistA meaningful use certified

I am happy to mention that Medsphere has received certification for their OpenVistA EHR system.

As far as I know, this is the only meaningful use certification for Open Source software, for the in-patient setting. All of the other certifications that I have mentioned so far have been ambulatory.

Congratulations to the Medsphere team. This is an important accomplishment, and a milestone for the Open Source health software community.

-FT

Health Foo Camp

I am happy to announce that I have been invited to the first ever Health Foo Camp. There is not even a web-page for this yet, but it has been previously announced on the RWJF blog

FOO stands for Friends of O’Reilly. It is an invitation event that puts some of the top geeks and thinkers in the same room. This is the first health-focused FOO camp.

This is a pretty big deal for me. The moment I first heard of Foo Camp, I realized that going to one was on my bucket list.

This was similar to the first time I realized that Regina Holliday sometimes auctions off her art. I realized that being wealthy enough to win an auction of one of her art work was my new definition of being rich… I also secretly covet one of her custom jackets.

Anyways, when something like this happens I begin to realize that maybe I am making the difference I want to with my life. It looks like people are finally taking this whole Open Source Health Software thing as seriously as I do. Its a pretty awesome feeling and after sharing a celebratory dinner with my wife, and soaking up the good news for a few days, I thought my readers might like to share in my sense of satisfaction. At least I think I have readers….

-FT

ClearHealth, the first Open Source EHR Meaningful Use certified

I am happy to report (a little late) that ClearHealth is now the first commercial Open Source EHR product to be meaningful use certified.

This project holds a special place in my heart, since David Uhlman and I started it years ago as next generation PHP-based Open Source EHR. It is theoretically possible that some code that I wrote, all that time ago, has actually carried over into this certified version. A careful analysis of the sourcecode tools would probably reveal that I can take credit for perhaps 5 or even 6 carriage returns, in the current ClearHealth code-base.

In all seriousness, the ClearHealth project has grown by leaps and bounds. The PHP-product from ClearHealth, Inc has leveraged many of the innovations from the WebVistA project. Making it probably one of the most capable and robust web-based EHR systems in existence. Only OpenMRS competes in terms of complexity and scope at this stage. Unless Tolven, OpenEMR, PatientOS etc can get their act together, this certification will set ClearHealth aside as the “one project to rule them” in this space.

More importantly, ClearHealth is not ignoring the needs of its community users. They are developing a path to self-certification for ClearHealth users who rely on the community edition of the product. Pretty amazing stuff.

-FT

Prior Art for the BillingNetwork Patent Troll

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

Update 12-01-10: It turns out that someone decided to go toe to toe with BillingNetwork and apparently won. HorizonMIS announced dismissal of a Patent Infringement suit brought against it by BillingNetwork. Bob Bortz called this to my attention and offered to share his experiences with others attacked by BillingNetwork, you should be able to get a hold of him through the contact information at the bottom of the press release.

OpenMRS shines in Haiti

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

VistA License debate: its about proprietarization

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

Enabling open core

What license should you consider for your new Health IT platform? As you consider that, you should think carefully about your user audience. You want people in the Open Source community to develop against your code. You want people to add value to your core. To achieve this you have to recognize that our community does not share universal motivations. The most important detail that you need to understand about our community is the ways in which we we relate to proprietary software.

There are two general ways of thinking about how to relate to proprietary software within the FOSS movement.

There are those that believe that the most important potential feature in software is the ability to change and share it without restriction, which is software freedom.

Others in the FOSS community feel that the important issue is that we have a good method for collaboratively developing good software and if people want to make money selling software that restricts freedom (the definition of proprietary software) thats fine.

I am solidly in the first camp. However, for the purposes of this article I will treat them as equally valid perspectives. This respect for an opposing opinion is crucial for the FOSS community because we want to be able to develop software together!

People in the first group we might call freedom sticklers and the second group we will call pragmatic openers.

Before we move on we should discuss the basics of licensing. I have written on licensing before, but you will find my freedom stickler bias in those writings. I will try to avoid that here.

The most important thing to understand about licensing (for this discussion) is to consider the perspective of the person who accepts a license with the intention of redistributing the sourcecode with other software.

Imaging that Ozzie the Originator released some valuable software called coreware. He decides to release the code as open source! He must consider several perspectives as he chooses a license.

Freedom loving Fredi 😉 wants to ensure that whenever possible software that he writes will not be used to allow someone to control another person. Fredi appreciates the value of coreware and writes a module for it called Fredis freely scanning module.

However Proprietary Pat also has scanning application that has far more functionality than Fredis module. She likes the idea of open source but, for whatever reason, is not in a position to release her own software under a FOSS license. It is important to note that if Pat did not have a functionally better scanning module than Fredi, there would be no reason for Ozzie to consider her interests. Ozzie knows that when an open option is available, functional and stable end users will always prefer it. This can be called the Open Source Sets the Floor effect.

Pat has software patents and proprietary software that she feels must be protected from the full GPL (a license popular with Fredi and his ilk). Certain provisions of the GPL can have the effect of devaluing software patents, or at least that is how patent owners often feel about it.

Then there is Indifferent Ingride who writes a printing application. She has no specific position on proprietary vs. FOSS. She just wants her printing software to be as useful to as many people as possible.

Ingrid, Fredi and Pat would all be willing to help Ozzie improve coreware assuming they are happy with the license. Ozzie knows that if everyone is not happy, someone will start a competing project with a license more to their liking. This would dilute the talent pool available to work on coreware!

Ozzie the Originator is a bind. He knows that he can chose a proprietary-friendly license like the Mozilla Public License or the Eclipse Public License that will make Pat happy. But Fredi will never agree to a license that would be incompatible with the licenses that ensure that he can keep his own software freedom respecting. For people like Fredi there is no substitute for two very popular keep-it-free licenses the GPLv3 and the AGPL. The Free Software Foundation keeps a list of licenses that are and are not compatible with the GPL.

What is Ozzie to do? How to keep both Fredi and Pat happy? The first place to look is the LGPL which stands for the Lesser General Public License. This license does two important things, first both Pat and Fredi can use coreware as the basis for the coreware + someothermodules under their preferred license. You can think of coreware + somemodules as a “rollup”.

From a licensing perspective some open source rollups are loosely coupled (like GNU/Linux distros) while other rollups are more tightly coupled (like the Linux kernel itself). Tightly coupled rollups must have identical or fully compatible licenses. Most thinking says that if one software package locally calls the functions exposed in another software package, then they are tightly coupled. (Any VA VistA -server- rollup is likely to be considered a tightly coupled rollup while the relationship between VistA clients and VistA servers would probably considered loosely coupled). It should be noted that these ideas are generally accepted as flowing from a consensus understanding by the Open Source community lawyers of the copyright rules of derivative works, not all of them look at this way.

Ingrid can release her printing component under the LGPL too; essentially adding it to the core… Both Pat and Fredi will then benefit from Ingrids code. Of course end users will have to chose between Pats code and Fredis code because their chosen licenses are incompatible. Each of them is creating a new rollup of coreware with a different family of licenses. While coreware can be included in each rollup, the two rollups are license incompatible.

Both Fredi and Pat can collaborate on coreware with a LGPL codebase because they know that in the end the license of their own module will determine how the LGPL acts for the their users. For Fredis users the LGPL upgrades to the GPL and the AGPL, but for Pat, the LGPL does not interfere with her proprietary license.

Everyone is happy. (or close)

Is the LGPL the only license that is intended to work in this way? No, but it is the license that is specifically designed to solve this problem. Another license that attempts to be compatible with GPL/AGPL projects is recent iterations of the Apache license. Apache is generally considered more proprietary friendly than the LGPL. If Ozzie uses the Apache license, Proprietary Pat could make changes to the internals of coreware, that she does not need re-distribute. Both Apache and the LGPL give here the right to “hoard” or “protect”, depending on your perspective on the matter 😉 her module. But Apache also allows her to horde/protect her changes to coreware itself.

The reality of licensing is that at least two parties must be satisfied with the license. The end user and the most significant contributor. The GPLv2 made Torvalds happy, and his end users tolerate it. Everyone else in the Linux universe tolerates the GPL for Linux because the value of Torvalds original contribution and those contributions he was able to amass around that original contribution. Together these are too valuable to try and replicate. Companies that hate the GPL and everything it stands for, like Microsoft, contribute GPL code to the Linux kernel because Linux is too important for them to ignore. (P.S. If you hear someone talking about these issues in terms of viral or non-viral, you can bet that freedom is not a priority for them)

For VA VistA we have a conundrum, the originator of the code, the US government, has left the code basically licenseless. I believe this means that the choice if preferred license should be up to the most substantial third-party developers. I believe that the most substantial way to make VistA better is to make contributions that make further development easier. MUMPS is a great language but it makes VA VistA inaccessible to most programmers. Given that I believe the most significant third-party contributions to VA VistA are (in no particular order):

  • Medsphere’s OVID – because it lets you code for VistA in Java. (AGPLv3)
  • EWD from M/Gateway – because if you already code in MUMPS you should still be able to write web interfaces. (AGPLv3)
  • Astronaut VistA – because you want to be able to install… With all of the above development environments, in seconds…. Not months… (AGPLv3)
  • TMG-CPRS – because adding patients and correcting demographics should be easy. (GPL v2 or later as per the core WorldVistA EHR license)
  • OpenVistA CIS – because we want to be able to run VistA without Windows. (AGPLv3)
  • Timsons Fileman – VistA Fileman is an important core VistA component that has had many improvements since George Timson left the VA. (LGPL)

-all- of these applications do not just make VistA better, the are Platform Improvements. These improvements are designed to spur new innovation by making hard things easy or previously impossible things tractable.

-all- of these innovations (as far as I can tell) are available under either the GPL or AGPL.

I hope that it is now obvious why most of the VistA community believes that if there is to be collaboration between the Fredis and Pats of the VistA community it must be around a LGPL VistA core.

Soon DSS will be releasing a version of vxVistA under the Eclipse Public License. That license is not compatible with the GPL. If vxVistA is released under the EPL none of the above platform improvements would be available to vxVistA. However all of them are available to users of OpenVistA, WorldVistA and Astronaut VistA, all of which use GPL variants.

I have lauded the release of vxVistA but I fear that as a FOSS project, it will be stillborn because of the EPL. Users will be forced to choose between vxVistA and the considerable menu of proprietary partners whose patent and proprietary interests are satisfied by the EPL, and a projects where VA VistA is being improved -as a platform-

If we were talking about one or two minor improvements that might be available under the GPL variants the I would not take this position but practically, the most important member of any opencore community is not Fredi or Pat but Indifferent Ingrid. Ingrid wants to work with the best platform and contributes in such a way that it makes the platform itself better. Whoever wins the attention of Ingrid, wins.

These lessons are applied in the specific context of VistA, but I hope that is clear that these issues are generalizable to any Health Information Technology (HIT) platform.

(Update 10-13-09 Medsphere has released its server project under the LGPL)

(Update 10-16-09 Ben from Medsphere has responded to my post)

(Update 10-18-09 Thanks for Theodore Ruegsegger, who pointed out several serious errors… fixed)

-FT

Defining terms

NAHIT has released its definitions.

In summary:

An EMR is a record for the doctor.

An EHR is a record for the doctors. (with data ready to move)

A PHR is a record for the patient.

A HIE is the process of moving health data.

A HIO is a O that does HIE.

A RHIO is a HIO that is Regional.

Well now that that is settled, I am sure that the whole industry will stop using the terms EMR and EHR interchangeably. I am sure that no one will refer to a RHIO as an HIE.

Thank God for the government.

-FT