synthetic-claims-warehouse
claims-utilization-dataset
data governance and revenue operations review before live claims analytics
Request signals
fixture-claims-utilization-dataset-v1
claims-utilization-synthetic-v1 fixture from synthetic-claims-warehouse
01member: Synthetic member key and eligibility band.
02claim: Synthetic claim header and line metadata.
03diagnosis: Synthetic diagnosis grouping for analytics only.
04procedure: Synthetic procedure grouping for utilization review.
05payer: Synthetic payer and plan category.
06allowedAmount: Synthetic allowed amount value for cost modeling.
Expected signals produced after contract normalization.
- member
- claim
- diagnosis
- procedure
- payer
- allowedAmount
Signals that block fixture acceptance when absent.
- member
- claim
- payer
- allowedAmount
Unsafe connector behavior that must stay blocked.
- final reimbursement decision
- unpartitioned access
- unversioned schema change
Fixture payload present
Every non-synthetic integration contract must have a synthetic request and expected-response fixture.
Synthetic-only fixture
Integration fixture requests must be explicitly synthetic-only until live connector approval.
Contract binding
Fixture and request payload must bind to the same integration contract slug.
No production identifiers
Fixture payload must not include obvious SSN, MRN, email, or phone identifiers.
Required signals covered
Fixture must cover every required signal declared by the integration contract.
Safeguards mapped
Fixture text must map all declared safeguards into guardrails, trace, review, or prohibited-action controls.
Trace complete
Expected response must include at least four deterministic trace steps.
Live review required
Fixture must require human review before live connector promotion.
Prohibited actions
Expected response must define prohibited actions for unsafe connector behavior.
Diff fingerprint
Fixture diff fingerprint must change when expected request or response fields change.