Building custom software in the clinical genomics laboratory space is a complex and challenging proposition. However, most times, it’s the only viable option for labs seeking an efficient end-to-end process.
In our experience, clinical genomics labs often follow a familiar path. They begin by purchasing an off-the-shelf (OTS) software product that seems to fit most of their needs. However, as they use the product and discover it leaves critical gaps in their workflows, they realize they require custom software solutions on some level, either built in-house or with a consultant’s help.
Due to the complexity of the laboratory business and the cost of ramping up new test development and production capabilities, lab software that allows you to customize and adapt as necessary is critical. The challenge is that each lab is different, and often these differences can make OTS solutions undesirable or even rule them out completely. While custom software may cost more up front, it’s built to support long-term planning and maintenance in a way that suits a lab’s scientific or business demands. That can mean cost savings and less frustration down the line.
If you decide that custom software is the right solution, it’s important to realize that it can require significant time and investment—which is why you should understand the nuances of each decision you make and how it will affect the lab’s performance. Here’s the approach we recommend to labs tackling a custom software project.
1. Identify the problems you want to solve
The requirements for custom development will be unique for your lab, so it’s essential that you make a comprehensive list of the problems to solve. These will be based on your business now, your strategic goals for the future, who your customers are and what they need, the regulatory requirements relevant to your work, and, of course, your lab’s processes. Start at a high level and work down from there.
Often individuals involved in the planning will have fantastic ideas and ambitions for the software. Some will have suggestions that are important for one area of the business, but less important for others. These inputs are valuable and must be managed and organized so that you can make a plan and move forward.
Also, identify the stakeholders to consult throughout the design and implementation phases. It’s all about balance—sharing information with the right people while not slowing down the decision-making process.
2. Visualize how the system will work and look
Consider where boundaries exist with other systems or user interfaces, and the data models of each piece of software with which you will be interacting. You will likely need translation layers to transform data as it passes from one system to another. Sometimes the data in different systems won’t map exactly one to one, and you’ll need to include stakeholders to agree on the best fit. Ensuring your team understands the system and interdependencies now will help prevent surprises later.
Develop a diagram that shows the end-to-end process of your lab and the connections between each system. This will help you determine exactly where your new software will fit into your process. Think about how you will structure your data and determine which system is the system of record (the de facto “source of truth”) and how they will interact and share information.
Mapping out your end-to-end laboratory workflow helps you clearly identify where the custom software fits into your process.
Will your software solution require users to interact with it, or will it run independently without user input? In either case, what information should be displayed and/or logged? If your software needs a user interface (UI), creating UI designs or mock-ups is an essential step. Doing this at the start will help you determine if you’re collecting and displaying the right information before any software is built. Wireframes or screen mock-ups don’t have to be polished to be an effective preliminary view of how the new software will work and they’ll help you identify missing pieces.
When you’ve created the diagram and other materials, make sure the designated stakeholders agree that everything is valid. It is vital to get sign-off at this stage to help minimize churn and rework.
3. Document requirements and plan the solution
Write down the functional requirements, describing how the software is to perform to solve the problems you identified earlier. We recommend working top-down from the process diagram and including the wireframes or mock-ups, calculations, instrument integrations, and resulting or reporting information. Starting with clear requirements will pay dividends downstream, but keep in mind that it’s OK to refine and adjust requirements during development and early testing.
Don’t forget to document non-functional requirements too. For instance, if you are storing protected health information (PHI), it must comply with privacy rules such as HIPAA and GDPR. If the software has to support regulatory requirements associated with CAP, CLIA, FDA, or others, make sure this is clear and included in the requirements documentation. This information may impact your planning in later stages.
When you’ve completed the requirements and solution designs, get the approval of all relevant stakeholders again.
4. Estimate time, effort, and costs
The next step is to develop high-level time and cost estimates for building the software. Make sure you consider the following:
- Have all basic user scenarios been covered in the requirements?
- Are edge cases or limitations outlined clearly?
- Are there any pieces that your software developers think are risky or particularly difficult? If so, ask them to do some research to reduce risk and uncertainty.
- Do you have any outstanding questions before proceeding with development?
- Will iterations be likely or necessary? Add time for review and approval for each iteration by all parties or stakeholders relevant to the development stage or project.
- Do you have the dedicated resources needed for development, quality assurance, project management, and analysis? Remember that switching people mid-stream in a project with complex technical requirements often negatively affects project timelines.
- Have you accounted for user acceptance testing? This will be performed by the lab staff, whose time is valuable and potentially difficult to schedule.
- Have you included extra time and budget for the additional requirements you might discover during the project? In our experience, it’s difficult to accurately identify all the lab’s or user’s needs in the planning stages of a project, and we usually recommend adding a contingency budget of 20% in anticipation of changing requirements.
- Have you thought about maintenance and support?
Approval and completion of this stage typically mean you’ve obtained internal funding or commitment, or external contracts with consultants.
5. Build the software and test it
Iterate, iterate, iterate
Building software should be an iterative process. Even with the most thorough planning, issues or additional requirements will inevitably come to light as the project progresses. Users and other stakeholders should be engaged early—and often—during development to tease out these differences. It may seem like a divergence from the plan, but embracing change at this stage will save time and money in the long run. Rework in a regulated production instance is extremely expensive; rework during development is trivial in comparison.
The system and diagrams created earlier during planning should be heavily referenced and traced through requirements decisions or changes and into the documentation or build systems as much as possible. Can you follow each individual requirement or system element from its initial planning through the development process into a final build? This information is critical if you plan to seek certification or accreditation.
Test it early and often
Build with testing in mind too. Automated testing is an investment that will pay off in the long term if implemented correctly. Automated user interface testing can be expensive and complex and may not fit the project’s scope or budget. However, we highly recommend the investment in development-based testing such as unit and integration tests.
Be sure to create and compile documentation around the system’s architecture, design decisions, and logic as you build. While this may seem like extra work, it will be needed by regulatory bodies during approval or accreditation. Information relating to deployment, usage, or technical requirements should be available to all relevant parties once the system is ready to deploy. Remember to reconcile the implemented software against the original requirements definitions to ensure that traceability in the system is complete from requirement through to code, testing, and release planning.
Make sure end users interact with it
Once internal testing is complete, it’s time to conduct user acceptance testing in a setting as close to the production lab as possible. A dedicated server, ideally one that allows interaction with other connected systems (or simulators of these systems), creates an ideal environment where lab staff can interact with the software without affecting production data. Listen carefully to issues that arise and make sure you address them in further iterations or prior-to-production deployment. Some of these issues may be “nice-to-have” items, but others may end up saving time and materials or impact a regulatory requirement. Input from the users will also be crucial for building trust and gaining buy-in when you launch the new solution.
6. Create a deployment plan
To ensure a successful launch, create a plan:
- Pick the date you’ll move the software to the production environment.
- Work out how to minimize the lab’s downtime. For instance, how will you migrate in-progress lab work?
- Ensure that nothing will be actively interacting with the system (including instrument integrations) when the new software is deployed.
- Determine who will provide support, and how, during the deployment and once the software is in production. Will you use a ticketing system? How will support tiers work?
- Have a plan to confirm the software is running properly once deployed to the production environment.
A good plan is only as good as its execution, but not having a plan usually guarantees a poor result. Make sure everyone knows the plan and is on board. Deviations from this during launch and deployment may be sources of great pain down the road.
7. Launch the new solution
The release date has arrived. The software is ready, and it meets your end users’ needs. You’re all set for success, right? Right?
Make sure you consider the following:
- Have all your users been trained?
- Do all end users and stakeholders know the launch is happening?
- What reporting or process checks do you have in place to know if there are issues after launch?
- What happens if something goes wrong? Is there a rollback plan?
- Do you have change management strategies in place to deal with issues or bugs?
Software, independent of whoever built it, will need changes. It will potentially have bugs. It will have ways of doing things that users never expected. Don’t plan for your launch to be 100% successful; plan for iterative successes and expect changes.
8. Maintain and support the software
Software maintenance and updates are par for the course. For every update, the software requires further testing and validation. Maintenance may mean small configuration-based changes or larger rework for evolving lab processes. There’s no avoiding it, so make sure you have a plan and budget in place to minimize downtime. This aspect of software is often overlooked, or it’s hoped that the solution will work the first day and forever without ever mentioning it again. This is highly unlikely in a dynamic environment like a clinical genomics lab.
If this all sounds daunting or if you would prefer to focus your internal resources on other priorities, Semaphore Solutions is here to help. We know that custom software for genomics labs requires a lot of attention to detail. Important considerations, such as regulatory requirements, also influence each step of the process. That’s why we believe that working with a software consultant experienced in the genomics space is a smart choice for many labs.
If you’d like to learn more about our processes and methods, visit our website and check out our other blog posts. Or reach out to us directly if you have a unique problem or a gap in your lab that can be solved with custom software.
