Can 'Agile' be applied to Healthcare IT teams?

Question

Can Agile be employed in a field like Healthcare IT, where so much of patient care depends on the quality and timely delivery of systems?

Answer 1

Yes, agile development absolutely has a role in Healthcare IT development. No one, not the end-user, not the patient and certainly not the development team is well served by a poorly done development process. Considering some of the principles that underly the Agile manifesto (list shamelessly ripped from Wikipedia with my commentary):

• Customer satisfaction by rapid delivery of useful software. When isn't this an objective?
• Welcome changing requirements, even late in development. Healthcare IT integrates into a field that, while absolutely inundated with technology, isn't particularly IT focused. The potential for a system being designed to "get it right" right off the bat is pretty low.
• Working software is delivered frequently (weeks rather than months). As an end-user of some of this stuff, god would I love this. Rapid, working changes are invaluable, and what turns Healthcare IT from "that thing we need to do" to "that thing that changes the way I do my job".
• Working software is the principal measure of progress. Makes sense in most applications, so there's really no reason it wouldn't span to HIT.
• Sustainable development, able to maintain a constant pace. You see this all over healthcare, from infection surveillance to HIT to facilities. Healthcare isn't a boom-or-bust cycle, its a constant drumbeat.
• Close, daily co-operation between business people and developers. Most HIT isn't a developer tool. It's a tool made by developers. Contact with the client is, and should be, key. It's also much easier to get a system adopted if it works and integrates into the clients workflow, rather than needing to be tacked on, patched, etc.
• Face-to-face conversation is the best form of communication (co-location). From my interaction with clinicians, it's way easier to get stuff done in person, preferably with pads of paper, than any other way.
• Projects are built around motivated individuals, who should be trusted. This is something that will make your life better - so yeah, it should be adopted ;)
• Continuous attention to technical excellence and good design. This is again one of those "everyone should do this, so of course you should" thing. But consider the complexity of HIT systems, and the myriad ways they end up being used, day-in, day-out. A shoddy system isn't going to cut it.
• Simplicity. It should work out of the box. It should work well, all the time, and in the way it's supposed to. People are idiots. Healthcare workers are people. Therefore...you know the rest. Simplicity helps.
• Self-organizing teams. This one might be a little more of a stretch for HIT. Honestly, I'm not confident enough to say one way or the other whether self-organization in this setting is good or not.
• Regular adaptation to changing circumstances. HIT is an active, growing industry with complex, changing regulatory burdens. Being able to adapt seems like a decent idea.

Answer 2

The discussions surrounding the use of Agile Medical Device Software Development in a FDA regulated setting have been around for awhile and are relevant to this question. Here are some reasons why:

1. The Waterfall vs. Iterative development pros and cons are essentially the same and would need to be considered for any Health IT project.
2. The FDA mandated quality systems (see General Principles of Software Validation; Final Guidance for Industry and FDA Staff) for medical device software development used is the industry gold standard. It should be noted that these regulations do not dictate any particular development methodology. In any case, the quality of Health IT software would be vastly improved if these best practices were followed by all.
3. Most Heath IT software development does not currently operate under these FDA regulatory standards. As the barriers for medical device interoperability continue to fall, in particular for mobile platforms, this is likely going to change -- see FDA Addresses Mobile Medical Apps.
4. Also, if you are developing commercial Health IT software you have to ask yourself if you are creating a medical device data system (MDDS): Is My Product a MDDS?

Answer 3

The short answer is "Yes". A longer but more accurate answer is "If you take it seriously."

There are a few themes to keep in mind, which I like to separate into concerns related to (a) patient safety & product quality, and (b) industry regulation.

On the safety and quality side, keep in mind that making safe software is difficult. A few good programmers with some domain knowledge can crank out incredibly useful software that's pretty safe. If they are part of the deployment in a local clinical setting, and can keep responding and adjusting to events during deployment and use of the software, the software might provide value, saving or improving lives with only a few injuries or deaths relate to use errors or software bugs. But the software will require the programmers to be there, all the time, responding, co-evolving the software as the use of the software evolves. This is not a scalable process and when the programmers die or get bored the system can easily become very hazardous very quickly. In order to improve these outcomes and make safe software, there are important development process steps that need to be taken while the software is developed. A good "out of the box" introduction to these can be found in the international standard for development of medical device software, ISO/IEC 62304. The main concept is safety risk management at all stages - during use case analysis and story development, requirements elucidation, system and architectural design, implementation, unit and integration testing. Being agile won't make any of this work go away, or be less difficult, but by focusing on value creation and eliminating work (such as unneeded features, or excessive verification test/fix cycles) that does not create value, agile development can allow a team to integrate this work into development, resulting in safer software developed in the same time. The iterative development practices commonly used by agile teams are very well suited to getting the safety risk management work done, evolving throughout the life of the project rather than being an afterthought. And after the software is operational, feedback from the users and any events even potentially leading to injury need to be considered, individually, and in aggregate, to keep the software safe to use. Agile can help here if it provides a fast-track, safe process for incorporating changes without breaking other parts of the system - which in turn once again requires a good architecture and well-understood design interactions that were created when the software was developed.

The second concern is regulatory. In an ideal world, safety regulations would apply to all products that could be sufficiently dangerous, and a vendor would be able to comply by doing some simple things once they started to cross the line. In practice, global regulations are complex and fast-moving in this industry, meaning that one day you can be developing a small iPhone app that shows some medical data, and the next you are expected to comply with ISO and FDA standards for "quality management system", or QMS. That can be scary for companies that have not had a formal QMS in the past. And agile can exacerbate this because you might start out with a product concept, and through evolutionary development enter unwittingly into a regulated intended use (such as displaying clinical diagnosis data to a user). It's October 2011; my advice to any company contemplating marketing a product that has "health", "medical", "healthcare" in the category name is that they should have a plan for when the product they make becomes regulated by one or more medical device regulators worldwide. Here again agile can help, because the agile practices generally produce (or easily could produce) compliant outputs to satisfy regulatory customers both for pre-market clearance submissions (like FDA 510k), certification (like ISO 13485), and post-market operations. Test-first development fits right into medical software. Continuous integration, automated unit testing, and SCRUM sprint metadata can provide complete objective evidence that risk management and proper verification are done not just as an afterthought but baked in to the development process. In most cases I think agile produces more artifacts than "waterfall", perhaps not in the same form. But conversion of the outputs into something satisfying regulators is a relatively small problem to solve.

So in summary... yes Virginia, there is agile for healthcare IT (and other medical device) software development. Like all things agile, it takes dedication to process, business support, and courage.

Answer 4

Yes, one of the premises of agile development is customer involvement. This is critical in healthcare IT systems and processes. Healthcare IT departments will make better decisions if a customer representative is involved and giving input about how the decisions will affect patient care.

Answer 5

I think it is possible, but the industry needs a huge paradigm shift. I'm in my second year as a health care developer, and trust and self organizing are not anywhere apparent. Healthcare would greatly benefit from formally adopting agile, since it's mostly chaos anyway, with iterative development called "thrash" and late changing requirements because, well, big design upfront doesn't work anyway.

Answer 6

I do understand your question. A good example of Agile development is building a website for someone. Usually a customer doesn't know exactly what he/she wants, so there's a lot of interaction with the customer.

Healthcare IT might seem like a very predefined field in the computer science; with it's strict standards (DICOM, HL7) it seems like there's only one way to implement them, but there's also a lot of preferences and decision making.

In my opinion, whatever product you're making, you're not able to determine ALL the requirements ahead of time, so an agile software development method works very nicely.

Answer 7

As noted, the answer is yes.

When applying Agile to regulated or high risk areas you must define "Done" at each iteration such that regulatory compliance and other risk mitigation strategies are included. For instance, this may require QA documentation, requirements traceability, security audit and other actions to be completed on every iteration.

There's good art and practice, for instance, for application of Agile approaches to FDA regulated environments.

Answer 8

The short answer: Yes. There is a good blog about Agile in High-Assurance Environments that gives some tips.

However, there are some compromises that need to be made. Consider the Agile Manifesto:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

The regulatory bodies value the left-hand side as much as agile teams do, but they require more emphasis on the right-hand side than a typical agile team would do. The FDA, for instance, requires that you validate your processes and tools, asks for fairly comprehensive design and test documentation, and definitely requires a good deal of planning.

On the flip side, many agile principles fit very well into the healthcare world, including:

• TDD and Pair Programming - increase quality
• Tight Customer Feedback Loops - early validation is great
• Iterative Planning - regulatory bodies are all about planning

Answer 9

Some disciplines are already agile in nature. Nursing, for example, relies on a an 'assessment-evaluation-planning-intervention' cycles that depends on multiple iterations of diagnosis/prognosis to incrementally achieve final outcomes.

However, it would be a fatal conflation to try to suggest that health care services provided in such a manner are specifically suited to an essentially single-instance application of Agile software development toward a software tool or system for use in said service delivery.

Answer 10

AAMI is actively working on a Technical Information Report entitled:
AAMI TIR SW1, Guidance on the use of agile practices in the development of medical device software.

I've heard that it may be published in 2012.

It discusses the alignment of the principles of the Agile Manifesto (see EpiGrads answer) with the regulatory requirements, typical processes and other product practicalities associated with medical device software.