Claim and ClaimResponse

The FHIR Claim resource is not just a billing claim — it is the submission mechanism for three distinct financial workflows: billing, prior authorization, and benefit predetermination. The use field determines which workflow a given Claim represents. This distinction is fundamental: a Claim submitted for billing (use: claim) goes through adjudication and produces payment; a Claim submitted for prior authorization (use: preauthorization) goes through coverage review and produces an authorization number. Different workflows, different endpoints, different ClaimResponse structures.

In the Da Vinci PA stack, the PAS IG uses Claim with use: preauthorization as its submission format. This is the same resource model, profiled for FHIR-based electronic prior authorization under CMS-0057-F. For the full PA workflow, see Prior Authorization Workflow.

The `use` field

"use": "preauthorization"

Value	What it is	Response type
`claim`	Post-service billing claim	ClaimResponse with payment amounts
`preauthorization`	Pre-service PA request	ClaimResponse with authorization number or denial
`predetermination`	Non-binding cost estimate	ClaimResponse with estimated amounts (no commitment)

This is the first thing a receiving system checks. A payer’s billing adjudication endpoint and its PA endpoint are separate. Submitting a preauthorization Claim to a billing endpoint (or vice versa) typically returns an error or, worse, silently misprocesses.

predetermination is the most commonly misunderstood value. It produces a non-binding estimate — useful for patient cost transparency — but it creates no authorization. A predetermination response is not a PA approval.

Key structural elements

status

Required. Most Claims in active use have status: active. The full lifecycle:

active — the claim is valid and submitted
cancelled — the claim was voided
draft — not yet submitted (rare in practice; most implementations submit directly)
entered-in-error — the record is invalid

For PA submissions, status: active is required.

type

The broad category of services being authorized or billed:

"type": {
  "coding": [
    {
      "system": "http://terminology.hl7.org/CodeSystem/claim-type",
      "code": "professional"
    }
  ]
}

Common codes: professional (CMS-1500), institutional (UB-04), oral (dental), pharmacy, vision. This determines which code systems apply to item.productOrService and which X12 transaction the payer’s backend will use for translation.

patient and insurer

patient — reference to the Patient resource
insurer — reference to the Organization (payer) receiving the claim

For PA submissions, insurer points to the payer organization that will process the authorization.

provider

The Practitioner, PractitionerRole, or Organization submitting the claim. For billing, this is the billing provider. For PA, this is the requesting provider.

priority

Required. For PA purposes, this carries clinical urgency:

"priority": {
  "coding": [{ "code": "normal" }]
}

Codes: stat (urgent/immediate), normal (standard). CMS-0057-F mandates 72-hour turnaround for urgent PA requests (stat) and 7 calendar days for standard (normal). The payer’s SLA enforcement is triggered by this field.

insurance

The coverage(s) being billed or authorization being requested under:

"insurance": [
  {
    "sequence": 1,
    "focal": true,
    "coverage": { "reference": "Coverage/member-456" },
    "preAuthRef": ["AUTH-20250101-999"]
  }
]

focal: true marks the primary coverage. When submitting a billing claim after a prior authorization has been issued, preAuthRef in the insurance element carries the authorization number obtained from the PA ClaimResponse. This is how the payer’s adjudication system validates that authorization was obtained.

diagnosis

"diagnosis": [
  {
    "sequence": 1,
    "diagnosisCodeableConcept": {
      "coding": [
        {
          "system": "http://hl7.org/fhir/sid/icd-10-cm",
          "code": "C34.10",
          "display": "Malignant neoplasm of upper lobe, bronchus or lung, unspecified side"
        }
      ]
    },
    "type": [
      {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/ex-diagnosistype",
            "code": "principal"
          }
        ]
      }
    ]
  }
]

diagnosisCodeableConcept accepts ICD-10-CM codes for most US submissions. diagnosisReference is the alternative — a reference to a Condition resource — and is the preferred form when the condition is already in the FHIR record. For PA requests, the diagnosis provides the medical necessity context the payer evaluates.

sequence is a local identifier used to link diagnosis entries to item.diagnosisSequence. The same sequence numbering pattern applies to procedure, insurance, and item.

procedure

Procedures included in the submission:

"procedure": [
  {
    "sequence": 1,
    "procedureCodeableConcept": {
      "coding": [
        {
          "system": "http://www.ama-assn.org/go/cpt",
          "code": "96413",
          "display": "Chemotherapy administration"
        }
      ]
    }
  }
]

procedureCodeableConcept carries CPT, HCPCS, or ICD-10-PCS codes. procedureReference is the Procedure resource alternative.

item

The line items being billed or authorized:

"item": [
  {
    "sequence": 1,
    "diagnosisSequence": [1],
    "procedureSequence": [1],
    "productOrService": {
      "coding": [
        {
          "system": "http://www.ama-assn.org/go/cpt",
          "code": "96413"
        }
      ]
    },
    "servicedDate": "2025-02-01",
    "quantity": { "value": 1 },
    "unitPrice": { "value": 850.00, "currency": "USD" }
  }
]

diagnosisSequence and procedureSequence link back to the diagnosis and procedure entries by their sequence numbers. productOrService is the service code — CPT, HCPCS Level II, NDC, or local codes depending on type. servicedDate or servicedPeriod is the date of service (or proposed service date for PA).

Items can contain detail and detail.subDetail for compound or packaged services. For most PA submissions, flat items are sufficient.

Modifier codes adjust the meaning of productOrService — they indicate that a service was modified in some way without changing the base code. Common uses: bilateral procedures, professional vs technical component, multiple procedures on the same day. Modifiers go in item.modifier:

"modifier": [
  {
    "coding": [
      { "system": "http://www.ama-assn.org/go/cpt", "code": "50", "display": "Bilateral procedure" }
    ]
  }
]

Encounter reference links the item to a specific Encounter resource, which provides the setting and clinical context. For inpatient institutional claims, item.encounter is particularly important for tying service lines to the admitting encounter.

supportingInfo

The vehicle for attaching clinical documentation. In DA Vinci PAS, the completed QuestionnaireResponse from DTR is attached here:

"supportingInfo": [
  {
    "sequence": 1,
    "category": {
      "coding": [
        {
          "system": "http://hl7.org/fhir/us/davinci-pas/CodeSystem/PASSupportingInfoType",
          "code": "patientEvent"
        }
      ]
    },
    "valueReference": { "reference": "QuestionnaireResponse/qr-oncology-chemo-001" }
  }
]

The PAS IG defines specific category codes for the types of supporting documentation it carries.

ClaimResponse

The payer’s response to a submitted Claim. The ClaimResponse mirrors the Claim’s use value — a response to a preauthorization Claim has use: preauthorization.

outcome

The top-level decision:

Value	Meaning
`complete`	Fully processed; adjudication or authorization decision is final
`error`	Processing error; the Claim could not be processed
`partial`	Some items were processed; others require additional information
`queued`	Pended; the request is being processed asynchronously

For synchronous PA responses, complete means a final decision was made (approve or deny). queued means the payer will deliver the decision later via subscription notification or polling.

item.adjudication

Line-level decisions:

"item": [
  {
    "itemSequence": 1,
    "adjudication": [
      {
        "category": {
          "coding": [{ "code": "submitted" }]
        },
        "amount": { "value": 850.00, "currency": "USD" }
      },
      {
        "category": {
          "coding": [{ "code": "eligible" }]
        },
        "amount": { "value": 850.00, "currency": "USD" }
      }
    ]
  }
]

For PA ClaimResponses, adjudication carries the authorization decision rather than payment amounts. The PAS IG uses the reviewAction extension (see below).

preAuthRef and preAuthPeriod

When authorization is approved, these fields on ClaimResponse.item carry the authorization number and validity period:

"item": [
  {
    "itemSequence": 1,
    "adjudication": [...],
    "extension": [
      {
        "url": "http://hl7.org/fhir/us/davinci-pas/StructureDefinition/extension-reviewAction",
        "extension": [
          { "url": "number", "valueString": "AUTH-20250115-001" },
          {
            "url": "code",
            "valueCodeableConcept": {
              "coding": [{ "code": "A1", "display": "Approved" }]
            }
          }
        ]
      }
    ]
  }
]

The authorization number (AUTH-20250115-001) must be captured and carried forward into the billing Claim’s insurance.preAuthRef field. This is the linkage that proves to the payer’s adjudication system that prior authorization was obtained before the service was rendered.

addItem

addItem in ClaimResponse allows the payer to adjudicate services that were not on the original Claim — for example, when the payer applies a bundling rule that substitutes one procedure code for another, or adds a service line for a fee that the provider didn’t bill. addItem follows the same adjudication structure as item but references original items by itemSequence. For straightforward PA ClaimResponses, addItem is rarely used; it is more common in full adjudication responses.

processNote and denial reasons

For denied ClaimResponses, CMS-0057-F requires structured denial reasons. Free-text denial descriptions in processNote alone are not sufficient — a coded reason is required:

"processNote": [
  {
    "number": 1,
    "type": "display",
    "text": "Service not covered under patient's benefit plan for the provided diagnosis."
  }
],
"error": [
  {
    "itemSequence": 1,
    "code": {
      "coding": [
        {
          "system": "http://terminology.hl7.org/CodeSystem/adjudication-error",
          "code": "not-covered"
        }
      ]
    }
  }
]

Da Vinci PAS profiles

The PAS IG defines profiles that constrain Claim and ClaimResponse for electronic prior authorization:

Profile	URL	What it constrains
PAS Claim	`.../profile-claim`	Requires `use: preauthorization`, mandates `insurer`, constrains `supportingInfo` types
PAS ClaimResponse	`.../profile-claimresponse`	Requires `reviewAction` extension on item adjudication, mandates structured denial reasons
PAS Claim Inquiry	`.../profile-claim-inquiry`	For status check queries on pended requests
PAS Claim Inquiry Response	`.../profile-claimresponse-inquiry`	Response to status check queries

The reviewAction extension is the PAS-specific addition that carries the payer’s authorization decision (Approved, Denied, Pended, Partial) as a coded value in the ClaimResponse.

X12 278 relationship

Most payer backends still process PA requests as X12 278 transactions (278 Request / 278 Response). When a provider system submits a PAS Claim to a FHIR endpoint, an intermediary (clearinghouse or FHIR facade) translates the FHIR Claim to X12 278 Request on the way to the payer, and translates the X12 278 Response back to a FHIR ClaimResponse.

FHIR Claim field	X12 278 equivalent
`item.productOrService`	Loop 2000E HL / Service Type Code
`priority` (stat/normal)	AAA Rejection Reason / CER Certification Type
`diagnosis`	HI Health Care Diagnosis segment
`insurance.coverage`	SBR Subscriber Information
`preAuthRef` (on billing)	REF Prior Authorization Number

The translation is not lossless. X12 278 has constraints and code sets that differ from FHIR. Intermediary-fronted payer responses may lack some structured data that a native FHIR PAS endpoint would return — particularly for denial reason codes and pended decision notifications.

R5 changes

R4 Claim is Trial Use. R5 makes targeted improvements:

encounter moves from item-level only to top-level, allowing a single encounter reference for the whole claim.
diagnosis.condition adds a reference to a Condition resource alongside the existing diagnosisCodeableConcept / diagnosisReference polymorphic choice.
item.revenue is promoted to a first-class element (it existed in R4 as well, primarily for institutional claims using UB-04 revenue codes).
ClaimResponse reviewOutcome replaces the PAS-specific reviewAction extension with a standardized base element, reducing the need for implementation-guide-specific extensions for PA decision codes.

Most US implementations are built on R4 and will remain so through the current regulatory cycle. R5 changes are informational for R4 implementers.

Search parameters

Parameter	Type	Finds
`patient`	reference	Claims for this patient
`use`	token	Claims with this use value (claim, preauthorization, predetermination)
`status`	token	Claims with this status
`created`	date	Claims created on/after/before this date
`insurer`	reference	Claims submitted to this payer
`provider`	reference	Claims submitted by this provider
`identifier`	token	Claim with this business identifier
`priority`	token	Claims with this priority code

Payer PA endpoints typically accept use=preauthorization + patient + created for status queries. Not all payer endpoints expose a search interface — many accept only direct Claim POST and inquiry operations.

Claim vs ExplanationOfBenefit

This is the most common architectural confusion in FHIR financial resources:

Resource	Purpose	Who creates it	When
Claim	Submit a request for payment or authorization	Provider	At billing or PA request time
ClaimResponse	Payer’s decision on a Claim	Payer	After adjudication or PA review
ExplanationOfBenefit (EOB)	Post-adjudication summary for the member	Payer	After the claim is paid

The EOB is what appears in patient portals and payer member APIs (CARIN Blue Button profile). It is not a Claim. An EOB contains references back to the original Claim and ClaimResponse but is a distinct resource representing the finalized financial event.

For the CMS Patient Access API, payers expose EOB resources — not Claim resources — to patients. Implementing the Patient Access API means creating EOBs from adjudicated claims, not exposing raw Claims.

Implementation considerations

preAuthRef propagation is bilateral. The provider system must capture the authorization number from the PA ClaimResponse and pass it to the billing system so it appears in Claim.insurance.preAuthRef on the subsequent billing claim. If this handoff fails — whether due to a system integration gap or a workflow gap — the billing claim arrives without an auth number and the payer’s adjudication system may deny it.

Track pended submissions actively. When a ClaimResponse returns outcome: queued, the PA decision is not yet available. The provider system must record the pending request and surface the decision when it arrives via subscription notification or polling. Treating all submissions as synchronous is one of the most common PA implementation failures.

preauthorization vs predetermination on use. These are not interchangeable. Submitting a request with use: predetermination when authorization is required produces an estimate, not an authorization. The downstream claim will arrive without a valid auth number and face denial.

Diagnosis coding depth. Payers evaluate PA requests against diagnosis codes. Submitting with only a high-level ICD-10 code (e.g., C34 instead of C34.10) may result in a pended decision requiring additional information, whereas the specific code would have triggered an automatic approval.

Common mistakes

Using use: claim for a PA request. The Claim hits the billing adjudication system, not the PA review system. The result is either an error or a billing claim processed without a service having been rendered.

Not including preAuthRef on the billing claim. After PA is approved, the authorization number from the ClaimResponse must appear in the billing Claim’s insurance.preAuthRef. Missing it causes adjudication failure or auto-denial for “no authorization on file.”

Returning free-text denial reasons only. CMS-0057-F requires structured reason codes in ClaimResponse for denied PA requests. processNote text alone doesn’t satisfy the requirement.

Misusing predetermination. A predetermination ClaimResponse is not binding and does not authorize the service. Patients shown a predetermination estimate should not interpret it as an authorization.

Omitting supportingInfo on PAS submissions. The PAS IG requires clinical documentation attached as supportingInfo. Submitting a bare Claim without the completed QuestionnaireResponse will result in a pended decision requiring resubmission.

Not setting insurance.focal. When multiple coverage entries appear in insurance, exactly one must have focal: true to designate the primary payer. Omitting focal leaves the payer’s system unable to determine coordination of benefits order, often resulting in a processing error.

Mismatched diagnosisSequence in items. Each item.diagnosisSequence value must reference a valid sequence number in the top-level diagnosis array. Off-by-one errors or re-sequencing after edits create broken references that cause parsing failures or adjudication errors at the receiving system.

Claim and ClaimResponse

Claim and ClaimResponse

The use field

Key structural elements

status

type

patient and insurer

provider

priority

insurance

diagnosis

procedure

item

supportingInfo

ClaimResponse

outcome

item.adjudication

preAuthRef and preAuthPeriod

addItem

processNote and denial reasons

Da Vinci PAS profiles

X12 278 relationship

R5 changes

Search parameters

Claim vs ExplanationOfBenefit

Implementation considerations

Common mistakes

See also

The `use` field