The model is mostly populated by integration, but the configuration of objects, layouts, and mappings is the admin''s job.
- Enable Health Cloud Settings
Setup, Health Cloud Settings; toggle the master enable. This activates the HealthcarePayer family of objects.
- Configure page layouts and FLS
Set up Lightning record pages for HealthcarePayer, HealthcareProduct, HealthcareProductCoverage, and PurchaserPlan. Decide who can see and edit each object.
- Set up the EHR integration
Configure the FHIR Coverage and CoverageEligibilityResponse mappings under Health Cloud Setup. Test with a sandbox EHR before going live.
- Build the Patient Card eligibility view
Add a Lightning component to the Patient Card that surfaces active PurchaserPlan, coverage details, and the last eligibility check timestamp.
- Define prior authorization workflow
Build a Flow Orchestration that routes prior auth requests from the requesting provider to the payer integration to the approving clinician. Capture every state change for audit.
- Train patient access reps
Walk reps through the eligibility check workflow. Cover the most common edge cases: terminated coverage, secondary insurance, and pre-existing condition exclusions.
Required parent record for any plan; the insurance company.
The specific plan SKU; child of payer.
The patient''s enrollment record linking patient to plan with dates.
The cost-share and coverage rules per service.
- Healthcare plan data is high-volume and high-update. Plan storage and integration throughput before going live, because the daily eligibility refresh can produce millions of records per year.
- Prior auth status changes are time-sensitive. Build the integration as event-driven where the payer supports it, not polling-only, to keep the status fresh.
- Patient consent is required to query payer eligibility in some jurisdictions. Consent Management must be configured alongside the plan data model.
- Effective-date arithmetic is the most common source of plan-data bugs. A patient who switched plans mid-year needs both the old and new PurchaserPlan records with non-overlapping dates.