top of page

Having Your Learning Health System and Eating It Too!

Summary

There is general agreement that disease research and clinical care would benefit from enhanced coordination, increased patient and provider engagement, and faster communication of results.  The concept of a Learning Health System (LHS; plural LHSs) has emerged to fill this role. Despite progress clarifying the LHS concept and the factors shaping application development, little attention has been given to translating these insights into specific software requirements. As a result, functional variation is the norm among applications claiming the LHS mantle. This article examines some of the main factors shaping development and proposes a minimum set of LHS software requirements, along with example features.

 

What’s In a Name?

The process of naming and defining conceptual attributes plays a key role in establishing development boundaries that distinguish between what is and is not included.  The “Learning Health System” concept originated in 2007 with a description by the Institute of Medicine (IOM) as an application that: 


“…generates and applies the best evidence for the collaborative healthcare choices of each patient and provider; drives the process of discovery as a natural outgrowth of patient care, and ensures innovation, quality, safety and value in health care. (link)”


Subsequent work revealed two major LHS components (Easterline, et. al. 2022; link):


  1. LHS Work activities that improve patient care (e.g., data analysis, quality improvement initiatives, research, translating results into practice, etc.)

  2. Enabling Conditions that facilitate LHS Work (e.g., policies, IT infrastructure, employee competency, etc.).


As is often the case, a concept’s definition consists of high-level, abstract terms that provide only loose guidance for the development roadmap. One way to clarify the development roadmap is to first look at when LHSs veer off the road, this is particularly helpful in determining what NOT to build. 


FAIL: A four letter word

Failure is a risk for all large-scale software engineering projects and many LHSs fail, mainly due to inadequate value (e.g., Stewart and Shah: link):


“…solutions need to be developed that serve one critical purpose: to create value.”


Software value is primarily determined by usability and features. Thus, the death knell for LHSs is an inability to recognize and prioritize high-value features, and/or a poor user interface design. The reasons for failure are often multifaceted, but some of the most common include:


  1. Inability to deliver promised technology (e.g., system integration).

  2. Cumbersome, poorly organized, difficult to learn interface.

  3. Top down, bureaucratic (e.g., metrics) aims, rather than bottom up, applied clinical aims.

  4. Overreach into early technology not ready for the clinical setting.

  5. Little attention given to workflow efficiency and productivity aims.


Although failure can bring an abrupt end, typically it is a protracted process whereby the LHS fails to gain widespread adoption. That is, the LHS lingers within a small set of early adopters, often just the founding members of the LHS initiative. In such cases, even initial supporters may gradually disengage, expressing sentiments like, “I support the initiative, but only agree to contribute data from existing systems (i.e., the EMR) and will make little or no real-time use of results in my practice.”  In other words, there is no value in changing. Therefore, high-value features delivered through an easy-to-use interface are crucial for successful LHS development.

Apples Vs. Oranges

Development boundaries are also defined by an application’s inherent constraints. A key LHS constraint is the co-deployment with an electronic medical record (EMR). Keeping these apples and oranges separate is a crucial consideration to minimize redundant features, data capture, storage, and workflow disruption navigating between systems.  Some of the key differences in aims and scope are:

  • EMR

    • Aims: Source document for patient disease history and medical care, practice management and billing.

    • Scope: Patient

  • LHS

    • Aims: Research management, knowledge generation and dissemination, patient reported outcomes and education, clinical decision support, productivity and efficiency of care.

    • Scope: Patient, extended family / community


Note even within an organization utilizing a single EMR (and version), significant variability can exist across departments in terms of feature deployment, IT support focus, administrative priorities, etc. Consequently, LHSs require flexible configuration options to effectively address this patchwork of needs.

Requirements Roadmap

Despite progress clarifying the LHS concept and the factors shaping development, little attention has been given to translating these insights into specific software requirements. Functional variation is common among applications claiming the LHS mantle.  For example, some “LHS initiatives” are no more than a database of health metrics (e.g., Were patient-reported outcomes collected?) paired with intermittent provider reports (see blog here).  Moreover, existing literature focuses on large scale, electronic medical record restructuring efforts which offers little guidance for the majority of LHS initiatives that navigate significant resource constraints and target specific disease populations.


The requirements presented below represent the minimum necessary for a system to qualify as an LHS. The requirements are descriptive overviews, with subsequent blogs to explore additional details, specific features, and example deployments in various disease populations. The list is separated into four broad functional domains, chosen to best capture the main goals of LHSs.  Common descriptions of these goals include terms like ‘continuous quality improvement’, ‘evidence-based knowledge and decision making’, ‘research driven’, ‘engagement of clinicians, patients and other stakeholders.’ The chosen domains are as follows:


  1. Practice Enhancement: Focusing on ongoing enhancements to healthcare processes, outcomes, and interventions.

  2. Research Advancement: Leveraging research and clinical evidence to inform medical decisions and practices.

  3. Results Dissemination: Supporting research initiatives and facilitating data-driven discoveries.

  4. Patient Engagement: Involving patients and associated individuals in healthcare decisions, feedback, education, and research.

Practice Enhancement

Delivering value within the clinical setting is crucial for widespread LHS adoption, and arguably the most important area of focus. In addition to flexible data capture, numerous requirements could be highlighted, but two of the main ones are:


Real-time Utilization: The inherent problems of delayed reporting loops has been previously discussed (see here). Both patients and staff must be able to transform raw data into useful, actionable information in real-time.  The scope of data used to generate information must accommodate three levels, individual patients, groups based on specified characteristics, and/or the entire sample. The information needs to dynamically update as data is incorporated to the system.


Workflow Improvement: LHSs often minimize the importance of workflow optimization.  One key factor contributing to this oversight is that LHS initiatives are typically spearheaded by health experts, who tend to prioritize abstract modeling and analysis of health data over the practical, day-to-day tasks and responsibilities of clinical staff. Consequently, these initiatives can become disconnected from the operational realities of healthcare environments. LHSs must support and enhance the workflows of a broad range of clinical staff (e.g., scheduling coordinator, receptionist, nurse, physician, etc.).  

Research Advancement

The need for improved coordination between disease research and clinical care is well established (e.g., see here). Indeed, the essence of the LHS is the generation of knowledge and subsequent integration of results back into the clinical setting.  Thus, the LHS needs to be able to do the following:


Manage Research Protocols: The LHS needs to be able to run a wide range of research designs including randomized controlled trials, case series, observational studies, and more. 


Link Protocols: Disconnected data silos are the norm across research projects.  A LHS needs to address this limitation by allowing a single subject to be enrolled in multiple studies using a universal, linked ID and account, and, when appropriate, share data. Connected protocols are critical for Learning Health Networks which always involve multiple research projects. 

Results Dissemination

Data analysis and dissemination of results are fundamental objectives for all LHSs. Despite this shared goal, LHSs typically lack integrated tools to facilitate this process, instead merely provide raw data dumps for analysis in external applications (e.g., statistical packages). Even extracting raw data often requires considerable technical expertise. LHSs need to develop robust tools for efficient data analysis and dissemination of results.


Integrated Dissemination Tools: A key development target for LHSs is the enhancement of the entire workflow associated with data analysis and dissemination. This includes functionality to organize dissemination plans (e.g., journal article, administrative report), extract and analyze data, collaborate with other users, manage files, format text (i.e., word processor), create tables and charts, and update results on demand.


Abstracted Data Model: LHSs need to lower the skill set required to extract raw and / or transform (e.g., recode variables) data for analysis. One of the most effective ways to do this is to design the system so that users do NOT need to understand the underlying data model to query and export data. 

Patient Engagement

The patient is a primary stakeholder of LHSs. However, patient engagement is often an afterthought in LHS design, at best patients experience little more than the burden of data entry.


Patient Portal: Learning Health Systems (LHSs) need to engage and retain participants effectively. Every LHS should include a patient portal with functionalities for data entry, secure communication, incentives (e.g., gamification, points for gift card exchange), and targeted information. Patients often feel overwhelmed by generic health information (see here), especially when it is presented as an undifferentiated mass ("here's everything"). Instead, disease information should be tailored to each patient's own data. This personalization makes the portal more relevant to the patient, providing a "me-first" reason to remain engaged and actively participate.


Across Project Access: To maximize ease of participation across research and clinical initiatives (e.g., participation in a registry), the portal should allow patients to navigate across multiple projects using a single account. Centralized access is a direct benefit of linked protocols and is critical for Learning Health Networks as it eliminates numerous barriers and steps, facilitates recruitment and participation, coordinates communication, and simplifies data aggregation.

Next Steps

LHSs are a crucial component of the overall healthcare delivery system and a key contributor to its incremental quality improvement. While an extensive and dynamic range of features is expected to evolve over time, this article covers some of the essential, minimum requirements for LHSs. While there are other minimum requirements to be discussed, it would be difficult to argue against those presented. Future articles will provide additional requirements, details and example implementation of features using various patient populations (e.g., see here).


Recent Posts

See All

Kommentare


bottom of page