Healthcare Plan
A Healthcare Plan in Salesforce Health Cloud is a record on the HealthcarePayerNetwork or HealthcareProductCoverage object representing the insurance plan a patient is enrolled in, with the relationships to the issuing payer, the covered services, the network of providers, and the cost-sharing details (copays, deductibles, out-of-pocket maximums).
Definition
A Healthcare Plan in Salesforce Health Cloud is a record on the HealthcarePayerNetwork or HealthcareProductCoverage object representing the insurance plan a patient is enrolled in, with the relationships to the issuing payer, the covered services, the network of providers, and the cost-sharing details (copays, deductibles, out-of-pocket maximums). The object family includes HealthcarePayer (the insurance company), HealthcarePayerNetwork (a named network within a payer like PPO or HMO), HealthcareProduct (a specific plan SKU), HealthcareProductCoverage (what the plan covers), and PurchaserPlan (the patient''s membership in a plan).
The Healthcare Plan model exists because patient access, prior authorization, claims handling, and care coordination all depend on knowing what insurance a patient has and what it covers. Without the structured plan data, every benefit check is a manual phone call to the payer. Health Cloud encodes this data in the standard objects, lets the payer integration populate it automatically via FHIR Coverage and CoverageEligibilityResponse resources, and surfaces the active plan on the Patient Card so providers can see eligibility in real time.
How Health Cloud structures the insurance side of the patient record
The five core healthcare plan objects
Health Cloud splits the insurance domain into five linked objects. HealthcarePayer is the insurance company (Aetna, Cigna, Blue Cross). HealthcarePayerNetwork is a named sub-network within a payer (Blue Cross HMO Massachusetts). HealthcareProduct is a specific plan SKU (Aetna Silver 2026). HealthcareProductCoverage breaks down what the plan covers and at what cost share. PurchaserPlan is the patient''s enrollment, linking the patient to a specific HealthcareProduct with effective dates and member ID.
Eligibility verification flow
When a patient checks in, the patient access representative queries the payer for eligibility. The response (an FHIR CoverageEligibilityResponse) maps to records in the HealthcareProductCoverage object, populated automatically by the EHR or clearinghouse integration. Health Cloud Setup includes mapping configurations that translate the FHIR fields into the Salesforce data model. The result is a live eligibility view on the Patient Card.
Prior authorization workflow
Prior authorization is the process of getting payer approval for a covered service before performing it. Health Cloud ships a Prior Authorization object that links the patient, the requested service, the payer, and the authorization decision. The workflow uses Flow Orchestration to route the request from the requesting provider to the payer integration to the approving clinician, with status updates flowing back to the requesting provider in real time.
Cost-share calculation
HealthcareProductCoverage stores cost-sharing rules: copay amount, coinsurance percentage, deductible to date, out-of-pocket maximum. A formula on the patient encounter can compute the patient responsibility for any given service based on the active coverage. This is what powers the patient cost estimator some Health Cloud deployments show to patients before they schedule.
Network adequacy and referral routing
The HealthcarePayerNetwork object links to a list of in-network Provider records. When a referring provider books a specialist, Health Cloud can filter the specialist directory to in-network providers for the patient''s plan, reducing the out-of-network surprise bills that plague patient experience. The data model supports multiple plans per patient (commercial primary, Medicare secondary) with effective-date ranges.
Integration with EHR and clearinghouse
Most healthcare organizations pull plan data from the EHR (Epic, Cerner) or a clearinghouse (Change Healthcare, Availity) rather than entering it manually. Health Cloud connectors and MuleSoft templates handle the integration. The records refresh on a schedule (typically daily) or on demand via real-time eligibility queries. Health Cloud Setup includes the configuration node where the integration polling cadence is set.
Reporting on plan mix and revenue
The Healthcare Plan data model supports standard reporting on plan mix, payer mix, claim status, and authorization throughput. Build dashboards joining PurchaserPlan, HealthcareProduct, and Account (patient) to surface the population by plan type, the average copay by service line, and the bottleneck stages in prior auth. These dashboards are the most common executive-facing Health Cloud reports.
Configure the healthcare plan data model
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.
Trust & references
Cross-checked against the following references.
- Healthcare Plan Data ModelSalesforce Help
- Eligibility VerificationSalesforce Help
Straight from the source - Salesforce's reference material on Healthcare Plan.
- HealthcarePayer ObjectSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is a Healthcare Plan in Health Cloud?
Q2. Why are care plans important?
Q3. What does a Healthcare Plan typically include?
Discussion
Loading discussion…