Payer-data contracts with their limits visible.
Evaluate four non-PHI contracts against synthetic sandbox data. Live results are customer-scoped, provenance travels with available sources, and insufficient network evidence is withheld.
What is Upstream Data?
Upstream Data exposes requirements, benchmarks, denial-risk signals, and prior-auth readiness through a non-PHI API boundary. Each response distinguishes synthetic sandbox data, customer-scoped live data, source provenance, and withheld network evidence.
What the contracts preserve.
A useful payer signal needs more than a value. It needs its source, status, scope, and limits so a product can decide whether to use it, hold it for review, or treat it as unknown.
Requirements with provenance
Requirement responses carry the source and effective date when available. Missing or unsupported source material stays explicit instead of being filled in.
Benchmarks that can be withheld
Live benchmarks are customer-scoped and require at least three contributing practices. When that threshold is not met, the network result is withheld rather than inferred.
A labeled risk signal
The denial-risk contract returns drivers and model status. It remains a heuristic signal until it passes the repository promotion gates for a production model.
Sandbox and live data are deliberately different.
Synthetic sandbox
Representative, non-PHI records let builders validate authentication, schemas, null handling, provenance, and withholding without treating sample data as observed payer behavior.
Scoped live access
Production keys are issued after access review. Results stay customer-scoped, and network aggregates remain unavailable when fewer than three practices contribute.
The API boundary is designed for payer data, not patient records.
The published schemas use policy references, procedure and diagnosis codes, counts, anonymized aggregates, and model signals. Patient-level clinical records are outside this API contract.
- Synthetic records in sandbox responses
- No patient-level fields in the published API schemas
- Network benchmarks require at least three practices
- Live keys issued after scope and access review
Built for builders close to the work.
- Teams training and evaluating models on payer-behavior data
- Revenue-cycle tools that need benchmarks to understand submission risk
- Researchers studying prior-authorization burden across payers
- Builders who want to evaluate the contracts against synthetic sandbox data
Upstream Data, answered plainly.
- What makes Upstream Data different from a generic healthcare dataset?
- Upstream Data is focused on payer behavior, requirements, benchmarks, and submission patterns around real specialty workflow questions. It is not a broad claims dump or a general-purpose healthcare warehouse.
- Does Upstream Data include patient information?
- The public API contract is intentionally non-PHI. It accepts and returns policy references, codes, counts, aggregates, and scored patterns. Patient-level records are outside this surface.
- What data is available now?
- Sandbox responses are synthetic and intended for contract evaluation. Live access is customer-scoped and requires an access review. A network benchmark can be null or withheld when its contribution threshold is not met.
- Who is this page really for?
- It is for technical buyers, product teams, and researchers who want to understand the non-PHI layer beneath Upstream before they evaluate the API or the platform itself.
Evaluate the contracts with synthetic data.
Review the four endpoints, null and withholding behavior, and the path from a sandbox key to scoped live access.