Medical Device CRM: What Regulation Requires

Why a medical device CRM is not just CRM with a healthcare label

Search for a medical device CRM and you will mostly find lists of vendors with healthcare logos on the pricing page. That framing misses the thing that actually separates this category from ordinary B2B sales software.

The difference is not features. It is that in a medical device company, a CRM record can stop being a sales artefact and become a regulated record. Once that happens, the questions that matter change completely. Not "does it have good pipeline reporting" but "can anyone edit this field without leaving a trace, and can I prove it during an inspection."

Three quite different companies search for this term. A manufacturer running field sales to surgeons and hospital systems. A manufacturer with a direct relationship to patients, through remote monitoring, reimbursement support or consumer devices. And a distributor or dealer reselling other people's products. They need genuinely different systems, and the dividing line between them is whether regulated data lands in the CRM.

The rule that changes everything: awareness starts the clock

This is the single most important thing to understand before you evaluate any platform.

Under FDA's Medical Device Reporting regulation at 21 CFR Part 803, a manufacturer is considered to have become aware of a reportable event when any of its employees becomes aware of it. Not when the quality team logs it. Not when it reaches the complaint handling unit. When any employee knows.

Think about what that means operationally. A sales rep is in a hospital corridor. A nurse mentions that the infusion pump alarmed during a procedure and the patient was admitted overnight. The rep types a note into the CRM after the visit. The reporting clock started at that conversation.

The clocks themselves are unforgiving:

United States. Most manufacturer reports are due to FDA no later than 30 calendar days after awareness, covering deaths, serious injuries, and malfunctions that would likely cause or contribute to a death or serious injury if they recurred. Certain events require a report within 5 working days, including where remedial action is needed to prevent unreasonable risk of substantial harm, or where FDA has requested 5-day reporting for a pattern.
European Union. Under EU MDR Article 87 the timelines are shorter and tiered. Serious incidents are reportable within 15 days, dropping to 10 days for death or unanticipated serious deterioration in health, and to 2 days where there is a serious public health threat.

One naming trap worth flagging before you sit through vendor demos. In the United States, MDR means Medical Device Reporting. In Europe, MDR means the Medical Device Regulation. They are not the same thing, and vendors, consultants and their marketing pages use both meanings without always saying which.

What this means for CRM selection is concrete. If your field team's notes can contain complaint information, the system needs structured intake with a reliable timestamp, an escalation path into your quality system, and no way for anyone to quietly rewrite or delete what was originally entered. A free-text "notes" box that a rep can edit next week is a liability, not a feature.

Complaint records got more explicit in February 2026

If you last mapped your systems against 21 CFR Part 820, that map is out of date.

The Quality Management System Regulation became effective on 2 February 2026. It amends Part 820 to incorporate ISO 13485:2016 by reference, keeping a smaller set of FDA-specific provisions that fill gaps the international standard leaves. The final rule was published two years earlier, on 2 February 2024, with a two-year transition. FDA also stopped using the Quality System Inspection Technique on that date and moved to the inspection process in Compliance Program 7382.850.

The part that bears directly on CRM is 820.35, Control of records. It sets out content requirements for complaint records explicitly, including when a complaint should be investigated, and does the same for service records. This is more prescriptive than the language it replaced, which is worth reading carefully rather than assuming ISO 13485 covers it.

Two knock-on points:

Exemption from CGMP requirements does not exempt a manufacturer from complaint file and general record obligations. Smaller companies with exempt Class I products sometimes assume otherwise.
Electronic records and signatures still fall under 21 CFR Part 11. If your CRM holds a regulated record, its audit trail, access controls and signature capability are in scope, and so is the validation evidence behind them.

Once a system holds a regulated record, "we use a CRM for that" becomes a statement you have to defend with documentation.

What a medical device CRM must do that a generic CRM does not

Six requirements separate the category from ordinary sales software. Use them as a filter before you look at price.

Complaint intake as a first-class object. Not a note, not a task, not a custom field bolted onto an opportunity. A dedicated record type with mandatory fields, its own lifecycle, and its own permissions.
An audit trail you cannot edit. Every change captured with user, timestamp and prior value, retained for the required period, exportable in a form an investigator will accept.
Vendor validation support, not vendor compliance claims. No software is "FDA compliant" out of the box. What you want is documentation you can build installation, operational and performance qualification on top of, plus a clear statement of what changes with each release and who owns re-validation.
Transfer-of-value capture at the point of interaction. More on this below.
Account structures that match how healthcare actually buys. Integrated delivery networks, group purchasing organisation contracts, affiliated clinics, individual practitioners with privileges at several institutions. A flat company-and-contact model breaks immediately.
Installed base and field service tied to identifiers. Serial number, lot, and Unique Device Identification, linked to the account and to any complaint or service record raised against that unit.

The Open Payments problem is really a data capture problem

Applicable manufacturers of drugs, devices, biologicals and medical supplies covered under Medicare, Medicaid or CHIP have to report transfers of value to covered recipients under the Physician Payments Sunshine Act, through the CMS Open Payments programme.

The rhythm is annual. Data is captured throughout the calendar year, submitted to CMS between 1 February and 31 March for the prior year, opened to covered recipients for review and dispute for roughly 45 days from early April, corrected by late May, and published publicly around 30 June. Reports fall into general payments, research payments, and ownership or investment interests.

Two mechanics make this a CRM problem rather than a finance problem.

The aggregate threshold works retroactively. Individual transfers below a small per-payment minimum are excluded, but once cumulative payments to one covered recipient pass the annual aggregate threshold, every payment to that recipient becomes reportable, including the small ones you excluded earlier. Both thresholds are adjusted for inflation each year, so check the current figures on the CMS Open Payments site rather than relying on a number from an older article.

The covered recipient definition is wider than physicians. It now includes physician assistants, nurse practitioners, clinical nurse specialists, certified registered nurse anaesthetists and certified nurse midwives.

Put those together and the practical requirement is that a $9 coffee has to be attributed to a specific named practitioner at the moment it is bought, along with the nature of payment category. If a rep reconciles a year of meals and samples from memory and a credit card statement in January, the submission will be wrong, and CMS has been running audits since fiscal year 2023.

A separate patchwork of state requirements sits on top of the federal one. Vermont, Minnesota, Massachusetts, West Virginia, Nevada and the District of Columbia have their own transparency laws, with different thresholds, definitions and deadlines. If your CRM cannot tag an interaction by state and export in more than one shape, someone is going to spend February building spreadsheets.

HIPAA: many device companies need less than they think, and some need much more

There is a lot of confused writing about this, so it is worth being precise.

Business contact information about a physician is not protected health information. A hospital's address, a surgeon's work email, a purchasing manager's phone number, the fact that a cardiology department bought forty units last quarter. None of that is PHI. A large number of device manufacturers selling capital equipment or consumables to institutions never put PHI in their CRM at all, and buying a HIPAA-scoped platform for that use case is money spent on the wrong problem.

You cross the line when the CRM touches patient-identifiable clinical information. Common triggers:

Patient support, reimbursement or prior authorisation hubs
Direct-to-patient devices such as continuous glucose monitors, hearing aids or sleep therapy equipment
Remote monitoring and connected device telemetry
Complaint intake taken directly from a patient with clinical detail attached
Field service on a device that stores patient data

Once you are there, you need a Business Associate Agreement. Three cautions about BAAs that vendor comparison articles routinely skip:

A BAA is scoped to specific covered services, not to the whole platform. Vendors typically list which product areas are covered and which are excluded. Newer AI features are frequently outside the covered list, which means feeding PHI into an AI assistant inside an otherwise covered platform can be a breach.

Marketplace integrations are separate vendors. Your platform's BAA does not extend to the apps you install on it. Each one needs its own assessment.

Published roundups on which CRMs will sign a BAA disagree with each other, sometimes flatly, and vendor positions change between plan tiers and between quarters. Do not treat any article, including this one, as the source of truth. Get the current covered-services list from the vendor in writing and have counsel read it before PHI touches the system.

The vendor landscape is mid-reshuffle, and the timing matters

Anyone making a platform decision right now is doing it during the largest disruption this category has seen.

Veeva has stated in its SEC filings that it does not intend to renew its agreement with Salesforce for use of the Salesforce platform, that it has begun migrating CRM customers to Vault CRM built on its own Veeva Vault platform, and that Veeva CRM will be supported until 1 September 2030. New customers start on Vault. Salesforce has moved in the other direction, launching Life Sciences Cloud as a direct alternative for pharmaceutical and medtech customers.

Three things follow for a medtech buyer.

The 2030 date is later than it sounds. A platform migration in a validated environment is not a data migration with a training day attached. Validation, integration re-testing and change control sit on top of the move itself, and every integration that pointed at Salesforce objects has to be rebuilt against a different API. Organisations that treat 2030 as distant tend to discover they needed to start years earlier.

Veeva's centre of gravity is pharmaceutical. The commercial model it was built around is a rep detailing a prescriber. Medtech buying cycles involve capital equipment, tenders, GPO contracts, installed base management, consignment inventory and field service engineers. Some medical device companies find the fit excellent. Others find they are paying for a model that does not match how they sell.

A third path exists. Plenty of device manufacturers run a general enterprise CRM such as Microsoft Dynamics 365 or Salesforce, and layer purpose-built medtech or complaint-handling applications on top, keeping the regulated records in systems designed to hold them. That can be the cheaper and lower-risk answer, provided the handoffs between systems are themselves controlled and documented.

Whichever direction you go, ask about the exit before you sign. The lesson of the last few years is that platform relationships end, and the companies that suffered least were the ones that already knew how to get their data out.

If you are small, you may not need any of this yet

Not every company that searches for a medical device CRM needs a validated, Part 11-capable system.

If you are a distributor of exempt Class I products, you hold no PHI, you have no field service organisation, and you make no reportable transfers of value to healthcare professionals, a general-purpose CRM is very likely adequate and a great deal cheaper. Buying enterprise life sciences software at that stage burns budget and slows the sales team down for no compliance benefit. If that describes you, our roundup of the best CRM for small business in 2026 is the more useful starting point.

The triggers that mean you have outgrown it are specific. Your first complaint that has to be formally logged and investigated. Your first transfer of value to a covered recipient. The first time patient-identifiable information reaches a customer-facing team. Any one of those changes the requirement.

One caveat for the smallest companies. As noted earlier, being exempt from CGMP requirements does not exempt you from complaint file and record obligations. "We are exempt" is not the same as "we do not need a complaint process."

Questions to ask every vendor

Take these into the demo. They surface the difference between a platform built for this and one with a healthcare page on its website.

Show me the complaint object. Not a customised opportunity. Show me the record type, its mandatory fields, and its lifecycle.
Show me the audit trail on that record, including what happens if an administrator tries to change a historical value.
What is your Part 11 position, and what validation documentation do you supply? Who owns re-validation after each of your releases?
Exactly which of your services does your BAA cover, and which are excluded? Send me the current list.
How do you capture a transfer of value at the moment it happens, and can you export in a format that maps to the CMS submission?
Can a record be linked to serial number, lot and UDI, and can I pull every complaint against a given lot in one query?
How do I get all of my data out, including audit history, and in what format?
What happens to my integrations if you change your underlying platform?

FAQ

Is a CRM a regulated system for a medical device company?
It can be. It is not regulated because it is a CRM. It becomes subject to record and electronic record requirements when it holds regulated content, most commonly complaint information, service records or data feeding adverse event reports. If your field team can enter complaint information into it, assume it is in scope until you have documented otherwise.

Do I need a HIPAA BAA for my medical device CRM?
Only if protected health information will be in it. Business contact details for physicians and hospitals are not PHI. If you run patient support programmes, direct-to-patient devices, remote monitoring, or take complaints directly from patients with clinical detail, you do need one, and you need to check exactly which services it covers.

What is the difference between a CRM and a QMS here?
The CRM is where the customer relationship lives and where information often arrives first. The quality management system is where complaints are formally handled, investigated, linked to CAPA and turned into regulatory reports. The failure mode is the gap between them: information sitting in a CRM note while a reporting clock runs. What matters is the controlled, timestamped handoff.

Did the QMSR change my CRM requirements?
It changed the record requirements that a CRM may be feeding. Part 820 now incorporates ISO 13485:2016 by reference as of 2 February 2026, and 820.35 sets out complaint and service record content more explicitly than the old regulation did. If you built your complaint intake design against pre-2026 Part 820, re-check it.

Should we wait for the Veeva and Salesforce situation to settle?
Waiting is itself a decision, and it consumes part of a window that is shorter than it appears once validation is factored in. If you are already on Veeva CRM running on Salesforce, the useful move now is scoping the migration and the integration rebuild rather than picking a destination under time pressure later.

Where to start

Before you look at a single vendor, map where regulated information can enter your organisation and who touches it first. In most device companies the answer is the field team, which means the CRM is upstream of the quality system whether anyone designed it that way or not.

Once you know that, the selection question becomes tractable. You are not buying sales software with compliance features attached. You are deciding which system of record holds evidence, and building the rest around it.