Agile Model Driven Development of Electronic Health Record-Based Specialty Population Registries

Abstract

The transformation of the American healthcare payment system from fee-for-service to value-based care increasingly makes it valuable to develop patient registries for specialized populations, to better assess healthcare quality and costs. Recent widespread adoption of Electronic Health Records (EHRs) in the U.S. now makes possible construction of EHR-based specialty registry data collection tools and reports, previously unfeasible using manual chart abstraction. But the complexities of specialty registry EHR tools and measures, along with the variety of stakeholders involved, can result in misunderstood requirements and frequent product change requests, as users first experience the tools in their actual clinical workflows. Such requirements churn could easily stall progress in specialty registry rollout. Modeling a system’s requirements and solution design can be a powerful way to remove ambiguities, facilitate shared understanding, and help evolve a design to meet newly-discovered needs. “Agile Modeling” retains these values while avoiding excessive unused up-front modeling in favor of iterative incremental modeling. Using Agile Modeling principles and practices, in calendar year 2015 one institution developed 58 EHR-based specialty registries, with 111 new data collection tools, supporting 134 clinical process and outcome measures, and enrolling over 16,000 patients. The subset of UML and non-UML models found most consistently useful in designing, building, and iteratively evolving EHR-based specialty registries included User Stories, Domain Models, Use Case Diagrams, Decision Trees, Graphical User Interface Storyboards, Use Case text descriptions, and Solution Class Diagrams.

I. Introduction

The evolving transformation of the American healthcare system from fee-for-service to value-based care links payment to quality of care. This drives a need to identify population registries of patients with specialized conditions, and measure their clinical status and quality of care in addition to costs. Capturing the data needed for multiple disparate specialty measures by manual chart abstraction proves unsustainably costly and time-consuming. With the increased adoption of electronic health records (EHRs) in the U.S. following the HITECH Act of 2009 [1] [2], clinical registry projects increasingly employ electronic EHR-based tools for data collection, for providing real-time clinical decision support, and for reporting/feedback to clinicians within their normal work environment and tools [3]. However most current EHR-based registries and measures focus on primary care conditions: work on developing EHR-based specialty care registries is just now underway. The complexities of specialty registry EHR tools and measures, along with the variety of stakeholders involved, can result in misunderstood requirements and initial product defects. Requirement changes–especially for data collection tools–are frequent and inevitable, as users first experience the tools in their actual clinical workflows.

Modeling a system’s requirements and solution design offers a powerful way to remove ambiguities and facilitate shared understanding of an EHR-based solution design. Useful models also facilitate continued evolution of the design to meet newly-discovered project needs. However traditional “Big Design Up Front” (BDUF) modeling of requirements often results in a large expenditure of time/effort to create models that may prove to be for features that are changed, or never used [4].

The “agile modeling” movement grew from a desire to harvest the benefits of shared unambiguous models of a system design, while reducing the time needed to create models and the wasted effort associated with creating models for unused features [5]. As we embarked on an ambitious project to develop new specialty registries and associated EHR tools across a 40-specialty academic medical center practice within one year, the need for rapid yet high quality development led us to employ iterative development and agile modeling principles and practices.

Accordingly, we adopted the following project aims: Apply agile modeling tools to the design of EHR-based specialty registry projects, in order to:

• depict the full scope of each project and its deliverables visually

• remove ambiguities about the intended structure and behavior of EHR-based tools

• promote shared understanding among multiple stakeholder teams: clinical operations, performance improvement, information resources, and analytics.

• support rapid-cycle time-boxed development of multiple registries and associated EHR tools

• promote agility in responding to evolving requirements as stakeholders interact with delivered EHR-based tools.

II. Methods

A. Agile Modeling Principles and Practices

1) Why Model?

In 1999, the Unified Modeling Language (UML) User Guide described 4 primary reasons for modeling a complex system: to visualize the system, to specify its behavior and structure, to guide construction, and to document [6]. In his 2002 book introducing “agile modeling”, Scott Ambler honed the core purposes of modeling to two: to understand, and to communicate [5].

Wherever possible, we elected to use UML for the following reasons:

• Each diagram type has a clear purpose, allowing selection of the “right tool for the job”.

• Each diagram type has clear “rules” about content and allowed relationships. This element of rigor helps in thinking more clearly during problem analysis and solution design.

• UML is well-supported by available modeling applications—if one wishes to persist diagrams beyond a whiteboard and digital photos (the most commonly used agile modeling tools).

• Since UML is not an idiosyncratic local set of diagrams, it also helps communicating with others outside one’s institution.

2) Agile Modeling Practices

Ambler describes a series of Agile Modeling Best Practices, Values, Principles, and Practices, both in his book [5] and available for review online [7]. Though beyond the scope of this paper to review exhaustively, especially relevant Agile modeling practices to clinical specialty registry development include, among others:

• Active Stakeholder Participation

• Model with Others

• Apply the Right Artifact(s)

• Use the Simplest Tools

• Model in Small Increments

• Create Simple Content

Applying these principles led to frequent whiteboard modeling, using a variety of UML and non-UML diagram types, most often to understand a problem or solution design better, but also commonly to communicate effectively among our team and outside of it.

B. Methodology

The methodology we ultimately settled on blended features from Rosenberg’s ICONIX process [8] and Ambler’s Agile Model-Driven Development [9]. From the ICONIX process we took the overall framework of using a core subset of models for both dynamic (behavioral) and static (structural) modeling, tying the two together in the context of a graphical user interface (GUI) storyboard. From Ambler’s Agile Model Driven Development, we employed his concept of an “Iteration 0” envisioning phase of initial requirements and architectural modeling, followed by frequent small “model storming” sessions during 2-week development iterations.

An overview of our model-driven methodology derived from these processes is shown in Fig 1.

Figure 1.

Model-Driven Development Methodology Employed

C. Models Employed: UML and non-UML Diagrams

The authors of the UML User Guide famously included the comment that one “can model 80 percent of most problems by using about 20 percent of the UML” [10]. Additionally, even UML experts tend to agree that additional non-UML models and artifacts will be needed to model certain topics, conceding “UML is Not Enough” [11].

• Agile artifacts we used that are not formally part of UML include: User Stories [12], User Interface storyboards, and Use Case text [13].

• UML diagrams employed include: Class Diagrams (Domain Model, Solution Class or Object Diagram), Use Case Diagrams, Decision Trees (a form of Activity Diagram), Swimlane Workflow (Activity) Diagrams, and State Diagrams [14].

Descriptions and examples of the diagram types and other artifacts we found most consistently useful for EHR-based specialty registry development follow:

1) User Stories (and Acceptance Criteria)

Purpose

Define who the product is for, what it should do, and why (for what benefit). Specify what success (being “done”) looks like.

Example

User Story for an Osteoporosis Registry:

“As a specialist caring for patients with osteoporosis and/or osteopenia,

I want to develop a registry of all patients seen with either of these conditions (a) in my clinic and (b) across the Health System,

so that I can more easily identify and rectify care gaps in appropriate use of medications for these conditions in order to improve bone health in the patients we serve.”

Acceptance Criteria for a User Story can be a simple bulleted list:

• Population registry report of all osteoporosis patients

• Clinical decision support tools to prompt providers to order Vitamin D, calcium supplements, and/or bisphosphonates for osteoporosis patients

• Report of potentially-eligible patients not enrolled in registry

• Training on use of decision support tools and reports

2) Class Diagram (Domain Model)

Purpose

Define ‘nouns’ of system - depict the major terms and concepts (‘objects’ or ‘classes’ of things) relevant to the project, and show how they are related to each other ( Fig. 2).

Figure 2.

Domain Model (Class Diagram) for an Osteoporosis Registry

3) Use Case Diagram

Purpose

Define ‘verbs’ of system - depict the major activities people in various roles can accomplish when using the system ( Fig. 3).

Figure 3.

Use Case Diagram for an Osteoporosis Registry

4) Decision Trees

Purpose

Unambiguously define the logic (‘business rules’) involved when evaluating one or more input conditions to derive a result, such as whether or not to display an alert to a physician or nurse ( Fig. 4).

Figure 4.

Decision Tree for a Clinical Alert

5) Graphical User Interface storyboard

Purpose

Provide the customer a chance to anticipate what the system will look like, and to visualize interacting with it when reading a Use Case Text, described next (UI mockup of EHR Alert: Fig. 5).

Figure 5.

Graphical User Interface (GUI) Storyboard

6) Use Case Text

Purpose

Define the ‘sentences’ of the system. Describe how the end-user will interact with the system’s objects in the context of a given user interface, typically in a ‘user does this, system does that’ format.

Partial example - Basic Path

“The provider opens the Office Visit encounter. The system evaluates the Alert logic (see Decision Tree) and displays the Alert window in the provider’s EHR screen, with a statement that says ‘Your patient has a diagnosis of Osteoporosis/Osteopenia and is not on Bisphosphonates.’

The provider clicks Jump to Order Entry hyperlink. The system silently stores a record of this as “Action taken” and opens up the Order Entry activity for the provider to prescribe a bisphosphonate.”

All model validation was via design reviews and demos.

III. Results

A. Quantitative Results

During calendar year 2015, the co-development team:

• developed 58 total EHR-based registries, with 1 or more for each of 33 specialties included in the project’s initial scope

• defined 134 clinical process and outcome measurements

• built 111 EHR-based data collection tools

• placed over 16.000 patients on registries.

B. Qualitative Results

1) Specific benefits by diagram type

• User story: rapidly gaining consensus on the purpose and scope of a given registry project. Along with the Acceptance Criteria, served as a useful point of reference when questions about original intent of a registry project’s scope arose.

• Domain model: identifying clearly what clinical conditions or procedures define a given registry, and what data collection tools and reports are envisioned.

• Use case diagram: clarifying which EHR-based clinical alerts should display for which roles

• Decision tree: removing ambiguity about the exact conditions under which a clinical alert should “fire” (display to the end-user).

• UI Mockup and Use Case Text: gaining agreement on data collection tool design and selection options. Specifying exactly what should happen when selecting a given option after a clinical alert is presented, including any lockout times to prevent the alert from re-firing prematurely.

2) General benefits of modeling

• recognizing useful design patterns for re-use on subsequent projects

• speeding the learning curve for cross-training team members on EHR tool capabilities new to them

• providing a “mental model” to start from when needing to quickly adapt a design to clinical feedback

IV. Conclusion

Electronic Health Records can be powerful data collection tools for specialty patient registries. The complexities of these registries, tools, and measures can result in requirement ambiguities and initial unexpected or unwanted EHR tool behavior. Thus requirements evolution is to be expected and embraced, to help ensure new EHR tools work in clinicians’ actual workflows. An “agile modeling” approach can foster shared understanding of registry requirements and design, removing ambiguities and promoting a shared mental model. A working set of structural and behavioral models promotes rapid-cycle evolution of EHR tool design in response to clinical feedback. A subset of diagram types proved most useful for constructing EHR-based specialty registries and associated data collection tools.