Agility for Health IT
Posted on August 23, 2016
Agile development is no longer just a movement, it has now become established as a best practice in software engineering, but what is it? Today, there is no one agile process or methodology, there are many.One of the earliest is Extreme Programming (or XP).Another that is popular today is Scrum. But regardless of the name, each incorporates the principles of 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
Now, you may thinking that that all sounds very nice, but can it really work for Health IT? After all, we have regulatory concerns. We have patient safety issues. Our software is extremely complex. These are legitimate concerns, and I certainly don’t mean to belittle them. But leaving aside, for the moment, the fact that the Agile Manifesto was mean to be deliberately provocative, let’s explore them a bit.
Processes and tools are essential in software development, but they exist for a reason. They help us to manage complexity and, yes, be more productive. They are net ends in themselves, they are tools that help us to do our work. In Health IT tools are important for another reason: we must work with large datasets, complex vocabularies, and externally imposed requirements. What is so bad about tools that help us to achieve these goals? In a word, nothing. But that really isn’t the point. Rather, we don’t want to fall into the trap of becoming dependent on our processes and tools, and we don’t want to assume that difficult issues can be resolved if we just “follow the process”.
Instead, we need to learn to rely on our most valuable assets, which are people, to solve difficult problems. The best way to design a CPOE system that suits the needs of healthcare practitioners is to sit down with people who will be using the software and explore design ideas. This isn’t to say that we shouldn’t write specifications. Instead, to paraphrase Humpty Dumpty in Through the Looking Glass, the question is whether or not they will become our master.
This line of thought leads naturally to the second point of the manifesto. Specifications are one form of documentation, and trying to ensure that they are set in stone at the outset of a project is generally an excercise in futility. Actually, it is possible to take this approach, but it will be very expensive to do so, and it is almost inevitable that our products will fall short of expectations. Instead, agile is a process (there’s that word!) of progressive refinement. One of the best ways to get feedback early on and, if necessary, make changes, is to deliver working software. The sooner health care practitioners are able to start working with the software (in simulated situations, of course), the sooner we will discover problems, missing functionality, and unnecessary or unwanted features.
Okay, but what about standards and regulatory requirements. In my view, it is best to treat them as needed functionality. In Scrum, projects are divided into epics and sub-epics which, in turn divided into user stories. One approach is to create a conformance epic. The stories in this epic will address conformance with standards and compliance with relevant regulations. These stories will be a little different from stories such as: “As a physician, I need to be able to order a basic metabolic panel (BMP) with a priority of stat”, but I don’t think it is pushing the concept of user stories too far to include, say, “As a developer, I need to be able to generate an ADT_A01 (HL7) message that conforms too…” At any rate, conformance is a fact of life, so if we do not accommodate it through user stories, we must find another way.
The third point of the manifesto is really a special case of the second. The difference is that the focus here is on software economics and, in particular, the use of contracting as a means of developing software. The terms of a contract are a form of documentation, and the same risk exists here as does with any other requirement or specification; namely, that it will become an end in itself. Now, I can only address contract negotiations from the point of view of a developer, and leave it to others to address legal and business concerns. The terms of a contract can rapidly become a strait jacket, and will enforce an approach to a particular problem, even if it proves counterproductive. How much better would it be if a culture of ongoing collaboration between contractor and customer made it possible to respond to changing requirements and new discoveries in real time? This is a different type of relationship and, I think, a more positive one. I also believe it is more conducive to building quality software that meets customer needs.
The final point of the manifesto really summarizes the other three. Responding to change is the raison d’être of agile, and each of the other three points of the manifesto has focused in some manner on responding to change. Health IT is complex, and the more complex a system or project, the more susceptible it is to change. This means, ironically, that agile principles, if anything, are more important in Health IT than in other domains, because significant (and disruptive) change is all the more likely during the lifetime of a project (never mind a system).