Consider a daughter who signs up for disease information on behalf of her father. Weeks later, he enrolls in copay assistance and asks another website for updates. To the family, this is one patient’s experience. To fragmented systems, it can look like three unrelated records, and one of them belongs to a different person.
The difference matters more than it first appears. A duplicate email is an annoyance. Treating a caregiver as the patient, or carrying a permission from one program into another, damages trust that rare-disease companies spend years building. Yet patient CRM modernization is usually planned as a platform or campaign migration. The harder work is deciding who each record represents, what communication it permits, how quickly changes reach every system, and who answers for the data when it is wrong.
In 2025 I led the data integration and migration workstream of a patient CRM modernization at a rare-disease company. We connected nine integrations spanning six websites, a patient-services environment and a legacy CRM. In the first 75 days after cutover, internal reporting showed 30% less time to plan and execute patient communications and 45% less rework from changing requirements; we later presented these results at an industry conference. These are operational results; they say nothing about clinical outcomes. The four decisions behind them apply to any technology stack.
1. Identity is a decision about relationships
The visible part of a CRM migration is rebuilding messages and campaigns. We began with a data audit and a ranked inventory of campaigns instead. Before moving any journey, we had to establish whether two records described the same patient, and whether the person acting on that patient’s behalf was someone else entirely.
Record matching is a known weak spot in healthcare. In 2018, The Pew Charitable Trusts reported that as many as one in five patients may not be matched correctly to their records even within a facility they have visited before. Marketing databases differ from clinical records, but the lesson carries over: a missed match and a false match fail in different ways, and a false match can pose a more serious privacy risk.
Our team wrote the identity and reconciliation rules together with the business owners: which identifiers could support a match, which uncertain cases went to a person for review, and how a caregiver stays linked to a patient while remaining a separate record with separate permissions. Fewer records was a side effect. The goal was an accurate account of who takes part in each relationship and whose consent applies.
2. Consent has to work wherever the data goes
A disease-awareness registration, a copay enrollment and a request for product updates grant different permissions. When those choices are scattered across platforms, compliance rests on campaign builders remembering every exception.
We made consent part of the data model: purpose, channel, source, date and withdrawal status. Eligibility is checked when an audience is activated, and a marketing opt-out stays separate from the service messages a patient still needs. Access to sensitive information is governed on its own track, with procedures reviewed through our data governance process.
Standards help with half of this. The HL7 FHIR Consent resource gives healthcare a common way to record a consent decision, and its specification states plainly that enforcement is out of scope and left to access-control mechanisms. A well-recorded permission protects no one until every downstream workflow honors it. That is why we tested withdrawals, exceptions and channel-specific rules with the same care as new opt-ins.
3. Agree on meaning and timing before you integrate
One-off integrations can turn every new campaign into a new engineering project. We standardized the single path by which website registrations, program data, patient-services records and legacy history enter the engagement environment, pass through reconciliation and become available for segmentation. Standardizing the integration path reduced the need to rebuild data pipelines when campaign requirements changed. Across the migration, internal reporting showed a 45% reduction in rework associated with requirement changes.
Timing deserves the same attention. Our sources refresh four times a day, which suits scheduled outreach and falls short of real-time interoperability. An event-triggered journey can only react as fast as the data that feeds it. For every new use case, decide how fresh the data must be, how late-arriving changes are handled and which events need a different integration pattern.
My 2026 reference architecture for FHIR-enabled healthcare CRM describes six integration patterns, among them identity matching, consent enforcement, terminology normalization, bulk synchronization and event-driven subscription. The migration predates that paper and did not implement it. Looking back, the experience reinforces a distinction my research also addresses: integration patterns define how systems exchange and manage data, but organizations must still establish who owns the data, resolves conflicts and governs its use.
4. Every important signal needs an accountable owner
Web registrations, patient-services data and legacy CRM history are usually maintained by different teams. Connecting the systems does not settle what a field means, when it should change or which source wins a conflict.
We assigned owners to the critical sources and fields and brought those owners into design decisions from the start. Definitions got resolved upstream, once, so campaign teams downstream stopped reinterpreting conflicting signals. Governance became part of the architecture from the first design meeting.
Four questions before the next integration
Before approving another patient CRM integration, I would ask:
Can we tell the patient from the caregiver?Can every activation show the permission it relies on?Do we know when each signal becomes available, and is that soon enough for the message it drives?Who fixes the data when the answer is wrong?Go back to the daughter and her father. Connecting their records may make communication more efficient, but earning their trust requires something more: recognizing each person’s role, honoring their individual preferences, and ensuring those choices are reflected before communications are sent. That is the difference between connecting patient data and building a reliable patient relationship.
About Jaymin Sutarwala
Jenkins, Jaymin Sutarwala
Jaymin Sutarwala is Associate CRM Strategy & Operations Director at United Therapeutics, where he leads the CRM platforms that support commercial and medical teams. His research on healthcare CRM architecture and patient privacy appears in peer-reviewed and open-access journals.
Sources cited in the text:
The Pew Charitable Trusts, “New Report Lists Steps to Improve Patient Matching Across Electronic Health Records”, 2 October 2018.HL7 FHIR R4, Consent resource, section 6.2.3 “Background and Context”.J. H. Sutarwala, “A Reference Architecture and Integration Pattern Catalog for FHIR-Enabled Healthcare CRM Systems”, 2026, doi:10.5281/zenodo.19163604.
Bengali (Bangladesh) · 
English (United States) ·