How to Implement Agile Software Development in Healthcare

Tim Parsons | June 19, 2019 | 12 Min Read

We explain how teams developing software products for the healthcare industry can implement Agile development methodology, as opposed to a pure Waterfall methodology, to create solutions that still meet security and regulatory requirements, but deliver more value to the end user.

The Agile methodology is favored by many software development teams because of its flexibility, receptiveness to change, and room for creative opportunity. However, when developing solutions within the highly regulated healthcare industry, the majority of teams are likely accustomed to the traditional Waterfall method of development that lays out all requirements and expectations before the work begins. Well, what if we told you that Agile is actually a very suitable, if not more suitable, methodology for developing healthcare solutions?

In this article, we’ll dive into the unique challenges that are faced by teams creating healthcare software products and how they can apply an adapted Agile methodology to address these challenges and develop solutions that still meet all the necessary requirements, but exceed expectations.

Agile Development Practices

If your team is used to the traditional Waterfall development process and is not familiar with Agile, these are the core elements and practices of developing using an Agile methodology – all of which can be adjusted to fit your team’s needs:

  • Sprints: Sprints are the foundation of Agile. A sprint is a defined period of time where the team focuses on delivering a set of product features. Sprints can vary in duration depending on the project’s needs. We’ve found that sprints of two weeks in duration usually work well when developing healthcare software.
  • Sprint planning: Prior to the execution of a sprint, the entire team gathers to plan the activities that will occur during that sprint. The team commits to a set of user stories during sprint planning. User stories are defined as a set of requirements and acceptance criteria that define a feature or scenario from a user’s perspective. User stories are used to define how a function should work and behave.
  • Sprint demonstration: At the end of every sprint, the team has an opportunity to demonstrate the work they’ve accomplished. The sprint demonstration is also an important opportunity for the product owner to provide feedback and make adjustments to the work that was delivered during the sprint. This feedback process can save healthcare organizations a lot of time and money from having to correct mistakes or make changes/improvements after a solution is delivered, as typically seen when working using Waterfall.
  • Sprint retrospectives: At the end of every sprint the team gathers to review the sprint and identify areas that went well and things that could be improved upon. This allows the team to continuously review what they are doing 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. With more minds at the table comes more ideas to solve any roadblocks experienced.
  • Backlog: The backlog is a list of prioritized user stories or features that details what is required to build the product. The product owner ‘owns’ the backlog, meaning that the product owner must define and prioritize all of the user stories within it. The product owner is expected to make feature trade-off decisions based on the product vision and the business needs.
  • Sprint board: The sprint board is a tool used by the team to organize and express the status of the work in the current sprint. Issues are moved from one status to the next as they are being worked on.

Your team does not need to consider these practices prescriptive if you’re trying to implement Agile development for the first time; adjust the practices as needed to make them work for your product team. For example, the team can use a software tool for their sprint board, like JIRA, or they can use a physical board with “post-it” notes.

Let’s dig into how we can apply these core Agile practices to the unique complexities of developing healthcare solutions.

Navigating a Complex Regulatory Environment

The healthcare space is highly regulated by a number of government and non-government entities. Although these regulations are well-intentioned and are in place to protect patient safety, they result in a complex regulatory environment that impacts the processes required to design and build a software product.

When delivering a healthcare application using Agile, you’ll need to consider and conform to various regulatory requirements (ie HIPAA compliance) just like you would using Waterfall. However, some key benefits of using an Agile development methodology is that it fosters innovation and functionality is able to be delivered at a faster rate. If the software product is considered a medical device, there will be significant regulatory requirements to observe. Your team will need to determine these requirements up front and they’ll be largely dependent on two key questions:

  1. Is the software product considered to be a medical device OR is it part of a medical device?
  2. Are you storing protected health information (PHI)?

If you answer yes to either of these, then your team will need to identify all of the regulatory requirements that you must adhere to, become educated on them and then develop an approach and a set of processes that will meet those requirements before any development sprints occur – something that isn’t common with an Agile approach. Requirements are usually defined as development occurs when using the Agile methodology. The work to identify the processes that are required to meet the regulatory requirements begins with first understanding what the requirements are for the specific jurisdiction that the application will operate in. This can be done by consulting a regulatory expert, or, if your organization already has a set of process to meet the regulatory requirements, then you should leverage those. Regardless of whether you use an Agile or Waterfall approach for software development, the regulatory requirements will not change. Once you have determined what the regulatory requirements are, they can be documented as non-functional user stories and placed in the backlog. By doing this, these requirements become visible to the team and can be treated as would the functional user stories in the backlog. Usability testing, also known as formative testing, can also be integrated into the sprint cycles to ensure the team meets regulations and is able to identify any possible safety risks with the product being developed.

If it hasn’t been made clear by now, the development of healthcare solutions includes quite a bit of overhead associated with regulatory requirements, especially if the solution you’re developing is considered to be a medical device. Your team will need to include the regulatory overhead in the Agile sprint planning process so that the workload is properly assigned and product development is on track to meet the delivery deadline.

Now, although it’s ideal when developing healthcare solutions to define all product requirements upfront, healthcare software products are typically complex; they can include integration with other systems and are often mission critical. Their complexity adds to the difficulty of being able to define all the requirements prior to any development occurring – this situation is where Agile becomes very useful. Using Agile, corner cases and unknown complexities, as well as valuable features and new requirements, can be discovered by the team as development occurs and can be addressed and corrected in future iterations. Course corrections, which are part of the nature of Agile development, can be used to figure out complex solutions as you deliver functionality. This means that although your team may discover an element of the solution needs to be changed or added, Agile course corrections will allow the team to account for the necessary work to execute within the following sprints and not block them from delivering functional features each sprint. This is one of the most compelling reasons to use Agile as a software development methodology. By implementing sprints, your resulting product may actually end up being more valuable and usable than your team initially had anticipated and this process prevents expensive time wasted correcting a solution once it’s developed.

Securing PHI

One of the unique requirements of healthcare solutions is the security of Protected Health Information (PHI). Special considerations must be made to ensure that patients’ health information is protected from intentional or unintentional access by individuals that are not authorized to access this data, including members of the development team during the development process. Securing PHI is an essential element of any delivered healthcare solution, so it’s critical to get this step right.

When it comes to securing PHI, a number of processes need to be added or modified to your Agile software development process to protect patient data and to protect the development team from intentional or unintentional exposure to patient data. To do this, your development team should:

  • Obfuscate the data: If you need to use patient data during product development, obfuscate the private health information. A superior approach to obfuscating the data is to not use ‘real’ data for software development and testing purposes. Our teams often will build and use a repository of fictional patient test data.
  • Create non-functional user stories for PHI requirements: The security requirements for protecting PHI must be captured in user stories so the team can implement those requirements in the product.

Managing a High Volume of Stakeholders

Aside from managing a strict regulatory environment and taking proper measures to ensure patient information security, another characteristic unique to developing healthcare software is that many stakeholders are typically involved in the development of the product. Product initiatives tend to have a wider reach in a healthcare organization and, therefore, have a greater number of stakeholders. It’s critical that all stakeholders are identified and that their needs are captured by the product owner; failing to do so will put the product’s success in jeopardy.

Agile puts a lot of focus on dynamically adjusting what the team is delivering throughout product development. For this reason, there needs to be an increased level of communication with all stakeholders to ensure they are engaged in a meaningful way. For a healthcare organization where many stakeholders are involved in the development of a product, congregating everyone for regular and frequent syncing can be a bit of a challenge. Usually with Waterfall, key stakeholders are only updated on project milestones. But by communicating more frequently, you allow the opportunity for stakeholders to offer suggestions, ask questions and make requests. This way, product development keeps in alignment with stakeholder expectations and the overall product vision. To address the challenge of frequent communication with all key stakeholders, you can leverage a gate review process. A gate review meeting is a session where stakeholders are gathered and the product is demonstrated to the participants. The schedule is reviewed and the risks and issues are examined. At the end of the meeting, the stakeholders are asked if the team should continue or if the project should end. The purpose of the gate review meeting is:

  • To show the stakeholders what has been accomplished to date and solicit their feedback
  • To ensure that all stakeholders are aware of the project status and the priorities for future sprints
  • Gain the buy-in of the stakeholders

Agile Software Development Works For Healthcare Projects

An adapted Agile development methodology works well for most healthcare solution projects because it enables the product team to more accurately capture the elements and features that matter most to end users (whether it be medical staff or patients) and prioritize the delivery of those features. And in the end, being able to deliver useful software that addresses end users’ needs impacts the quality of care provided to patients through technology.

Exact implementation of the Agile practices outlined at the beginning of this article typically isn’t feasible when working with healthcare organizations that have inflexible processes in place and strict requirements, but that doesn’t mean that your product team should dismiss Agile all together. For example, when developing healthcare software has a hardware component, the team may want to conduct Interaction and Visual Design using Waterfall, and then can apply an Agile methodology to the development of the software (i.e. prioritisation of the features via backlog grooming, etc.). This can be referred to as a “Wagile” approach to development.

The next steps for implementing Agile within your team are to become more educated on Agile practices – but don’t apply the Agile Manifesto to the letter. You need to make judgments for yourself on how to adapt Agile principles to meet the needs of your organization. Once you’re able to do that, then you can work on getting an executive sponsor to buy into a pilot to demonstrate and determine if some adapted version of Agile will work for you.

Like you would with the development of any other product, you will need to mitigate or avoid risks. The risk management processes for Agile are the same as you would need for a Waterfall project. What’s important to note when developing healthcare software is that risk mitigation is critical not only for the successful delivery of the product, but also for the patient’s well being.

Lastly, it’s important to acknowledge that although in most cases Agile development can be modified to fit the needs and processes of a healthcare organization, in some cases, a different methodology may be more suitable. For example, the Agile methodology may not be suitable for interoperability solutions where the requirements are well defined and non-negotiable. Your team should take the time to analyze if Agile is truly right for the development of your product and establish which methodology you’ll be using at the onset of the project.

Download the Guide to Developing Engaging Digital Health Software

This 90+ page guide focuses on the intersection of your user, technology choices, and the regulatory environment you face that will play a critical role in the success of your application.

Suggested Stories

Guide to Creating Engaging Digital Health Software

This guide shares our knowledge and insights from years of designing and developing software for the healthcare space. Focusing on your user, choosing the right technology, and the regulatory environment you face will play a critical role in the success of your application.

Read More

Accelerate Time To Market Using Rapid Prototyping

In this webinar, you will learn how to leverage rapid prototyping to accelerate your products time to market in one week, agile sprints.

Read More

WebRTC: Top 5 Unified Communications Systems Integration Challenges

WebRTC is looking to be a game changer in terms of its impact on voice and data communications.

Read More
Macadamian has been acquired by Emids 🎉
This is default text for notification bar