Strategies for Improving Bespoke Software Quality within Healthcare and Clinical Trials
What does ‘bespoke software’ mean?
Bespoke software is used to refer to the process of designing, building and maintaining a custom software solution. Bespoke software is designed and built with a specific purpose and set of user requirements for the purpose to solve a particular business need within a company/organisation that has commissioned the build.
Jump to how can we improve bespoke software quality section.
Bespoke software is the opposite of COTS software. COTS stands for commercial off the shelf software, this is typically an application that solves a particular problem and is brought into a company/organisation. e.g. Microsoft Word/Office.
COTS solutions are a lot faster to adopt. They can often be bought, installed and used in minutes with no design work required.
What are the advantages of bespoke software?
Bespoke software can be considered easier to use because it works the way you have decided in your requirements. You are often in full control and changes and new features can be implemented quickly. You can expand the application as your company/ organisation grows. As often the case new legislation or requirements can evolve over time, bespoke application can consider these changes over time. Bespoke applications can in some cases increase productivity, and reduce costs in the long term by automating and making repetitive tasks non-existent or more efficient.
For example with bespoke software applications, you could automate report generation, emailing reports or analysis, schedule import and export of data etc.
What are the disadvantages of bespoke software?
The disadvantages of bespoke software is that standard commercial off the shelf software can have many useful features or tools that might solve a lot of your business problems and would help your team. There can be a significant time cost to the company/ organisation in the planning and delivery of any size bespoke software application.
Delivering bespoke software in house can be challenging and getting stakeholders to agree on a strict set of features and clear roadmap can be difficult.
How can we improve bespoke software quality?
This article explores how we can improve bespoke software quality with respect to healthcare and clinical trials. The main criteria for bespoke software within a clinical setting, as opposed to other non-clinical settings is the strict regulations and standards that the software must adhere to.
The software system must also withstand and inspection from the Medicines and Healthcare products Regulatory Agency (MHRA).
To improve quality of bespoke software, we have to improve the quality of bespoke programming. I am using two aspects to approach this problem:
- Skills Matrix
- ECRIN Standards
The skills matrix is used to identified training needs. The European Clinical Research Infrastructures Network (ECRIN) standards identifies best practice.
In practice, these are interlinked. The best practices that we need to improve inform the skills and training we need in order to improve. And so, is a cyclic relationship between skills matrix and ECRIN standards.
The European Clinical Research Infrastructures Network set up a working party that considered the GCP guidelines, along with many other international and national documents and regulations, and used them to derive a set of more detailed IT systems and Data Management (DM) specific standards.
The version of the ECRIN standards referred to in this article is Version 4.0, April 2018 https://ecrin.org/sites/default/files/Data%20centre%20certification/Standards%20v4%20201804.pdf
ECRIN Guidance for “Good practice in Software development”
Version 4.0, April 2018 page 46 (page 52 pdf).
Good practice in Software development
“Though not required as a standard, there are a variety of development techniques which would help to indicate high quality practice and which should make systems easier to develop and safer to maintain”
- Design techniques that promoted clear ‘separation of concerns’ between different parts of a system.
- Use of a source control system that allows branching and release management.
- Programming against interfaces rather than concrete fixed components, with dependency injection.
- Programming against data repositories rather than fixed data sources.
- Use of a unit testing framework and / or integration tests.
- Continuous integration of a test regime with a source control system.
- Use of a library of user controls / common modules across systems.
- Regular code reviews and walk-throughs; shared coding.
- Use of a bug tracking system.
- Use of a scripted build and / or deployment scheme.
- Use of scripts for constructing and modifying databases.
- Consistent and effective error / exception handling techniques.
- Consistent and comprehensive logging techniques.
ECRIN Guidance + Topics
I have taken the ECRIN standards, as shown above, and aggregated them into topic areas. These topic areas cover the majority of the areas when it comes to software engineering and therefore bespoke software development.
I have shown these aggregated topics below.
Software design patterns
● Design techniques that promoted clear ‘separation of concerns’ between different parts of a system.
An example is SOLID.
SOLID principles of object-oriented programming
- (s) Single responsibility
- (o) Open–closed
- (l) Liskov substitution
- (i) Interface segregation
- (d) Dependency inversion
(https://en.wikipedia.org/wiki/SOLID)
● Programming against interfaces rather than concrete fixed components, with dependency injection
Version control
● Use of a source control system that allows branching and release management.
Data
● Programming against data repositories rather than fixed data sources.
● Use of scripts for constructing and modifying databases.
Unit / Integration Testing
● Use of a unit testing framework and / or integration tests.
Repository of libraries and modules
● Use of a library of user controls / common modules across systems.
Code review
● Regular code reviews and walk-throughs; shared coding.
Bug tracking system
● Use of a bug tracking system.
Build and Deployment
● Use of a scripted build and / or deployment scheme.
● Continuous integration of a test regime with a source control system.
Error and exception handling
● Consistent and effective error / exception handling techniques.
Comprehensive logging
● Consistent and comprehensive logging techniques.
I have then grouped these topics in two main categories that either denote if this is a Methodology [M] improvement, or an Infrastructure [I] improvement. The result of this is shown in the table below.
DevOps Processes
After sorting the ECRIN guidance into sections and identifying methodology and infrastructure changes, I then looked to the field of DevOps.
The infrastructure aspect has a lot of similarities with an area in software development called Development Operations or ‘DevOps’ for short.
Development Operations (DevOps) is the entire service life-cycle of software including operations and development engineering with every aspects working together in harmony.
Many companies will have teams dedicated to building and maintaining DevOps workflow. As the major benefits of an efficient software pipeline will pay dividends because reduce number of
- defects,
- deployment problems,
- bugs
- etc.
The main principals and processes in DevOps are:
- Plan
- Code
- Build
- Test
- Release
- Deploy
- Operate
- Monitor
I have mapped ECRIN Guidance for Good practice in Software development onto the principles of DevOps. This shows the overlap. But more importantly, how we can borrow the years of development and refinement of DevOps best practice, and integrate into bespoke software development in clinical trials.
ECRIN Guidance Mapped with DevOps
The table below shows the ECRIN Guidance for Good practice in Software development mapped with my own set of topics alongside the principals of DevOps.
You can download the full presentation notes.
If you have any questions, please get in touch. I would be glad to help out if I can.