Full Release Notes
Everything that shipped in this release, organized by area.
Ship
Scheduling Reliability & Observability
Provider calendar connections through Google and Outlook are now fully observable. Previously, when a connection broke, the first sign was a patient who couldn’t book — the system offered no visibility into what had failed or when. This release adds session-level logging for every calendar connection, an alert that fires when a connection fails (PP-118), and an error log that admins can view directly in the platform (PP-30). A booking override audit flag captures when a booking is forced through outside normal rules (PP-127), giving ops a paper trail for exceptions.
Provider & Clinic Operations
Tiffany’s availability at MMH is now correctly configured (PP-161). The MMH-Osgood 2 location has been removed from the dropdown, cleaning up an option that was creating confusion in the scheduler (PP-160). ARcare Watson Chapel has been added as a clinic (PP-131), and Permian Regional users have been provisioned with access (PP-132). Lubbock and CHCL are stood up and live (PP-134).
Cancellation & Reschedule Notifications
Patients and providers now receive notifications when an appointment is cancelled or rescheduled (PP-41, PP-47). This closes a gap that had existed since launch — the system could create and confirm bookings, but changes to those bookings weren’t surfaced to the people affected.
Syringa Missed Appointments Reconciliation
Syringa missed-appointment data is now being reconciled against Peregrine OS records (PP-165). When partner reports come in late or include updates to previously reported visits, the diff pipeline catches the discrepancy and flags it for resolution — rather than letting it drift.
Emma: Live at FCHC and ARcare
Emma is live in production at two partner sites, handling referral intake calls. This is not a pilot — it’s deployed. Goshen is the next site on the onboarding track. Once Goshen is live, Emma will be in production across the full managed services footprint.
AI Clinical Notes Pilot
A pilot of AI-assisted clinical note generation has launched with a first cohort of providers. Feedback from this cohort will shape the feature’s next iteration. A training guide covering the workflow is live in the Flight Deck.
Under the Hood
Dagster in Production
Dagster base infrastructure has been deployed to production (PP-80). This is the orchestration layer that all current and future data pipelines run on — EMR reconciliation, visit diffs, reporting. Getting it into production unblocks everything else in this section.
EMR Visit Pipeline
Three pipeline components are live: SFTP file consumption (PP-82), a diffing system that compares what’s in the EMR against what’s in Peregrine OS (PP-83), and a diff report that surfaces the gap for resolution (PP-84). The result: when a visit exists in one system and not the other, the platform knows — and the information doesn’t have to come from a scheduler running manual comparisons.
Per-Customer Reconciliation
Per-customer reconciliation infrastructure is in place, including pipeline infrastructure (PP-119) and a customer config loader that makes the system aware of each partner’s specific data shape (PP-121). This means reconciliation can run per-organization rather than globally — which matters as partners have different EMR setups and reporting cadences.
Referral Standardization
Referral data from ARcare is now being transformed into the Healthpoint format on ingest (PP-125). The Healthpoint ID field has been removed from the Unity file, eliminating a field that was causing parsing errors downstream (PP-135). Cancelled-by-Phreesia referrals are now handled explicitly, so they’re classified correctly rather than falling into an undefined state (PP-136).
Appointment Migration Scripts
Migration scripts for appointment data have been built and tested (PP-129). These are the tools used to move historical appointment data into Peregrine OS when a partner onboards — part of the onboarding infrastructure that has to exist before Goshen goes live.
Fixes
- Retry storm on auth (PP-48) — CORS OPTIONS requests were causing the front-end to spam auth requests on certain flows. Fixed with a timeout and exponential backoff. Left unaddressed, this would have caused cascading auth failures at scale.
22 issues shipped · 14 stories · 7 tasks · 1 bug · 4 epics touched (PP-54 OS Scheduling, PP-57 Dagster, PP-58 EMR Pipelines, PP-120 EMR Reconciliation)