The Agile methodology is preferred by many software development teams for its flexibility, openness to change, and room for creative possibilities. However, when developing solutions in the highly regulated healthcare industry, the majority of teams are likely accustomed to the traditional waterfall approach, where all requirements and expectations are set before work begins. But what if we told you that Agile is a very appropriate, if not the more appropriate, method for healthcare solution development?
In this article, we will address the specific challenges faced by teams developing healthcare software products and how they can apply an adapted Agile methodology to overcome these challenges and develop solutions that meet all the necessary requirements and exceed expectations.
Agile Development Practices
If your team is accustomed to the traditional waterfall development process and unfamiliar with Agile, these are the core elements and practices of developing with an Agile methodology – all of which can be customized to meet your team’s needs:
Sprints
Sprints are the foundation of Agile. A sprint is a defined period of time during which the team focuses on delivering a set of product features. Sprints can vary in length depending on the needs of the project. We have found that sprints of two weeks duration generally work well for healthcare software development.
Sprint Planning: Prior to running a sprint, the entire team gathers to plan the activities that will be performed during that sprint. During sprint planning, the team commits to a set of user stories. User Stories are defined as a set of requirements and acceptance criteria that define a function or scenario from a user’s perspective. User stories are used to define how a feature should work and behave.
Sprint Demonstration: At the end of each Sprint, the team has the opportunity to demonstrate the work that has been done. The sprint demonstration is also an important opportunity for the product owner to provide feedback and make adjustments to the work that was done during the sprint. This feedback process can save healthcare organizations a lot of time and money by not having to correct errors or make changes/improvements after the solution has been delivered, as is the case with waterfall work.
Sprint Retrospectives
At the end of each sprint, the team gathers to review the sprint and identify areas that went well and things that can be improved. This allows the team to continually review their work and improve their processes.
Daily stand-ups: these are very short daily team meetings where each team member shares what they are working on and if they are blocked. The more heads around the table, the more ideas can help solve roadblocks.
Backlog
The backlog is a list of prioritized user stories or features that detail what is needed to create the product. The product owner owns the backlog, which means he or she must define and prioritize all the user stories it contains. The Product Owner is expected to make feature replacement decisions based on the product vision and business requirements.
Sprint Board
The Sprint Board is a tool used by the team to organize and express the status of work in the current Sprint. Issues are moved from one status to the next as they are worked on.
Your team does not need to think of these practices as prescriptive when you first try to implement agile development; adapt the practices as needed to make them work for your product team. For example, the team can use a software tool like VReli for their sprint board, or a physical board with post-it notes.
Let us explore how we can apply these core agile practices to the unique complexities of healthcare solution development.
Regulations
Healthcare is heavily regulated by a number of governmental and non-governmental entities. While these regulations are well-intentioned and designed to protect patients, they result in a complex regulatory environment that impacts the processes required to design and develop a software product.
When developing a healthcare application using Agile, you need to consider and comply with the various regulatory requirements (e.g., HIPAA compliance) just as you would with Waterfall. However, among the most important benefits of an Agile development methodology is that it encourages innovation and can deliver functionality faster. If the software product is a medical device, there are significant regulatory requirements to consider. Your team must determine these requirements in advance, and they depend largely on two key issues:
- Is the software product a medical device OR is it part of a medical device?
- Do you store protected health information (PHI)?
If you can answer yes to any of these questions, your team will need to identify any regulatory requirements you need to comply with, learn about them, and then develop an approach and set of processes to meet those requirements before a development sprint takes place -something that is not common with an agile approach. In the agile methodology, requirements are usually defined during development. The work to identify the processes needed to meet regulatory requirements begins by first understanding the requirements for the specific jurisdiction where the application will be deployed. To do this, you can consult with a regulatory expert. If your organization already has a set of processes in place that meet the regulatory requirements, you should leverage them. Regardless of whether you use an agile or waterfall approach to software development, the regulatory requirements will not change. Once you have defined the legal requirements, they can be documented as non-functional user stories and included in the backlog. This way, these requirements become visible to the team and can be handled like the functional user stories in the backlog. Usability testing, also known as formative testing, can also be integrated into the sprint cycles to ensure that the team is compliant and able to identify potential security risks in the product being developed.
In case you have not noticed: Developing healthcare solutions involves a lot of effort related to regulatory compliance, especially if the solution you are developing is considered a medical device. Your team needs to incorporate the regulatory effort into the agile sprint planning process so that the workload is properly distributed and product development can meet the delivery deadline.
Although it is ideal to define all product requirements upfront when developing healthcare solutions, healthcare software products are typically complex; they may involve integration with other systems and are often mission-critical. Their complexity makes it even more difficult to define all requirements before development begins – in this situation, Agile is very useful. With Agile, corner cases and unknown complexities, as well as valuable features and new requirements, can be discovered by the team during development and addressed and corrected in future iterations. Course corrections, which are part of the nature of Agile development, can be used to find complex solutions as you deliver features. This means that while your team may find that an element of the solution needs to be changed or added, agile course corrections allow the team to consider the necessary work in subsequent sprints and do not prevent them from delivering functional features in each sprint. This is one of the most compelling reasons for using Agile as a software development methodology. By adopting sprints, your product can end up being even more valuable and usable than your team originally expected, and this process prevents expensive time from being wasted fixing a solution once it’s developed.
Securing User Information
The protection of Protected Health Information is one of the special needs for healthcare solutions (PHI). Patients’ health information must be protected from purposeful or unintentional access by anybody who are not authorized to have access to it, including members of the development team while the application is being created. Any given healthcare solution must include PHI security, thus it is crucial to do this step right.
Your Agile software development process has to include or change a variety of steps when it comes to PHI security in order to safeguard patient data and shield the development team from purposeful or unintended exposure to patient data. Your development team ought to:
- Obscure the data: Private health information should be obscured if patient data must be used for product development. Avoiding the use of “real” data in software development and testing is a better way to obfuscate the data. Our teams often create and use a database of fictitious patient test results.
- For PHI requirements, create non-functional user stories: the user stories must include the security specifications for securing PHI so the development team can incorporate them into the final product.
Agile software development is suitable for healthcare projects
An adapted agile development methodology is well-suited for most healthcare projects because it allows the product team to more accurately capture the elements and features that are most important to end users (whether medical staff or patients) and prioritize the delivery of those features. And ultimately, the ability to deliver useful software that meets the needs of end users impacts the quality of patient care through technology.
Accurately implementing the agile practices described at the beginning of this article is usually not possible when you are working with healthcare organizations that have inflexible processes and strict requirements. For example, if healthcare software development has a hardware component, the team may waterfall the interaction and visual design and then apply an agile methodology to the development of the software (i.e., prioritizing features through backlog grooming, etc.).
The next steps to implementing Agile on your team are to learn about Agile practices – but do not apply the Agile Manifesto to the letter. You need to assess for yourself how you can adapt Agile principles to your organization’s needs. Once you are able to do so, you can look to engage an executive sponsor for a pilot project to demonstrate and determine if an adapted version of Agile is right for you.
As with the development of any other product, you need to mitigate or avoid risks. The risk management processes for Agile are the same as you would need for a waterfall project. When developing healthcare software, keep in mind that risk mitigation is critical not only to the successful delivery of the product, but also to the well-being of patients.
Finally, it is important to recognize that while agile development can be adapted to the needs and processes of a healthcare organization in most cases, in some instances another methodology may be more appropriate. For example, the agile methodology may not be appropriate for interoperability solutions where requirements are well-defined and non-negotiable. Your team should take the time to analyze whether Agile is really right for developing your product and determine which methodology you will use at the beginning of the project.