We are at Dreamforce 2026, Industry Pavilion at San Francisco
June 11, 2025
Healthcare data arrives in two shapes, and that single fact decides most of your project. Older clinical systems speak HL7 v2, a pipe-delimited message format from the 1980s. Newer ones speak FHIR R4, a modern REST API standard. MuleSoft integrates both into Salesforce Health Cloud, but each needs different transformation work, and knowing which one you face changes your timeline before you write a line of code.
Here is what goes wrong when nobody asks that question early. A health system approves a project to give care teams one patient view. The team assumes the EHR exposes FHIR endpoints, because the vendor's marketing says so. Six weeks in, they discover the modules they need still emit HL7 v2 segments, and half the build has to be redesigned. Nobody made a mistake exactly. The question just never got asked. Meanwhile the compliance team is asking a separate question nobody has answered either — what does the integration log when the payload contains protected health information?
This guide covers the four things that decide whether a healthcare integration ships. Which message standard you are actually dealing with. Whether MuleSoft Direct for Health does the job or you need a custom build. How to layer your APIs so clinical data stays reusable. And how to handle PHI inside a Mule flow so the compliance conversation is short. Read the first table before you scope anything.
Healthcare is not one system. A mid-size health system runs an EHR for clinical records, a separate lab information system, a practice management system for scheduling, a billing platform, and a patient portal. Each was bought at a different time by a different committee.
None of them was built to talk to a CRM.
That is the gap MuleSoft and Salesforce close together. MuleSoft Anypoint Platform sits between the clinical systems and Salesforce, translating message formats and enforcing rules. Health Cloud then presents the result as a patient record a care coordinator can actually work in.
Three things make healthcare harder than a typical CRM integration.
The data is regulated. Patient records are PHI. Every hop has to be defensible to an auditor.
The formats are old. Systems built in the 1990s are still running, and they still emit the message format they were written for.
Downtime has clinical consequences. A sync failure in a retail org is an inconvenience. In a health system it can mean a clinician working from stale information.
Our Salesforce MuleSoft integration practice starts every healthcare engagement by inventorying which standard each source system speaks, because that answer sets the scope.
This is the section every competing article skips, and it is the one that decides your estimate.
Both standards come from HL7 International. They do the same job — moving clinical data between systems — in completely different ways.
Table 1 — HL7 v2 vs. FHIR R4 in a MuleSoft Build
| Attribute | HL7 v2 | FHIR R4 |
|---|---|---|
| Format | Pipe-delimited segments (MSH, PID, OBR, OBX) | JSON or XML over REST |
| Transport | Usually MLLP over TCP, or file drop | HTTPS, like any modern API |
| Typical use | Lab results, ADT (admit/discharge/transfer), orders | Patient access apps, care coordination, bulk export |
| MuleSoft work needed | HL7 connector plus segment-level DataWeave mapping | Standard HTTP request plus lighter transformation |
| Where you meet it | Legacy modules, lab interfaces, older inpatient systems | Newer EHR modules, payer APIs, patient-facing apps |
| Build effort | Higher — segment parsing, ack handling, custom Z-segments | Lower — resources map closer to Salesforce objects |
Two practical points follow.
You will almost certainly meet both. Most health systems are mid-transition. Scope for both rather than assuming one.
Custom Z-segments are where estimates break. HL7 v2 lets vendors add their own segments. If your source system uses them, your mapping is bespoke and nobody's connector handles it out of the box. Ask for a sample message during discovery, not during build.
Interoperability fundamentals and the healthcare data model are well covered in the modules on Trailhead if your team is building this knowledge internally. Our healthcare practice runs that message inventory as a fixed-scope discovery before any build estimate.
Salesforce ships a capability for this that almost nobody writing about the topic mentions.
MuleSoft Direct for Health gives Health Cloud built-in FHIR R4 and HL7 support with bi-directional EHR integration. It is packaged, not a custom build. That changes the decision meaningfully.
Table 2 — Three Ways to Connect Clinical Data to Salesforce
| Approach | What It Is | Best For | The Trade-off |
|---|---|---|---|
| MuleSoft Direct for Health | Packaged FHIR R4 and HL7 EHR integration into Health Cloud | Standard patient, encounter, and clinical data flows | Covers what it covers; less room to bend |
| MuleSoft Salesforce Connector | The general connector inside an Anypoint flow you design | Non-standard sources, complex transformation, multi-system orchestration | You build and maintain the flows |
| Custom API layer | Your own Apex or middleware calling EHR APIs directly | Requirements neither option meets | Full retest at every Salesforce release |
Start here. If your requirement is a bi-directional flow of patient demographics, encounters, and clinical results between a FHIR-capable EHR and Health Cloud, the packaged path is faster to stand up and cheaper to own. Salesforce maintains it.
Test it against your top ten requirements before dismissing it. Teams routinely build custom because they assumed the packaged option was thin, without checking.
Three situations justify going custom. Your source system emits HL7 v2 with custom Z-segments. You need to orchestrate across several systems in one transaction, not just move data point to point. Or the destination is not Health Cloud at all.
Outside those, custom is a choice you will pay for three times a year at release testing. Our post on Salesforce integration with MuleSoft covers the general build-versus-packaged decision in more depth.
Two of the three EHR vendors most articles name have been renamed, including the earlier version of this post. Get this right in your documentation and your tender responses.
Table 3 — EHR Vendor Naming and What Each Exposes
| You May Still Say | Current Name | What It Typically Exposes |
|---|---|---|
| Cerner | Oracle Health | FHIR R4 APIs plus HL7 v2 interfaces on older modules |
| Allscripts | Veradigm | FHIR APIs and a developer program; HL7 v2 on legacy products |
| Epic | Epic (unchanged) | FHIR R4 via its App Orchard developer program; HL7 v2 interfaces |
| MEDITECH | MEDITECH (unchanged) | FHIR APIs on newer platforms; HL7 v2 widely in use |
Carry both names internally. Someone searching "Cerner integration" in 2028 still needs to find your runbook, and RFPs will keep using the old names for years.
One practical note. What a vendor supports at platform level and what your specific licensed modules expose are different questions. Ask your EHR account team which APIs are enabled on your contract before you design against them.
A single point-to-point connection solves one problem and creates a maintenance liability. Layered MuleSoft API integration solves the same problem in a way the next project can reuse.
Three layers, each with a clear job.
One API per source system, doing nothing but exposing that system's data cleanly. It handles the HL7 parsing or the FHIR call, normalizes the output, and stops there. No business logic.
Build these once. Every later project consumes them instead of rebuilding the EHR connection.
These hold the logic. Merging a patient record from three sources. Deciding which lab result triggers a care team alert. Reconciling identifiers when the EHR and the CRM disagree about who a patient is.
Patient identity matching belongs here, and it is the hardest part of any healthcare build. Two systems, two IDs, one human being. Decide your matching rule explicitly and write it down.
The outward-facing layer. A patient portal needs a different data shape than a care coordinator's console. Experience APIs give each consumer what it needs without duplicating the work underneath.
The payoff is real. Add a fourth consumer later and you write one Experience API rather than a fourth full integration. Connector-level setup and authentication are covered step by step in our MuleSoft Salesforce connector setup guide.
Most healthcare integration projects are not optional. Regulation is driving them, and no competing article names a single rule.
Information blocking under the 21st Century Cures Act. HealthIT.gov defines information blocking as a practice by an actor that is likely to interfere with the access, exchange, or use of electronic health information, unless required by law or covered by an exception. It applies to healthcare providers, developers of certified health IT, and health information exchanges and networks. In practice it means you cannot make patient data hard to get at.
The Standardized API certification criterion. Certified health IT has to meet it, which is why FHIR-based APIs have spread so quickly across EHR platforms.
USCDI. The United States Core Data for Interoperability defines a standardized set of data classes and elements for nationwide exchange. It tells you which data elements to plan for.
CMS Interoperability and Patient Access. CMS-regulated payers must expose Patient Access APIs. If you sit on the payer side, this is your driver.
TEFCA. The Trusted Exchange Framework and Common Agreement sets the national rules of the road for exchange between networks.
The scope and enforcement of these rules keep evolving, so confirm current requirements with your compliance counsel rather than an article — including this one. What matters for scoping is the direction: US regulation is pushing clinical data toward standardized, API-accessible access, and a Salesforce MuleSoft integration is one legitimate way to meet that.
HIPAA still governs how you handle the data once it moves. Our post on Salesforce Health Cloud and HIPAA compliance maps Health Cloud against the HIPAA safeguards in detail.
Here is the part your compliance team will ask about, and the part every competitor treats as a slogan.
When a Mule flow carries a patient record, that payload is PHI. Everything the flow does with it is in scope.
Five rules keep the conversation short.
Turn off payload logging on PHI flows. Default debug logging writes the payload to the log. That log is now a PHI store you did not intend to create.
Mask identifiers in anything you do log. Log a transaction ID and a record count. Not a name, not a date of birth, not a medical record number.
Encrypt in transit and at rest. TLS on every hop. If the flow stages data to a file or queue, that staging location needs encryption too.
Use a dedicated service account with scoped access. Not a person's login. Not an account with Modify All Data because it was quicker to configure.
Keep an audit trail that names the human. When an integration writes a record, the trail shows the service account. Capture who or what triggered it in a separate field, or you cannot answer an auditor's question.
Then test the failure path. When a record fails validation, where does it go? A rejected-row file containing PHI needs the same protection as the production database. Ongoing monitoring of these flows sits with our Salesforce managed services practice, because an unwatched integration is a compliance risk as much as an operational one.
Scopes vary widely, and the differences are where projects get into trouble. MuleSoft integration services for a healthcare build should cover eight things.
Message inventory. Which standard each source system speaks, with sample messages captured.
Identity matching design. How a patient in the EHR maps to a patient in Salesforce, written down and agreed.
API layer design. System, Process, and Experience APIs specified before any are built.
Transformation build. The DataWeave work, including any custom Z-segments.
PHI handling and logging policy. The five rules above, configured and verified.
Volume testing. At real record counts, not sample data.
Error reprocessing. A path for failed records that does not depend on someone reading a log.
Runbook and handover. So your team can operate it after go-live.
Ask any provider which of those eight they treat as optional. The answer tells you a great deal. Certification-track material on MuleSoft development and architecture is available through SaaSGuru if you are building this capability internally rather than buying it.
Our Salesforce consulting services team scopes healthcare integrations against that eight-item list so nothing lands as a change request later.
Run this before clinical data flows in production. It takes a day and it catches most of what the sections above describe.
Table 4 — Healthcare Integration Pre-Go-Live Checklist
| Check | Why It Matters | What a Pass Looks Like |
|---|---|---|
| Message inventory complete | Standard determines scope and effort | Every source system documented as HL7 v2 or FHIR R4 |
| Sample messages captured | Custom Z-segments break estimates | Real message samples from each interface, not vendor docs |
| Identity matching rule agreed | Mismatches create duplicate patients | Written rule, signed off by clinical and IT |
| Direct for Health evaluated | Packaged is cheaper to own | Documented reason for any custom build |
| Payload logging disabled | Debug logs become PHI stores | No patient data in any log output |
| Identifiers masked | Logs get exported and shared | Transaction IDs only, no names or MRNs |
| Service account scoped | Over-permissioned integrations are a live risk | Only the objects and fields the flow uses |
| Encryption verified end to end | Every hop is in scope | TLS on all hops; staging locations encrypted |
| Audit trail names the trigger | Auditors ask who authorized a change | Requesting user or system captured per transaction |
| Failed-record path secured | Error files contain PHI | Rejected rows encrypted and access-controlled |
| Volume tested | Sample data hides real failures | Full expected daily volume run in a sandbox |
| Runbook handed over | Unowned integrations drift | Named owner and written operating steps |
Every row is checkable in under an hour. A failing row is cheap to fix now and expensive once clinicians depend on the data.
Broader patterns for building these flows are documented well by SFDCPanther and worth reading alongside this. For the wider Health Cloud picture, our post on Salesforce for healthcare covers the eight capability areas beyond integration.
MuleSoft Anypoint Platform sits between clinical systems and Salesforce, translating message formats and applying rules. It parses HL7 v2 or calls FHIR R4 APIs, normalizes the data, and writes it into Health Cloud. Health Cloud then presents it as a patient record a care team can work in.
It is Salesforce's packaged integration capability for healthcare, giving Health Cloud built-in FHIR R4 and HL7 support with bi-directional EHR integration. Evaluate it before scoping a custom build, because it covers standard clinical data flows without one.
Yes, and it is the first question to answer. FHIR R4 maps closer to Salesforce objects and needs lighter transformation. HL7 v2 needs segment-level parsing and acknowledgment handling. Most health systems have both, so plan for both.
No platform is compliant by itself. HIPAA compliance depends on how you configure it — logging, encryption, access scope, and audit trails. The platform gives you the controls; you have to switch them on and prove it.
Patient identity matching. Two systems hold two identifiers for the same person, and the reconciliation rule was never agreed. Decide it during design and write it down.
A FHIR-based flow into Health Cloud using packaged capability can go live in weeks. An HL7 v2 interface with custom segments, multi-system orchestration, and full compliance review runs months. The message inventory is what tells you which you are looking at.
A named person, internal or external. Salesforce ships three releases a year, EHR vendors change APIs, and service accounts drift. An unowned clinical integration is an operational and compliance risk at the same time.
Yes, and you should. Build one System API on your primary EHR, prove one workflow end to end, then reuse that layer. Commentary on staged integration approaches appears regularly on Salesforce Ben.
Healthcare integration is not harder than other integration work because the technology is exotic. It is harder because the data is regulated, the formats are old, and a failure has clinical consequences. Minuscule Technologies works as a Salesforce engineering partner, not a connector installer. We design and operate clinical data integrations with engineering discipline and DevOps-led governance — new builds, HL7-to-FHIR modernization, and untangling flows that log more than they should.
Three things shape how we deliver. Our Accelerators and Starter Packs supply pre-built components for the patterns every healthcare build needs — HL7 v2 segment mappers, FHIR resource templates, identity-matching scaffolds, and PHI-safe logging baselines. Our Agentic DevOps practice runs Mule flows, DataWeave transformations, and connector configuration through AI-assisted CI/CD, so a change to a clinical interface is a reviewable, reversible deployment rather than an edit in production. And our re-engineering work replaces point-to-point connections with reusable API layers, with total cost of ownership as the number we report against.
Book a free integration review. We will inventory which standard each of your source systems speaks, run the twelve-row checklist against your current flows, and tell you where PHI is being logged that should not be. It takes about a week, with no obligation, and the findings are yours either way. Schedule your strategic Salesforce call and start with a message inventory instead of an assumption.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
