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
- Freeze source and target tenant states, release evidence, care settings, cohorts, note types, EHR templates, owners, and maintenance window.
- Use
Read,Glob, andGrepto inventory configuration, mappings, training, tests, dashboards, and downstream dependencies. - Classify changes by patient-selection, capture, generation, review, evidence, note-template, EHR handoff, access, and support impact.
- Test source and target side by side with approved test records; include rollback, partial migration, and in-flight encounter cases.
- Use
WebFetchonly for current official product context; require tenant release notes for actual change semantics. - Use
WriteorEditto 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.