Skip to main content
Synthpop is organized around a single idea: the work you do for a patient is not three disconnected systems, it is one journey. A referral arrives, coverage has to be confirmed, and the patient has to be moved forward. You reach every stage of that arc through one uniform interface — the Task — so you learn the model once and use it for whatever your organization has enabled.

​
One resource, three stages

There are no capability-specific endpoints. Everything you build starts with the same call, POST /task/create, and the only lever that changes what Synthpop does is the task_type you pass. Intake, coverage, and engagement are not separate products with separate APIs; they are different task_type values flowing through the same create → process → read loop.
Task types are provisioned for your organization during onboarding. There is no discovery endpoint — the concrete values available to you come from your Synthpop contact. Passing an unprovisioned type returns 400 "Task type 'X' not in list of tasks for your organization: [...]."

​
Following one patient through

1

Intake — turn documents into structured data

A packet lands: a multi-page fax, a scanned order, an insurance card, a clinical note. You upload it as-is. Synthpop classifies each document, extracts the clinical and demographic detail, and returns it as structured medical records on the Task — no templates, no manual keying.This is the mainline capability. See Referral & order intake.
2

Coverage — decide whether the documentation holds up

With the records in hand, Synthpop evaluates the submission against the clinical criteria and the patient’s payer policy. The outcome is expressed as Results: a per-code verdict (approved or not), the specific issues that stand in the way, and a plain-English conclusion you can show a human.Coverage is evaluated within a validation Task — its results appear in the same response, not behind a separate call. See Coverage & authorization.
3

Engagement — move the patient forward

When something is missing or a patient needs to be reached, engagement runs as its own Task (a voice task_type, for enabled organizations). The voice agent places outbound calls and handles inbound ones, working the follow-up end to end. Same Task model, same TaskDetails shape as every other capability — a separate Task, tied to the patient’s other work by your external_id.See Patient engagement.

​
Why it reads as one flow

Because every capability speaks the same Task model, what you learn once applies everywhere — and you tie a patient’s Tasks together with external_id:
  • One response shape. Every Task returns a TaskDetails object. Learn its Data Items and Results once and you can read intake, coverage, and engagement the same way.
  • One asynchronous model. Every Task is created immediately with status: "pending" and processed in the background. You observe progress the same way everywhere — polling GET /task/get or receiving a callback. See Async results.
  • One correlation key. Attach your own external_id on create and thread it through every Task for a patient to tie Synthpop’s work back to the case in your system.
A journey is one or more Tasks — you stitch them together, not Synthpop. Intake and coverage share a validation Task; engagement is a separate voice Task; a superseding submission is another Task again. There is no parent/child field on a Task — correlate a patient’s Tasks yourself with external_id and GET /task/list.

​
Where to go next

Tasks

The core resource and its status lifecycle.

Data Items

Inputs, outputs, and extracted medical records.

Results

Verdicts, issues, and conclusions.

Quickstart

From an API key to a validated Task.