In this article, we discuss the real cost to build hospital tech solutions viewed in the context of software as a service (SaaS*) in healthcare delivery versus a DIY solution to solve critical challenges like timely access to information and clinician wellbeing. Med Apps’ COO, Duncan Paradice outlines why an ‘own build’ technology solution in healthcare may not always be the answer.

There’s no debating many challenges in health that could benefit from the application of a technology solution. It’s the very reason we’ve seen a proliferation of technology in the sector. Complemented by easier access to IT solution builds, expanding in-house technology teams, and a general increase in technology literacy within the current generation of clinicians, configuring a technology solution – even a DIY build in-house – just makes sense. Or does it? A DIY solution can be tempting, intellectually interesting, and even achievable if all the planets align, particularly when considered against software as a service (SaaS), but it may not be the answer.

Those who argue the case for a DIY technology solution generally rest their case on a handful of tenets:

1. DIY is cheaper than off the shelf
2. There are great people inhouse to carry the project forward
3. We can build a system out of many parts
4. It’s not that complex to build and maintain a custom technology solution.

While each of these has its merits, they warrant deeper consideration, particularly when we consider the environment in which the application is required. The healthcare sector has unique requirements, so let’s look at these arguments in more detail.

Is DIY cheaper than off the shelf? 

Anyone who’s been involved in a software, app, or system development project can tell you the enthusiasm which abounds at the start of the project is not usually there when things wrap up.

But it’s not only enthusiasm that wanes. Budgets and schedules often do too. One good reason this happens is not all project costs are clear at the start, because you don’t know what you don’t know, and important details are often obscured early on and costs may seem small and easy to manage. They could even be estimated poorly or not accounted for at all. 

Without knowledge, skills, and experience, it’s virtually impossible to calculate the costs of ongoing maintenance, updates, improvements, the requirements of meeting changing security issues, and the changing nature of codes and technology stacks. 

The upshot is, unless your organisation is in a position to overcome these challenges, you will probably find the alternative means being happy to accept a technology solution that is static, or be willing to pay to keep it up to date and evolving.

Getting Involved: Healthcare workers carry technology projects forward

Time spent working in a hospital environment tends to find a single clinician or group of clinicians who are drivers of change. Often juggling clinical work, exams, research, or further education, they may feel compelled to become involved or lead an IT project as a way to solve a critical service delivery issue. 

Already time-poor and stressed, adding further responsibility means over commitment that rarely ends well. Research into figures associated with clinician burnout is enough to discourage even the most enthusiastic advocate of a clinician-led technology project. So while there may be great people inhouse to carry a project forward, it doesn’t mean they should. Ultimately, this approach can exacerbate the very problem the project aims to resolve. 

This is not to say that clinicians and administrators (as  the users of the  system) shouldn’t be centrally involved. They absolutely should, and a core value of Med App’s implementation process is a governance team that includes clinicians (junior and senior), administrators, education officers and executives. It is more that the nuts and bolts of putting together, maintaining and updating a hospital system shouldn’t rest solely on a clinician or administrator.

Can you build it from many parts?

Many clinicians are driven out of necessity or frustration to create DIY technology solutions. We know, because that’s exactly how Med App came into being. An innate resourcefulness is characteristic of these clinicians, who are prepared to turn their hand to building websites, creating term handover documents, and even combining systems like Google Sheets, Docs, Calendars, Facebook, Whatsapp, and just about anything else to create a solution that supports them and their colleagues.

While each platform has its place and together may get the job done, they are designed for general use and typically don’t make a good fit for healthcare, which has very specific needs. An awareness of this limitation points to the underlying need for a technology solution with the capacity to address challenges around communication and ease of access to useful, localised information. 

Composite DIY solutions like those described often are created at the expense of clinician wellbeing, because involvement adds to an already significant workload. Additionally, projects like these carry the burden of handover as the next cohort comes through (as ownership hasn’t ever been clearly defined). There is also the potential for letting projects like these to stall or even fail if there is no one to drive it forward when the clinician leaves or the project is no longer relevant to them.

Ultimately, the clinician’s decision to work at creating a solution that helps himself and colleagues will need to be weighed up against continuing to develop and support the solution, handing it over, or letting it fall away. 

How complex is it to build and maintain? 

The hidden work and costs of building and maintaining IT systems is often discovered as a project unfolds and as the system evolves. At a very practical level, the amount of work involved is easily underestimated, leaving the door wide open for system failure. This applies both at initial development, as well as with ongoing development and maintenance. Technology solution costs can easily unravel too. A big spend doesn’t always equate to the ideal solution. Many technology solutions have incurred prohibitive costs and fallen well short of meeting the intended need. 

Without a deep understanding of the work, skills, and technology required, the evolution, design and interactive process with users is compromised. So too is the longevity of the solution because it becomes too unwieldy to fund and manage. Industry leading practice indicates careful mapping of user journeys, as well as collection and integration of feedback into the next development cycle is a must. Not only does this add significant value to the solution, in healthcare, it means clinicians and users at all levels still have a voice in the platform’s evolution.

What to consider?

If DIY technology solutions are not the answer to addressing some of the more pressing system challenges across healthcare delivery, like making the right information accessible to people who need it, when they need it, and supporting clinicians’ wellbeing, then what is? Could an off-the-shelf solution work for a hospital, or even a unit or particular clinician group in a hospital? These are reasonable questions that can be answered by knowing what to look for.

Solutions to the majority of problems are already built in	Rather than having to create a solution from scratch, an off-the-shelf solution can form the basis of what’s needed, while still being tailored to location or business specific needs. Think about this in terms of information and requirements that are common to most similar working working environments, regardless of geography, for example clinical guidelines.
Implementation support	Instead of managing an IT project without experience, an organisation can rely on the experience of implementation at other healthcare sites, allowing for a smooth transition to using the system and best practice from day one. New IT system implementation is notoriously difficult, but it doesn’t need to be. With the right support and training, all system users can gain competency in the system without impacting the quality of service delivery.
Regular updates	With a dedicated focus on introducing updates, improvements, and new features, new releases can occur as frequently as every two weeks. Unless system management is the priority task of staff, it is unlikely changes will keep pace with needs. Keeping pace with system updates is critical and really shouldn’t be found on the to do list of clinicians.
Ongoing support for the hardware security module (HSM)	An HSM is a tamper-resistant device that provides a high level of security for sensitive data. Ensuring there is support in place means security can be updated and improvements made as technology and threats evolve.
Quality assurance process	A proven development process with a detailed way of integrating new requirements into the production environment, means quality assurance is easier to maintain. This becomes even more important as complexity increases. It also provides stability in the platform, ensuring there is minimal downtime and bugs are fixed quickly.
Demonstrated success	Not having a standalone, DIY solution means you are not the only one using the system. Rather than feedback from one site or one department, there is a network of healthcare professionals who help improve the solution, and where it is possible, share information between sites.

Is it better to opt for DIY technology solutions in healthcare?

So where does this leave you with a decision around DIY v. SaaS as technology solutions in healthcare? 

DIY may work for very specific problems in a particular niche or specific location, however there are common challenges which occur broadly across different jurisdictions, hospitals, and disciplines that bring the merits of a DIY solution into question. 

It could be the right approach for your problem, but it comes with inherent risks for the quality, longevity and overall cost of the solution, regardless of whether that involves building your own app, software platform or website, or assembling a solution from a number of discrete systems. 

Keep in mind your decision should consider the solution’s value in terms of longevity and medium to long term costs, not just the immediate cost of a SaaS subscription versus developing a bespoke solution.

Other considerations if you elect to build inhouse or outsource to an agency to build a custom solution are the time and cost to maintain and improve the solution. Bespoke updates and changes can be deceptively expensive.

There is no one right answer to the question of SaaS v. DIY and the cost to build a hospital tech solution, but the solution should always aim to meet the needs of the healthcare workers it’s designed to serve.

---

Duncan Paradice is Chief Operating Officer at Med App. Together with the entire Med Apps team, he is committed to supporting clinicians to choose the right technology solution that meets their needs. Duncan can be reached at Med Apps to discuss how Med App can help your organisation answer the SaaS v. DIY technology question. Med App is an offline-accessible, mobile-first tool that helps healthcare professionals feel capable, confident, and efficient in their work. 
Software as a Service or SaaSis generally when a software is delivered via cloud under a subscription licensing model. Reducing ICT infrastructure and allowing for faster, easier updates and service.