FHIR Patient/$match vs Vendor MPI APIs: A Practical Comparison

A patient-matching call at the integration boundary can take two shapes. The spec-aligned shape is `Patient/$match`, the FHIR operation that returns a Bundle of candidate Patient resources ranked by match score. The vendor shape is a proprietary REST or SOAP API with its own request payload and its own response model. The comparison below covers what each gets right and where each falls down in 2026 production deployments. For broader context, see the FHIR comparison hub.

What Patient/$match Gets Right

`Patient/$match` is conformant, portable, and well-understood. The request is a Parameters resource carrying the candidate Patient and a `onlyCertainMatches` boolean. The response is a Bundle with a `match` extension that carries the score and grade. Any FHIR consumer can call any conformant server with the same code, which is exactly the win the operation was designed for.

For greenfield FHIR deployments and for cross-organization workflows where neither side controls the other's stack, `$match` is the natural choice. The population health MPI reference guide covers the spec-aligned path for the workflows where this matters most.

Where `$match` falls short is the matching depth. The spec deliberately leaves the matching algorithm to the server. A conformant `$match` implementation can be a state-of-the-art referential matcher or a simple deterministic name-plus-date-of-birth check. The grade and score values are normalized to the spec's value set, but the underlying confidence semantics vary between servers in ways consumers cannot inspect.

What Vendor MPI APIs Get Right

Vendor MPI APIs win on matching depth and configurability. Verato's API exposes referential-matching parameters, NextGate's API exposes the multi-dimensional confidence model, and Health Gorilla's API exposes HIE-style cross-network resolution. None of these surfaces fits cleanly into the `$match` Parameters envelope without proprietary extensions, and the extensions defeat the portability `$match` was supposed to provide.

For deployments locked to one MPI vendor with a long-term commitment, the vendor API gives access to features the spec does not model. The payer eligibility MPI engines roundup covers the vendor-specific features that drive selection in that workflow.

Where vendor APIs fall down is portability. Migrating from one vendor to another is a rewrite. Cross-organization workflows where each party uses a different vendor require translation at the boundary, and the translation usually loses the depth that motivated the vendor choice in the first place.

How to Pick the Right Surface

Three questions decide the surface. The first is whether the workflow stays inside one organization or crosses boundaries. Cross-organization workflows pick `$match` for portability reasons that outweigh the depth loss.

The second is the matching depth requirement. Workflows that need referential matching, multi-dimensional confidence, or HIE-style resolution pick the vendor API because `$match` cannot expose those features conformantly.

The third is the multi-payer network reality, which the EMPI vs MPI for multi-payer networks comparison covers in detail. Multi-payer networks usually end up running `$match` at the boundary and the vendor API internally, accepting the translation cost as the price of multi-vendor coexistence.

The right surface depends on the workflow's organizational scope, the matching depth the use case actually requires, and the migration appetite the team has signed up for. Most healthy deployments end up using both, with clear boundaries between them.