Provider contact data fields: definitions and how recruiters use each field

By Ben Argeband, Founder & CEO of Heartbeat.ai — Keep it factual and conservative.

Ops teams lose weeks when “accuracy” debates happen without shared field semantics. This hub is a data dictionary for provider contact data fields: plain-English definitions, how recruiters use each field, and the QA measurements that keep outreach workflows stable.

What’s on this page:

Who this is for

Buyers and ops teams who need to understand what fields mean. If you’re mapping data into an ATS/CRM, dialer, or sequencing tool, this page is meant to reduce rework and prevent bad routing rules.

TA ops / recruiting ops building field mappings and dashboards
Agency ops standardizing outreach workflows across recruiters
Data/RevOps teams integrating provider datasets into internal systems

Quick Answer

Core Answer: A provider contact data dictionary defines each field, allowed values, and how recruiters use it to route outreach, enforce suppression, and measure outcomes.
Key Insight: Field-level clarity prevents false QA: you can’t validate, suppress, or prioritize outreach if fields don’t have consistent definitions and timestamps.
Best For: Buyers and ops teams who need to understand what fields mean.

Compliance & Safety

This method is for legitimate recruiting outreach only. Always respect candidate privacy, opt-out requests, and local data laws. Heartbeat does not provide medical advice or legal counsel.

Framework: The “Field-Level Trust” Pattern: definition + how to use + common mistakes

Definition

Field-Level Trust is a simple rule: every field you operationalize must have (1) a definition, (2) an intended workflow use, (3) a measurement method, and (4) a known failure mode.

How to use it

Define the field in plain language (what it is and what it is not).
Constrain it with allowed values and formats (including null rules).
Route it into a decision (call vs email, prioritization, suppression, assignment).
Measure outcomes tied to the field (per 100 dials, per 100 sent emails, per 100 delivered emails).
Correct definitions or workflow rules based on observed failure modes.

Common mistakes

Mixing “type” with “quality.” Example: “mobile” is a type; “line tested” is a quality signal. Keep them separate so reporting stays honest.
Assuming a field implies consent. A contact path existing in a dataset is not permission to spam it.
Overwriting multi-path contact data. If you normalize everything into one “phone” field, you destroy routing and QA.
Not versioning definitions. If semantics change, your dashboards become misleading.

Step-by-step method

Inventory your contact fields and map each to a decision.

List every field you ingest that affects outreach: phone(s), email(s), location(s), identifiers, specialty, suppression flags, and timestamps. For each field, write the decision it drives (routing, prioritization, suppression, assignment, reporting).
Standardize definitions and allowed values.

For each field, define format (E.164 for phone, consistent constraints for email), allowed values (enums), and null rules. If a field can be multi-valued (multiple locations, multiple phones), store it as such instead of overwriting.
Add provenance and freshness metadata.

At minimum, store source category and last updated for each contact path. Freshness is what lets you explain performance changes without guessing.
Implement suppression as a first-class system.

Maintain do-not-contact flags, channel-level opt-outs, timestamps, and reasons. Enforce suppression before any dial or send, and enforce it across tools (ATS/CRM, dialer, email platform).
Instrument outcomes so you can QA fields.

Measure this by… logging outcomes with denominators you can audit: phone metrics per 100 dials, email metrics per 100 sent emails and per 100 delivered emails, and identity metrics per 100 records (match/duplicate rates).
Close the loop weekly.

Review the top two failure modes (wrong number, gatekeeper routing, bounces, opt-outs). Update routing rules, suppression, and field definitions accordingly.

Directory (jump to field groups)

Identity fields (who is this?)
Segmentation fields (who should work this?)
Phone fields (how do we call?)
Email fields (how do we email?)
Location fields (where do they practice?)
Suppression & preferences (who should we not contact?)
Provenance & freshness (why should we trust it today?)

Diagnostic Table:

This table is a field-level troubleshooting guide for buyers and ops teams. Use it to align definitions, workflow usage, and QA measurement.

Field / Concept	Definition	How recruiters use each field	Common failure mode	QA / measurement
NPI	National Provider Identifier: a unique identifier for covered health care providers in the U.S.	De-duplicate; match records across systems; anchor identity when names/locations vary.	Individual vs organization NPIs mixed; stale practice location attached to the NPI record.	Match rate per 100 records; duplicate rate per 100 records (after matching rules applied).
Provider name	Structured name fields (first/last/suffix) used for matching and personalization.	Personalize outreach; match to internal records.	Nicknames, initials, suffix mismatches create duplicates.	Duplicate rate per 100 records; manual review queue volume.
taxonomy	Standardized classification describing provider type, classification, and specialization.	Route to the right recruiter; tailor messaging; segment reporting by specialty.	Multiple taxonomies per provider; taxonomy too broad for routing.	Segment-level Reply Rate per 100 delivered emails; connect outcomes by taxonomy.
Role / specialty label (internal)	Your internal normalized specialty label mapped from taxonomy and/or business rules.	Assignment, comp plan routing, and pipeline reporting.	One-to-many mapping causes misroutes (e.g., subspecialties).	Reassignment rate per 100 assignments; recruiter override frequency.
direct dial	A phone number intended to reach the provider without going through a main switchboard.	Prioritize for first attempts; use for time-sensitive outreach.	Routes to front desk/shared line; forwarding changed; number reassigned.	Connect Rate per 100 dials; wrong-number disposition rate per 100 dials.
Main line	A practice or facility phone number that typically reaches a switchboard or front desk.	Gatekeeper-friendly outreach; confirm best contact path; request message routing.	High gatekeeper friction; long hold times; after-hours routing.	Connect Rate per 100 dials; “gatekeeper” disposition rate per 100 dials.
Phone type	Enum describing the phone’s role (direct dial, main line, scheduling, fax, unknown).	Routing rules (who calls what first) and suppression (don’t dial fax).	Fax mis-labeled as voice; direct dial overwritten by main line.	Disposition mix per 100 dials by phone type.
Phone extension	Extension required to reach a person/department after dialing a main number.	Reduce wasted dials; improve gatekeeper routing.	Extension missing or outdated.	Connect Rate per 100 dials for records with extension vs without.
line tested	A phone number that has been programmatically checked for basic callability (e.g., rings, busy, disconnected) at a point in time.	Prioritize callable numbers; reduce wasted dials.	Test is stale; callable but wrong person/department.	Connect Rate per 100 dials segmented by last test date.
Phone carrier / line class (when available)	Carrier and/or line classification metadata (when available) used for routing and QA, not as a guarantee of reachability.	Sequence design and troubleshooting (e.g., why certain numbers never connect).	Ported numbers and carrier changes make this stale.	Connect Rate per 100 dials segmented by carrier/line class.
Timezone	Timezone associated with the practice location used to schedule outreach windows.	Call-window planning; reduce after-hours attempts.	Provider practices across timezones; timezone inferred from a billing address.	Answer Rate per 100 connected calls segmented by local time-of-day.
Best call window (operational)	An internal field derived from your outcomes (not a static attribute) indicating when calls are most likely to reach a human.	Schedule call blocks; route to recruiters working that window.	Overfitting to small samples; not refreshed as patterns change.	Answer Rate per 100 connected calls by call window.
Email address	A professional email associated with the provider or their practice context (does not imply personal/private sourcing).	Compliant email outreach; nurture when calling is low-yield.	High bounce; role-based inbox; filtering.	Deliverability Rate per 100 sent emails; Bounce Rate per 100 sent emails; Reply Rate per 100 delivered emails.
Email type	Enum describing the email’s role (personal professional, practice, role-based, unknown).	Sequence design (short vs detailed); routing to admin vs provider.	Role-based inbox treated like provider inbox.	Reply Rate per 100 delivered emails by email type.
Verification method (email)	How you validated the email operationally (e.g., delivered, bounced, confirmed by reply). This is a workflow field, not a promise of future deliverability.	Prioritize channels that have worked; suppress known bad paths.	Method not stored; teams treat “present” as “verified.”	Deliverability Rate per 100 sent emails segmented by verification method.
last verified	Timestamp for when a contact path was last confirmed by an outcome (e.g., connected call, delivered email, reply). Distinct from last updated/imported.	Prioritize fresher, outcome-confirmed paths; set refresh rules.	Confused with last updated; timestamp reflects import date only.	Outcome metrics segmented by last verified buckets.
Confidence score (internal)	An internal scoring field you define to rank contact paths for routing. It should be explainable and auditable.	Prioritize which phone/email to try first; reduce wasted attempts.	Score treated as “accuracy”; not recalibrated as data decays.	Connect/Deliverability outcomes segmented by score bands.
Practice location	Address/location metadata tied to a practice site (not necessarily where the provider lives).	Territory assignment; local market prioritization; call-window planning.	Provider works multiple sites; billing-only address used for routing.	Reassignment rate per 100 assignments; recruiter “wrong market” flags.
Multi-location count	Count of distinct practice sites associated with the provider record.	Decide whether to run multi-site outreach (main line + site-specific admin) vs single-path.	Collapsed locations hide the best contact path.	Connect Rate per 100 dials for multi-location vs single-location records.
Do-not-contact (global)	Flag indicating the record should not be contacted via any channel.	Hard suppression across all tools.	Duplicates bypass suppression; flag not synced to dialer/email tool.	Suppression enforcement rate per 100 attempted dials/sends.
Channel opt-out	Channel-specific suppression (e.g., do not email, do not call) with timestamp.	Respect preferences; protect deliverability and brand.	Opt-out stored in notes only; not enforced automatically.	Opt-out recurrence rate per 100 contacted records.
Suppression reason	Enum describing why suppression exists (requested, bounced, wrong number, compliance policy).	Auditability; faster remediation (fix data vs stop outreach).	Free-text reasons break reporting.	Reason distribution per 100 suppressed records.
source category	High-level label for where the field came from (e.g., registry, practice site, user feedback, outreach feedback).	Trust weighting; debugging when a source starts decaying.	Source missing; mixed sources in one field without traceability.	Outcome metrics segmented by source category.
last updated	Timestamp for when the field value was last refreshed or changed in your system.	Prioritize fresher contact paths; explain performance shifts.	Timestamp reflects import date, not refresh date.	Outcome metrics segmented by last updated buckets.

Metric definitions (canonical): Connect Rate = connected calls / total dials. Answer Rate = human answers / connected calls. Deliverability Rate = delivered emails / sent emails. Bounce Rate = bounced emails / sent emails. Reply Rate = replies / delivered emails.

Weighted Checklist:

Score a dataset or integration design without hand-waving. Score each item 0–2, multiply by weight, and total it. Use the notes column to record what you verified.

Category	Check	Weight
Definitions	Every contact field has a written definition, allowed values, and null rules.	5
Multi-path storage	Phone and location fields support multiple values (no overwriting direct dial with main line).	5
Provenance	Fields include source category and last updated timestamps.	4
Freshness vs verification	last updated and last verified are distinct and used in routing rules.	4
Phone usability	Phone fields distinguish direct dial vs main line; include line tested status/date where applicable.	5
Email usability	Email fields support deliverability QA (delivered/bounced tracking) and suppression.	4
Identity	NPI supports de-duplication and matching (with rules for edge cases).	5
Segmentation	taxonomy supports specialty routing (including multi-taxonomy handling).	3
Suppression	Global and channel opt-outs are enforced across all outbound systems.	5
Feedback loop	Structured dispositions feed back into suppression and routing rules weekly.	4

The trade-off is… richer field semantics (multi-path phones, timestamps, source categories) increase integration work up front, but they reduce wasted outreach and make QA defensible.

Outreach Templates:

These templates assume professional, compliant recruiting outreach. Keep messages short and easy to decline. Use suppression and preferences before sending.

Template 1: First-touch voicemail (direct dial)

Voicemail: “Hi Dr. [Last Name], this is [Name] with [Org]. I’m calling about a [role] opportunity in [market]. If you’re open to a quick, confidential conversation, call me at [number]. If you’re not interested, tell me and I’ll stop.”

Template 2: Email (deliverability-first)

Subject: Quick question — [specialty] role in [market]

Body: “Dr. [Last Name] — I recruit physicians for [Org]. Are you open to a brief call about a [role] position in [market] (schedule, comp model, call expectations)? If yes, what’s the best time this week. If no, I won’t follow up.”

Template 3: Gatekeeper-friendly main line script

“Hi, I’m trying to reach Dr. [Last Name] regarding a professional opportunity. What’s the best way to send a message for review — email or fax — and who should I address it to?”

Template 4: Ops feedback loop (data correction + suppression)

“We attempted outreach for Dr. [Last Name] and got [wrong number/bounce/opt-out]. Please (1) suppress the invalid channel with reason and timestamp, and (2) confirm the best professional contact path for future outreach.”

Common pitfalls

Single-field normalization that destroys routing. If you collapse all phones into one field, you can’t prioritize direct dial vs main line, and you can’t explain outcomes.
Missing timestamps. Without last updated and last verified, you can’t separate “bad data” from “old data.”
Suppression not enforced across tools. If opt-outs live only in notes, duplicates will keep getting contacted.
Confusing identity with reachability. NPI and taxonomy help match and segment; they don’t guarantee you can reach the provider.
Mini-case: duplicates bypass suppression. A common failure is email-only suppression: Record A is suppressed due to an opt-out on email, but Record B (same NPI, different email/phone) still gets dialed. Fix it by (1) normalizing identity (NPI where applicable), (2) enforcing a global do-not-contact flag at the identity level, and (3) applying channel opt-outs across all contact paths tied to that identity.

How to improve results

1) Use canonical metric definitions (so reporting is comparable)

Connect Rate = connected calls / total dials (report per 100 dials).
Answer Rate = human answers / connected calls (report per 100 connected calls).
Deliverability Rate = delivered emails / sent emails (report per 100 sent emails).
Bounce Rate = bounced emails / sent emails (report per 100 sent emails).
Reply Rate = replies / delivered emails (report per 100 delivered emails).

2) QA sampling protocol (no guesswork, no invented numbers)

Pick a cohort. Example: one specialty + one market + one week of outreach.
Sample records. Pull a fixed-size sample you can review weekly from that cohort, and include both phone and email where available.
Log outcomes with structured dispositions. Wrong number, gatekeeper, voicemail, provider answered, bounced, replied, opted out.
Compute metrics with denominators. Phone: per 100 dials and per 100 connected calls. Email: per 100 sent and per 100 delivered.
Segment by field values. Compare outcomes for direct dial vs main line; line tested recent vs older; email type; last verified buckets.
Change one rule at a time. Adjust routing (which phone first), suppression rules, or freshness thresholds, then re-measure on the next cohort.

3) Field naming + storage conventions (integration clarity)

Use enums for types. Example: phone_type = direct_dial | main_line | fax | unknown.
Store multi-values explicitly. Prefer arrays/child tables for phones, emails, and locations instead of overwriting a single field.
Separate timestamps. last_updated (system refresh/change) is not the same as last_verified (confirmed by an outcome).
Keep suppression structured. do_not_contact_global (boolean) plus channel_opt_out_email/channel_opt_out_call with timestamps and reasons.

4) Uniqueness hook worksheet: the “3-Layer Contact Path” rule

This is the fastest fix I’ve seen for field-level credibility problems in recruiting CRMs.

Layer 1: Routing number (practice main line). Use for gatekeeper workflows and confirmation.
Layer 2: Priority number (direct dial). Use for first attempts when present.
Layer 3: Learned best channel (from dispositions). Store the last successful channel and timestamp (e.g., “provider answered on main line ext 214”).

When you store all three, you stop overwriting good paths, and your QA becomes explainable: you can see which layer produced the outcome.

Legal and ethical use

Legitimate recruiting only. Don’t repurpose contact fields for unrelated marketing.
Respect opt-outs and preferences. Suppress quickly and across all systems.
Minimize data. Store what you need for recruiting operations; avoid collecting sensitive personal details.
Not legal advice. Align your process with applicable laws and your organization’s policies.

Evidence and trust notes

Definitions are only useful if they’re measurable and auditable. For how Heartbeat.ai defines and evaluates accuracy and outreach metrics, see: accuracy and metrics definitions methodology.

Primary references for common provider identifiers and classifications (definitions and standards):

Related Heartbeat.ai field explainers:

FAQs

What should a provider contact data dictionary include?

Field name, definition, allowed values/format, null rules, provenance (source category), freshness (last updated), intended workflow use, and a QA metric tied to outcomes.

How do ops teams compare two datasets with different field names?

Map both to shared concepts (identity, segmentation, phone, email, location, suppression, provenance). Then compare using the same denominators: per 100 dials, per 100 sent emails, and per 100 delivered emails.

What’s the difference between direct dial and line tested?

Direct dial describes intended routing (reach the provider without going through a switchboard). Line tested describes callability at a point in time. You can have one without the other.

Which metrics should we track for phone and email fields?

Phone: Connect Rate (connected calls / total dials) and Answer Rate (human answers / connected calls). Email: Deliverability Rate (delivered / sent), Bounce Rate (bounced / sent), and Reply Rate (replies / delivered).

How should we handle opt-outs and do-not-contact flags?

Store them as structured fields with timestamps and reasons, and enforce them across every outbound tool. Don’t rely on free-text notes.

Next steps

Operationalize the directory: pick your top 20 fields and copy these definitions into your internal schema docs.
Instrument QA: ensure your dialer and email platform export the denominators needed for the canonical metrics.
Go deeper on key phone fields: start with direct dial and mobile vs VoIP.
Implement in your workflow: create a Heartbeat.ai account to map fields into a recruiting workflow with suppression and QA built in.

About the Author

Ben Argeband is the Founder and CEO of Swordfish.ai and Heartbeat.ai. With deep expertise in data and SaaS, he has built two successful platforms trusted by over 50,000 sales and recruitment professionals. Ben’s mission is to help teams find direct contact information for hard-to-reach professionals and decision-makers, providing the shortest route to their next win. Connect with Ben on LinkedIn.