Highlights
New features
New: Scribe Configuration (UI) & Text Editor for Templates
ISL- 8596: Previously, Scribe Note chart tab-to-template mappings were only manageable on the backend. With this release, practices gain a self-service, permission-controlled interface to review and understand their current Scribe configuration, improving transparency and reducing reliance on support for visibility into mapping status. Practices can now manage Scribe Note template mappings directly from OfficeEMR, without needing backend support. This release adds a new configuration screen (Setup > Interface Setup > Scribe Configuration) that gives authorized users visibility and control over how each Scribe Note chart tab connects to its encounter template.
The new Scribe Configuration screen displays all 5 supported chart tabs along with their current mapping status giving the practice a single, clear view of their Scribe Note setup. Access to this screen is controlled by a new Security Screen specifically for Scribe Configuration. This follows the same role-based access control pattern already used throughout OfficeEMR for other Security Screens. Practice administrators should review role permissions and grant access to the new Scribe Configuration Security Screen for any users who need to view or manage these mappings. 
This release also introduces the foundational building block for Scribe functionality in OfficeEMR via a new Text Editor control within the EMR encounter templates. When creating or editing a template item, users can now select Text Editor as a control type, alongside existing control options. This allows users to create more expressive, readable template content rather than plain, unformatted text. When configured, text entered into a Text Editor control will flow through to the SOAP note, allowing formatted content to carry over into the patient encounter documentation automatically.
Ready to Send Statement – New Last Payment Date & Amount Display Setting
ISL- 8550: The Ready to Send Statement window now supports displaying the patient's last payment date and amount, giving billing staff quicker visibility into recent payment activity without leaving the statement workflow. When enabled, these columns show the most recent payment made toward the patient's account by their responsible party. If a patient has more than one responsible party, the displayed date and amount will reflect the most recent payment made by either party, ensuring the information shown is always the latest, regardless of who made the payment. If no responsible party payment exists for the patient, the Last Payment Date and Last Payment Amount fields will simply display blank rather than an error or placeholder value.
Both fields have also been added as Advanced Search parameters, allowing users to filter statements by:
- Last Payment Date (as a date range)
- Last Payment Amount (as an amount range)

This allows practices to quickly identify accounts based on recent payment activity — for example, finding patients who haven't made a payment recently, or filtering by payment amount ranges.
To Enable the columns go to Billing > Statements > Ready to Send > More > Change Display Settings and select Last Pay. Date & Last Payment.

Ready to Send Statement – Next Appointment Display Setting
ISL- 7883 The Ready to Send Statement window now also supports displaying a patient's next upcoming appointment, giving billing staff useful context about scheduled visits directly within the statement workflow. When enabled, this new column displays the patient's first future appointment (i.e., the earliest appointment with a date/time greater than today), shown with both date and time. This enhancement gives billing staff added context when reviewing statements helping identify patients with upcoming visits, which can be useful for coordinating statement timing, in-office collections, or follow-up communication.
To Enable the Next Appointment column go to Billing > Statements > Ready to Send > More > Change Display Settings and select Next Appt. 
Enhancements
MyMedicalLocker Modernization – Streamlining Account & Health Records
As part of our ongoing modernization of MyMedicalLocker (MML), we've streamlined the Account and Health Record modules by removing several sections that were redundant, non-authoritative, or disconnected from actual provider workflows. This update simplifies the patient experience and ensures that the information patients see in MML reflects only data that is genuinely maintained and used by their practice.
Why We're Making This Change
Across a number of MML sections, patients have long had the ability to enter or edit information directly within the portal, such as demographics, contact details, employer information, medical history, and personal health data. However, none of these patient-entered updates were ever transmitted to connected practices or incorporated into provider workflows. Practices continue to rely exclusively on their own EHR systems as the authoritative source for this information.
Over time, this created a disconnect: patients would update information in MML and reasonably assume their provider had seen it, when in reality the data lived only in MML and was never shared. This led to confusion, mismatched records between MML and the practice's EHR, and unnecessary maintenance overhead for data that provided no real clinical or administrative value. Removing these sections ensures that MML reflects only practice-sourced, clinically relevant data going forward, eliminating duplication and the risk of patients relying on information their provider never actually sees.
What's Changing
The following sections have been removed entirely from MML:
- Account – Emergency Contact - The Emergency Contact section has been removed entirely from MML. Patient-entered emergency contact information was never transmitted to connected practices, so practices will continue relying solely on emergency contact details maintained in their own EHR systems.
- Account – Demographics - The Demographics section (name, date of birth, gender, address, and contact details) has been removed entirely from MML. This information was never shared with connected practices and often conflicted with the authoritative demographic data providers maintain in their EHR systems.
- Account – Address and Phone - The Address and Phone section has been removed entirely from MML. These patient-entered updates were never transmitted to connected practices, which continue to rely on their own EHR systems as the single source of truth for patient contact information.
- Account – Employer - The Employer section has been removed entirely from MML. Employer information was never transmitted to practices and was not tied to any clinical, administrative, or billing requirement.
- Health Record – Summary - The Summary section has been removed entirely from both the frontend and backend. This section duplicated information already available elsewhere (such as Medications, Allergies, and Conditions) and was never standardized or shared with connected practices.
- Health Record – Lifestyle - The Lifestyle section (exercise habits, diet, smoking status, etc.) has been removed entirely from both the frontend and backend. This data was never standardized against clinical frameworks, was never shared with practices, and was not actionable for providers.
- Health Record – Goals (My Goals only) - The My Goals option has been removed from the Goals section. Patient-entered personal goals were never transmitted to practices or standardized against care plan frameworks. Practice Goals remains fully intact and unchanged, as it is tied directly to provider workflows and continues to support care plan tracking.
- Health Record – Medical Conditions - The Medical Conditions section has been removed entirely from both the frontend and backend. Patient-entered conditions were often incomplete, not linked to standardized clinical codes, and in some cases never reached the practice at all outside of intelligent intake.
- Health Record – Family History - The Family History section has been removed entirely from both the frontend and backend. This information was never transmitted to connected practices, was not standardized against clinical codes, and added clutter without clinical value.
Impact to Patients
Patients will no longer see these sections when logging into MML. Any previously entered information in these areas will no longer be accessible through the portal, as none of it was ever shared with or used by their practice. Sections tied to active provider workflows, such as Practice Goals, Medications, and Allergies, remain fully available and unaffected.
This change reduces clutter and confusion within MML by ensuring patients only interact with data that is actually meaningful to their care team. It also reduces long-term maintenance overhead by eliminating parallel, non-authoritative data stores that never aligned with practice records in the first place.
MyMedicalLocker – Vitals Modernization Updates
ISL- 8509: As part of our ongoing modernization of MyMedicalLocker (MML), the Vitals section has been updated to ensure that vitals data displayed to patients is accurate, clinically reliable, and sourced directly from their connected practice. Previously, patients were able to manually add, edit, and delete their own vitals entries within MML, including weight, height, blood pressure, blood sugar, and SpO₂. However, these patient-entered values were never standardized, were never transmitted to connected practices, and often conflicted with the official vitals recorded by providers. This created confusion for patients who assumed their self-entered values were part of their official medical record, and introduced risk for providers who rely on accurate, practice-sourced data when making clinical decisions. To address this, MML now displays only vitals data sourced from connected practices, while continuing to give patients visibility into their trends over time.
What's Changing
- Weight: The ability to add, edit, or delete weight entries has been removed from MML. Patients can continue viewing weight trend data based on entries recorded by their connected practice.
- Height: The ability to add, edit, or delete height entries has been removed from MML. Patients can continue viewing height trend data based on entries recorded by their connected practice.
- Blood Pressure: The ability to add, edit, or delete blood pressure entries has been removed from MML. Patients can continue viewing blood pressure trend data based on entries recorded by their connected practice.
- Blood Sugar: The ability to add, edit, or delete blood sugar entries has been removed from MML. Patients can continue viewing blood sugar trend data based on entries recorded by their connected practice.
- SpO₂: The ability to add, edit, or delete SpO₂ entries has been removed from MML. Patients can continue viewing SpO₂ trend data based on entries recorded by their connected practice.
Impact to Patients
Patients will no longer see options to manually add, edit, or delete vitals within MML. All vitals values and trend charts displayed will now reflect only data entered by their connected practice, ensuring the information shown is consistent with their official medical record. This update removes the risk of patients relying on unofficial, self-reported vitals data and ensures that the trends and values shown in MML always match what providers see and use for clinical decision-making.
Appointment Comment & Complaint - Default Comments Screen Modernized (Vue)
ISL-7987: The Default Comments screen, accessed from within the Appointment Comments & Appointment Complaint windows, has been modernized as part of our transition to the Vue framework. This Default Comments screen has been fully rebuilt on the Vue.js framework, replicating the look, feel, and functionality of the legacy screen while improving performance and maintainability. This update covers both the Appointment Complaint Default Comment as well as the Appointment Comment Default Comment windows. All existing business rules and backend behavior have been preserved and there are no changes to how default comments interact within Appointment Complaint or Appointment Comment fields. This update is part of a broader initiative to modernize legacy screens within OfficeEMR onto the Vue.js framework, improving long-term maintainability, performance, and consistency across the application.
Scheduler Analytics Cube – Appointment Insurance Section Added
ISL- 8403: The Scheduler Analytics Cube now includes appointment-level insurance information, giving users the ability to analyze and report on scheduling data alongside the insurance details captured at the time of the appointment. We added a new Appointment Insurance section to the Scheduler Analytics Cube, containing the following fields pulled directly from Appointment Edit:
- Ins. Profile
- Ins. Primary
- Ins. Secondary
- Ins. Tertiary
These fields reflect the insurance information as it was set on the appointment itself, allowing for accurate historical reporting and analysis. It allows practices to build reports and analyses that incorporate insurance context directly into scheduling data, supporting use cases such as:
- Identifying scheduling trends by insurance profile or payer
- Analyzing appointment volume by primary, secondary, or tertiary insurance
- Cross-referencing scheduling and insurance data without needing to pull from multiple sources
Security Report – Time Zone Update
ISL- 4991: Previously, the Security report found under the Reports portal > Audit section always displayed log timestamps in EDT, regardless of the time zone actually configured for the client's database. This caused a mismatch for clients on other time zones. For example, a database set to PDT or MDT would still show log activity in EDT, leading to confusing or inaccurate timestamps.
In this release, the Security report has been updated to correctly display log dates and times based on each client's database-configured time zone, rather than always displaying in Eastern Time (EDT). This ensures audit and security log timestamps are accurate and meaningful for every client, regardless of their database's time zone.
Total Patient & Insurance Payment Added to Patient Transaction History
ISL-7258: The Patient Transaction History screen now displays running totals for patient and insurance payments, so users can instantly see how much a patient or insurance has paid toward a claim without manually adding up individual line items. The new display options are:
- Total Patient Payment: Reflects the sum of all responsible party payments.
- When viewing an individual claim, the total reflects patient payments for that claim only.
- When viewing multiple claims, the total reflects the combined patient payments across all claims displayed.
- Total Insurance Payment: Reflects the sum of all insurance payments.
- When viewing an individual claim, the total reflects insurance payments for that claim only.
- When viewing multiple claims, the total reflects the combined insurance payments across all claims displayed.
This gives front-desk and billing staff an at-a-glance view of payment activity when a patient calls in, eliminating the need to manually tally individual payment line items to answer questions like "How much have I paid so far?" 
Desktop Gadgets – Graphs Upgraded to Syncfusion
ISL- 8620: We upgraded the graphs displayed within Desktop Gadgets from HighCharts to Syncfusion, our new charting library. This update modernizes the underlying charting technology that powers Desktop Gadgets, ensuring continued reliability and vendor support while keeping the look, feel, and functionality exactly as users expect. This release focuses on preserving everything users already know and rely on. Sector labels continue to display as expected, and hovering over any point on a graph still shows the corresponding label and value. Users can still expand any graph into full screen view, print it directly, or download it in PNG, JPEG, PDF, or SVG format, just as they could previously.
Allergy Screen – UI Aligned to Syncfusion Design
ISL- 8330: The modernized Allergy screen, previously built using our legacy Vue component set, has also been visually realigned to match our newer Syncfusion design. This update brings the Allergy screen's look and feel in line with the Problems screen modernization, creating a more consistent experience across modernized areas of OfficeEMR. This release is focused purely on visual and component alignment rather than new functionality. The legacy Vue UI components used throughout the Allergy screen have been replaced with their Syncfusion equivalents. All existing behavior and workflows remain exactly as they were; only the visual presentation and underlying UI components have changed. The screen also continues to be accessible only through the existing modernization and beta flag configuration, now managed through the new Beta Flag screen in the Admin portal.
Aligning the Allergy screen to the Syncfusion design system ensures a consistent, modern look and feel across the application as more screens are modernized, while laying the groundwork for a smoother transition into QA and Beta testing.
Resolutions
Fixed: PM Reports – Patient Transaction History Column Alignment
ISL-11086: We resolved a column alignment issue in the Patient Transaction History report that could occur when a claim contained a large number of payments, such as a claim with 39 payments spanning roughly 43 rows, causing the report's page-break logic to split that claim across two pages in a way that separated the claim information from its associated procedure and payment rows. Because the claim's row was designed to span all of its related rows as a single connected block, splitting it across pages caused everything on the following page to shift one column to the left. As a result, values like the Balance column would appear misaligned and no longer line up under their correct headers.
In this release, we updated the report's page-break logic so that when a single claim is too large to fit within a full page on its own, it's now allowed to run long on that page rather than being split apart from its related rows. This keeps the claim information and all of its associated procedure and payment rows together in the same table on the same page, preserving correct column alignment throughout the report.
Fixed: Down-Coding Report – Remark Code Filtering, Claim Status, and Scrolling
ISL-14321: This release addresses three reported issues with the Down-Coding report, improving how remark codes are filtered and displayed, correcting an outdated claim status value, and fixing scrolling behavior on the drilldown when viewing large result sets.
Remark Code Filtering and Display
Previously, the Down-Coding report's drilldown only filtered and grouped by claim-level remark codes (MOA), even though procedure-level remark codes (LQ) were also being pulled correctly from the claim. This meant that remarks tied specifically to a procedure weren't being reflected in filtering or grouping, even though the underlying data existed.
To resolve this, the drilldown now separates and displays remark codes more clearly. Claim-level remarks are broken out into RARC 1, RARC 2, and an Other RARCs column, which lists any additional remarks (3–5) concatenated together. Procedure-level remarks now follow the same structure, displayed as PRC RARC 1, PRC RARC 2, and PRC Other RARCs.
To keep the drilldown easier to scan, remark code columns now display just the code itself rather than the full description, with the complete description available on hover via tooltip. Most importantly, filtering and grouping by remark code now takes both claim remarks and procedure remarks into account, so procedure-level remarks are no longer excluded from results.
Claim Status Accuracy
The drilldown was previously displaying the claim status as it existed at the time the deposit was posted, rather than the claim's current status. This has been corrected so the drilldown now reflects the claim's current status, giving users an accurate, up-to-date view when reviewing down-coded claims.
Scrolling and Pagination Display
When viewing the drilldown with a high number of items per page, such as 50 or 100, the footer and column headers would scroll out of view, making it difficult to navigate or read the table without scrolling all the way down first. This has been fixed: the column headers now stay fixed in place while scrolling vertically, and the footer remains visible, allowing users to scroll and navigate the table more easily regardless of page size.
Fixed: Billing Analytics – Download Link Fix
ISL-14149: We resolved an issue occurring when downloading the Billing Analytics from the Billing portal. Previously, attempting to download Billing Analytics from the Billing portal resulted in an invalid link and a connection error, preventing users from opening the .odc file. The broken download link has been corrected, and Billing Analytics can now be downloaded successfully from the Billing portal without encountering a connection error.
