Build vs. Buy Healthcare Software: Which Decision is Best For You?

The time has come for you to make a big decision on a new software solution for your healthcare organization. You may be wondering – build it or buy it?

There are lots of factors to think about when considering building or buying a new solution. Below, we’ll go through the most important considerations. First, however, here are a few questions you want to think about that can guide you on evaluating this decision:

1. How important is this feature to my organization?
2. How critical is it that we go live with this solution quickly?
3. Will it integrate well with your current technologies?
4. What will be the cost, in the short and long term, to build vs. buy a solution? If we build it, how will we maintain it? How much will this cost us in the long run?
5. What skills will we require to build and maintain? Do we have these skills on our team today? What projects will be placed aside for them to be focused on building this instead? How will that affect our organization?
6. Technology is improving rapidly, are we building something for today, or the future? How will we adapt this in-house product to keep up to date with technological innovations in the future?
7. Who’s responsible for upkeep? Who does QA on an ongoing basis?
8. If something ends up not working the way we envisioned, how long will it take us to pivot and rebuild? What will be the impact on our healthcare system?

When it comes to building your own software vs. buying, a common concern we hear is that hospital know their own complex internal processes and have a deeper knowledge of the way things work and they want to build something tailor-made to their unique processes. For example, perhaps your patient assignment process is quite complex, and you believe a standard software won’t be able to automate such a complicated process, so you lean towards building a solution that meets your unique specific needs. Another common concern is with time and limited budgets. As healthcare organizations focus on delivering the best patient care under tighter financial constraints, an in-house solution could look attractive. But does it solve your needs for the long-term?

Sure, you could develop a solution and stay on top of it for a few years, but what inevitably happens is keeping it up to date falls behind. Or the upfront time and costs are underestimated.

So, what do you have to really consider when it comes to making this important final decision?

Cost

When making the decision to build vs. buy software, cost is often the number one concern. Initially, it might seem less expensive to build in-house, but it often ends up being more expensive in the long run once you consider the long-term costs such as ongoing costs and maintenance costs.

When evaluating the cost of building software, a good idea is to remember, unfortunately, that like building a house, projects often go over budget and overtime.

A rough formula to evaluate the cost to build may look like:

Short-term cost = Estimated development months x Monthly developer cost x Number of developers you need.

If you want a true estimate of the long-term cost, the formula really looks a little more like this:

Cost to build = Initial build time (Months x dev cost) + Hosting costs for various device types + Cost to maintain + Cost of updating for every software update + Cost of adding new features + Building and maintaining security + Opportunity build cost.

Here’s a brief overview of what each of those costs represents:

• Initial build time = What is the cost of your development team for the time estimated for your project? Always assume the project will take longer than expected.
• Hosting costs = If your new in-house software requires big data, the costs of adding servers or increasing hosting can be expensive.
• Cost to maintain = The hidden cost that gets underestimated. Once your software is built, it needs to be maintained – at a minimum every year. Machine learning models will need to be optimized; technical debts need to get sorted; security patches need to be installed, etc. A rough estimate of this cost is the monthly cost to build your first version and allocate 5-20% of that every month for ongoing maintenance.
• Cost of updating for every software update = This applies more for solutions that need to be tightly integrated into other solutions. For example, if your in-house solution will be integrated with your EHR, as your EHR does a software update, you may need to update something on your end.
• Cost of adding new features = What new features will your users want? You can bet they will have opinions once they get to use it.
• Building and maintaining security = The cost to keep your software secure, HIPAA compliant, and safe from hacking attacks.
• Opportunity cost = The potential benefits a business misses out on when choosing one alternative over another. When you are devoting time and resources to building something internally, you’re choosing this project over another potential cost. What is the cost of allocating your time and resources to this instead of something else? What will benefit your business more? What will grow your organization more? What could you have done with these resources that could help us better down the line?

When choosing an established software company, you pay an annual maintenance price that includes all these costs already – and is usually less expensive than if you had to pay for it yourself, because a vendor’s security costs and software update costs and so on, are spread out amongst all their customers. You only pay a portion, but you reap the benefits of all of them.

Plus, an established company has an in-house team that is always working on building and maintaining their solutions, so you don’t have to. For example, we have at minimum five developers, two product managers and three QA staff who spend thousands of hours a year on our products alone.

Security and IT

So, if you’ve decided you’re going to build your own software, how would you keep your product safe and information secure, especially since you will be transmitting sensitive PHI data? Who will be responsible for data security? Will you be able to stay up to date on new security protocols and routine testing?

From a vendor perspective, we have done our due diligence when it comes to safety and security checks. Medaptus conducts three types of safety checks regularly: static, dynamic, and penetration tests. To keep your software running correctly, rescanning the product on a consistent basis is required. If you’re doing this in-house, you don’t get quarterly security checks, or the advantage of having a whole QA department to run these ongoing safety checks and troubleshoot complex issues for you.

Hospitals have a robust security system – this is a must when dealing with rigid HIPAA laws. If you are creating and maintaining your solution in-house, you don’t get any of these extra safety precautions, and you will have to periodically rescan your solutions to stay compliant which is an ongoing process that can be handled completely by a QA department if choosing to use a vendor – one more thing you can cross off your to-do list!

Our security standards are unparalleled. As a Volaris Group company, we adhere to strict IT security protocols. Our Security and Compliance Framework consolidates security practices which align with NIST, HIPAA, HITRUST controls and best practices.

By using a SaaS vendor for your security checks, you eliminate a ton of upkeep and liability. Infrastructure will be kept running smoothly which will result in cost savings for you.

You are benefiting from other customers using the same software vendor as well and being a customer by covering costs associated with these expensive safety checks, which can cost upwards of $70,000 annually.

Time

Time is another important factor. If you are building your own software, who will be needed to make this happen? This is likely to be a big project that will take up a significant amount of time. How will these employees shift their responsibilities? What is the overall effect on the day-to-day operations of the business? If it’s a complex solution you need, it will be a huge investment personnel-wise.

A task such as annually updating CPT codes can be a tedious and daunting task, but if you work with a vendor, you’ll have a whole support team working behind the scenes doing this for you. Another thing you can cross off the to-do list! (this is sounding better and better, right?).

Expertise & Personnel

When you work with a vendor, you’re getting access to a wealth of knowledge from people who have probably solved your problem many times. Vendors also have knowledge of best practices, industry trends, and insight on important things to look out for.

Our Customer Success and Support teams have over 20 years of experience with healthcare technology (EHRs such as Cerner, Epic, and more) and have worked on numerous large-scale implementations for hospitals and healthcare organizations in the United States to make this decision an easy one for you.

Another key thing to consider if you choose to build software in-house is who will be the superuser of the software. Will one person primarily know the ins and outs of it? What happens if they are off sick, go on vacation, or leave your organization?

Scalability

If you choose to build your own solution, will the product you build be easily scalable? When Medaptus builds a product, it is designed to be used by a wide range of people, users, and facilities to meet the needs of our customers as their organization expands. If you built your own product in-house, would you be able to expand easily, or not?

Final Questions to Consider

For complex software, it often ends up making more sense to buy rather than build. What is best for you? We’ll leave you with some questions to think about.

Your organization would benefit from buying software, instead of building, if:

• Building software is not a core part of what you do.
• There are solutions on the market that address your relevant business challenges.
• Your internal resources are limited, and your organization needs to focus on core competencies rather than software development.
• Fast deployment is a higher priority than a fully customized product.

To learn more about our solutions, check out our website here.