Results

When a validation Task reaches a terminal status, Synthpop reports its findings in three linked places on TaskDetails:

verdicts — the per-code decision: approved or not.
issues — the specific problems Synthpop found, which verdicts point at.
verdict_summaries — a per-code human-readable conclusion.

Think of this as a result, not a bare pass/fail: a decision, its supporting issues, and an explanation, all in one response.

verdicts and verdict_summaries are empty on a freshly created Task and are populated only once processing finishes. Poll GET /task/get to a terminal status, or use a callback. See Async results.

Verdicts

A Verdict is the decision for one code (e.g. an HCPCS procedure code or an Exxxx code).

code

string

required

The code being evaluated.

approved

boolean

required

Whether the code was approved.

issues

integer[]

required

Indices into TaskDetails.issues — pointing at the issues that affect this verdict and may have caused it not to be approved. This is a list of array positions, not issue objects.

The index linkage

A verdict does not embed its issues — it references them by position. To resolve them, index into the Task’s top-level issues array:

{
  "issues": [
    { "key": "task.medical_record.expired", "medical_record_type": "clinical-note", "message": "The clinical note is older than the allowed window." },
    { "key": "task.data.missing", "property": "physician_signature", "message": "The order is missing a physician signature." }
  ],
  "verdicts": [
    { "code": "70551", "approved": false, "issues": [0, 1] }
  ]
}

Here verdict 70551 (an illustrative example code) was not approved, and its issues: [0, 1] point at the two entries in issues — the expired clinical note and the missing signature.

The indices are positions in this response’s issues array. Resolve them against the same payload; do not cache indices across separate reads, since the array can change as processing progresses.

Issues

TaskDetails.issues is a list of problems detected with the Task or its medical records. It is a discriminated union keyed by the key field — every issue has a key and a human-readable message, plus type-specific fields. There are nine issue types:

`key`	Meaning	Extra fields
`task.data.missing`	A required input data item is missing.	`property`
`task.data.inconsistent`	Inconsistent data found across documents.	`property`
`task.medical_record.missing`	A required medical record type is missing.	`medical_record_type`
`task.medical_record.expired`	A record’s service date is too far in the past.	`medical_record_type`
`task.medical_record.incorrect_sequence`	The sequence of documents does not meet requirements.	`medical_record_type`
`task.logic.fail`	A deterministic logic check failed.	`code`
`task.logic.warning`	A deterministic logic check raised a warning.	`code`
`task.llm.other`	A generic issue reported during analysis.	—
`medical_record.data.missing`	Required information is missing from a specific medical record.	`property`, `medical_record_type`

Switch on key to handle each issue type. The union is the single source of truth for what can appear — new issue types would appear as new key values.

Show Example issue objects

[
  {
    "key": "task.data.missing",
    "property": "physician_signature",
    "message": "The order is missing a physician signature."
  },
  {
    "key": "task.medical_record.expired",
    "medical_record_type": "clinical-note",
    "message": "The clinical note is older than the allowed window."
  },
  {
    "key": "task.logic.fail",
    "code": "70551",
    "message": "Ordered code is not supported by the diagnosis codes provided."
  }
]

Conclusions

For validation tasks, verdict_summaries gives a plain-English conclusion per code — the sentence you can surface to a human reviewer.

code

string

required

The code the conclusion applies to.

conclusion

string

required

Human-readable conclusion summary for this code.

{
  "verdict_summaries": [
    {
      "code": "70551",
      "conclusion": "The submitted documentation supports the ordered procedure (an _illustrative example_). The required criteria are met, including a signed physician order, a supporting clinical note within the allowed window, and diagnosis codes consistent with the request."
    }
  ]
}

Reading a result end to end

Check the status

Confirm the Task reached a terminal status (completed, failed, or invalid). A Task can also stop in waiting if it needs more input.

Read the verdicts

For each Verdict, look at approved.

Resolve the issues

For an unapproved verdict, map each index in its issues array to TaskDetails.issues[i] and switch on key to explain what is wrong.

Show the conclusion

Surface the matching verdict_summaries entry for a reviewer-ready sentence.

If a verdict is not approved because of a missing document, the Task often sits in waiting — supply the document to resume it. See Responding to waiting tasks.

Get started

Core concepts

Working with the API

Referral & order intake

Coverage & authorization

Patient engagement

Resources

Support

Verdicts

The index linkage

Issues

Conclusions

Reading a result end to end

Where to go next

Tasks

Data Items

​Verdicts

​The index linkage

​Issues

​Conclusions

​Reading a result end to end

​Where to go next

Tasks

Data Items

Verdicts

The index linkage

Issues

Conclusions

Reading a result end to end

Where to go next