I write medical software. When I talk to people and they inevitably ask what I do, that�s what I say. When I say this, a look comes across their face. They make some assumptions that on the surface would appear to be very sound. Assumptions: Medical Software means cutting edge. It means that what I do affects life and death situations. They believe working in this field requires education, experience, and an understanding of two completely different fields, computers and medicine. The Medical Software field is big, scary and has important medical procedures and tests and anyone who understands it must be smarter than the average person. Unfortunately almost none of this is true.

For example, if you work with computers in an architecture firm, in order to assist the architects you have to understand the software they use and the job they do. The same is true in the car manufacturing field, the construction field, and virtually any field you can name. As a software engineer in any of these fields you need to have an understanding of the job they do, the language they speak, the tools of their trade. The only notable exception is the Medical Software field.

It is not uncommon for a new programmer in this industry to receive no training beyond the minimal required training in the language they write code in. Very few medical software engineers actually know anything about medicine at all. Only one in ten programmers has any medical knowledge and those that do acquire it from two distinct places. The first group is actually medical people that move out of the medical industry and take their knowledge to the software industry. As a general rule these people are not doctors but some sort of technician that is good with computers and computer languages. These people have a solid grip on the terminology used within the medical community and usually know the job they were trained for very very well. Outside of that job they at least can still understand the language. The second group is large but unfortunately less skilled. They are programmers that because of the nature of a job they worked were forced to work with a group of users in medicine. This is a practice strongly discouraged in the medical programming community since it only ever gives them more criteria to incorporate into the software thus creating scope creep. This group has various levels of understanding of terminology and job function depending on the amount of contact they had with the end users.

The rest of the engineering community are forced to create medical software based on, if they are fortunate, written specifications that are usually a combination of requirements from a medical person, that has no understanding of computers and the language the system is being written in, and a sales person that has limited understanding of both the software and the medical job being programmed. Thus the programmers do their best to deliver what has been asked for, not realizing the huge number of assumptions the medical person has made regarding the nature of the software to be produced and the lack of understanding of exactly how the software environment will deliver a given type of functionality. These base assumptions are where much of medical software loses its traction. For example I asked a new programmer to help me write a vital signs monitoring package. In this package one of the specifications was that abnormal and critical values were to be flagged and presented to the physician. In the first round of coding the new programmer hard coded abnormal ranges and critical ranges that he guessed at. This presented 2 problems: first the critical values he had used were not consistent with life. Second he did not understand abnormal and critical values are variable from location to location, therefore it was essential to be able to set them depending on the user. However this simple misunderstanding cost over a week worth of re-engineering once it was discovered, since it had been several weeks since the system had been coded before it was tested.

The problem is not confined to lack of understanding on the developers part either. The medical community has no idea what to expect for their money. This has been a continuous problem with inaccurate expectations of the solution being delivered. Often many of the promised features are not part of the delivered package. The software itself usually requires a change in routine that may or may not be more efficient for the users. Usually the software is a stand alone application and does not integrate well with other software already in use, and the users are forced to switch between multiple software packages in order to perform a single task.

To complicate matters the amount of money that the medical industry is able to spend on computers and software is shrinking. Thus less money is available for development of solutions that keep pace with new equipment and procedures. In addition the medical software purchasing life cycle is so long and involved now, in an attempt to ensure the agreed software is delivered, that often by the time it’s delivered it is no longer relevant, or useful.

An accurate analogy of medical software sales can be given if you imagine a car salesman that has no ability to drive a car, trying to sell a car to a man that knows he needs to buy a car. However the man buying the car is also unable to drive the car, has no intention of ever driving the car, but is buying it for his people, none of them are able to drive this particular car, but they have each driven other cars and try to tell the buyer what they want the car to have for options. However the buyer is only able to communicate with the people that will be driving the car by a very bad cell phone connection, and is only hearing every third word.

If this sounds like a recipe for disaster then imagine when the car sale fails, and either the buyer is not happy, or the sale falls through the car salesman then goes back to the car manufacturer and tries to tell them how to change the car so that future buyers will be happy with it.

So what is the solution? Well as is almost always the case, education, and improvement in the developer�s knowledgebase begins to solve almost all the user related issues. However most software companies are unable, or unwilling to devote the resources necessary to ensure medical software developers understand the jobs of the typical medical users. As this is most often the case the next best solution is to get the community of medically savvy users involved in the development.

The effect of making medical software open source ensures that any level of deficiency in a solution that shows otherwise great promise will be found and solutions suggested that a medical software company can then choose to incorporate or not. It is also possible that the community itself may engineer solutions to help with the overall health care process. This has been the case in one major open source effort.

It is interesting to note that for all intents and purposes a similar process has been going on for almost 30 years on a very large and capable medical software system. The VA�s VistA medical system has had constant feedback and improvement dictated not by a company looking for sales but by the administration of a community of users that encouraged the users to tell the developers how to improve the product.

Now the same VA has begun to accept back into the VistA product developed software that has come from outside the VA. Further improving the quality of the product by expanding the user community to those outside the VA that also use or wish to improve the product. This model proves the value of a totally open source medical software process, and also proves that such a process can produce a better product than the closed source competition.

Typical medical software life cycle consists of a first release filled with promise, sales and a significant lack of feature and a few bugs, the subsequent releases improve the product designed to improve sales and as long as the product continues to generate massive revenue with sales it�s feature and function continues to grow, with it�s list of bugs also growing. At some point this sales versus development model slows down and then begins to reverse. As sales slip, new development is cut. Bug fixes become slower and slower, and eventually the sales versus support model becomes unprofitable and the product is retired, or discontinued, regardless of how many users still use it and require fixes to existing problems.

This closed profit based model has some advantages, but ultimately is doomed to produce a product that will be no longer truly supported, and with the longevity of today�s software, most likely remain in use and be frustrating for years after the company has ceased any serious development.

The open source model ensures that until something better comes along a product continually is improved, fixes resolved quicker and new functionality added. This has been successfully shown in a variety of software both at the operating system level, Linux, application infrastructure level, Apache, and application proper, Mozilla�s suite of applications.

Why does this problem persist, why do companies continually follow an inferior model for their software? In a word, profit. If the medical community can educate itself on what makes good software, and then insist that these processes are followed, they don�t need to become software experts, but the medical software community will become much more educated about the tasks set before the medical community.

Brian Lord has a Masters in Software Engineering, as well as being an ASCP certified Medical Technologist. He has degrees in Physics, and Mathmatics and has worked in the Medical Software industry for 20 years. He is active in WorldVistA. His company, Sequence Managers Software(SMS) have developed and are deploying an ASP version of the VistA product called NationalEMR, to both Clinics and Hospitals. Editor’s disclosure: I have a financial interest in the author’s company.