The Elastic Electronic Health Record: A Five-Tiered Framework for Applying Artificial Intelligence to Electronic Health Record Maintenance, Configuration, and Use

Introduction

Properly and proactively configuring modern electronic health records (EHRs) has grown beyond human capabilities. As they are infinitely configurable, embedded potential and capabilities exist; however, properly configuring these capabilities at scale in a timely manner in an increasingly resource-constrained environment is not possible through the manual approaches of today. Fully leveraging this potential will require artificial intelligence (AI)-powered governance. AI integration with EHRs, however, has almost exclusively focused on front-end, user-, and patient-facing “copilots.” These copilots enhance navigating, searching, understanding, synthesizing, or documenting medical information. AI copilots have benefits, but they operate on a manually maintained, costly, and continuously noncurrent EHR content and configurations, ie, their effectiveness is fundamentally limited by flaws in the underlying EHR architecture. These flaws result from the complexity and scale of configurable “solutions” that comprise health record platforms; to solve this issue, we propose the “Elastic EHR”. We define this as an EHR that can proactively suggest and, upon validation, perform optimal configuration changes, significantly reducing governance costs and providing better user and patient experience. To specify the areas in which AI should target EHRs, we propose a five-tiered model (please see Table 1), each tier building upon the previous, with an emphasis on Tiers II-IV, as Tiers I and V have already been unofficially defined.

Tier I: Autonomous Database Tuning

Tier I consists of autonomous database reconfiguration, operating similarly to the Oracle Autonomous Database with automated tuning, patching, and workload balancing [1]. This tier creates a change log for retroactive review, with examples including component upgrades, system maintenance suggestions, software error detection, cyber security threat detection, and supplemental database backups. To clarify, Tier I does not involve independent editing of the EHR production environment or any create, update, or delete functions.

Tier II: Internal Configuration Optimization

Introduction to Tier II

In Tier II, EHR clients shape the performance based on the desired “solution” strategy, style guides, and standardizations via approval and scheduling of recommended changes. Solutions are defined as a discrete set of functionality, including templated notes, auto text shortcuts (aka “dot phrases”), orders, order sets, and alerts. This tier optimizes connected EHR solution builds. For example, the Oracle Health EHR (formerly known as Cerner Millennium) contains up to 850 content and configuration tools, each with dozens to hundreds of options and subtools. The output of each of these tools may be connected to one or multiple other solutions. To build a simple form, we may require up to 12 distinct tools and a week of skilled architect time. The proper front-end flow depends on the coordinated build of solutions, but the tools to configure these solutions are siloed, and the solution architect or informaticist may be blind to the full system impacts. Changing the content of this form may negatively impact multiple other solutions, including note templates, orders, interfaces, and discrete data capture. Tier II ensures this hypothetical form is built both to institution-set standards and aligns with these other solutions.

Tier II Scenario

A solution architect needs to update a form, a context-dependent collection of discrete data entry fields. However, multiple other solutions may populate or use these data fields, including results or data review solutions, “smart” documentation or ordering templates, outbound interfaces, logical rules or alerts, or patient registries. Without querying the database or system configurations for each potential impact, the architect is largely unaware of possible downstream ramifications. Tier II addresses this by providing AI-assisted guidance on how these solutions interact, automatically suggesting any necessary edits to keep interrelated components synchronized. In this process, a middleware layer becomes invaluable; it orchestrates data exchange among siloed EHR modules, allowing the AI engine to integrate seamlessly with the relevant system components. By maintaining consistent data structures and communication channels, middleware ensures that the architect’s updates are executed safely and comprehensively. Technically, this would include AI-generated queries of relevant database tables and system files, as well as a graphical user interface overlay that helps the architect visualize potential impacts and either approve or deny suggested changes.

Evaluating Tier II

Tier II is designed to streamline how institutions sustain their EHRs, according to enterprise standards, while reducing configuration silos and ensuring that changes to one component do not inadvertently disrupt others. Evaluation metrics may include configuration turnaround time, error rates, compliance with institutional standards, and architect or administrator feedback.

Configuration Turnaround Time

This is the time to implement a specific EHR change—from the initial request to the final deployment. An effective Tier II system should significantly shorten this resolution process.

Error Rates

This is to monitor the frequency of errors or backouts after initial release. Fewer postdeployment fixes indicate that AI-driven guidance is proactively catching conflicts and dependencies.

Compliance with Institutional Standards

This is the alignment of new solutions with established style guides, templates, and regulatory requirements. A high compliance rate suggests that Tier II is helping maintain standardized, high-quality configurations.

Architect or Administrator Feedback

This includes qualitative feedback from solution architects, informaticists, and administrators about the system’s ease of use, clarity of recommended changes, and impact on daily workflows.

Tier III: Workflow Optimization

Introduction to Tier III

Tier III proactively suggests configuration changes to optimize EHR choice architecture. Optimal choice architecture in this context entails a configurable design that incentivizes the minimum number of clicks, keystrokes, and mouse miles to achieve an intended, quality outcome. Optimal architecture makes the right, efficient choice path the intuitive option, enhancing EHR usability [2]. With the current complexity of EHR design to account for the high variability within patient care, following the most efficient choice paths is not easy or intuitive. By globally monitoring user behavior and determining pockets of efficient users achieving defined process or outcome metrics, Tier III finds the ideal choice paths and suggests configuration changes to democratize them across all relevant user populations. It makes the easy path, the right path. Examples include identifying missing orders or default selections within order sets; optimizing note template content to reduce the manual insertion of discretely captured information or the unnecessary use of free text; updating default naming conventions and selections to reduce the misrouting of orders, notes, or messages; and consolidating unnecessary user positions, preferences, or roles.

Tier III Scenario

An example scenario involves monitoring the ordering patterns of outpatient primary care physicians treating acute nasopharyngitis (common cold). Across hundreds of outpatient clinics, ordering times for these encounters vary widely, despite similar order volumes and medication classes. Tier III AI identifies a subset of providers who achieve faster, more efficient workflows by using personal order sets. The system consolidates these personal sets into a recommended, enterprise-level order set and queues its integration into the primary care physician’s workflow position. Once approved, the AI executes the change. To achieve this level of real-time monitoring and seamless deployment, a robust middleware solution can mediate data traffic, collecting operational metrics from disparate EHR modules, and pushing approved configuration changes into production.

Evaluating Tier III

Tier III aims to optimize user workflows by identifying and disseminating best practices across relevant roles and settings. Key metrics may include user efficiency, clinical process and outcome metrics, adoption and utilization rates, and user satisfaction and burnout scores.

User Efficiency

This is used to quantify the number of clicks, keystrokes, mouse miles, or time spent per task. A Tier III system that democratizes efficient workflows should reduce these metrics across user populations.

Clinical Process and Outcome Metrics

For instance, we measure whether streamlined order sets improve prescribing accuracy, reduce redundant orders, or decrease overall encounter time. Monitoring patient throughput, wait times, or complication rates can highlight improvements in care quality.

Adoption and Utilization Rates

This is used to track how often recommended workflows, templates, or order sets are actually used by clinicians. High adoption signals that Tier III optimizations align with user needs and clinical realities.

User Satisfaction and Burnout Scores

Survey clinicians gauge whether the system’s workflow suggestions reduce frustration, documentation burden, and burnout. Positive shifts in these areas suggest that Tier III is effectively enhancing usability.

Tier IV: External Knowledge Linkage

Introduction to Tier IV

Tier IV proactively maintains the currency of EHR clinical content and decision support through two mechanisms. First, content may be directly linked to its derived source. For instance, registries and their integrated actions (orders, forms, laboratory or radiographic studies) could be linked to the United States Preventive Services Task Force (USPSTF) guidelines [3]. When the guidelines change, Tier IV proactively offers the configurations required to incorporate these updates. These linkages could also extend to nonclinical sources including governmental regulations or issuances, institutional policies, or payer requirements. When the Centers for Medicare and Medicaid Services update the essential elements for clinical note content, Tier IV offers the configurations to add or remove the applicable sections for efficient documentation. Second, Tier IV crawls sources of evidence and peer-reviewed literature and cross-checks these findings with existing EHR configured content. As evidence becomes available, Tier IV suggests its EHR incorporation, either as de novo content or updating existing solutions. If a trusted source of truth publishes a new clinical practice guideline, then Tier IV offers a set of EHR solutions to incorporate this clinical practice guideline across the relevant EHR workflows and positions.

Tier IV Scenario

The USPSTF updates their breast cancer screening recommendation to begin at age 40 years versus age 50 years [3]. Because the USPSTF had been identified as a source of truth as part of Tier IV, a web-crawling, agentic AI identifies the change and suggests the requisite configuration changes to incorporate this update into the corresponding EHR patient registry. With the underlying Tier II AI system in place, changes to other associated solutions can also be performed concurrently, such as any related forms, rules, or clinical documents.

Evaluating Tier IV

Tier IV proactively updates clinical content and decision support based on changing guidelines, regulations, and published evidence. Key metrics include update lag time, completeness of updates, accuracy of incorporated guidelines, and regulatory compliance.

Update Lag Time

This measures how quickly new guidelines or evidence-based recommendations are integrated into EHR workflows after they are published. Shorter lag times indicate that Tier IV is effectively automating the update process.

Completeness of Updates

This is to evaluate how comprehensively the system identifies and applies relevant updates. A high success rate suggests that the AI is accurately mapping external knowledge sources to the EHR’s configuration.

Accuracy of Incorporated Guidelines

This is to assess whether the recommended EHR changes align with the authoritative sources, ensuring no contradictory or partial implementations that might compromise clinical care or billing requirements.

Regulatory Compliance

This is to track how often Tier IV updates help ensure compliance with evolving payer, government, and institutional mandates. Fewer compliance violations or missed updates reflect a more robust external linkage mechanism.

This also helps to track how often Tier IV updates help ensure compliance with evolving payer, government, and institutional mandates. Fewer compliance violations or missed updates reflect a more robust external linkage mechanism.

Tier V: Copilots and Assistants

Introduction to Tier V

Finally, Tier V involves context-dependent functions that serve to enhance care efficiency, quality, and user experience for both patients and providers. These are the copilots. This tier is the current, almost exclusive focus of integrating AI within EHRs. Examples are robust, but popular ones include Microsoft’s GenAI copilot integration within Epic Systems [4] and the Nuance Dragon Ambient eXperience (DAX) AI copilot [5].

Safeguards

Integrating AI into EHR maintenance and configuration carries inherent risks that require careful mitigation strategies. These safeguards must address proper human oversight, data security, safety testing, legal and regulatory compliance, and data standards.

Tiered Approval

Although AI can autonomously recommend changes to database configurations or workflows, no modifications should be pushed into production without human review and authorization (particularly for Tiers II–IV).

Change Log and Audit Trails

We need to maintain comprehensive records of all AI-generated recommendations and subsequent human-validated changes. This includes versioning, timestamps, rationale for acceptance or rejection, and who approved the changes.

Backout Steps

All AI-recommended changes should come with manual build and backout steps in case manual, direct human architect involvement is required to modify or rollback the change.

Role-Based Access Controls

Authority for approving final changes should be restricted. Only designated administrators, informaticists, or clinicians with appropriate privileges should “sign off” on AI-driven recommendations [6].

Data Security and Privacy

Encryption and Secure Communication

Ensure all data in transit or at rest is encrypted. For Tiers III–IV, where external data sources and registries may be accessed, secure protocols should protect patient and system information.

Regulatory Compliance

Any AI-based solution that handles protected health information must adhere to federal regulations and equivalent international guidelines. This includes thorough documentation of access, role-based permissions, and breach reporting mechanisms [7,8].

Deidentification for Training

If EHR data is used to train AI models, employ robust deidentification or anonymization methods to protect patient privacy.

Safety Testing and Sandbox Environments

Staged Deployments

Deploy AI-generated configuration changes in a nonproduction environment first. Validate for unintended effects, usability impacts, and potential conflicts with existing solutions. Only after thorough testing and clinician feedback should changes move to production.

Automated Regression Testing

Implement continuous and automated testing routines that check clinical workflows, alert systems, and data integrity after each AI-prompted change. This helps identify errors early and prevents adverse impacts on patient care.

Algorithm Transparency and Explainability

Explainable Recommendations

Tiers II–IV rely on AI to suggest or enact configuration changes. Provide clear justifications or “explanations” for each recommendation (eg, how the model determined a particular workflow optimization). Transparency bolsters trust and aids human reviewers’ decision-making [9,10].

Ethical and Legal Considerations

Liability and Accountability

Clearly define who bears responsibility if AI-suggested changes negatively impact patient care—whether it is the vendor, the health care institution, or a combination. Incorporate these details into institutional policies and vendor contracts.

Regulatory Approvals

Some aspects of Tiers II–IV that meaningfully affect patient care (eg, advanced clinical decision support) may require regulatory oversight or approval from agencies. Understand and follow applicable guidelines when introducing these features [11].

Interoperability and Third-Party Validation

Standards-Based Implementation

Align AI-driven changes with industry standards (HL7 [Health Level Seven], FHIR [Fast Healthcare Interoperability Resources], SNOMED CT [Systematized Nomenclature of Medicine Clinical Terms], LOINC [Logical Observation Identifiers Names and Codes], etc.) to maintain interoperability.

Independent Audits and Certification

Consider periodic third-party evaluations of AI systems and processes, focusing on data handling, software quality, and patient safety standards.

Challenges

Although nearly every hospital and office-based physician now use a certified EHR [12], the market remains dominated by three vendors—Epic Systems (36%), Oracle Health (25%), and MEDITECH (16%) [13]. This concentration, coupled with the high up-front investment required for AI development and proprietary configuration tools, could stifle the adoption of Tiers II–IV. Overcoming this dynamic requires forging partnerships that incentivize vendors to open their proprietary configuration tools through standardized application programming interfaces and collaborative research and development initiatives. Such measures would allow third-party and in-house AI solutions to integrate, reducing reliance on vendor-specific consulting and expanding client autonomy. By adopting off-the-shelf AI modules—rather than building everything in-house or through a single vendor—small-to-mid-sized health care organizations can gradually implement Tiers II–IV at a lower cost. To make this financially viable for vendors, professional organizations, health care systems, and regulatory bodies should leverage market demand and policy incentives that reward open architectures, building upon the 21st Century Cures Act [14]. In doing so, vendors could reorient their business models—moving from fee-based solution architecture services toward engineering-focused products and support—without sacrificing profitability. This shift would ultimately accelerate innovation, lower costs, and help realize the full potential of the Elastic EHR.

Conclusions

The adoption of the five-tiered Elastic EHR framework represents a structured approach for overcoming some of the major limitations in commercial EHR systems. By leveraging AI to manage and optimize configurations, this model addresses the inefficiencies and high costs, and downstream frustrations, associated with EHR sustainment. However, the realization of this potential faces significant hurdles, particularly due to the dominance of a few major vendors who control the necessary configuration tools and must see financial benefit in adopting such changes. Additionally, the complexity of health care environments, the need for substantial financial investment, and the lack of robust research on this topic also represent significant hurdles. Successful implementation will require collaboration, continuous research, and a balanced approach that augments medical, solution architect, and clinical informatics expertise with AI capabilities. If these challenges can be addressed, the Elastic EHR could substantially improve the efficiency, quality, and user experience of health care delivery, fully delivering on the promises of digitization within health care.