Digital health and telemedicine are not a single hiring problem. They are three at once: a software company hiring engineers in jurisdictions that treat health data as a special category, a regulated-product company hiring regulatory and quality leads against EU MDR Regulation 2017/745 and the EU AI Act, and a clinical-services business that has to put licensed clinicians on payroll in the right jurisdictions. Each of those three has a different hiring envelope.
This article maps where an Employer of Record (EOR) actually fits in that envelope, where it does not, and how to think about HIPAA, GDPR, and SaMD obligations when employees sit outside your home country. It is the digital-health and telemedicine spoke of our broader hub on why medical companies use EOR.
Why telemedicine and digital-health scale fragments hiring
The companies that scaled fastest in the post-2020 telehealth wave hired in three concentric rings.
The innermost ring is the software team: engineers, ML researchers, data, product, design, security. These roles are remote-friendly by default and are often the first hires made outside the home country. Public hiring patterns at category-defining digital-health companies bear this out. Maven Clinic accelerated its UK growth through the 2023 acquisition of Naytal, building on a UK employer-client base served by international engineering and clinical hiring; Ro and Hims & Hers built large remote engineering benches; Teladoc operates engineering and product across multiple geographies after the Livongo combination disclosed in its 10-K filings.
The middle ring is regulatory, clinical-quality, and medical affairs: regulatory affairs leads, clinical safety officers, post-market surveillance, medical writers, pharmacovigilance for any combination products. These roles cluster in jurisdictions with deep regulator-adjacent talent (Germany, Ireland, Switzerland, the Netherlands, the United Kingdom) because EU MDR Article 15 requires a Person Responsible for Regulatory Compliance (PRRC) and the talent pool follows the regulation.
The outermost ring is licensed clinicians: physicians, nurses, therapists. This ring is where most of the EOR confusion sits in the digital-health buyer's market, and where the wrong vendor pitch can do the most damage. We come back to this below.
What fragments the hiring problem is that each ring has a different cost of getting the country wrong. Hiring a senior backend engineer through the wrong contracting model is a misclassification problem. Hiring a regulatory lead in a country whose authority does not formally recognize the role is an EU MDR problem. Hiring a clinician in a US state where the company is not registered is a corporate-practice-of-medicine problem.
The clinician vs. technologist hiring split
The single most useful frame for digital-health hiring is to separate the workforce into "directs care" and "everything else."
Everything else is EOR-friendly. Engineers, data scientists, clinical informaticists, designers, product managers, regulatory affairs specialists, medical writers, pharmacovigilance, customer success, operations, marketing, business development, legal, finance: these roles are typically employable through an EOR in any country where the provider holds an entity. The classification question is normal SaaS-shaped: are the deliverables, supervision, and exclusivity consistent with employment in that jurisdiction?
Directs care is regulated separately. A US-state-licensed physician practising telemedicine into Texas patients must have a Texas medical license and must operate inside whatever corporate-practice-of-medicine rules Texas imposes on the employing entity. An EOR cannot create that license. Nor can it convert a New York license into a Texas one. Where international clinicians are employed (for example, a UK GMC-registered physician practising into UK patients, or a Spanish psychologist seeing Spanish patients), an EOR can be the legal employer in that country, but local healthcare-practitioner employment rules still apply on top.
The honest version: an EOR is excellent at the technologist side of digital health. On the clinician side, it is one tool among several, and it is most useful for international clinicians employed inside their own jurisdiction. It is not a workaround for US state licensure, US corporate-practice-of-medicine restrictions, or DEA registration for controlled-substance prescribing.
HIPAA, GDPR, and health-data handling for international employees
This is the section that most competitor content gets wrong. The two regimes are not interchangeable.
HIPAA is a US federal statute that regulates "covered entities" (most providers and health plans) and their "business associates" (vendors handling protected health information on behalf of a covered entity). The core contract is the Business Associate Agreement (BAA), required by the HIPAA Privacy Rule and reinforced by the HIPAA Security Rule for electronic PHI. A BAA flows obligations down a vendor chain. It is not a data-transfer instrument and it does not, by itself, satisfy any non-US privacy law.
GDPR is an EU regulation that classifies health data as a special category under Article 9 and imposes specific lawful-basis and safeguard requirements. The contract between a controller and a processor is a Data Processing Agreement (DPA) under Article 28. Cross-border transfers out of the EU/EEA require a separate transfer mechanism, typically Standard Contractual Clauses or, for the US specifically, the EU-US Data Privacy Framework. A DPA does not flow HIPAA obligations and does not satisfy a BAA.
The practical implications for digital-health employers hiring across borders:
- A BAA is between covered entities, business associates, and their subcontractors. An employee is not a business associate. Your EOR is generally not your business associate either, because the EOR is the legal employer of a worker, not a vendor processing PHI on the covered entity's behalf. Specific scopes (for example, an EOR offering health-benefits administration that incidentally handles US PHI) can change that analysis; verify per-engagement.
- A BAA does not extend HIPAA's scope outside the US, and it does not give a non-US employee any special right to handle PHI. The data-handling controls are operational: encryption, access scoping, audit logging required under the Security Rule, breach response.
- For EU-resident employees touching EU patient data, the binding instrument is the DPA, not the BAA. For US PHI processed by EU-resident employees, both regimes can apply simultaneously; that is the case where most competitor content collapses the distinction.
- Country-level data-residency requirements are a third layer. Several jurisdictions (notably parts of APAC and LATAM) restrict where personal-health data can be stored or routed. An EOR cannot waive those; they are infrastructure decisions, not employment decisions.
The takeaway: HIPAA covers who can access US PHI under what contract. GDPR covers how EU personal data, including health data, is processed and transferred. Most digital-health companies hiring globally end up needing both, plus operational controls and country-level data-residency analysis. None of those are produced by employment paperwork.
SaMD engineering and regulatory hiring across the EU
If your product is, or contains, software that meets the definition of a medical device, you are hiring inside a regulatory perimeter that is wider than most early-stage teams realize.
The EU framework rests on EU MDR Regulation 2017/745 and the In Vitro Diagnostic Regulation 2017/746. For software specifically, MDCG 2019-11 explains qualification and classification of SaMD. EU MDR Article 15 requires a Person Responsible for Regulatory Compliance (PRRC), which materially affects where regulatory leads are hired.
The EU AI Act layers on top. AI systems used as safety components of medical devices, or that are medical devices, fall into the high-risk category under Article 6 and Annex III, which means specific obligations on data governance, risk management, and post-market monitoring on top of MDR. The European Commission's implementation timeline phases obligations through 2026 and 2027.
In the UK, post-Brexit, the MHRA's software and AI programme is reshaping the standalone-software pathway. In the US, the FDA's SaMD framework and the more recent PCCP guidance on Predetermined Change Control Plans for ML-enabled devices are relevant for any company building learning-systems into a regulated product.
The hiring consequences:
- Regulatory affairs leads for an EU launch are typically hired in Germany, Ireland, the Netherlands, or Switzerland. The Notified Body relationship and PRRC requirement push this concentration. EOR is the standard mechanism for the first one or two such hires.
- Quality / QMS engineers under ISO 13485 need real medical-device-quality experience, not generic SaaS quality. The bench is small and geographically distributed; companies often hire across Poland, Portugal, Spain, and the UK.
- Clinical evaluation and post-market surveillance roles increasingly hire across the EU because the data flows are local. EOR fits.
- AI/ML engineers building into a high-risk classification need to sit inside a documented data-governance process from day one. The hire itself is EOR-friendly; the data architecture they walk into is the harder question.
A useful internal split: SaMD engineering hiring is largely SaaS-shaped and EOR-friendly; SaMD regulatory hiring is country-driven by where the regulatory authority's adjacent talent lives.
Commercial hires for multi-country launch
Telemedicine and digital-health companies launching commercially in a new country usually make the first hire before they make the entity decision. That first hire is almost always one of:
- a country general manager or commercial lead
- a senior business development hire targeting payers, providers, or pharma partners
- a regulatory or market-access lead, where reimbursement or HTA processes drive the launch sequence
EOR is the standard mechanism for any of these. The buying question is whether the EOR has hired into that specific commercial profile before, and whether their entity in the country supports the equity-treatment, expense, and benefits package that a senior commercial hire will negotiate.
For an entity-vs-EOR sequence, the hub article covers the cost and timeline math. The short version for digital health: if the country is going to host fewer than ten employees over the next 18 months, EOR is almost certainly cheaper than entity setup. Crossing that threshold is a finance call.
Where telemedicine companies actually use EOR vs. clinician-licensed employment
A practical map:
The pattern public companies follow is consistent with this split. Telehealth platforms that have grown an international engineering and operations footprint, including those discussed in Teladoc's annual filings and in the Babylon Health era's pre-2023 public press releases, kept clinical employment local to the country of practice while running technology and corporate functions through a tighter set of hubs.
Honest limits
A few things an EOR does not do for a digital-health employer. Stating these directly is more useful than burying them.
- An EOR does not make a US-state-licensed clinician employable across states. Licensure is jurisdictional. The Interstate Medical Licensure Compact and similar arrangements operate independently of any employment vehicle.
- An EOR does not extend a HIPAA BAA's scope. A BAA flows down a vendor chain inside HIPAA's regulatory perimeter. Hiring an employee through an EOR does not, by itself, change who is a covered entity, who is a business associate, or what PHI an employee can access.
- An EOR does not waive country data-residency requirements. Where personal-health data must remain within a national border, that is an infrastructure question. The employment contract is silent on it.
- An EOR is not a substitute for a regulator-recognised QMS. Hiring a quality engineer through an EOR is normal; ensuring your ISO 13485 certification, technical documentation, and Notified Body relationships are intact is a separate workstream.
- An EOR is not a clinical-malpractice carrier. Clinical professional liability is procured separately and follows the clinician's licensure jurisdiction.
Any vendor that implies otherwise is selling something an EOR is not.
A short checklist for digital-health teams hiring globally
- Map the role to the correct ring: technologist, regulatory, or clinician.
- For technologist roles, default to EOR in the worker's country.
- For regulatory roles, let the country's regulatory recognition (PRRC, Notified Body geography) drive the country choice before the EOR question.
- For clinical roles, separate "non-US clinician in their home jurisdiction" (EOR plus local rules) from "US clinician across states" (state licensure, not EOR).
- Sign the right paper for each data flow. BAAs cover HIPAA. DPAs cover GDPR. SCCs or the DPF cover EU-to-US transfers. None of these substitute for the others.
- Confirm data-residency, not just employment-residency, for any country with health-data localisation rules.
- Reserve "we'll figure out compliance later" for things that genuinely have a later. Health-data and regulated-product hires usually do not.
For Borderless customers, the operational pattern most digital-health teams settle into is documented on the healthcare industry page: owned entities across 170+ countries, payroll invoiced without pre-funded salary deposits, and in-house support that aligns to digital-health hiring cycles. That profile is one input into the buying decision; the criteria above are the rest.
FAQs
Can a telemedicine company use an EOR to hire physicians across US states?
Generally no. US state medical licensure and corporate-practice-of-medicine rules govern who can employ a physician treating patients in a given state. An EOR can employ international clinicians in their own jurisdiction and can employ all non-clinical roles supporting US operations, but it is not a replacement for state licensure or for a multi-state clinical-employment structure.
Does my EOR need to sign a HIPAA Business Associate Agreement?
Often not. An EOR is the legal employer of a worker, not a vendor processing PHI on a covered entity's behalf. A BAA may be appropriate where the EOR's specific service scope (for example, benefits administration that touches US PHI) makes them a business associate. Verify per engagement, and do not treat a BAA as a substitute for a GDPR Data Processing Agreement.
What's the difference between a BAA and a DPA?
A BAA is the HIPAA contract between a covered entity and a business associate, governing how protected health information is handled inside the US regulatory perimeter. A DPA is the GDPR Article 28 contract between a controller and a processor of any personal data (including health data) in the EU. They cover different statutes, different obligations, and different counterparties. A digital-health company processing both US PHI and EU personal-health data needs both, plus a transfer mechanism such as Standard Contractual Clauses for any EU-to-US flow.
Can we hire SaMD engineers through an EOR in the EU?
Yes. Software engineering work on a medical-device product is itself EOR-friendly. The regulated workstream (technical documentation, QMS, post-market surveillance, PRRC) sits alongside the engineering hire and is governed by EU MDR and, where applicable, the EU AI Act, regardless of the employment vehicle.
Is HIPAA-compliant remote hiring a thing?
"HIPAA-compliant" describes data-handling controls, not a hiring mechanism. Remote employees can access PHI under HIPAA's regulatory perimeter where the employer maintains the required administrative, physical, and technical safeguards under the HIPAA Security Rule. The hiring vehicle (direct, EOR, or contractor) is a separate question from whether the resulting access scope is compliant.
Where do digital-health companies most commonly use EOR first?
The most common first-EOR-hire pattern is a senior engineer or a country commercial lead in the UK, Ireland, Germany, Spain, Portugal, Poland, or India, depending on the function. Regulatory leads cluster in Germany, Ireland, and the Netherlands. Clinical operations expansion follows trial geography rather than the digital-health pattern specifically; that is covered in our companion piece on hiring CRAs globally.
Further reading
- Why Medical Companies are Turning to Employer of Record services
- How to Hire Clinical Research Associates Globally
- How Medical Device Companies are Staffing Rollouts
- Hiring Medical Science Liaisons Internationally
- EOR for Biotech Startups on Tight Runway
- How Tech Companies Are Turning to Employer of Record Services
