It may be appealing for a healthcare organization to consider writing their own enterprise medical software to specifically meet their unique needs. Commercial software is generally written to serve the more general demands of the healthcare industry and often doesn’t address the nuances of each particular organizations' operations. This makes it attractive to the in-house team to believe that it uniquely understands these peculiarities and dive head-first into the deep end to begin to code.

But writing software is a challenging endeavor. For those who don’t write commercial software for a living, producing resilient supportable software is much harder than it looks. Much like the proverbial iceberg, what is below the water line is often much more of the mass of the effort than the portion that the user interacts with.

You Get What You Pay For

When an enterprise writes its own software, assuming that it is successful, it gets just what it paid for. Seems fair? Sure. But a software company, that markets its software to hundreds of customers, is able to spend a great deal more effort on its coding endeavors and amortize this investment over its hundreds of customers. For each dollar of licensed software, the customer will be getting tens or hundreds of times the results that it got from its own efforts.

Gartner Group reports, that one out of six internally developed software projects has an average cost overrun of 200% and a schedule overrun of 70%. Some fail completely. Organizations who are planning to develop their own software should consider the risks and likelihood of delays in excess of expectations in the opportunity cost of waiting for their custom software to be completed.

Some of this overrun may be the product of poorly written specifications. It’s easy to jump into a project without a complete set of requirements, use cases, quality assurance testing scripts, and architectural diagrams. These are not necessarily part of the day-to-day for an internal team, while a software company itself wouldn’t consider starting a project without them. Lacking specifications can send a project into a black hole, consuming many more resources and time than was originally planned.

Looking for software to support Remote Second Opinions?
Watch the software demonstration on-demand!

The Support Nightmare

Internal company software teams who may be sufficiently savvy to write serviceable code, may not realize what it takes to support that software. Internal employees that write code usually go back to their “day jobs” or perhaps leave the company when the coding is over. Support calls from users tend to be a distraction or go unanswered altogether. There is no 24 x 7 service desk to pick up the phone when a user needs help for a critical task in the off-hours.

When upgrades (due to hardware or operating system changes), bug fixes, or enhancements are required, the people who wrote the code internally similarly may not be around. While people may also leave the software company, those companies that build software as their business have processes to ensure that knowledge is transferred among team members, code is well documented, and processes are firmly engrained to continuously improve and support the software.

All too often, internal teams don’t use these kinds of practices when writing custom software. The lead developer recently left an organization where they had opted to build rather than buy software to run its practice. It turned out that no one in the organization knew how to fix the code, there was little documentation, and they ended up spending hundreds of hours just to fix a small bug. Subsequently, they decided to acquire commercially available software, rather than struggle through similar issues in the future.

Meeting Industry Standards

The business world, and especially the healthcare world, we currently live in is fraught with regulations and required certifications. Internal software teams may not be intimately familiar with what is required to write HIPAA secure products or GDPR compliant privacy controls. Add to that any FDA approvals that may be required, and the internal team may find it is quickly wading into deep water.

Writing Software is a Major Decision

Organizations often struggle with the idea of implementing a commercial “off-the-shelf” solution that does not exactly meet their needs. Understandably, they believe that their organization is unique and that having software the specifically addresses how they do business today would be advantageous.

However, writing enterprise medical software often requires more and different resources than most organizations have available or are prepared to deploy. In most situations, the opportunity costs alone should convince you to deploy a proven already available solution that is immediately available.

A blog by Jaemi Bremner, including contributions of others on her team at Adobe, suggested the 60% rule of thumb in deciding whether to build or buy. If there are commercial alternatives in the market that meet two-thirds of your customized requirements, you might be better off selecting the closest commercial alternative rather than building it internally.

Obviously, the resources you have available for this project, how core this function of the software is to your organization, and your experience in managing software development projects like the one you are about to engage in, can tip the balances in either direction. But before making the decision to begin a software project internally, be sure to consider the implications of the project that may lie beneath the surface.