> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cairhealth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Update Professional Claim

> Update an existing professional claim

Accepts the **same JSON request body** as `POST /api/claim/professional/v1`. The server matches on key fields to update each related entity (Claim, Patient, Provider, etc.)
You should use this endpoint when you've already sent a claim through `POST /api/claim/professional/v1` and you want to make modifications to any part of the claim.

***

### Pre-flight Validation

Before processing the transaction, the server verifies that each target resource already exists for the provided identifier(s).\
If **no** resource matches any required lookup, the API returns a **404**.

***

### Fields Used to Determine Which Existing FHIR Resource Is Updated

* **Claim**:\
  Uses `id` (claim control / CMS id) — the Cair claim id identifier.
* **Patient**:\
  Uses `patient.id` (provider patient id) as the Cair provider-patient identifier;\
  **OR**, if `patient.id` is absent, uses `first_name`, `last_name`, and `dob` to resolve to a unique patient.
* **Service Location**:\
  When `service_location` is present, uses `service_location.name`.
* **Billing Provider**:\
  Uses both `billing_provider.npi` and `billing_provider.tax_id` (NPI + EIN identifiers).
* **Rendering Provider**:\
  Uses `rendering_provider.npi`.
* \*\*Payer Organization \*\*:\
  Uses `insurance_plan.payer_id` on each policy (EDI payer identifier).
* **Coverage**:\
  Matched server-side to existing coverage for the patient using the policy's **group** and **member** (`num` / `id`); the update targets the matched `Coverage/{id}` on the server.

***

> **Note:**\
> The optional query parameter **`attachmentId`** behaves the same as for POST.\
> This links `DocumentReference` resources to the claim.