Agile Development of Clinical Decision Support Tools Using Stories

I recently read a fascinating article in JAMIA about using Agile development techniques and stories to prioritize, create, and test clinical decision support (CDS) tools in healthcare information technology (IT). I wanted to share it because I think Agile in general, and stories specifically, can be leveraged in many different ways that benefit clinicians and patients.

The Agile software development methodology came about in 2001 when a group of programmers met to find a better way to organize, write, and test computer code. They agreed on twelve principles to follow, such as delivering working software frequently in an iterated process, working closely with end users throughout the project, and continuously focusing on technical excellence and good design. A nice summary notes that the Agile methodology advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change.

The researchers from the University of Texas Southwestern Health System, Parkland Health and Hospital System, and Texas Health Resources used user stories in lieu of complicated software requirements or specifications. Instead of forcing the clinical or operational users who want a tool built into the electronic health record (EHR) to fill out complicated forms and to think like programmers or IT analysts, the group asked for three data points. At a generic level, these include: As a [type of user], I want [some goal] so that [some reason]. For CDS, certain guidelines were put in place. The authors wrote:

We required that the “As a [type of user]” field be the recipient of the CDS, typically a clinical role, though it could be a patient role for patient-facing decision support.

In general, the team initially tried to describe the “I want [some goal]” entry in technology-agnostic terms: for instance, “I want to be advised that the patient. . .,” rather than “I want a Best Practice Advisory to pop up that the patient. . .” By doing so, we hoped to encourage consideration of a wide array of possible methods for delivering decision support—not just interruptive pop-up alerts—and avoid premature lock-in to one specific method.

For clinician-facing CDS we sought to complete the “so that [some reason]” section with one or more of the following: (1) a direct benefit to the clinician (e.g., streamlined work), (2) a benefit to their patient, or (3) a benefit to meeting a shared goal of the organization in which the clinician practices.

I want to highlight their attempt to encourage the requestor to use terms that didn’t specify a kind of technology or explicit tool in order to keep all the options on the table. Often, end users don’t know what they don’t know; I’ve seen many very specific requests for tools to be built into the EHR that are not the best options, hence keeping it generic is essential.

The authors gave a great example of a before and after user story. What started out with “As Pharmacy and Therapeutics Committee co-chairs, we want the EHR to prevent physicians from ordering IV hydromorphone so that we won’t run out, which we are on track to do in in seven days despite sending two email memos to all medical staff” became “As a provider ordering IV hydromorphone (Dilaudid), I want to be advised of the national shortage and prompted to order an alternative instead, so that our nearly depleted stock is preserved for those patients of mine and my colleagues who truly cannot be given the alternatives of intravenous (IV) morphine or oral hydromorphone.” Wow. What a difference! The final user story will get much more buy in and generate much more physician goodwill.

It’s important to be able to evaluate the outcome of any intervention that is being contemplated, so the researchers made certain to develop and agree upon both process measures and outcome measures. Naturally, these measurements were begun before the intervention (i.e. CDS tool) was introduced into the EHR so pre- and post-results were available.

I’m excited that the medical literature now includes articles about how hospitals and health systems are using proven software development techniques to build and maintain their EHRs. The days of the “wild west” are soon to be in the past as we learn and share lessons of best practices and their proven results.

Are you using Agile methodology or stories with your EHR? Reach out to me and tell me how.