Cotiviti completed its Edifecs acquisition—but a combined company is not a migrated prior-auth workflow
Cotiviti's official record says it completed the acquisition of Edifecs in March 2025, and current Edifecs product paths now point into Cotiviti's web estate. Buyers should update ownership and support records without assuming that a licensed gateway, interface, configuration, contract, or production workflow changed in the same way.
Editorial figure by Prior Auth Monitor. Source context: Cotiviti Completes Acquisition of Edifecs.
The corporate record and the production record answer different questions
Cotiviti's official announcement states that it completed its acquisition of Edifecs on March 31, 2025. It describes the combined organization as bringing together healthcare interoperability, data management, payment, enrollment, and related operating capabilities. The current Edifecs web presence now identifies Edifecs with Cotiviti, and the maintained FHIR Gateway record redirects into a Cotiviti-hosted source. Those are material identity and source-provenance facts for a buyer's market record.
They do not show what happened inside one customer's prior-authorization environment. A payer may operate licensed software, hosted services, managed interfaces, partner components, custom mappings, clinical-policy integrations, transaction routes, portals, and support agreements with different versions and change schedules. Corporate integration can alter ownership, roadmap, contracting, branding, support, or packaging without proving that a production endpoint or review workflow changed on the same date.
Update ownership while preserving product and contract lineage
The maintained vendor record should connect the legacy and current names, legal contracting party, parent organization, product names, licensed modules, environment, hosting party, implementation partner, support contacts, renewal and assignment terms, data-processing roles, subprocessors, security evidence, service commitments, and roadmap statements. Historical incident, validation, conformance, and performance records should remain attached to the exact product and period they describe rather than being silently relabeled as proof for the combined company.
Prior-authorization architecture adds another layer. Teams should retain the FHIR implementation-guide and transaction versions, EDI bridges, payer and provider endpoints, requirement and documentation sources, utilization-management systems, clinical-review owners, status and reason records, consent and authorization controls, audit exports, and fallback channels. A new corporate name on a source or invoice should trigger review of those dependencies, not an assumption that they have already been migrated or revalidated.
Ask for a change statement that can be tested
A buyer review should ask the combined organization to identify what changed, what did not, which dates apply, which products and customers are affected, and what future changes are planned. The team should verify the legal entity on the contract, support escalation, security and privacy commitments, product release notes, interface endpoints, certificates, service accounts, mappings, test evidence, disaster recovery, data export, and rollback. A representative prior-auth case should pass through both the normal and exception paths before any production change is accepted.
Cotiviti's announcement establishes the completed acquisition and the combined-company positioning; it does not independently establish product continuity, migration, configuration, conformance, uptime, clinical-policy behavior, transaction accuracy, or customer outcome. Payers, providers, delegated reviewers, procurement, architecture, security, privacy, finance, clinical, compliance, and legal owners retain their respective decisions. The correct result is an auditable change record, not a brand-level assumption about authorization operations.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Prior Auth Monitor will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.