ChartRequest is Proudly Partnered With
Switching release of information vendors can look simple: choose a cutoff date, route new requests to the incoming vendor, and let the outgoing vendor finish the rest. In reality, that is how requests get stranded.
A request paused due to an incomplete authorization may still remain with the outgoing vendor when the corrected form arrives. If the new vendor never received the original request, neither workflow may recognize it as active.
Requests do not pause during the handoff. For applicable HIPAA access requests, HHS explains that delays involving a business associate still count against the covered entity’s response time.
Treat the switch as a reconciliation exercise. Before the old workflow closes, the organization should know where every active request sits and who is responsible for moving it forward.
When Should You Consider Switching Release of Information Vendors?
One difficult month does not mean the relationship has failed. A switch becomes more reasonable when requests keep aging, leaders cannot see why work is stalled, and staff still spend too much time chasing status or correcting errors.
AHIMA recommends beginning an outsourcing decision with a needs assessment. Start with the backlog, oldest request, turnaround, complaint volume, rework, and the staff effort the process still consumes.
Be honest about where the problem sits. Incomplete EHR access, undocumented intake channels, slow internal approvals, and unclear exception ownership can follow the organization to its next vendor. A vendor change can remove a weak partner, but it cannot fix internal ambiguity unless the workflow changes too.
Before comparing release of information vendors, define the problem the new partner must solve. A modern release of information software workflow can improve visibility, but responsibilities still need to be clearly divided.
Define What the New Release of Information Vendor Will Own
The change may replace one full-service vendor with another, move from software to a managed service, bring selected work in-house, or affect only certain facilities.
A multi-location practice may expect the new vendor to handle electronic intake, authorization review, retrieval, quality assurance, and delivery while facility staff continue managing walk-in requests and incomplete authorizations.
Document who handles failed deliveries, requestor questions, fee disputes, and other exceptions. Otherwise, each team may assume someone else is watching the request.
Give the transition one clear leader. HIM, Health IT, operations, and finance may each own part of the work, but one person needs authority to resolve conflicts or delay the cutoff.
Health IT should own access, integration readiness, technical testing, data portability, and eventual decommissioning.
Inventory, Assign, and Reconcile Every Open Request
This is the part of the transition that matters most.
An open request is any active request without documented closure. The easiest to miss are often waiting on corrected authorization, payment, delivery confirmation, supplemental records, a resend, or complaint resolution.
Do not send every new request to the incoming vendor and assume the outgoing vendor will quietly finish everything else. That creates two queues and no dependable view of the work between them.
A transferred request should arrive ready to work, not as a case number someone has to rebuild.
| Category | Information needed |
| Request identity | Patient, requestor, facility, request number, and date received |
| Scope | Requested records, date range, authorization, or other supporting documentation |
| Current state | Status, deadline or target, outstanding dependency, and delivery state |
| Work completed | Records retrieved, correspondence, fees, payments, and previous actions |
| Ownership | Current owner and destination workflow |
| Next step | Required action and escalation path |
Include requests that appear complete in one system but still need action. A failed delivery, unresolved correction, expected payment, or reopened complaint can return a supposedly closed request to the active workload.
ened, and what needs to happen next.
Redirect Intake and Test the New Workflow
Even a clean handoff can fail if new requests continue entering the wrong place.
Can Requests Reach the New Workflow?
Vendor transitions often reveal more intake paths than leadership expected. Fax lines, shared inboxes, web forms, portal instructions, EHR queues, mailing addresses, phone scripts, and local workarounds may all route requests differently.
Give each channel a destination, change date, monitoring period, and owner. Test the route from the requestor’s perspective, then update forms, portals, public instructions, and staff scripts. High-volume requestors and anyone directly affected may need targeted communication.
Can the Workflow Handle the Requests You Actually Receive?
Test the request types and exceptions the organization handles, including patient, legal, payer, imaging, billing, correction, resend, and requests involving sensitive information.
Use the five phases of the release of information process as a test structure. Check the path from intake and authorization review through retrieval, quality assurance, delivery, and closure.
Look for incorrect patient matching, incomplete scope, wrong attachments, duplicate releases, and delivery to an outdated recipient or channel.
What Should Health IT Confirm Before Cutover?
The most dangerous technical failure is not always a visible outage. It may be an integration that appears active but quietly stops delivering requests to the tracked workflow.
Confirm that accounts have the correct permissions, integrations route information to the intended destination, and failed transactions create visible alerts. Test every system and location that sends, receives, or stores information used in the ROI workflow.
Also document how requests will continue during an outage. A temporary manual route, escalation owner, and recovery process should be ready before launch.
Can It Handle Realistic Volume?
A handful of successful test cases does not prove readiness. The new workflow may need to absorb normal demand, transferred work, misrouted requests, and higher support volume.
Before go-live, confirm that:
- The right users and service accounts have access.
- Priority scenarios have passed.
- Intake and integrations route correctly.
- Open-request ownership is documented.
- Escalation and contingency support are ready.
Train teams on the paths and exceptions they will handle, and define which unresolved failures would delay the cutoff.
A demonstration proves the technology can function. A transition test proves the organization can keep fulfilling requests when something does not go as planned.
Close the Outgoing Workflow, Not Just the Contract
Remove the outgoing vendor’s access once its assigned work and exception handling are complete. Technical offboarding should cover user and service accounts, API credentials, file-transfer connections, automated routing rules, and administrative access.
Do not remove access so early that unresolved requests cannot be finished or investigated. Do not leave it active without a clear reason, owner, and removal date.
Monitor the remaining queue independently rather than assuming the outgoing vendor will maintain its previous pace. Aging requests, unanswered escalations, and incomplete transfers should surface immediately.
Document what PHI and operational information the outgoing vendor returned, destroyed, or retained. Reconcile final invoices, payments, credits, refunds, disputed charges, and cross-workflow billing.
During stabilization, average turnaround can be misleading. A small group of aging requests may remain hidden behind an acceptable overall number. Active queue management should focus on request aging, exceptions, and the oldest outstanding work.
The transition should remain open until:
- Every active request is visible and assigned.
- The outgoing and incoming totals reconcile.
- Remaining work is resolved or formally accepted.
- Old intake channels are closed or redirected.
- Outgoing access is removed or intentionally retained for a documented reason.
- PHI disposition and outstanding financial activity are documented.
Keep the final reconciliation, exception log, access approvals, decommissioning records, and PHI disposition documentation together.
Technical go-live is not transition completion. The organization must still account for requests, intake channels, system connections, and remaining work on both sides of the cutoff.
Choose a Dependable Release of Information Partner
ChartRequest follows a structured onboarding process that includes implementation, EMR training, go-live support, and post-launch follow-up.
Organizations using a managed model can place more of the daily ROI workload with ChartRequest. Self-service organizations retain more responsibility and receive deeper workflow and platform training.
ChartRequest’s onboarding prepares the new workflow for incoming requests. The provider and outgoing vendor should separately document how they will close or transfer requests received before the cutoff.
NY Orthopedics switched to ChartRequest after repeated staff turnover at its previous ROI vendor and complaints about delayed or incomplete records.
After the switch, the practice reported responsive support, greater peace of mind, and more than $136,000 in annual staffing savings. The case study documents a ChartRequest partnership lasting more than seven years.
The real test begins after implementation, when request volume rises, exceptions appear, and the provider needs a responsive partner rather than another support queue.
Planning to switch release of information vendors? Schedule a consultation with ChartRequest to define responsibilities, map intake channels, and prepare the new workflow for a controlled handoff.
Frequently Asked Questions
How Do You Prevent a Backlog When Switching Release of Information Vendors?
Inventory every active request, assign it to the outgoing vendor, incoming workflow, or documented closure, and reconcile both queues throughout the cutover. Monitor exceptions and reopened requests until every active request has an owner and next action.
How Long Does It Take to Switch Release of Information Vendors?
Timing depends on the operating model, contract terms, locations, volume, system access, integrations, open work, and training needs. Set the cutoff based on proven readiness rather than a universal timeline.
What Happens to Requests That Are Open When the Vendor Changes?
The outgoing vendor may finish pre-cutover requests, the incoming vendor may assume selected work, or the organization may move in phases. Document which workflow owns each request and how unresolved work will be monitored.
What Information Should Transfer to the New ROI Vendor?
Transfer enough information for the receiving team to continue without rebuilding the request, including its scope, supporting documentation, current status, completed work, unresolved dependency, relevant payment activity, and next action.
When Should the Outgoing Vendor’s System Access Be Removed?
Keep access only as long as needed to finish assigned work, investigate unresolved exceptions, and meet remaining obligations. Any retained access should have a clear purpose, owner, and removal date.
Facebook
Twitter
LinkedIn
Stay Updated
100% Privacy. No spam guaranteed.
