Problem Management Module: An Innovative System to Improve Problem List Workflow

Abstract

Electronic problem lists are essential to modern health record systems, with a primary goal to serve as the repository of a patient’s current health issues. Additionally, coded problems can be used to drive downstream activities such as decision support, evidence-based medicine, billing, and cohort generation for research. Meaningful Use also requires use of a coded problem list. Over the course of three years, Intermountain Healthcare developed a problem management module (PMM) that provided innovative functionality to improve clinical workflow and boost problem list adoption, e.g. smart search, user customizable views, problem evolution, and problem timelines. In 23 months of clinical use, clinicians entered over 70,000 health issues, the percentage of free-text items dropped to 1.2%, completeness of problem list items increased by 14%, and more collaborative habits were initiated.

Background

A problem list is a fundamental component of an electronic health record (EHR), serving as a thumbnail view of ongoing diagnoses, findings, symptoms, and other health concerns that pertain to an individual patient [1]. When clinicians maintain an accurate problem list, patients generally receive better care [2], have less frequent omissions of care [3], and benefit from more frequent adherence to evidence-based care. Clinicians also benefit from using the problem list by receiving clinical decision support (CDS) alerts [4] that guide them to better outcomes, viewing detailed information about a disease via infobuttons [5], and more easily referring to a list of ongoing health issues, without searching through past notes. Furthermore, medical researchers benefit from an accurate problem list as they seek/mine for specific diseases in order to generate study cohorts and conduct comparative effectiveness research based on diagnoses and other patient health issues [6–9]. Effective use of a problem list is necessary for certification through Joint Commission [10], ONC HIT certification [11], and American Recovery and Reinvestment Act/Meaningful Use (ARRA/MU) [12], which can ultimately lead to incentive pay and/or avoidance of penalties.

Despite their many benefits, problem lists have been found to be sub-optimal, being inaccurate, incomplete, and out of date [13]. Studies have shown that even major health issues such as coronary artery disease and hypertension have a 49–51% probability of inclusion on a patient’s problem list [2,14]. There is disagreement about what actually belongs on a problem list [15], and who owns the list, consequently leaving clinicians often unwilling to update a problem to its proper state [2] even if they know it to be inaccurate. Adding a duplicate problem to the list rather than updating an existing item adds clutter, which further reduces the value of the problem list. This behavior can be compounded by the fact that many organizations maintain multiple problem lists per patient – often segregated by discipline, care site, or acute/chronic state of the problem.

At Intermountain Healthcare (IH), an electronic problem list has been available for almost 20 years [16]. However, low utilization of the problem list, high prevalence of free-text problems, the need to replace an aging problem list system in the NICUs, and Meaningful Use (MU) requirements prompted the design of a new problem management module (PMM) that expanded the notion of the problem list to include a wider scope of health issues and workflow associated with them. When this project began in January 2011, only 47% of patients had any problems on their list. In fact, as a whole, IH averaged 8 problems per patient, with a median of just 1 problem per patient, 72.5% of which were coded. In the entire IH inpatient population, only 34% had an active, coded problem as required by MU.

Objective

The objective of this paper is to describe the PMM developed at IH and the functionality designed to overcome the following limitations of the prior system: underutilization, duplicate entry, out-of-date problems, free-text problems, missing attributes, inability to find the proper problem in a large list, cumbersome addition of new problems, an inability to tell the clinical story, and problem maintenance tension between care givers, resulting in incorrect problem status. We present new and unique functional improvements incorporated into the PMM, and present quantitative results of pilot implementations at IH care locations.

Materials and Methods

Setting

The PMM was built at IH, in Salt Lake City, Utah, a not-for-profit integrated health care delivery network. IH operates 22 hospitals across Utah and southern Idaho and employs over 33,000 employees, 1,000 of whom are multispecialty clinicians working in 185 ambulatory clinics [17].

In order to meet the specific needs of the clinicians, and IH in general, a steering committee was formed, comprised of clinicians from different disciplines and care settings. This committee met every week, along with representatives from informatics, terminology, data modeling, knowledge management, clinical analysis, user interface design, and software engineering. Weekly meetings focused on forthcoming work, demonstration of the current state of the PMM, and resolution of issues that arose during the development process. Additionally, several structured user-acceptance testing sessions occurred with clinicians from many specialties. This iterative, user-centric, participatory approach culminated in the PMM tool that was initially released to a select, primarily inpatient audience at IH, including newborn and adult Intensive Care Units (ICU), acute care floors, and Tele-Health. The goal of the participatory design was to develop a common model that could be used across diverse care settings.

For quantitative results, we queried usage statistics for the PMM and legacy problem list application from our enterprise data warehouse and terminology logs for the period from the original pilot implementation on August 24, 2012, to the most recent data available on July 21, 2014. In some cases we compared data from before PMM implementation to post-implementation. Simple statistics were generated by the authors from these data. IRB approval was obtained prior to study initiation.

System Description

Master List

When opening the PMM, a longitudinal list of problems is presented, containing all problems from birth to death, whether active, inactive, acute, chronic, or historical (Figure 1). Viewing historical problems alongside active problems made it easier to ascertain a picture of a patient’s overall health status. However, for the master list to be useful and not overwhelming, focus on data presentation and mechanisms for sorting, filtering, and grouping was needed.

Figure 1.

Master problem list view within the PMM.

One such mechanism aggregated multiple instances of the same problem, reducing overall length of the master list. Once aggregated, only the most recent instance of the problem was visible, with a superscript denoting the actual number of instances. Clicking the superscript opened a list of all prior occurrences with their detail.

Another mechanism for managing data was custom sorting. Each list column defined a custom sort order that tailored sorting of problems to an individual clinician’s needs. When applied to body system, a clinician may choose to see cardiovascular-related problems first, respiratory-related problems second, and fluids/electrolytes-related problems last. Once set, data are automatically sorted according to the clinician’s own preference.

Smart Search

Scrolling through a long list of problems on the master list was a tedious task. IH created the Smart Search field to be the integral means by which clinicians searched for existing problems within the problem list, and as the sole means of adding new problems. Smart Search allowed clinicians to find a problem of interest by typing in a portion of the problem description. The description was used to find matches in three data sources: the patient’s master list, the terminology database, and the clinician’s common list. The results from searches against these three sources were then merged, ordered, and displayed as a single result set (Figure 2).

Figure 2.

Smart Search results. Existing problems are shown first, followed by matches from terminology, both results are ordered by common list preference

Searching the master list first allowed identification of the patient’s existing problems. Presenting existing problems helps to keep the problem list uncluttered and up to date. An active instance of a problem cannot be added to the list until the current instance is resolved.

The second source searched is the terminology database. The search term is matched against a constrained domain of problem concepts that have been explicitly included based on identified needs and historical usage patterns. The matches are also translated into possible synonyms, so closely related terms and acronyms may be quickly found. For example, if a clinician enters ‘heart’, the search will return exact matches with the word ‘heart’, but also synonyms or acronyms, such as CHF, myocardial infarction, cardiomyopathy, etc. Search results are pre-coordinated so that body system, problem type, and status are automatically selected for the clinician [18]. The pre-coordinated attributes for each problem are available in an XML document residing in our knowledge repository [19].

The third source searched is the clinician’s common list, consisting of a clinician’s most commonly used problems. Matches against the common list are used to prioritize search results, so the clinician’s preferred terms (typically specialty or setting specific) are shown at the top of the result set. This allows faster identification of higher-interest problems that a patient may have. The search results are limited to 40 items to avoid overwhelming clinicians. Clicking on one of the search results will add the pre-coordinated problem to the patient’s problem list. Problems are mapped to SNOMED-CT terms where possible.

Feedback Mechanism

IH works with clinicians prior to implementation of vocabularies to define, pre-coordinate, and load only the concepts and representations that are clinically relevant, as evidenced by usage and clinician review. Post-implementation, clinicians require new content, and request synonyms for existing content that allow for efficient searching. When terminology is incomplete, clinicians revert to adding patient data as free-text rather than as coded concepts. Current processes for handling terminology requests are ad-hoc and entail months of effort. This can leave clinicians disengaged from content governance, and patient data remain uncoded and thus unavailable for decision support. To address these issues, IH developed a new terminology feedback process to engage clinicians. Novel and efficient mechanisms were developed to identify gaps and allow clinicians to interactively review and approve recommended content in the context of patient care.

When clinicians added a free-text problem, a structured request was automatically routed to the terminology work queue. Clinical modeling engineers (CME) then inspected the free-text term, and searched for and evaluated matches for the term in the existing dictionary, to determine if the term was misspelled, an acronym, a synonym, or missing. CMEs then added the new content or created mappings between the synonym/acronym and root concept, ensuring future searches return proper results. CMEs then created a list of candidate substitutions for the clinician’s free-text problem, and sent that list back to the application for review by the clinician.

The next time a clinician opened the same patient’s problem list, the application presented the clinician with the substitution candidates for the free-text problem (Figure 3). When reviewing, the clinician viewed the original free-text alongside the list of candidates. The clinician could select a single choice to serve as the replacement for the free-text problem, or could choose to reject all provided choices with an accompanying reason. If rejected, the process was performed one more time, resulting in a new set of candidates. If the clinician chose to accept one of the newly provided terms, the free-text problem was automatically replaced by the coded concept.

Figure 3.

Feedback Mechanism presenting a clinician with suitable substitutes for an entered free-text problem.

Problem Evolution

Problems tend to follow a predictable progression, or evolution. When treating a patient, clinicians begin creating a mental list of differential diagnoses, ruling out or confirming each one as data become available. Once confirmed, a differential diagnosis is evolved to a diagnosis, meriting treatment and monitoring. When a diagnosis is resolved, if a clinician decides that a reminder of the condition should be available to other caregivers, the diagnosis is evolved to a historical problem.

To support the evolution of problems, IH worked with a team of clinicians to enumerate 10 distinct problem types (Table 1). Through experience, IH clinicians felt that the problem list was the logical place to record and communicate these various types of health issues managed by their interdisciplinary teams. (Health issue is the more correct term for items on the PMM list, but we will interchangeably refer to them as problems throughout the paper for brevity.) A mapping between the types was created, defining the evolution pathway. For each coded concept in the problems terminology domain, a knowledge document was created that described how the specific problem may progress along the evolution pathway. Each of the 10 problem types was given a set of unique statuses that, when used, automatically triggered the progression of a problem along its evolution pathway.

Table 1.

Problem Types & Statuses.

Type	Description	Possible statuses
Finding	Observation about the patient that is less than a diagnosis occurring in relation to a physical exam. E.g., Abdominal pain.	Active, Inactive, Proposed, Resolved, Error, Resolved, Create History <Evolve>
Procedure	An action taken on a patient’s body, typically diagnostic or treatment related. E.g., Lumbar puncture.	Active, Cancelled, Candidate, Resolved, Error, Unconfirmed, Ordered, Scheduled, Resolved, Create History <Evolve>
Differential Diagnosis	A possible diagnosis that has yet to be confirmed or ruled out. E.g. Sepsis, suspected.	Working Up, Ruled out, Error, Confirmed <Evolve>
Diagnosis	A confirmed health issue, describing the nature of a disease, injury, or congenital defect that requires monitoring or treatment. E.g. Carotid artery stenosis, or Trisomy 8 mosaic syndrome.	Active, Inactive, Proposed, Resolved, Error, Working Up <Devolve>, Resolved, Create History <Evolve>
Health Maintenance	Care steps taken to maintain good health, focused on early detection and prevention. E.g., Well child check-ups or vaccinations.	Due, Error, Recommended, Up-to-date, Resolved, Create History <Evolve>
Risk	An event with high probability of occurrence. E.g., Falls Risk.	Active, No Longer of Concern, Proposed, Resolved, Error
Event	A specific major occurrence. E.g., Automobile accident.	Active, No Longer of Concern, Proposed, Resolved, Error, Resolved, Create History <Evolve>
Device	An implantable device designed for a specific function. E.g., Pacemaker, or Port-a-cath.	Unconfirmed, Present, Removed, Error, Removed, Create History <Evolve>
History Of	Any medical and surgical item that has resolved, but continues to be pertinent to patient care. E.g., Breast cancer, or organ transplant.	Validated, Unknown, Proposed, Resolved, Error
Social History	Lifestyle choices. E.g., smoking, alcohol, or illicit drug use.	Active, Unknown, Proposed, Resolved, Error, Resolved, Create History <Evolve>
Family History	Major diseases which were/are present in the patient, but which are present in family members, potentially increasing the likelihood the patient will acquire the disease. E.g., cystic fibrosis.	Validated, Unknown, Proposed, Error

The evolution document describes possible evolution pathways and the coded concepts that represent an evolved problem. When a clinician changes a problem’s status to one defined in the document, evolution is triggered. For example, when a differential diagnosis is ‘Confirmed’ the problem automatically evolves to a diagnosis concept. The new diagnosis concept is added to the problem list and linked to the existing differential diagnosis. Only the most recent evolution for the problem is shown in the list, though all linked previous evolutionary states may be seen in the change history (Figure 4).

Figure 4.

Change history of Sepsis showing evolution.

Once the diagnosis is resolved, a clinician may choose to evolve the problem to the terminal state of historical problem. Selecting the status of ‘Resolved, Create History’ will trigger a traversal of the evolution document one more time, locating the equivalent concept for the historical problem. That new concept is added to the list and linked to the end of the problem chain.

Having so many different statuses for each type of problem was confusing to the clinicians. Thus, a second knowledge document was created that mapped each problem status to one of four overarching meanings: active, proposed, inactive, or error (Table 2). This equivalency mapping was used to present a color-coded status indicator, agnostic of the actual status wording. For instance, a ‘Recommended’ health maintenance issue and a ‘Scheduled’ procedure both mapped to a yellow indicator, meaning both were in a proposed state. This allowed clinicians to focus on the meaning of the status, not the wording of the status.

Table 2.

Status Equivalency

Status Equivalent	Description
Active (Green)	The problem is currently present in the patient, or is actively monitored and treated.
Proposed (Yellow)	The problem is potentially of concern, but more work is needed to confirm.
Resolved / Inactive (Grey)	The problem is resolved or no longer a concern.
Error (Red)	The problem was added in error, perhaps on the wrong patient.

New Problem Indicator

When a clinician sees a patient and updates the problem list, there is a sense of ownership over what is in the problem list. However, when the same patient is seen later, the list may be significantly different because other clinicians have seen the patient and added and updated problems. When this occurred, the sense of ownership over the list was lost because it was too difficult to easily determine what specifically had changed, and a clinician may no longer be willing to maintain the list, even if they know it is inaccurate. To combat this, an indicator was created that alerts clinicians to changes in a patient’s problem list.

Each time a clinician views a patient’s problem list, a time-stamp is logged for that clinician-patient combination. On subsequent views, the time-stamp is retrieved and compared against the last edit time of the patient’s problems. A running count is generated that tracks how many problems were added or updated since that date. This number appears directly on the master list tab (Figure 5). The clinician can click on the number to get more details about what has changed since last review. When clicked, a popup appears listing newly added or updated problems and relevant details. Selecting a problem from the list navigates the clinician directly to the problem in the master list.

Figure 5.

New problem indicator. The superscript “1” on Master List tab indicates one new problem on the list.

Assessment and Plan

The prior version of the IH problem list application required clinicians to open a separate module to create the assessment and plan (A&P) for a problem. To find previous A&Ps written for a specific problem, one would have to review all recent clinical notes for any mention of the problem, which was a tedious task because previous A&Ps were sometimes copied forward without adding new information. IH clinicians expressed a desire to add and review A&P notes while reviewing a specific problem, using a single application.

To address this workflow issue, the PMM allowed an A&P to be created and stored for an individual problem. All A&Ps pertaining to a problem are listed in chronological order and are readily accessible from a note icon next to the problem. This makes it easier to determine progress towards treatment goals.

When an overarching clinical note needs to be created, such as a progress or discharge note, the latest A&P of each active problem was retrieved and automatically inserted into the note. This generated note contained much of the necessary detail of each problem, requiring only small changes before finalizing it.

No Known Problems

To meet MU requirements, functionality added to the PMM allowed attestation that a patient has “no known problems”. If there are no MU-defined problems on a patient’s list, the PMM displayed a link to a “no known problem” form (Figure 6). By using the form, the clinician affirms that the patient had no known problems. This attestation counted as a coded problem in the MU numerator. When attested to, the date and clinician name is shown. Once an actual problem was added to the problem list, the “no known problem” assertion was automatically removed since it is mutually exclusive to coded problems on the problem list. If all problems were resolved, attestation would begin anew.

Figure 6.

No Known Problems indicator.

Patients may visit a clinician to address any of the health issue types shown in Table 1, allowing entry of a broader range of health issues than just diagnoses and medical history. For example, if the visit is for purely preventative reasons, a health maintenance problem can be added to the problem list. However, the numerator criteria set forth in MU guidelines do not recognize all 10 health issue types that PMM supports. In the case that none of the items on the patient’s problem list meets the MU criteria for problems, the “no known problems” logic is initiated.

Timeline View

To improve the comprehension of complex problem lists, and to see patterns in a patient’s health history, a timeline view of the problem list was created, similar to work reported by Plaisant et al. [20]. The timeline view graphs health issues currently in view, in relation to time. The x-axis is time, starting at the patient’s date of birth, minus 9 months, on the far left, until present day on the far right. The y-axis lists each distinct health issue visible on the patient’s list, placing the earliest onset health issue on top, and the most recent onset health issue at the bottom. When multiple occurrences of the same health issue are present, they are mapped on the same line, and each occurrence is placed in the appropriate period on the x-axis. Each health issue is drawn as a rectangle with the onset of the health issue as the left edge, and the resolution date as the right edge of the rectangle, showing the lifespan of the issue. A patient’s encounters/visits are overlaid on the graph to correlate them in time with health issues. Thin transparent bars represent a short visit to an outpatient provider, and a wider bar denotes a longer inpatient encounter (Figure 7).

Figure 7.

Plotting problems in chronologic order for a holistic representation of the patient’s problem history.

The timeline view provides immediate detail about how many problems a patient has had, how long these problems lasted, what health issues occurred concurrently, if a caregiver was seen during that time, and when the most recent instance occurred. Long-standing problems will show prominently, prompting clinicians to inquire further. Additional patterns, such as problem overlaps, may emerge when viewing data on a lifetime scale that are otherwise not obvious.

Views

During clinician testing of the PMM, it was observed that some clinicians occasionally became frustrated that there were problems on the list that did not specifically pertain to the patient’s current visit. These frustrated clinicians chose to resolve all the problems on the list and then add problems specific to the current visit, rather than deal with the existing large problem list. This action is detrimental to the accuracy of the patient’s problem list, and may destroy years’ worth of problem history. This phenomenon was termed Tension, because a clinician was acting as a force to deform the problem list, pushing it out of harmony with the patient’s true health state.

To resolve the underlying cause of this behavior, Views were introduced (Figure 8). A View is simply a way for a clinician to separate problems from the large master list, narrowing to a focused problem list. A View references selected problems from the master list, allowing the clinician to choose only those problems that are of interest, imbuing the clinician with a sense of ownership over those few problems.

Figure 8.

A team view that depicts subsumed and prioritized problems for a care team.

This concept reduced clinician’s frustration with large lists; however, they became curious about what other clinicians’ Views looked like for the same patient. To satisfy that curiosity, a search function was added that allowed discovery of other Views, and allowed them to be opened in read-only mode. The viewing of other clinician views was useful when dealing with referrals to a specialist.

Now that IH clinicians could create a list of problems for their own needs, they wanted to show the interrelatedness of those problems, to better express the clinical story. The PMM allowed clinicians to drag and drop one problem onto another, building a subsumption hierarchy in whatever manner best depicts the clinicians thought processes. When the PCP searched for the cardiologist’s View, he or she would not only see the problems the specialist was concerned with, but also the relations between them. For example, the hierarchy might inform the PCP that the patient has underlying heart issues caused by poorly managed diabetes, prompting a discussion with the patient.

When presented with Views for individual clinicians, it was realized that an entire care team could also benefit from the Views concept. The Team View allows groups of clinicians in a specific care setting, such as an ICU or outpatient clinic, to define a set of problems with relationships. The Team View allows the entire care team to collaborate on what problems should be monitored and treated, giving all shifts and specialties a better understanding of the team’s priorities. Just as personal views could be searched for and inspected in read-only mode, so too could Team Views. Using another team’s view is useful when patients transfer from one team to another. The prior team’s thoughts and work could be referred to before receiving the patient in a new unit so that preparations could be made, thereby improving handoffs.

Results

During the time period examined, 580 clinical users, including physicians, nurse practitioners, and physician assistants from 9 locations, have used the PMM. These users entered information on 5,557 patients, adding 71,838 total health issues. On average, 110 clinicians are entering or updating 3,900 health issues per month, with a peak of almost 200 clinicians entering over 4,700 issues during one month. Clinicians used the Assessment and Plan tool to attach over 997,000 A/P notes to problems on 5,079 patients.

Free-text problems entered using PMM were 1.2% of the total problems entered during the study period. During the same period, 11% of problems entered using the legacy problem list application were free-text. We also found that roughly half of the problem terms selected by users in the Smart Search tool contained pre-coordinated information.

The number of missing data elements has fallen from an average of 27.63 per 100 problems using the old problem list application, to 13.73 using the PMM, for fields such as body system, problem type, and status.

Not only are data more complete, problem evolution has added a new dimension of insight to the problem list. Using PMM, clinicians evolved 3,098 health issues, most commonly by changing a status to “Resolved, create history.” But clinicians also evolved a differential diagnosis to a confirmed diagnosis 1314 times: The most frequently evolved differential diagnoses were Jaundice due to preterm infant, suspected (308), Respiratory distress syndrome, suspected (208), Jaundice in a term infant, suspected (175), and Sepsis, suspected (142).

Clinicians utilized views, subsumption hierarchies, and prioritization to organize problem lists in clinically-meaningful ways. Care-teams selected problems off the master list and built Team Views 9,352 times; individual clinicians created clinician-specific Views 116 times. Arbitrary segregation of problems into a View is one way of organizing problem data; an additional method is to subsume problems into a hierarchy of relatedness. The maximum depth any view subsumed a problem is 5 levels deep, with an average depth of 1.5 per view. When prioritizing problem data in a View, the largest number of problems prioritized was 18, with an average of 3. The most commonly prioritized problems were apnea, nasal cannula oxygen administration, hyperbilirubinemia, and septic shock.

Discussion

The large number of problems added per patient (average 12.9/patient) using the PMM can be explained in three ways. First, problem evolution results in many new problems being created automatically for a single issue as the original problem’s status is changed to “resolved” and its newly evolved instance is created, which is not readily apparent to the clinical user. Second, most of the users of the PMM were in ICU settings, which average a much higher number of problems per patient than other care settings. Third, organizational incentives for clinicians to meet MU goals coincided with use of the PMM, possibly inflating results. Future studies will further compare use of the PMM with the legacy problem list application, which is still in use in certain locations (primarily outpatient clinics), to determine if the new features are the cause of a perceived improvement in problem management at IH. Workflow and clinician engagement improved as a result of the new problem terminology search and maintenance functionality. The large percentage of pre-coordinated terms selected in the Smart Search tool likely helped clinicians find appropriate terms and reduced free-text entry. The usefulness of the Feedback Mechanism was also evident and will be incorporated in other parts of our EHR.

Not only has the PMM created much more data than a typical problem list application, it has created entirely new types of data for study, such as how clinicians aggregate data in a view and evolve problems. It is evident from our usage statistics that clinicians in our currently ICU-centric pilot sites prefer to create team views rather than personal views. This is largely due to the fact that these clinicians use a team-oriented model for care in which information and treatment plans are shared. Future work will explore how clinicians and teams use Views, and the manner in which they impart order to the Views by subsuming problems into a hierarchy. Additional studies will investigate if Views lead to a more accurate problem list, and if they reduce tension between caregivers of the same patient.

The goal of the PMM project was to increase clinician adoption of the problem list by addressing issues associated with the use of problem lists in general. Each of the enhanced features described was designed to address one or more of these issues. Current usage statistics indicate that these interventions have been successful. However, a more formal study will be necessary in order to determine the exact impact of each of these enhancements on problem list usage and patient care, and their generalizability to more clinicians and settings. In the 23 months of use, feedback from clinicians has been extremely positive, affirming that the PMM provides more value, is easier to use, and offers innovative features that entice use of the system.