White paper — Connected health: interoperability and patient data security

White paper · February 2026

Connected health: interoperability and patient data security

Making health data flow without ever losing it — or letting it leak

“Health data has two ways of serving no one: staying locked inside a single application, or ending up on a ransomware forum. This entire document lives between those two failures.”

4 layers

1 identity

90 days

of interoperability — technical, syntactic, semantic, organisational — and which one really blocks your projects

The national health identity (INS), foundation of every exchange — and the identity-quality effort nobody budgets for

The action plan, from the data-flow inventory to the first cyber crisis exercise

This white paper draws on the digital-steering engagements of the Clarendis network with healthcare providers and e-health companies; it reads on its own, and re-reads at every new data-exchange project.

Contents

Foreword 03 Executive summary — the document in ten statements 04 Your reading path 06 1 The connected-health misunderstanding The tool is not the project · What the framework already requires — Ségur, INS, Mon espace santé · What the status quo costs · The question that orders everything 07 2 Interoperability: four layers, one identity The four layers · The INS, foundation of everything · The core national services — DMP, MSSanté, Pro Santé Connect · FHIR and the CI-SIS · What breaks in practice 12 3 Security: the regulatory base and the architecture GDPR and health data · HDS hosting · NIS2 and the CaRE programme · The architecture that holds: identities, segmentation, backups · The human factor 18 4 The blind spots Connected medical devices · Clinical shadow IT · Subcontractors · Remote patient monitoring · Research data · The legacy EHR · The cyber crisis 25 5 2026-2031: the European trajectory The EHDS, the European Health Data Space · Primary use, secondary use · From compliance to value · The no-regret decisions of 2026 31 6 The 90-day action plan Where are you starting from? · D1-D30: see clearly · D31-D60: harden the foundations · D61-D90: prove it — pilot flow and crisis exercise · The five-number dashboard 35 Moving to execution 40 Appendices — Glossary, references, about Clarendis, self-assessment 41

Foreword

French healthcare is living a digital paradox. Never has so much data circulated — discharge reports in Mon espace santé, lab results over secure messaging, connected devices in patients' homes — and never have the two symmetrical complaints been so sharp: “I re-type everything, nothing talks to anything” on one side; hospitals paralysed by ransomware on the other. Interoperability and security are two faces of a single subject: mastery of the patient data journey. Yet almost everywhere, they are entrusted to two teams that do not talk to each other.

This white paper was born of a field observation: connected-health projects that fail rarely stumble on technology — they stumble on unqualified patient identities, un-inventoried data flows and unwritten responsibilities. The reference frameworks exist, the standards exist, the funding exists. What is missing is a method that puts them in order, and that is what this document offers: the framework first (chapter 1), circulation next (chapter 2), protection (chapter 3), the blind spots (chapter 4), the European trajectory (chapter 5), and an executable plan (chapter 6).

One point of intellectual honesty: we sell no EHR, no hosting, no cybersecurity product, and we receive no referral commission. Every regulatory statement rests on a public text or framework, all listed in the appendix; what comes from our field experience is flagged as such.

How to read this document. The chapters stand alone. If your exchange projects are stalling, start with chapter 2. If the last security audit worried you, chapter 3 is your plan. If you are preparing for 2027 and the European Health Data Space, chapter 5 awaits you. Each chapter closes with the same panel, what this changes for you , written for three readers: the executive of a healthcare organisation or health-tech company, the CIO, the CISO or DPO. Deliberately the same subject seen from three seats — because these projects fail precisely where leadership, IT and security do not share the same map.

Enjoy the read — and may your exchanges be secure.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

for the Clarendis team

Executive summary

The document in ten statements. Each is developed and sourced in the chapter indicated.

1

2

Interoperability and security are one subject. Both describe the patient data journey: who produces it, where it passes, who accesses it. Treating them separately means mapping twice — or not at all. (Chapter 1)

The framework is no longer a prospect — it is a given. Mandatory INS, Ségur software certification, feeding Mon espace santé, HDS-certified hosting: the structuring obligations are in force. The question is no longer “must we?” but “where do we really stand?”. (Chapter 1)

3

4

Interoperability has four layers, and the hardest is not technical. Transporting (technical), structuring (syntactic), understanding alike (semantic), agreeing (organisational): most projects block on the last two — terminologies and responsibilities. (Chapter 2)

The first project is not the tool — it is patient identity. Every exchange rests on the qualified INS; every doubtful identity is a document that does not leave — or worse, lands in the wrong record. The qualified-identity rate is the dashboard's first indicator. (Chapter 2)

5

6

FHIR is the language of the decade — the CI-SIS remains the French grammar. Demand both from every vendor: compliance with the interoperability framework's volets, and a documented FHIR API, testable before signature. (Chapter 2)

The threat is not hypothetical — it is statistical. Healthcare remains one of France's top ransomware targets; the goal is not to prevent every intrusion, but to keep treating patients during one — segmentation, tested immutable backups, a written degraded mode. (Chapter 3)

7

8

Compliance does not protect — it funds and it orders. GDPR, HDS, NIS2, the CaRE programme: the mille-feuille converges on a few simple demands (inventory, identities, backups, exercises). Treat it as a funded architecture plan, not a pile of attestations. (Chapter 3)

Your blind spots are peripheral — therefore decisive. Never-updated connected devices, WhatsApp between clinicians, unaudited subcontractors, an inextricable legacy EHR: every blind spot in chapter 4 is an attack path or a break in the patient pathway. (Chapter 4)

9

10

Europe sets the horizon: the EHDS. The European Health Data Space regulation entered into force in March 2025; its obligations apply in stages from 2027-2029. The 2026 choices — formats, terminologies, access architecture — decide the cost of that deadline. (Chapter 5)

The constraint hides an asset. The same plumbing that satisfies the regulator opens three value streams: patient pathways without re-typing, data that can serve research and management, and proven continuity of care that becomes an argument of trust. (Chapter 5)

Where to start, depending on your situation:

Nothing is mapped. Chapter 1 (what the framework already requires), then straight to the 90-day plan of chapter 6, “cold start” sequence. Your absolute priority: the data-flow inventory and the state of your patient identities.

Exchange projects are stalling. Chapter 2: the four layers will tell you which one is blocking — rarely the one under investigation. Then chapter 4, §4.6: the legacy EHR is often the knot.

The security audit was frightening. Chapter 3 in full, then the crisis exercise of chapter 6 (D61-D90): a crisis plan never rehearsed is not a plan — it is a document.

Your reading path

Three marked itineraries. The “what this changes for you” panels at the end of each chapter are written for your seat.

CEO Executive 25 minutes

CIO CIO 1 h 30

CISO CISO / DPO 1 hour

01 Executive summary

Full document recommended. Your critical path:

You live this subject daily. Your path:

02 chapter 1 (§1.3: what the status quo costs, in business language)

01 chapter 2 in full (the four layers, the INS, the core services)

01 chapter 3 in full (the regulatory base put in order, the architecture)

03 chapter 3, §3.5 (the human factor — the trade-off that is yours to make)

02 chapter 3, §3.4 (the architecture that holds)

02 chapter 4 (the seven blind spots — your audit plan for the year)

04 chapter 6, §6.4 (the five numbers for your monthly agenda).

03 chapter 4 (your blind-spot map — legacy EHR included)

03 chapter 2, §2.2 (the INS: where identity vigilance and security meet)

04 chapter 5, §5.3 (EHDS: the 2026 technical choices)

You will know what to fund, what to demand, and how to verify progress.

04 the six “CISO / DPO” panels, at each chapter's end.

05 chapter 6 in full — the plan is yours.

What you came looking for

Need

Where

In what form

A map of the regulatory framework that fits on one page

Chapters 1, 3

Ségur, INS, HDS, GDPR, NIS2, CaRE: who requires what, from whom, and what converges

An interoperability method that unblocks projects

Chapter 2

The four layers, the INS, the core services and the vendor requirements grid

A security architecture that withstands ransomware

Chapters 3-4

Identities, segmentation, immutable backups, degraded mode — and the seven blind spots

A plan executable tomorrow

Chapter 6

90 days in three phases, one pilot flow, one crisis exercise, five numbers

Chapter 1

The connected-health misunderstanding

1

Before talking standards and firewalls, the subject must be freed of its founding misunderstanding — believing connected health is about apps — and grounded in what the French framework already requires.

1.1 The tool is not the project

Ten years of “digital transformation in healthcare” have produced a reflex: for every problem, an app. Appointment booking, remote monitoring, patient portal, coordination platform — each bought for a real need, each adding its own patient base, its logins, its exports. The most constant finding of our engagements: the average organisation does not suffer from a lack of tools — it suffers from an excess of tools that share neither identities, nor data, nor responsibilities.

Connected health is not a collection of applications: it is a circulation system. A patient data item is born somewhere (an EHR, a lab analyser, a sensor), travels (secure messaging, API, feeding the national record), and serves someone (a clinician, the patient, a researcher, a regulator). Every link of that journey asks exactly two questions: does the data arrive intact and understood? — that is interoperability; does it reach only those entitled to it? — that is security. Two questions, one journey: that is why this document treats both together.

This reversal has an immediate practical consequence: the first deliverable of a connected-health project is not a tool specification — it is a map of the flows. Who produces which data, in which system, where does it go, over which channel, under which patient identity? That map — one page per domain is enough — is the most profitable document of chapter 6, and the one most often missing from the projects we take over.

From the field. In a hospital group we supported, the initial census counted 47 applications handling patient data — the IT department knew of 31. The other 16 had arrived through wards, research projects and partnerships. No malice anywhere: simply, nobody had the map. It is the most common starting point, and it is not shameful — it is just urgent.

1

Chapter 1 — The connected-health misunderstanding

1.2 What the framework already requires

French digital health is no longer a field of recommendations: it is an enforceable framework, built in layers since 2019, most of which is already in force. Five building blocks structure everything else:

Block

What it imposes

Where it plays out for you

INS — national health identity

Reference all health data with the patient's qualified INS — mandatory since 2021 for every actor

Your admissions, your identity vigilance, every application that creates a record

Ségur digital programme

Certified software (EHR, lab, imaging, pharmacy…), funded to feed the core national services

Your vendor contracts: is the certified version deployed — and configured?

Mon espace santé / DMP

Feed the patient's national record with the key documents — discharge report, lab results, imaging, care letter

Your real feed rates, ward by ward — not the contractual ones

HDS

Any health data hosted for a third party lives with a certified host

Every one of your SaaS contracts — including the “small” departmental tools

PGSSI-S / CaRE / NIS2

An enforceable security baseline and, for providers, a funded national programme of exercises and remediation

Your security roadmap — detailed in chapter 3

Two readings of this table. The defensive one: “more obligations”. The accurate one: the State has built, funded and made mandatory the foundations every local project used to reinvent — a single identity, exchange formats, a national patient record, a security baseline. The remaining work is yours, but it is now bounded: plug your systems cleanly into these foundations, and keep up the quality of what flows through them.

Hence the question that orders this whole document, to ask before any purchase: “for each patient data flow, can we say who produces it, where it passes, who accesses it — and under which identity?” Everything that follows is a method for answering yes.

1

Chapter 1 — The connected-health misunderstanding

1.3 What the status quo costs

The status quo — systems that do not talk, ageing perimeter security — has a cost, but it is dispersed, hence invisible to budgets. Making it visible is the first act of governance:

The cost of re-typing. Every data item that does not circulate is re-entered — by a medical secretary, a nurse, the patient carrying results by hand. Re-typing costs clinical time, and it costs errors: a share of care-related adverse events originates in information that was missing, outdated or attached to the wrong patient. That is the clinical cost of non-interoperability — and it can be measured; internal case reviews are enough to objectify it.

The cost of the standstill. Ransomware in a healthcare organisation is not an IT outage: it is cancelled surgeries, patient transfers, weeks of paper operations, and months of rebuilding. The public post-incident reports of affected French hospitals converge: the order of magnitude runs in millions of euros and in months — not counting what no figure captures: lost chances, and trust.

The cost of the missed opportunity. Ségur funding left unclaimed for want of prerequisites, research projects impossible for want of structured data, remote monitoring not deployed for want of a receiving architecture: the status quo does not just cost — it prevents earning.

3 costs

1 map

2 questions

Re-typing · standstill · opportunity — to objectify in your own numbers

Of patient data flows — the first deliverable, before any purchase

Does it arrive understood? Does it reach only the entitled? — on every flow

1.4 Who this document is for

We write for three houses that share the same obligations with very different means: the healthcare provider (public or private, standalone or in a group), primary care and the medico-social sector (where the same rules apply to teams without a CIO), and the e-health company (software vendor, remote-monitoring operator, startup — for whom compliance is a condition of market access). The principles are common; where a recommendation diverges by house, we flag it.

One conviction to close this chapter: in healthcare more than anywhere, technology serves one simple promise — that the right information sits before the right clinician at the right moment, and before no one else. Every page that follows is judged against it.

1

Chapter 1 — The connected-health misunderstanding

1.5 The three houses, in practice

The principles of this document are common; their implementation differs deeply by house. For each: the most profitable entry point, and the most frequent mistake:

House

The profitable entry point

The frequent mistake

The chapter to read twice

Healthcare provider — public, private, in a group

A resourced identity-vigilance unit, and joint IT-biomedical governance

Entrusting interoperability and security to two teams that do not share the same flow map

Chapter 3 — the five barriers, on CaRE funding

Primary care and medico-social — practices, nursing homes, care networks

The national core services as they are: MSSanté, Mon espace santé, e-CPS — no infrastructure project of one's own

Waiting for an “IT project”: compliance here means configuring the Ségur-certified business software

Chapter 2 — the four layers, minimum viable version

E-health company — vendors, remote monitoring, platforms

FHIR + CI-SIS + HDS demonstrated in a sandbox: compliance as a sales argument

Leaving compliance to the end of the roadmap, when buyers now put it at the top of tenders

Chapters 4-5 — remote monitoring, EHDS and the market of 27

Three houses, one common point: none can treat the subject in a silo any more. The hospital depends on primary-care software for its referrals; primary care depends on hospitals for discharge information; the e-health company depends on both to exist. The quality of the system is decided at the seams — exactly where this document places its chapters 2 and 4.

For the smallest structures. If you have neither CIO nor CISO, the document still reads in an hour via the “Executive” path — and the chapter 6 plan reduces, for you, to five gestures: the Ségur-certified software up to date and configured, the qualified INS at admissions, MFA on remote access, one tested backup, and the CERT Santé number on the wall. That is already 80 % of the way.

1

Chapter 1 — The connected-health misunderstanding

The dated-decision template, to copy as is

As in every volume of this collection, everything begins with one signed page. In healthcare it has an extra virtue: it materialises leadership's responsibility on a subject NIS2 now explicitly assigns to it.

Decision to bring patient data flows under control

“[Date]. The management of [organisation / company] decides to bring patient data flows under control: interoperability and security, run as a single programme. [First name Last name] is appointed as its lead. Milestones: map of flows and applications within 30 days; state of patient identities and backups within 60 days; first hardened flow and first crisis exercise within 90 days. A dated log of incidents and decisions is opened as of today. Signature.”

This text is sent to no one: it is an internal note. It dates your trajectory — useful to the regulator, indispensable to your teams. Five lines dated today are worth more than ten pages dated the next incident.

What this changes for you

CEO

CIO

CISO

Executive. Sign the dated decision above this week — one page, one lead, three milestones. And ask the two-number question: how many applications handle patient data, and how many does IT know about. The gap is your real roadmap.

CIO. The first deliverable is the flow map, not a target-architecture diagram. One page per domain: who produces, where it passes, who accesses, under which identity. Chapter 2 gives you the grid to fill it in.

CISO / DPO. The same flow map is your record of processing activities, made alive. Every unmapped flow is at once a GDPR hole and an unwatched attack path: you now share an argument with the CIO to obtain it.

Chapter 2

Interoperability: four layers, one identity

2

“Our systems don't talk to each other” is too vague a diagnosis to treat. This chapter cuts it into four layers — and shows why everything starts with the patient's identity.

2.1 The four layers — and which one really blocks

W hen two health systems “don't talk”, four very different things may be at fault. The technical layer : does the pipe exist — network, API, messaging? The simplest, and the only one projects investigate spontaneously. The syntactic layer: does the message have an agreed structure — a CDA document, a FHIR resource, an HL7 message? The semantic layer: do both systems give the same meaning to the same codes — a creatinine coded in LOINC, a diagnosis in ICD, a procedure in the national nomenclature? The organisational layer: who sends what, when, who checks it left, who handles the rejects?

Our constant field finding: projects fail at layers three and four, and spend at layers one and two. An integration engine is bought (technical), formats are negotiated (syntactic) — and the project dies six months later because the lab's local labels were never aligned to LOINC, or because nobody decided who corrects a doubtful identity. The budget for the last two layers — terminologies and procedures — must be set on day one, and it is human more than software.

The four-layer test. Take your ailing exchange and ask the questions in order: does the message leave (technical)? Is it well-formed (syntactic)? Is it understood identically (semantic)? Does anyone notice when it fails (organisational)? The first “no” — or “we don't know” — names the project. Ten minutes, and the “it's the vendor's fault” debate becomes an action plan.

2

Chapter 2 — Interoperability

2.2 The INS: project no. 1, and the most underestimated

Every health data exchange rests on one certainty: both systems are talking about the same patient. That is the role of the national health identity — the INS number (derived from the social-security registry) and the five reference identity traits, retrieved via a national teleservice and qualified after verification of a high-trust identity document. Since 2021, referencing health data by the INS is mandatory for all actors.

The obligation is well known; its operational consequences less so. An unqualified INS, and the document does not reach the patient's national record. A duplicate identity, and the patient's history fragments into two records nobody will ever reconcile. A collision — two patients merged — and it is a direct clinical risk. The qualified-identity rate and the duplicate rate are therefore the first two indicators of any connected-health programme — before any technical metric. The identity-vigilance unit, long a discreet administrative function, becomes the most strategic team of the project.

Three concrete workstreams: qualification as you go (the INSi teleservice called at admissions, with identity-document verification tooled into the workstation — not a binder); clearing the backlog (qualify and de-duplicate the existing base, active patients first); propagation (every peripheral application — lab, imaging, specialties — must consume the INS from the identity referential, never recreate its own).

2.3 The core national services: what already exists, to plug into

Service

What it is for

The classic trap

Mon espace santé / DMP

The patient's national record, fed with structured documents (reports, lab results, care letters) — viewable by the patient and authorised clinicians

Feeding without verifying: the silent failure rate (unqualified INS, mistyped document) tracked by no one

MSSanté

The secure health messaging space — professional-to-professional exchange, and to the patient via their citizen mailbox

The organisational mailbox nobody checks — the digital equivalent of the forgotten fax machine

Pro Santé Connect / e-CPS

Professional identification, backed by the national registries (RPPS) — the “who accesses” of every connected-health service

Keeping it for national services while shared local accounts survive everywhere else

CI-SIS (ANS)

The interoperability framework: use-case volets, document formats, reference terminologies served from a national server

Citing it in tenders without ever acceptance-testing the actual deliveries

The cross-cutting lesson: these services exist, work and are funded — the remaining work is the plumbing and the quality of what you pour into them. A local project that reinvents one of them is in the wrong decade.