Salesforce Development for Healthcare: What Actually Needs Custom Building

Key Takeaways: 

• Health Cloud already provides a FHIR R4-aligned clinical data model, so rebuilding patients, care plans and clinical encounters is usually unnecessary.
• Health Cloud is HIPAA-eligible, not automatically HIPAA-compliant. Configuration, access controls, PHI handling and security remain the organization’s responsibility.
• Custom development is most valuable for patient/provider portals, clinical calculators, consent workflows, intake forms, integration logic and regulator-specific reporting.
• EHR integrations commonly involve FHIR R4 and HL7 v2, so teams should not assume every integration is simply a FHIR connector.
• Health Cloud is generally the better foundation for genuinely clinical use cases, while core Salesforce can be sufficient for administrative workflows without PHI.
• Healthcare Salesforce projects typically require 25–40% more investment than comparable unregulated projects because of testing, documentation, validation, and security requirements.
• Patient data should be masked before developers work in Full or Partial Copy sandboxes.
• The biggest mistake is building custom objects for functionality Health Cloud already provides.

Quick Answer: Salesforce for healthcare works best when organizations extend Health Cloud rather than rebuild its clinical foundation. Health Cloud already provides FHIR-aligned objects for patients, care plans, care teams and clinical encounters, while custom development is better reserved for patient portals, clinical calculations, consent workflows, EHR integrations and organization-specific reporting. Healthcare teams also need to treat HIPAA requirements, PHI security and compliance as part of the development process from the beginning, not as a final checklist.

The most expensive mistake in healthcare Salesforce projects isn’t building the wrong thing. It’s rebuilding something the platform already gives you.

Health Cloud’s clinical data model is aligned to FHIR release 4 out of the box. Patient, Care Plan, Care Team, Clinical Encounter, Condition, Medication – these exist as standard objects, structured to exchange data with EHR systems. Teams that scope custom objects for them spend six figures recreating something that already works, and then discover their integration doesn’t map cleanly.

This guide covers what genuinely needs building, what only needs extending, and the compliance details that shape both.

Where Standard Salesforce Stops for Healthcare

Sales Cloud and Service Cloud assume a commercial relationship – accounts, contacts, opportunities, cases. Healthcare assumes something structurally different: a patient with a longitudinal record, a care team rather than an owner, clinical encounters rather than transactions, and data governed by regulation rather than commercial preference.

Health Cloud closes most of that gap; it adds the clinical data model, care plans, referral management, provider and payer relationships, and an FHIR-aligned structure designed for exchanging data with external clinical systems.

What it doesn’t close is anything specific to your organisation’s protocols, your regulator, your patient experience, or the systems you happen to run. That’s where development starts.

Don’t Build What Health Cloud Already Gives You

Three-column comparison showing what is already standard in Health Cloud, what should be extended, and what genuinely needs custom building

The Rule: Salesforce publishes an HL7 and FHIR mapping reference for Health Cloud. Read it before scoping a single custom object.

Why It Matters Beyond Cost: If you build a custom Patient object rather than using Person Accounts, your EHR integration no longer maps to a standard structure. Every future interoperability requirement becomes bespoke work, and the FHIR integration framework Salesforce provides stops helping you.

The Honest Exception: Occasionally an organisation’s model genuinely doesn’t fit – unusual entity relationships, a non-clinical use case, or a regulatory structure with no standard equivalent. That’s a real conversation to have with an architect, not an assumption to build on.

When an organisation genuinely falls outside Health Cloud’s standard model, that decision should involve the right technical expertise. Understanding the difference between a Salesforce admin, developer, and architect can help determine whether the requirement needs configuration, custom code, or architectural design.

Related: The Salesforce data model explained · Configuration vs customization

Health Cloud or Build on Core?

The question most healthcare buyers actually have.

• Where The Maths Lands: Health Cloud licences cost more per seat and less overall for anything genuinely clinical, because you’re buying a data model rather than building one. Building the same capability on Service Cloud is usually cheaper in year one and more expensive by year three.
• Where core Salesforce Is Genuinely Fine: Administrative use cases with no PHI and no clinical model, a healthcare organisation’s HR portal, supplier management, or facilities requests. Don’t pay Health Cloud licence rates for those.

For administrative healthcare workflows without PHI or a clinical model, Salesforce low-code development can keep the implementation configuration-led rather than introducing unnecessary custom code.

Related: Salesforce customization cost

“HIPAA-Eligible” Is Not “HIPAA-Compliant”

Comparison of what Salesforce provides for HIPAA compliance versus what the customer must configure themselves

This distinction decides whether a build passes an audit, and it’s stated carelessly almost everywhere.

Salesforce signs a BAA, and Health Cloud along with select Enterprise editions of Sales and Service Cloud fall under it. That makes the platform eligible to handle PHI.

Two Things That Catch Teams Out:

• The BAA covers a defined list of services – not the whole platform. Not every Salesforce capability, add-on or feature is in scope. Building a PHI-handling workflow on a service that isn’t covered creates an exposure nobody notices until an audit.
• Configuration and access management remain your responsibility, not Salesforce’s. Sharing rules that over-expose PHI internally, an Apex class that skips FLS enforcement, or a sandbox full of unmasked patient data are all your problem regardless of what the BAA says.

What this means for development specifically:

• Enforce FLS in every Apex class and Flow touching clinical data – WITH USER_MODE rather than manual checks. See the Apex guide.
• Mask PHI before anyone develops against a sandbox. Full and Partial copies bring real patient data into a lower-security environment. See Salesforce sandboxes.
• Record-triggered Flows and Apex run in system mode and ignore sharing entirely – a genuine PHI exposure route. See Salesforce Flow.
• Shield Platform Encryption and Event Monitoring are paid add-ons, not included.

Related: Salesforce compliance and data security

What Healthcare Organisations Actually Build

The custom work that genuinely earns its cost:

• Patient And Provider Portals: Experience Cloud sites for appointment booking, results access, referral submission and document upload. Almost always custom, because the patient experience is the differentiator.
• Clinical Scoring And Eligibility Calculators: Risk scores, trial eligibility, care pathway triggers. Business logic no standard object encodes.
• Consent And Authorisation Workflows: Consent capture, revocation, and the audit trail proving both. Highly organisation-specific and increasingly scrutinised.
• Intake And Assessment Forms: Screen Flows for structured clinical intake, often with conditional logic reflecting a specific protocol.
• Integration Middleware Logic: The FHIR framework handles a lot, but mapping to a legacy Meditech instance or a claims platform with a proprietary format is real work.
• Regulator-Specific Reporting: Quality measures, submissions, and disclosure reports in whatever format your regulator specifies.

This is where Salesforce Development Services become valuable, extending Health Cloud with the patient experiences, clinical logic, consent workflows, integrations, and reporting requirements that are specific to each organisation.

The Integration Surface

Healthcare integration is where most of the budget and most of the risk sits.

Two Things Worth Knowing:

• Salesforce’s pre-built FHIR integration framework reduces custom development substantially, but it still requires meaningful configuration. Plan six to ten weeks for a first EHR integration rather than assuming it’s a connector you switch on.
• HL7 v2 and FHIR are not the same thing, and plenty of EHR estates still run v2 for real-time messaging. If your integration partner talks only about FHIR, ask what they’ll do about v2 interfaces.

Related: Salesforce API integration · Salesforce integration guide

What It Costs

Cost bands for healthcare Salesforce builds range from custom fields at 3 to 10 thousand dollars up to custom HL7 integration at 60 to 180 thousand

The healthcare premium is real; comparable builds cost roughly 25–40% more than in unregulated industries, and it isn’t the code; it’s the testing, the documentation, the validation evidence, and the security review that regulated environments require.

• Licences Sit On Top: Health Cloud lists from around $325 per user per month, rising for Unlimited and Einstein 1 editions. Mid-market implementations commonly land between $80,000 and $200,000 before ongoing development.

Discovery is heavier here than elsewhere, and cutting it is a false economy. A proper healthcare discovery produces a data model, an integration architecture document, a care plan template library, a persona matrix, and a HIPAA risk assessment. The gap between what administrators think clinical staff does and what they actually do is consistently larger than anyone expects.

Those costs also make the delivery model important. The in-house vs outsourced Salesforce development decision should account for healthcare-specific skills, compliance requirements, project duration, and the need for ongoing maintenance.

The Mistakes That Cost Most

• Rebuilding The Clinical Data Model: Covered above, and it’s the expensive one.
• Treating Compliance As A Phase: It runs alongside the build. Retrofitting FLS enforcement and audit trails across a finished system costs multiples of building them in.
• Developing Against Unmasked PHI: Common, and indefensible in an audit.
• Assuming The BAA Covers Everything: Check which services are in scope before you architect on one.
• Underestimating Clinical Stakeholder Time: Nurses and clinicians are the users, and they’re the hardest people in any organisation to get into a requirements workshop.
• Building For The Process Rather Than Fixing It: Automating a broken referral pathway makes it faster and harder to change.

Where to Go Next

For the compliance framework in more depth, see Salesforce compliance and data security.

For the integration surface, Salesforce integration and Salesforce API integration.

For the build decision, configuration vs customization and custom Salesforce development.

For budgeting, Salesforce customization cost.

For protecting PHI in lower environments, Salesforce sandboxes explained.

The complete Salesforce development guide is the hub.

Before You Scope a Healthcare Build

The first thing we do on a healthcare Salesforce enquiry is check what’s already standard.

It’s a slightly awkward opening, because it usually means the scope shrinks – but rebuilding Health Cloud’s clinical model is the single most expensive mistake in this sector, and it’s easier to prevent than to unwind.

We’re a certified Salesforce Consulting Partner with developers, architects and consultants across the US, UK, Australia, Canada, UAE and India.

On a scoping call, we’ll tell you which requirements are standard configuration, which genuinely need code, and where the compliance workstream has to run alongside the build rather than after it.