abridge-upgrade-migration

Abridge Tenant and EHR Change Migration

Overview

Treat every material workflow change as a clinical and EHR migration, not a generic API-version bump. Pin source and target behavior, identify affected cohorts and templates, test with designated records, and preserve a workable rollback.

Prerequisites

• The authorized Abridge environment, clinical owner, and health-system policy set
• Current tenant-specific implementation evidence for every private interface in scope
• Synthetic data or the organization's formally approved test-record procedure

Tool Discipline

Use Read, Glob, and Grep to inspect repository configuration, adapters, tests, policies, and existing evidence. Use WebFetch only for current official Abridge, HHS, or named EHR documentation. Use Write or Edit only after confirming scope, environment, owners, patient-data boundary, and approval state. These tools do not confer access to Abridge, an EHR, or a clinical record; return exact operator steps or an approval-gated handoff for live actions.

Current Contract

• Abridge capabilities differ across outpatient, emergency, inpatient, orders, note types, and integration modes.
• Note-setting changes can affect future notes without retroactively changing prior notes.
• Public announcements describe capability direction; the tenant's approved release and implementation documents control availability.

Authentication

Use only the health system's provisioned Abridge application access, SSO, administrative role, or tenant-specific partner authentication documented for the approved environment. Do not infer public API credentials, reuse production secrets in tests, or expose tokens and session material. Verify identity owner, least privilege, environment binding, storage, rotation, and revocation before any authenticated action.

Instructions

1. Freeze source and target tenant states, release evidence, care settings, cohorts, note types, EHR templates, owners, and maintenance window.
2. Use Read, Glob, and Grep to inventory configuration, mappings, training, tests, dashboards, and downstream dependencies.
3. Classify changes by patient-selection, capture, generation, review, evidence, note-template, EHR handoff, access, and support impact.
4. Test source and target side by side with approved test records; include rollback, partial migration, and in-flight encounter cases.
5. Use WebFetch only for current official product context; require tenant release notes for actual change semantics.
6. Use Write or Edit to publish the migration map, evidence, communications, cutover checks, and rollback authority.

Approval Boundaries

Do not cut over active clinical cohorts, change shared templates, or assume a newly announced feature is licensed and enabled without owner confirmation.

Output

Return source and target states, affected assets, test evidence, in-flight handling, training, cutover steps, rollback trigger, and decision owners. Separate verified facts, tenant-specific evidence, assumptions, and actions still awaiting approval.

Error Handling

Condition	Response
Target behavior is not documented for the tenant	Delay migration.
Prior note behavior is assumed to change	Separate prospective settings from historical content.
Rollback changes patient workflow	Rehearse and communicate it before cutover.

Example

The example is a redacted operational receipt, not patient data or proof of vendor certification.

change=inpatient-note-type; cohort=pilot; source=approved-r4; target=approved-r5; test-records=8; rollback=pass; decision=scheduled

Resources

• Official documentation map — dated public evidence and the limits of what those sources establish.

Read the source map before changing a workflow. Recheck tenant-specific implementation evidence for every interface or capability that public documentation does not define.

Next Steps

Revalidate the evidence date and tenant-specific authority before repeating this workflow in another environment, cohort, care setting, or integration mode.