Coverage & authorization

Getting a service approved is rarely a clinical question alone. Even when the documentation is perfect, a request can stall because the patient’s plan does not cover it, a prior authorization is missing, or the payer’s own rules were not met. Synthpop evaluates coverage and authorization together with the clinical documentation, so a single result tells you both whether the request is clinically supported and whether it holds up against the patient’s payer.

Availability — coverage is evaluated within a validation Task. Coverage and authorization are not a separate product or a standalone endpoint. There is no “coverage API” to call. Instead, when you submit a validation Task, Synthpop resolves the patient’s payer from the documents you upload and factors payer rules into the outcome. Coverage findings surface in the same verdicts, issues, and verdict_summaries as the clinical result. Some organizations have a coverage-focused task_type provisioned; if you need one, ask your Synthpop contact.

What it does

When you create a validation Task, Synthpop reads the payer-relevant material in the packet — insurance cards, demographics, the ordered service, and diagnosis detail — and evaluates the request against the payer’s coverage criteria in addition to the clinical criteria. In practice that means:

Eligibility & benefits. The patient’s carrier is identified from the uploaded documents and used to select the applicable coverage policy.
Payer rules. The documentation is checked against what that payer requires to authorize the service — the evidence, orders, and records a reviewer would look for before approving.
Authorization readiness. You learn before you submit to the payer whether the request is likely to be supported, and exactly what is missing if it is not.

Because this runs as part of validation, you don’t orchestrate a separate coverage step. You submit the same documents you already have, and the coverage assessment comes back folded into the Task result.

How coverage findings surface

A completed validation Task carries its outcome in three fields of TaskDetails. Coverage-related conclusions appear in the same places as clinical ones — there is no separate coverage payload to parse:

Field	What you read
`verdict_summaries`	A plain-English `conclusion` per `code` — the human-readable bottom line, including whether coverage requirements are met.
`verdicts`	The machine-readable decision per `code`: `approved` true/false, with the `issues` (by index) that affected it.
`issues`	Every gap Synthpop flagged — including coverage-related ones such as a missing insurance record or an unmet payer requirement — each with a human-readable `message`.

When a request is not supported for a coverage reason, the verdict for the affected code comes back approved: false and references the responsible entry in issues by index — the same pattern you already handle for clinical gaps.

The example payloads below are illustrative. The exact code values, issue keys, and messages you receive depend on your provisioned task_type and the patient’s payer. Treat verdict_summaries as the human-readable surface and verdicts + issues as the machine-readable one; don’t hard-code specific message strings.

A coverage requirement that is satisfied looks no different from any other approval:

{
  "status": "completed",
  "verdict_summaries": [
    {
      "code": "G0399",
      "conclusion": "Documentation supports the requested service and meets the payer's coverage requirements."
    }
  ],
  "verdicts": [
    { "code": "G0399", "approved": true, "issues": [] }
  ],
  "issues": []
}

When a coverage requirement is not met, the gap is described in issues and the verdict points at it:

{
  "status": "completed",
  "verdicts": [
    { "code": "G0399", "approved": false, "issues": [0] }
  ],
  "issues": [
    {
      "key": "task.medical_record.missing",
      "medical_record_type": "insurance-card",
      "message": "An insurance card is required to confirm coverage but was not found in the submission."
    }
  ]
}

Using it

You already know this loop from the Quickstart and the intake walkthrough — coverage adds nothing new to the mechanics. You create a validation Task, poll it to a terminal status, and read the result.

Create a validation Task with the payer-relevant documents

Include the insurance card and demographics in the packet alongside the clinical documents. Synthpop uses them to resolve the payer and evaluate coverage.

curl -X POST "https://app.synthpop.ai/public/v1/task/create" \
  -H "Authorization: Bearer $SYNTHPOP_JWT_TOKEN" \
  -F "task_type=task" \
  -F "uploads=@referral-packet.pdf;type=application/pdf" \
  -F "uploads=@insurance-card.jpg;type=image/jpeg"

task above is the org-provisioned validation type used throughout these docs; it evaluates clinical and coverage requirements together. If your organization has a coverage-focused task_type provisioned, use that value instead — like every task_type, it is assigned during onboarding, not discovered through the API. This value is illustrative; your Synthpop contact tells you which types are enabled for you.

Poll until the Task settles

GET /task/get returns the current TaskDetails. Poll until the status is completed, failed, or invalid. If the Task stops at waiting, it needs more input — often a missing insurance or clinical record — which you supply via POST /task/{uuid}/upload. See Responding to waiting tasks.

Read coverage findings from the result

Read verdict_summaries for the human-readable conclusion, and verdicts + issues for the machine-readable decision and the specific coverage gaps. See Results for the full shape.

Good to know

There is no standalone coverage endpoint or discovery call

Coverage is evaluated inside a validation Task. You will not find a /coverage-style endpoint in the API reference, and there is no endpoint that lists coverage capabilities — everything runs through the same POST /task/create → GET /task/get loop as intake.

The payer is resolved from the documents you upload

Synthpop identifies the patient’s carrier from the uploaded material (for example, an insurance card). The more complete the payer-relevant documents in the packet, the more precisely coverage can be evaluated — so include the insurance card and demographics when you have them.

Where to go next

Validate an order

The concrete end-to-end pattern coverage builds on.

Results

The full shape of verdicts, summaries, and issues.

Referral & order intake

The intake capability coverage is evaluated within.

Patient engagement

Reach patients to close coverage and documentation gaps.

Get started

Core concepts

Working with the API

Referral & order intake