Case Study: Custom HIPAA-Compliant Salesforce Portals for Healthcare SaaS

When a mid-market Healthcare SaaS company came to TeraQuint, they had a Salesforce org that had grown faster than their compliance program. Medication records sat in standard text fields. Patient data was mapped to generic Contact records instead of Person Accounts. Field-level security was inconsistent across profiles. Three audits in, they still could not get a clean HIPAA sign-off. This case study documents the exact Salesforce development decisions that fixed it.

If your org holds protected health information and you are heading into a compliance review, the architecture choices below are directly applicable to your situation.

What Is a HIPAA-Compliant Salesforce Portal?

A HIPAA-compliant Salesforce portal is a patient-facing or provider-facing Experience Cloud site built on a Salesforce org where all PHI is encrypted at rest using Shield Platform Encryption, access is governed by least-privilege permission sets, and every data interaction is logged through Event Monitoring. It must satisfy the HIPAA Security Rule across administrative, physical, and technical safeguards within the Salesforce data layer itself.

Why Standard Salesforce Configuration Fails Healthcare SaaS

Most Salesforce implementations are designed for commercial B2B use cases. When Healthcare SaaS companies go live on those foundations and then add patient data, the gaps compound quickly.

• Contact vs. Person Account mismatch: Generic Contact records do not carry the household and individual identity fields that patient data requires. Reporting breaks. Deduplication breaks. Audit trails become unreliable.
• No encryption on sensitive fields by default: Standard field-level security controls visibility, not encryption. An attacker or a misconfigured integration can still read unencrypted PHI at the database layer.
• Integration leakage: Connected apps, marketing automation tools, and third-party analytics platforms often pull data from Salesforce without any PHI filtering layer in place.
• Profile-based security drift: As orgs grow, profile cloning creates permission sprawl. Users end up with access to PHI they were never meant to see, and there is no automated detection.

These are not edge cases. They are the default state of a Salesforce org that was not architected for HIPAA from day one. See how revenue and compliance risk compound together in our Revenue Leak Audit framework.

The HIPAA-Compliant Portal Architecture TeraQuint Built

Step 1: Person Account Migration

The first structural fix was migrating all patient records from standard Contact objects to Person Accounts. This sounds straightforward. It is not. Person Accounts cannot be turned on without a full data model review because they change how relationships, sharing rules, and API integrations behave across the entire org.

We ran a full object dependency audit before enabling Person Accounts, identified 14 flows and 6 Apex triggers that referenced Contact directly, and refactored each one before migration. The cutover was executed in a sandbox with a full regression test cycle before touching production.

Step 2: Salesforce Shield Encryption on PHI Fields

Shield Platform Encryption was applied to every field carrying protected health information: medication names, dosage records, diagnosis codes, and appointment notes. This is different from Classic Encryption. Shield encrypts data at rest at the platform level, which means the encryption persists even if someone accesses the underlying database directly.

Key decisions made during this phase:

• Used tenant secrets managed by the client, not Salesforce, to maintain control of the encryption key lifecycle.
• Excluded fields used in formula calculations and SOQL WHERE clauses from deterministic encryption to avoid breaking search and reporting functionality.
• Documented every encrypted field in a data dictionary tied to the client HIPAA compliance binder.

Step 3: Least-Privilege Permission Set Architecture

We replaced 11 legacy profiles with a structured permission set group model. Every role in the org, from patient-facing portal users to internal care coordinators to billing staff, received only the object and field access their job function required. Nothing more.

Permission sets were named and documented according to job function, not technical role, so the compliance team could audit access without needing a Salesforce admin in the room.

Step 4: Event Monitoring and Audit Trail Configuration

HIPAA requires a full audit trail of who accessed what PHI and when. Salesforce Event Monitoring was enabled and configured to capture Login Events, Report Export Events, and Field History on all encrypted PHI fields. Logs were piped to the client SIEM tool via API on a 15-minute polling cycle.

This step alone resolved the auditor's primary objection from the previous two review cycles.

Step 5: Experience Cloud Portal Build

With the data model secured, we built the patient portal on Experience Cloud using a custom Lightning Web Component architecture. The portal allowed patients to view appointment history, medication records, and care team communications without any PHI ever being exposed in the URL, stored in browser local storage, or passed to third-party scripts.

All portal sessions were governed by a Named Credential pattern for backend API calls, eliminating the risk of session token exposure.

HIPAA-Compliant Salesforce Portal: Build vs. Configure Comparison

HIPAA Audit Outcomes After the Build

The client went through their next HIPAA audit four months after the Salesforce development project completed. Results:

1. Zero findings on technical safeguards. The auditor reviewed encryption coverage, access logs, and field history trails. Every item was documented and traceable.
2. Audit completed in two days instead of five. The structured data dictionary and Event Monitoring export eliminated the back-and-forth that had consumed previous reviews.
3. Business Access Agreement renewed without conditions. The covered entity partner that had been threatening to offboard them renewed the BAA for a three-year term.
4. Portal user adoption reached 74 percent in 60 days. The Experience Cloud build was the first portal patients could actually use on mobile without layout failures.

If your Salesforce org is carrying PHI and your compliance posture looks like the before state described above, the risk is not hypothetical. The path to a clean audit is a Salesforce development engagement scoped to your specific data model and audit requirements. Start with a structured audit of your current Salesforce compliance gaps before your next review cycle hits.

What Healthcare SaaS Companies Get Wrong Before Engaging a Salesforce Development Partner

• Assuming Shield Encryption is a checkbox feature rather than an architecture decision that affects search, reporting, and integrations.
• Running the HIPAA review with the same admin team that built the original org, without an outside set of eyes on permission sprawl.
• Treating the Experience Cloud portal as a front-end project while leaving the back-end data model unresolved.
• Not establishing a Named Credential pattern for API authentication before building integrations, which creates PHI exposure in connected apps.
• Skipping the data dictionary step and then being unable to answer auditor questions about which fields contain PHI and who can access them.

Each of these is a pattern TeraQuint has corrected in multiple Healthcare SaaS engagements. The Salesforce development work is not technically exotic. What makes it hard is that it requires touching the data model, the security model, the integration layer, and the portal layer simultaneously, in the right sequence.

Related Resources for Healthcare SaaS and Salesforce Development Teams

If this case study surfaces risks you recognize in your own org, these resources are the next logical step:

• Run a Revenue and Compliance Leak Audit to quantify what your current Salesforce architecture is costing you in audit risk and pipeline visibility.
• Talk to the TeraQuint team directly about your Salesforce development scope at teraquint.com/contact.
• Review the full range of Salesforce consulting services at teraquint.com to understand how compliance, RevOps, and portal development intersect in a single engagement model.