Skip to content

Why Health Facilities Should Prefer Open Source Over Proprietary Software

I have been very vocal about free and open source software (FOSS) for healthcare, mostly for philosophical reasons. But that approach is not always shared by other people with different views of the world. It seems ‘economics’ (being mostly quantitative) is easy for many to understand so let me use that as the platform for argument.

A hospital director can decide to either use FOSS or proprietary software. Whichever they use, they need to understand that they will still have to invest on ‘customization’ and ‘implementation’. Let me explain each.

Customization is when, after installing the software (eg, EHR), you still need to put in specific data about your facility. Examples: entering each room, bed, doctor, nurse, lab test, drug, drug prices, taxes, rules, workflow, etc. I have never seen an EHR software that has these data already built-in (and you never will) because these values differ widely between facilities. So when you install an EHR( regardless of whether it is FOSS or proprietary), there will be significant manpower time spent on customization — and that will have a price. For FOSS, it will be time lost by your internal staff when they do the customization; for proprietary software, the vendor’s employees will do this for you for a fee. Either way, the hospital pays for it.

After the EHR has been customized, you then go into ‘implementation’ or the actual use of the software by the workers in the facility. This is where things gets messy. Many hospitals are surprised that after all the effort (plus time and cost) of customizing, they suddenly discover that doctors and nurses are resisting the new system. Getting health workers to use electronic health information systems can be very challenging. Invariably (and this is a well-studied phenomenon), they will resist change. Most health informatics projects fail because of the implementation challenges. Whether you use FOSS or proprietary software, you will still need to hire a good project management team to implement the customized system.

The sad thing is that by the time hospitals fail in the implementation phase, so much money has been expended already in customization. That’s good money down the drain.

So the math is simple. For both FOSS and proprietary health information systems, there will be expenses in customization and implementation (ergo, they cancel out and there is not much difference with either system). But for FOSS, you don’t need to pay for an upfront license fee because it is free. For proprietary software, you need to pay outright a license fee (which can be substantial). This proprietary license fee is not refundable. If you fail in customization or in implementation, you’ll be stuck with license for software that does not work. Read the fine print: you can’t even sell it to another hospital. And even if you can, it won’t work because what you have is custom-fit for your hospital, not theirs.

Another way to look at it is — if you use FOSS and you customize it, the end product is owned by you, the health facility. But if you use a proprietary system and customize it, the end product will still be owned by the vendor — not by you, the health facility. Yes, your money would have been wasted because after all the effort (plus time and cost) you place on customization, you don’t even own intellectual property rights over your customized version.

Make sure you understand the licenses of the software you sign up for. These can make or break the success of your implementation.

Bottomline: FOSS is cheaper, better, more empowering for Philippine health facilities. Health facilities should prefer FOSS over proprietary software.

Recommendations:

1) Use CHITS (www.chits.ph) in rural health units (full disclosure: we manage the CHITS project — GPLv3)
2) Use OpenMRS (www.openmrs.org) for the rest: private clinics, district hospitals, provincial and regional hospitals GPLv2)
3) Hire people (IT/nurse/doctor) who can show certificates of attendance/competency for health informatics

2 Comments