CRM Data Model for Doctors, Practices and Organisations

One doctor may work in two practices, and a group of practices may belong to one organisation, so a flat contact list does not fit. I designed a multi-level CRM data model for healthcare partners that runs from the individual doctor up to the practice and its parent organisation. What follows is how such a model is structured and which mistakes to avoid.

Why a flat contact list breaks

Sales wants to see the organisation, email wants the person, and the call centre wants whoever is on the phone. In a flat list the same doctor appears two or three times, and nobody knows who owns the relationship.

The levels

A common structure has three levels.

Person: the individual healthcare professional.
Practice: the site where the person works.
Parent organisation: the owner of one or more practices.

A person can work in several practices, and a practice has several people, so link people and practices in both directions. Each practice belongs to one parent organisation. Give every relationship an internal owner and a status such as prospect, active partner or inactive.

An example

This is an illustration, not a real record. Doctor A works in practices X and Y. Practice X belongs to a group of clinics, practice Y is independent and has an organisation record of its own. In the CRM, doctor A is one person record linked to both practices. An email goes to doctor A once, on the basis of that person’s consent. A report for the clinic group includes practice X and leaves out practice Y.

Fields that earn their place

Role and specialty, picked from a fixed list instead of typed as free text.
Languages and region.
Consent for each channel, with a date and a source.
Last contact and the channel used.
Relationship status and internal owner.

Add a field only when a segment, a report or a call script uses it.

Where the data comes from

Record the source of each field: the person’s own form, a call-centre note, an import or a public register. Agree in advance which source wins when two of them disagree.

Record the legal basis and the source of every consent, and keep marketing consent apart from messages that are needed to run the service. An opt-out has to reach every system that sends or calls: the CRM, the email tool and the call centre. An API link between the CRM and the email tool does this without manual exports. I delivered such a link between Mailchimp and the CRM together with the CRM supplier, and email campaigns now run on CRM segments.

Access follows the same levels

If the data model feeds a platform with zones for doctors and partners, the access rules should follow the same levels: a person sees their own details and materials, and a practice sees what belongs to the practice.

What the model gives you

Email segments by role, specialty and region.
Call-centre prompts that show the person, the practice and the last contact.
Reports by practice and by organisation as well as by contact.
Fewer duplicates, and a record that survives when a doctor moves to another practice.

Mistakes to avoid

Free-text specialties, which make segments unusable.
Importing lists without matching them to existing records.
Consent without a source or a date.
No owner for a practice or an organisation.

In pharma terms, the same structure is described with healthcare professionals (HCPs), healthcare organisations (HCOs) and the affiliations between them. The logic of the model is the same.