Customer Data Platform Software for Healthcare in 2026: Why the Shortlist Depends on What You Can Activate

This piece is for the people who sign for patient data in a US healthcare organization: marketing and digital directors at provider groups and health systems, heads of patient experience, CRM and MarTech leads, and the compliance officer who will read the contract after you do. You get the criteria this category actually splits on, a card for each option with the same fields, the integration questions to ask before signing, and the part most shortlists skip, which is what happens to the segment once it exists.

The options spread across the map rather than clustering, which is why one ordered list cannot answer this question for every organization.

Why does a general CDP shortlist fall apart in healthcare?

Because the criteria that separate CDPs in retail stop separating anything once protected health information enters the picture.

Every platform in this category does identity resolution, real time profiles, behavioral segmentation and audience export. Those are properties of the category, not of a vendor. A comparison built on them returns eight platforms that look identical, and the buyer picks on price or on whoever answered the phone first.

What actually changes the answer is three questions that a general shortlist never asks. Will this vendor sign a business associate agreement, and does that agreement cover the specific product you are buying rather than the parent company’s cloud. Can it read the systems where your patient data already lives without a twelve month integration project. And once you have built the segment, what is it allowed to send, and through which channel.

Most of the pages ranking CDPs for healthcare today answer the first question with a logo and skip the other two entirely. If you want the general version of the category first, we wrote it separately: the types of CDP and how they differ covers packaged, composable and unified engagement platforms without the sector lens.

What does a CDP actually have to resolve in a healthcare organization?

One thing, and it has nothing to do with marketing: the same human being exists five times in your systems and none of those records know about each other.

There is a patient record in the EHR. A member record if you also run a plan. A caregiver who books on someone else’s behalf and whose phone number is the one that answers. A digital health app user with a device identifier and no name attached. And a marketing contact from a form filled in three years ago with a typo in the email.

A CDP in healthcare earns its keep when those five collapse into one profile, and when the platform knows which of the five identities a given message is allowed to speak to. That is different from retail, where the worst case of a bad merge is a wrong product recommendation.

The unglamorous half of that work is data quality, and it is where most projects lose their first six months. Phone numbers arrive from the CRM with country codes missing, with extensions glued on, with characters no dialer accepts, and every one of those creates a duplicate that is far more expensive to unpick later than to prevent now. It is worth noticing which vendors name this problem at all: indigitall’s own CDP page lists unresolved customer identities and poor CRM data quality as two of the four problems the product exists to solve, which is at least an admission that the work is real.

The merge is only half the work. The profile is only useful when it also records which identity a message is allowed to address.

Where is the line between unified data and activatable PHI?

This is the question that decides your architecture, and it is not the same as “is this vendor HIPAA compliant”.

Unifying data and activating it are two different permissions. A platform can lawfully hold a profile that includes clinical detail and still be the wrong place to trigger a message from, because the sending channel cannot carry that detail. Teams discover this in reverse order, usually in week six, after the segments are built.

The regulatory ground here also moved recently, and most vendor pages have not caught up. In December 2022 the Office for Civil Rights published guidance on online tracking technologies that treated a wide range of website analytics as regulated. On 20 June 2024 the US District Court for the Northern District of Texas vacated part of it. The HHS guidance page, last reviewed on 26 June 2024, now states that the Court vacated the guidance to the extent it provides that HIPAA obligations are triggered in circumstances where an online technology connects an individual’s IP address with a visit to an unauthenticated public webpage addressing specific health conditions or healthcare providers. OCR later withdrew its appeal.

That does not make web tracking on health pages a solved problem, and your own counsel will have a view. What it does mean is that a vendor still selling you a product on the strength of that specific 2022 interpretation is selling you a position that a federal court has partly struck down. Ask what their guidance is dated.

Holding the data and being allowed to send it are two separate permissions, and the second one is narrower.

Six criteria, declared before the list so the selection reads as a method rather than an opinion. Each one is something you can verify yourself from public documentation or from a contract, not something we scored.

1. Business associate agreement, and its scope. Whether the vendor signs one, and whether it covers the specific product rather than the wider cloud.
2. Where the data sits. In your warehouse, in the vendor’s platform, or split between both.
3. What it reads without a project. EHR, EMR, CRM, portal, app, scheduling, warehouse, and whether those are native connectors or integration work.
4. Identity resolution. How duplicates are collapsed, and what happens when the signal is a caregiver’s phone rather than the patient’s.
5. Activation. What the platform can send by itself, versus what it has to hand to another system to send.
6. Documented limits. Whether the vendor publishes what its product does not cover. This one is rarer than it should be, and it is the most useful.

The order is declared, and it is not a score. The entries run by how much of the path from patient data to sent message each platform covers by itself, without depending on another vendor. First, the option that owns the profile and the regulated channels without requiring you to already run its estate. Then the ones that own both, but only inside an estate you already have. Then the ones that own the data and hand the sending to somebody else. Within each group, alphabetical.

You can reproduce that ordering yourself from the seven public product pages, which is the point of declaring it. Be clear about what it is, though: it is a model of operating dependency, not proof that any given channel may carry protected health information under your agreement. No public page settles that, and the contractual check stays a prerequisite for all seven regardless of which group a platform sits in.

And the order says nothing about quality. For a health system with a mature warehouse, the third group is the correct answer and the position does not change that. What the order does is put the question this piece is about, what happens after the segment exists, in front of the question every other shortlist leads with.

One honest note on coverage. This covers the operating models most often seen in US healthcare programs. It does not claim to list every vendor in the category, and a selection by fit never can.

Key takeaways

• Every option here unifies profiles and resolves identity. That is the category, not the differentiator, so do not buy on it.
• A signed business associate agreement is necessary and not sufficient. Ask which product it covers, in writing.
• The integration question decides more than the feature question. Ask what it reads on day one, not what it could read.
• Activation is where healthcare shortlists break. A segment you cannot legally message is a report.
• The 2022 tracking guidance everyone quotes was partly vacated in June 2024. Check the date on any compliance claim built on it.
• Budget the identity and data quality work before the campaign work. Malformed phone numbers create duplicates that cost more to unpick than to prevent.

How do the options compare?

Read the row that matches the estate you already run, not the row with the most ticks. The last column is the one to take into the call.

The uncomfortable column is the last one, and it is the one every vendor page leaves out.

indigitall

The option for organizations whose real problem is the message, not the database.

The page commits to a single business associate agreement covering every channel, which is the claim to take into the contract conversation. Captured 18 September 2026.

Best for: healthcare providers and clinic groups that want a unified patient profile whose purpose is the next outbound message, on channels that can carry health information in the United States.

What it does well: it connects the profile to the journey and to the channels in one platform, so the segment you build is the segment that sends. Its published documentation sets out a customer identification method that assigns your own customer id to a device or session, which is the mechanism that ties an anonymous visitor to a known record. Its CDP page also documents native modules that synchronize with a CRM or an ERP, which matters because that synchronization is where most of the duplicate records come from.

The journey layer is what the rest of this category hands to somebody else, and it is worth understanding as a mechanism rather than as a promise. Its journey documentation describes entering people by event, an abandoned cart or a purchase being the examples it gives, and branching the path with decision splits based on whether the person interacted with the previous message. That is the building block. What you do with it is design the ladder yourself: start on the cheapest channel that can legally carry the message, let the patient leave the journey the moment they complete the goal, and let the expensive step fire only down the branch of people who did not respond. The platform does not decide that for you. What it gives you is somewhere to express it without reaching for a second vendor.

When the automation cannot finish a conversation, it hands to a person without switching tools, with the history and the profile traveling with the conversation.

There is published evidence for the model in healthcare, and it is worth reading for what it does and does not claim. A provider serving over 7 million patients a year reports 40% less call center volume, 15% fewer missed appointments and 85% patient satisfaction after deploying AI chatbots for patient communication. Those figures are for conversational engagement, not for a CDP migration.

Key features: unified patient profile with documented customer identification, native CRM and ERP synchronization modules, encrypted push, email, secure portal, AI voice calls in English and Spanish, AI agents with handoff to a human, HIPAA under signed business associate agreement, SOC 2 and ISO 27001, patient data hosted in the United States.

Worth knowing: no integration with a named EHR or EMR is published. If your requirement is a certified connector into a specific clinical system rather than API level integration, ask for that in writing before you plan a timeline. Its published security documentation is the right place to start that conversation.

Pricing: not published. Demo and contract, no self-service sign-up.

Not a fit if: what you need is a warehouse, a modeling layer or a place to run analytics. This is built so the profile can send, and if nothing is going to send, a data platform costs less and does the job.

The headline is the whole argument for this entry: the profile exists so the next message can be sent, not so the data can sit somewhere. Captured 18 September 2026.

What its users say. Two reviews speak to what this entry claims and to what it costs. The first is from a reviewer whose own headline names both halves of the trade:

“The interface is quite intuitive and allows us to launch campaigns quickly without constantly relying on technical support. We also greatly value the advanced segmentation, as it helps us target campaigns to specific users based on their behavior, which clearly improves results.”

A verified reviewer on G2, in a review titled “comfortable integration for web and app, but a noticeable initial learning curve”. The segmentation is the value and the ramp is the price, and both belong in your plan.

A second one points at reporting rather than sending, which is the gap worth budgeting for:

“I believe you can improve the visuals and give me more information on how the campaigns are going, especially regarding metrics.”

Nicolas M., on G2. If measurement matters to your business case, assume you will do some of that reporting outside the platform, at least at first.

The enterprise marketing platform, approached from a data estate you may already own.

Best for: large healthcare marketing organizations already running Adobe Experience Platform, where adding patient data to the existing profile is cheaper than standing up a second system.

What it does well: it keeps audience building, governance and campaign execution in one environment, which matters when the people running patient acquisition are the same people running everything else. Adobe publishes a healthcare specific add-on, Healthcare Shield, aimed at customers who need to handle protected health information inside Real-Time CDP.

Key features: real time profile, data governance and labeling, audience segmentation, connections to Adobe and third party destinations, Healthcare Shield as an add-on for regulated data.

Worth knowing: Healthcare Shield is an add-on with its own product terms, not a setting. Confirm which components of your Adobe estate it covers and what it changes about your existing implementation, because the answer is rarely “nothing”.

Pricing: not published. Enterprise agreement.

Not a fit if: you are not already on Adobe. The value here compounds with an existing estate and is hard to justify without one.

Governance leads the page rather than segmentation, which tells you which half of the problem this product is built around. Captured 18 September 2026.

Microsoft Customer Insights

The option for estates that are already Microsoft, end to end.

Best for: healthcare organizations running Dynamics 365 and the wider Microsoft cloud, where the CDP is one more component rather than a new vendor relationship.

What it does well: it sits inside an estate your IT organization already administers, which means identity, access and vendor management are questions you have answered before rather than questions you open from scratch. Whether that shortens your own security review is worth asking your IT team rather than the vendor, because the answer depends on how your agreements are actually written. Microsoft publishes a healthcare industry layer, Microsoft Cloud for Healthcare, that sits alongside its data and engagement products.

Key features: unified customer profiles, segmentation and measures, connections to Dynamics 365 and the Microsoft data estate, healthcare industry solutions available separately.

Worth knowing: confirm whether your use case is served by Customer Insights alone or needs the healthcare industry layer as well, because those are different products with different commercial terms.

Pricing: published list pricing for the base product, enterprise agreements in practice.

Not a fit if: your marketing and patient engagement stack is not Microsoft. The argument for this one is estate coherence, and without the estate the argument goes away.

The healthcare capability lives in documentation as a separate industry layer, which is exactly the scoping question to raise in the first call. Captured 18 September 2026.

Salesforce Data Cloud

The option for health systems whose clinical and service records already live in Salesforce.

Best for: organizations running Health Cloud, where the patient profile and the service record benefit from being in one estate.

What it does well: it puts the unified profile next to the clinical and service data model your teams already work in, so the profile and the record are not two copies in two systems. How much implementation time that actually saves depends on how much of your patient data is already in Salesforce today, which is the number to establish before anyone quotes you a timeline. Salesforce maintains a public compliance site documenting which of its products are covered for HIPAA regulated use.

Key features: unified profiles across Salesforce clouds, segmentation, activation into Marketing Cloud and connected destinations, Health Cloud data model, published compliance documentation.

Worth knowing: this is the one where scope of the business associate agreement matters most, because the estate is large and not every cloud and every feature is covered. Get the covered product list in writing and check it against what you actually plan to use.

Pricing: not published. Enterprise agreement.

Not a fit if: you are not on Salesforce. Adopting the estate to get the CDP is a much larger decision than the one you started with.

The page is a product by product list with dates on it, which is the reason to read it rather than accept a single yes. Captured 18 September 2026.

Hightouch

The composable option, for organizations whose data already sits where it should.

Best for: healthcare data teams with patient data modeled in a cloud warehouse, who want activation without copying that data into another vendor’s platform.

What it does well: two things, and they are worth separating because they are supported by two different statements on its own healthcare page. The first is architectural: Hightouch states that it “never stores any of your data” and “operates directly in your data warehouse”. The second is the regulated fit: it presents itself as “a HIPAA-compliant agentic marketing platform for healthcare” and describes activating patient and member data “without PHI ever leaving your infrastructure”. For a compliance officer, that second sentence is a materially easier conversation than “we copy it to a second vendor”.

Key features: warehouse native audiences, reverse ETL syncs to downstream tools, data contracts for approved and standardized fields, governance of access and usage rules across teams, published security documentation.

Worth knowing: the compliance question does not disappear, it moves. Once an audience syncs to a downstream tool, that tool now holds the data and needs its own agreement. Map the destinations before you map the sources.

Pricing: not published for regulated deployments.

Not a fit if: you do not have a warehouse, or you do not have a data team to model patient data in it. This assumes both.

The diagram is the operating model in one picture: the data stays put and only the audience travels. Captured 18 September 2026.

Tealium

The data and governance option, where collection comes before campaigns.

Best for: healthcare data and analytics teams whose first problem is controlling what gets collected and where it goes, before anyone builds an audience.

What it does well: it sits early in the stack, at collection, which is the right place to enforce rules about what leaves your properties in the first place. Tealium publishes a healthcare industry position and has announced HIPAA related milestones for its customer data platform, alongside a private cloud deployment option.

Key features: tag and data collection management, real time profiles and audiences, consent and governance controls, connectors to downstream tools, private cloud deployment option.

Worth knowing: ask early whether the private cloud option is required for your use case, because it changes both the architecture and the number.

Pricing: not published.

Not a fit if: what you need is the outbound patient journey. This feeds the tools that send, it is not the tool that sends.

The page puts the HIPAA compliance link next to the demo button, which is a fair signal of which question its buyers ask first. Captured 18 September 2026.

The packaged enterprise CDP, with a published HIPAA position and a new name.

Best for: large organizations that want a packaged platform to hold and model patient data centrally, with activation into whatever they already use to send.

What it does well: it is explicit in public about what its healthcare position is and is not. Its own healthcare page describes “governed, HIPAA-aligned profiles that unify PII and PHI from every source”, states that the company undergoes annual external audits covering PHI and ePHI, and says plainly that the product is a cloud, multi-tenant solution running on AWS. Read that last sentence carefully if your security review has a view on multi-tenancy.

Key features: unified profiles combining personally identifiable and protected health information, data ingestion and modeling, segmentation, connected destinations, published HIPAA documentation and annual external audits.

Worth knowing: two things. The company now trades as Treasure AI, so if procurement pulls documentation under the old name, check you are reading the current version. And the wording on its own page is “HIPAA-aligned”, not “HIPAA certified”, which is the honest formulation and also the one to take to your counsel.

Pricing: not published.

Not a fit if: your organization is small enough that an enterprise data platform is more governance than you need.

The Treasure AI name sits in the top left of its own page, which is the quickest way to confirm you are reading current documentation rather than an archived Treasure Data page. Captured 18 September 2026.

Which systems does it actually have to read?

Ask every vendor to walk you through all seven, and ask which are native connectors today rather than roadmap.

1. The EHR or EMR. The system of record for clinical data. Ask for a named integration and a named customer, not an API reference.
2. The scheduling system. Where appointments, cancellations and no-shows live. This is where most of the value in patient engagement sits.
3. The CRM. Where marketing and service contacts live, usually with the worst data quality of the three.
4. The patient portal and the app. Authenticated surfaces, where behavioral signal is richest and where consent is cleanest.
5. The warehouse. Whether the platform reads from it, writes to it, or ignores it.
6. Consent and preference storage. Per channel, not per person. Consent for SMS is not consent for anything else.
7. Analytics. Where you will prove the thing worked, and where you will discover the numbers do not reconcile.

The reason this list is long is that most of it is integration work, and integration work is the part of the plan that slips. The segment building is the fast part.

The clinical systems group is the longest stretch and the one campaign calendars consistently underestimate.

Which channels can carry health information in the United States?

This is the part that turns a good shortlist into a working program, and it is not a CDP feature at all, but a constraint the CDP has to respect.

Under a signed business associate agreement, the channels that can carry protected health information in the United States are narrower than the channel list on any vendor’s homepage. Encrypted push, a secure patient portal, email under agreement and voice under agreement are the usual set.

Two popular channels sit outside it, and the reason is contractual rather than technical. Google states it plainly in its own data security documentation for RCS for Business: “No, RBM is not compliant with HIPAA”, and the channel “supports healthcare-related use cases, provided that Protected Health Information (PHI) is excluded from such messages”. Meta, for its part, does not sign a business associate agreement for WhatsApp.

Both remain useful for non-clinical communication, appointment logistics without clinical detail being the obvious case, and neither belongs in a clinical journey in the United States. If a vendor puts either in a clinical use case on a slide, that is the moment to ask for the agreement in writing.

Which option fits which kind of organization?

• A provider or clinic group whose real problem is patient communication. indigitall, with the clinical system integration path confirmed in writing.
• A marketing organization already standing on Adobe. Adobe Real-Time CDP with Healthcare Shield, scoped in writing.
• An organization whose estate is Microsoft end to end. Microsoft Customer Insights, with the healthcare layer scoped separately.
• A provider group already running Health Cloud. Salesforce Data Cloud, with the covered product list checked line by line.
• A health system with a mature data team and a cloud warehouse. Hightouch, and spend the saved effort on mapping the destinations.
• A data and analytics function whose first problem is collection and governance. Tealium.
• A large enterprise that wants a packaged platform and published HIPAA documentation. Treasure AI, reading the current pages rather than the archived ones.
• An organization that only wants to store and analyze, with no messaging plan. None of these. A warehouse and a modeling layer cost less and do the job.

You do not need to migrate patient data to find out whether a platform works. A bounded pilot answers the question in weeks and survives a security review.

Pick one journey with a measurable outcome, appointment reminders being the obvious one. Define the minimum field set that journey needs and refuse anything beyond it, which is usually an identifier, a phone or device token, an appointment time and a location. Write down the purpose of use and hold the vendor to it. Require audit logging you can read yourself, not a report they produce. Set success criteria and a date before you start. And define the exit: what gets deleted, on what timeline, and who confirms it.

The pilot that fails this test is the one where the field set grows quietly because someone wanted a nicer segment.

When should you not buy a CDP at all?

Five cases, and they are more common than the category admits.

When the problem is data quality. If your records are wrong, a CDP will unify wrong records faster. Fix the source first, or at minimum understand that the cleaning work is the project.

When you need one integration, not a platform. If the actual requirement is “get appointment data into the reminder tool”, that is an integration. Buying a platform to solve it means operating a platform forever.

When the warehouse already does it. If patient data is modeled, governed and queryable in the warehouse and the only gap is getting audiences out, the composable route is smaller and cheaper than a packaged CDP.

When there is no repeatable activation case. A unified profile with nothing to send is a reporting project with a larger license. Write down the three journeys you will run in year one. If you cannot, the timing is wrong, not the vendor.

When nobody has agreed who operates it. This is the quietest of the five and the one that stalls projects after go-live rather than before it. A CDP sits between the team that holds the data and the team that wants the segment, and in a healthcare organization those are rarely the same team with the same access. Settle in writing who administers it, who approves a new field, and who answers when an auditor asks where a segment came from. That last question reaches further than it looks, because HHS requires the business associate agreement to apply the same restrictions to subcontractors, so every downstream tool the platform feeds belongs in the same answer.

So which one should you shortlist?

Answer three questions in this order and the list collapses on its own.

What do you already run? Adobe, Salesforce, Microsoft or a warehouse. That removes four of the seven before you take a single call.

Where does the protected data have to live? If the answer is “not in another vendor”, you are looking at the composable route. If the estate already holds it, you are looking at the platform that holds it.

What is going to send? If nothing, you do not need a CDP yet. If something, check that the segment can reach it without a second integration project, and that the channel it reaches on is one that may carry the data.

And ask for the security documentation while you are at it. SOC 2 Type II and ISO 27001 are the two that come up, and vendors that hold them usually publish them.

If what you need first is the general shape of the category rather than the healthcare shortlist, the benefits and mechanics of a CDP covers that ground without the sector constraints. And if the gap you are really trying to close is outbound patient communication rather than data architecture, start from the channels and work backwards.

FAQs: customer data platform software for healthcare

What is the best customer data platform for healthcare in 2026?

There is not one, and that is the honest answer rather than an evasive one. The category splits by where your data already lives and by what you need to send. Health systems on a warehouse land on composable tools, organizations standing on Adobe, Salesforce or Microsoft land on the platform they already run, and providers whose real problem is patient communication land on a platform built to activate rather than to store. Decide which of those describes you before you compare features.

Is a business associate agreement enough to make a CDP HIPAA compliant?

No. A signed agreement is necessary and not sufficient. It has to cover the specific product and configuration you are buying, which is not always the whole estate, and compliance also depends on what you do with the data afterwards. Ask for the covered product list in writing and check it against your actual plan.

Who should own a customer data platform inside a healthcare organization?

Whoever can answer an audit question about it without asking somebody else. Marketing usually asks for the platform and the data team usually ends up operating it, and the implementations that stall after go-live are the ones where that was never settled in writing. Name three people before you sign: the administrator, the person who approves a new field, and the person who can trace a segment back to its source. That third role is the one that matters when the business associate agreement is tested, because HHS requires the contract to apply the same restrictions to subcontractors, which puts every downstream tool the platform feeds inside the same answer.

Can a customer data platform read data directly from an EHR?

Sometimes, and the honest answer per vendor varies more than the marketing suggests. Some ship named connectors to specific clinical systems, others integrate at API level and expect your team or an implementation partner to build it. Ask for a named integration with a named reference customer, because “we integrate with any system via API” is a description of effort, not of a connector.

Does HIPAA still apply to website tracking on healthcare pages?

The position changed in 2024 and the answer is narrower than it was. On 20 June 2024 a federal court vacated part of the Office for Civil Rights guidance on online tracking technologies, specifically the part treating an IP address combined with a visit to an unauthenticated public page about a health condition as triggering HIPAA obligations. OCR later withdrew its appeal. Authenticated pages and actual protected health information are a different matter, and your counsel should have the final word.

Can I send appointment reminders over WhatsApp or RCS in the United States?

Not with clinical detail. Google’s RCS Business Messaging terms prohibit protected health information on RCS, and Meta does not sign a business associate agreement for WhatsApp. Both are usable for non-clinical communication. For anything containing health information, the usual channels are encrypted push, a secure portal, email under agreement and voice under agreement.

How long does a healthcare CDP implementation take?

Longer than the demo suggests, and the critical path is integration and review rather than segmentation. The clinical system connection and the security review are the two stretches that move, and both depend on work outside the vendor’s control. A bounded pilot on one journey is the fastest way to get a real number for your own organization.

Do we need a CDP if we already have a data warehouse?

Often not in the packaged sense. If patient data is already modeled and governed in the warehouse, the remaining gap is usually activation, and a composable tool that syncs audiences out is smaller and cheaper than a second platform holding a second copy. The question to settle first is which downstream tools will end up holding the data, because each one needs its own agreement.

What does a customer data platform for healthcare cost?

Almost none of them publish a price for regulated deployments. What you can compare is the cost structure: the base platform, the healthcare or regulated add-on where one exists, any private or dedicated hosting requirement, implementation and integration work, and the internal data quality effort nobody quotes. Ask for those five lines in writing and quotes that are otherwise incomparable become comparable.

About the Authors