synthetic-pricing-feed
pricing-transparency-dataset
pricing, compliance, and data governance review before live transparency analytics
Request signals
fixture-pricing-transparency-dataset-v1
pricing-transparency-synthetic-v1 fixture from synthetic-pricing-feed
01payer: Synthetic payer or plan category.
02facility: Synthetic site of care.
03serviceCode: Synthetic service, CPT, DRG, or internal service code.
04cashPrice: Synthetic cash-price amount for transparency modeling.
05negotiatedRate: Synthetic negotiated-rate amount by payer category.
06effectiveDate: Effective date used for staleness and rate-version review.
Expected signals produced after contract normalization.
- payer
- facility
- serviceCode
- cashPrice
- negotiatedRate
- effectiveDate
Signals that block fixture acceptance when absent.
- payer
- facility
- serviceCode
- effectiveDate
Unsafe connector behavior that must stay blocked.
- patient-specific estimate guarantee
- stale rate publication
- source reference removal
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.