Will Vendors of Medical Software Taste Forbidden Fruit?

With 16 known open source medical software projects underway, the likelihood of eventual success for at least one of these projects in the coming years seems secure. Current vendors of medical software may be, and should be asking: Why should I go into open-source medical software? Here’s 6 reasons.

Reason 1) Developing clinical software is hard.
Reason 2) It is expensive.
Reason 3) Customer satisfaction.
Reason 4) Enlarges the pie.
Reason 5) Liability
Reason 6) Security.

Reason 2) Expense: It requires years of comittment and top software engineering talent. Even if a company makes it to the marketing period with a good or even excellent product, success is not assured. Numerous competitors, a small market, technically illiterate potential customers and a lengthy survival period before profitability are daunting challenges to success. Even then, continued maintenance and expanded functionality require more time, more talent and again, no assurance of success. The decades are littered with expensive
failed commercial medical software products.

Even the most magnificent clinical computing software package to date is at best half of a solution and serves only specialized markets well. There is always enormous missing pieces, or a niche that is unserved. Clinical computing software is far too large of a project for a single company. When a satisfactory, digital-from-end-to-end medical system exists, the base software will be at least as large as the Linux operating system itself. The engineering talent and financial resources to achieve this simply do not exist in any one company.

Open-source enables access to large engineering talent pools and resources through collaboration over the internet. It also enables a much more comprehensive product than a single company could produce. All this occurs at a much lower cost since the cost of development is spread among many organizations. Additionally great engineering efficiency occurs because failures are never really failures. With open source, an organization can simply pick up a ‘failed’ software project football and carry it the next 10 yards until a winning implementation is achieved.

Successful adoption of open-source software would enable vendors to legitimately focus on more profitable aspects of the business such as service contracts, installation, data-security, training and documentation. Similarly, open source software does not preclude a vendor from including a profitable closed-source program with its open source products. In fact, it would be surprising if a hybrid did not occur, especially at this early stage of open-source medical software development.

Reason 3) Customers satisfaction: It is likely to be improved with open-source because the overall cost of clinical software (currently quite expensive) is likely to drop precipitously in an open-source world. Customers are also not locked-in to a single vendor which allows a customer to choose better service providers if they are unhappy with their present contractor.

Reason 4) Enlarging the pie. Vendors would also benefit from a larger reach as the currently high cost of entry into quality clinical computing software could be substantially lowered. The small practice could afford the same software as large organizations. This is not only good business, but good for society since doctors that do not have the clinical information power tools that larger organizations have only makes patient care suffer. Another, non-obvious barrier to enlarging the pie is that the lack of standardization makes medical schools unable to train medical students on a standard system and therefore not have trained users upon graduation. Look at computer science schools as a model. I can confidently say that for many years, no student has graduated without exposure and familiarity with Unix. One can argue that at least some of Linux current popularity is the knowledge these graduates have of it. The same could be true of medical schools if the goals of open source medical software are achieved.

Reason 5 & 6) Liability and security. Which are two concerns of medical software vendors that rightfully should keep them awake at night. A system built by multiple individuals and organizations should lower the odds of any one of these entities getting a lawsuit should the system be blamed for a patients death. This should give vendors pause that in the current closed-source world, they could be put out of business should a lawsuit occur since a single entity is easily blamed. They similarly might be (possibly are now) investigated for ensuring patients privacy. If a vendors software is found to have unacceptable confidentiality risks, with sufficient public and government pressure it might have to be scrapped. This would have disastrous consequences for the company. Open source software with its peer review mechanism of security could find many security flaws in advance as well as react quickly to changing public attitudes and government attitudes.

To be realistic, the majority of open-source medical software projects are currently not at the level of quality that there commercial counterparts are at now. But if recent trends continue, and the current 16 known open source medical software projects continue their current rate of advancement, this is likely to change in the coming years. Particularly if educated practitioners begin stating their preference for open-source in request for proposals. Even more so by requesting anyone with proprietary medical software to open-source it.

Medical software vendors? Are you listening? Will you taste forbidden open-source software fruit?

Leave a Reply

Your email address will not be published. Required fields are marked *