How to Build a Doctor 360 (HCP 360) View

What data goes into a doctor 360 profile?

Seven layers: identity (who they are and how you recognise them), professional (qualification, specialty, registration), affiliation (where they practise, and when that changed), behavioural (what they have done with you across every channel), commercial (prescribing, potential, segmentation), influence (publications, trials, networks, KOL status), and governance (consent state, data source lineage, last-verified date). Most teams build identity, affiliation and behavioural, skip governance, and discover the gap during their first audit.
The field lists below are the working version, not the aspirational one. Build the first three layers properly before adding the rest — a 360 with three complete layers is useful, and one with seven half-populated layers is not.

The hard part — identity resolution without a national identifier

Every published HCP 360 methodology assumes a step that does not exist in India. Understanding why is the difference between a project that works and one that produces a confident, wrong answer.
 

What other markets have that India does not

This single row is why an HCP 360 build in India is not the same project as one in Boston, and why match rates quoted in US-authored guidance are not achievable targets here. A team benchmarking itself against a 95% deterministic match rate will conclude its data is uniquely bad. It is not — the identifier is simply absent.

What is changing, and why it should affect your design today

The National Medical Commission published a draft amendment — the Registration of Medical Practitioners and Licence to Practice Medicine (Amendment) Regulations, 2026, in August 2026 — proposing a Unique Identification (UID) Number for registered medical practitioners, issued under the National Medical Register, structured to embed the state or union territory code together with the state register number. Once assigned, a practitioner would be eligible to practise in any state without fresh registration, and disciplinary history would be centrally tracked. This is a draft proposal, not implemented law. It should not be treated as an existing identifier — but it should absolutely change how you design your identity layer this quarter.

The architectural decision this forces — and the cost of getting it wrong

If a national doctor identifier arrives in India, every HCP 360 built without a slot for it will need surgery. Retrofitting a new primary key into a live 360 — with downstream systems, historical behavioural data and campaign histories all keyed on something else — is the single most expensive avoidable rework in this category.

The design that survives either outcome costs nothing extra today:

Use a stable, meaningless internal ID as the primary key. Not the registration number, not the CRM ID, not an email. A surrogate key that never changes and carries no meaning.

Store every source identifier as an alias, not as the key. State council registration number, CRM ID, vendor ID, event system ID — all aliases against the internal key, each with its source and date.

Leave the UID slot open now. One nullable field with a source and verification date. When and if the UID lands, it becomes the strongest alias and eventually the preferred match key, and nothing above it has to change.

This is a five-minute schema decision that either costs nothing or saves a rebuild. Make it before you ingest your first source.

How to build a 360 view of doctors — the nine-step method

Written in the order the work actually has to happen. Steps two and five are where projects are won and lost.

1. Define the entity before you define the fields. Decide precisely what one record represents — a person, or a person at a place of practice. A doctor consulting at three hospitals is one person and three affiliations, not three doctors. Teams that skip this decision discover it later as a duplicate problem that is actually a modelling problem, and no amount of match tuning will fix it.
2. Design the identity model with a surrogate key and an alias table. Stable internal ID as primary key; every source identifier stored as an alias with its source and date; a nullable slot for a future national identifier. Do this before ingestion, not after.
3. Inventory every source honestly. CRM, field application, event registrations, marketing platform, WhatsApp provider, sample management, web forms, purchased datasets, medical affairs records, and the spreadsheets on regional managers' laptops. The last category is always larger than expected and is often the most current.
4. Ingest raw, then standardise — never the reverse. Land every source unaltered in a staging layer, then standardise into a common structure. Cleaning during ingestion destroys the evidence you will need when a match looks wrong six months later, and it always looks wrong eventually.
5. Standardise the fields that matter for matching, aggressively. Names into components with transliteration variants; qualifications into a controlled vocabulary; specialties into a fixed taxonomy; mobile numbers into E.164; addresses into components with PIN; institutions into a canonical list. Matching quality is decided here, not in the algorithm.
6. Resolve identity in two passes — deterministic first, probabilistic second. High-confidence exact matches on strong keys, then scored fuzzy matching on the remainder. Never one pass. The detail is in the next section.
7. Apply survivorship rules to build the golden record. For every field, an explicit rule for which source wins and why. Written down, versioned, and reviewable — not embedded in a transformation script nobody can read.
8. Publish the record with provenance attached. Every field carries its source, its verification date and a confidence indicator. A 360 that cannot explain itself will not be trusted by the brand teams it was built for, and untrusted data does not get used.
9. Instrument it and set a refresh cadence. Match rate, false-merge rate, coverage and freshness measured monthly. Affiliation is the fastest-decaying layer and needs the shortest cycle.
   
   The step teams skip and always regret
10. Step four — ingest raw before you standardise.
11. The temptation is to clean at the door, because staging raw data feels like storing garbage. Six months later a brand manager insists a doctor has been merged with the wrong person. If you cleaned on ingestion, you cannot reconstruct what the source actually said, so you cannot tell whether the merge was wrong or the source was.
12. Raw staging is cheap. Unreconstructable history is not.

Match logic that works on Indian doctor data

The section that most guidance omits, written concretely enough to hand to an engineer.

Pass one — deterministic matching on strong keys

Exact matches on keys strong enough that agreement means identity. Run these first, accept them without scoring, and remove matched records from the probabilistic pass.

Pass two — probabilistic matching on the remainder

Everything unmatched goes to scored comparison. Three design decisions determine whether this works.

• Blocking keys, to make the problem computable. Comparing every record against every other is quadratic and unnecessary. Block on something cheap and reliable — first letter of surname plus city, or PIN plus specialty — and compare only within blocks. Use two or three different blocking schemes and union the results, so a record mis-keyed on one scheme still gets a chance on another.
• Field-level comparison with weights that reflect Indian data. Name similarity carries less weight here than in markets with stable spelling, because transliteration variance is genuine rather than erroneous — the same doctor legitimately appears with several spellings across sources. Registration number similarity carries more. Address similarity should be scored on components, since the same clinic is written five ways.
• Two thresholds, not one. Above the upper threshold, auto-merge. Below the lower, auto-reject. Between them, queue for human review — and staff that queue. Teams that set a single threshold either merge distinct doctors or leave obvious duplicates unmerged, and the first failure is far more damaging and far harder to detect.

The transliteration problem, specifically

Indian doctor names arrive in multiple romanisations across sources — the same person as Krishnan and Krishnann, Mohammad and Mohammed, Chatterjee and Chattopadhyay, with initials expanded in some sources and abbreviated in others, and given-name and surname order inverted between systems. Southern Indian naming conventions frequently place an initial before the given name in one source and after it in another.

Generic string-distance functions handle none of this well. What works is a preprocessing layer that generates name variants rather than a single canonical form — phonetic encodings tuned for Indian names, an expansion and contraction pass on initials, and an order-invariant comparison for given name and surname. Score against the best-matching variant rather than against one normalised string.

This is also why buying a verified doctor universe often outperforms building one. The variant handling is a specialised problem, and a provider who has solved it across a national universe has amortised work that is genuinely expensive to repeat. We set out how to evaluate that in doctor data validation for pharma.

Survivorship — deciding which source wins

Once records are resolved, conflicting values must be reconciled into one. This is where a 360 either becomes authoritative or becomes an average of everyone's mistakes.

The failure mode to avoid is a single global rule — "CRM always wins" or "most recent wins". Neither is true field by field. The rep who visited last week knows the current institution better than any vendor file; the vendor file knows the registration number better than a rep transcribing it into a phone.

How to know whether it worked

Four measures, reported separately. Collapsing them into one number is how a broken 360 passes review.

The relationship between the first two is the one to internalise. A 95% match rate with an 8% false-merge rate is materially worse than an 80% match rate with none — the unmatched records are a visible gap you can work on, while wrongly merged records are invisible corruption that propagates into targeting, territory alignment and incentive compensation. One under-delivers. The other actively misleads, and does so with total confidence.

Sample and hand-check merged clusters every month. It is dull work and it is the only way this failure is ever caught.

Consent state is a field, not a separate system

A short section on a decision that has become architectural rather than optional.

The common pattern is a consent platform beside the 360, with campaign tools querying it separately. It looks clean and it fails under pressure, because it makes permission a lookup that a system can skip. Every skipped lookup is a compliance event.

The alternative is to hold consent state on the doctor record itself, per channel and per purpose, with source and timestamp — layer seven above. Then a campaign selecting an audience from the 360 cannot select a doctor whose state does not permit that purpose on that channel, because the ineligible records are not returned. The restriction is enforced by the query, not by a person remembering.

The practical consequence for this build is that your 360 becomes the enforcement point, which raises the bar on the resolution step. If two records for the same doctor fail to merge and one carries a withdrawal, the unmerged twin remains contactable. An identity resolution failure becomes a consent failure. That is a strong argument for the human review queue described earlier, and for the monthly false-merge sampling.

We covered the obligations themselves in why pharma CRMs fail at consent tracking and the cascade requirement in consent withdrawal under DPDP.

Build it or buy the universe underneath it?

The honest framing is that this is not one decision. Almost nobody should build all of it, and almost nobody should buy all of it.

The pattern that works most often: buy the universe and the resolution capability, build the layers that are genuinely yours, and spend the saved time on adoption. The most common reason an HCP 360 fails is not that it was built badly — it is that it was built correctly and nobody used it, because querying it required a data analyst and brand teams have deadlines.

Seven ways this goes wrong

Failure modes, in roughly the order they appear.

1. Modelling the entity wrong at the start. Deciding late that a doctor at three hospitals is three records. Everything downstream inherits the error, and no matching improvement fixes a modelling mistake.
2. Cleaning on ingestion. Destroys the evidence needed to adjudicate disputed merges later. Always land raw first.
3. One match threshold instead of two. Guarantees either false merges or unmerged duplicates, and false merges are the expensive half.
4. Never measuring false merges. The system will not tell you. Sampling is the only detection method, and teams that skip it discover the problem through a brand manager's complaint about a specific doctor — by which point the corruption has propagated for months.
5. Global survivorship rules. "CRM always wins" is wrong for registration numbers; "most recent wins" is wrong for consent. Rules belong at field level.
6. Treating governance metadata as optional. Source lineage, verification dates and consent state added later cost several times what they cost built in, and some of it cannot be reconstructed at all.
7. Building for analysts instead of brand teams. If using the 360 requires SQL, it will be used by three people. Adoption is the deliverable, not the data model.
   
   The failure that dwarfs the others
8. False merges, undetected.
9. Every other item on this list produces a visible problem — a gap, a delay, an argument. This one produces a confident wrong answer that flows into targeting lists, territory alignment, call planning and incentive compensation, and it looks exactly like correct data until somebody notices that a cardiologist in Pune appears to have attended an event in Kochi.
10. By then it has been in the numbers for two quarters. Sample your merged clusters every month. It is the least interesting recurring task in this build and the one with the highest expected value.

Reference architecture — how the pieces fit together

Five zones. The discipline that matters is that each zone has exactly one job and never reaches backwards, because the moment a downstream zone starts patching upstream data, you lose the ability to reason about where anything came from.

Two design consequences follow from this shape, and both are worth defending in a design review.

• The golden record is derived, never edited. When someone finds an error, the correction goes into a source or into the survivorship rules — never into the golden layer directly. A hand-edited golden record is unreproducible, and the next rebuild silently reverts it, which is how teams lose faith in the whole system.
• The serving layer is where consent is enforced, not where it is displayed. If a user can build an audience and then see a warning about consent, the warning will be ignored under deadline. If ineligible records are simply not returned by the query, there is nothing to ignore.

Making brand teams actually use it

Worth its own section, because a technically excellent 360 that nobody queries has produced nothing — and this is the most common way these programmes quietly fail after a successful launch.

The pattern is recognisable. The data team delivers on time, the architecture is sound, the match rates are respectable. Six months later usage is three analysts, brand teams are still requesting lists by email, and the programme is reviewed as a partial success that will not be extended. Nothing was built badly. The deliverable was simply defined as a data asset when it needed to be defined as a product.

Four things that change adoption

1. Ship a segment builder, not a schema. A brand manager needs to answer "cardiologists in tier-two Maharashtra cities who attended an event in the last six months and have WhatsApp consent" without writing a query. If that takes SQL, they will email an analyst instead, and the 360 becomes an analyst tool rather than a commercial one.
2. Show provenance in the interface, not just in the schema. When a brand manager sees a doctor's institution, they should be able to see where it came from and when it was verified. Visible provenance is what converts scepticism into trust — and scepticism is the default, because everyone has been burned by a bad list before.
3. Make the feedback loop one click. A rep who knows a doctor has moved should be able to flag it from wherever they are looking, and that flag should enter the resolution process as a source rather than an email to the data team. The field force is your highest-frequency verification signal and it is almost always wasted.
4. Publish a coverage and freshness page and keep it current. Which specialties, which cities, how many records, verified when. Teams trust a system that tells them where it is weak far more than one that presents everything with equal confidence — and they stop asking the data team the same three questions every month.
   
   The adoption metric worth reporting to leadership
5. Not the match rate. The share of campaigns and target lists in the last quarter that were built from the 360 rather than from a spreadsheet.
6. That number is uncomfortable at first and it is the only one that measures whether the investment changed anything. A 360 with an 88% match rate and 20% campaign adoption is a worse outcome than one at 78% and 90% adoption — the first is a data asset, the second is an operating change.
7. Report it monthly from launch. What gets measured here is what gets used.

What good looks like at 90, 180 and 365 days

A realistic delivery shape for a team starting from scattered sources. It is deliberately unambitious in the first quarter, because the alternative is a broad shallow build that nobody trusts.

The most common planning error is inverting the first two rows — ingesting every source in the first quarter to demonstrate breadth, then spending the second fixing resolution problems created by sources that should have waited. Depth on a narrow universe first, breadth second. A brand team that trusts one therapy area completely will advocate for the programme far more effectively than one given national coverage it does not believe.

Frequently Asked Questions For How to Build a Doctor 360 (HCP 360) View