Identities and lifecycle

HospiConnect IAM: govern hospital identities and access

HospiConnect addresses the full electronic identification chain for healthcare professionals working in French hospitals: establishing who is working in the organisation, matching their local identity with the national healthcare identity where relevant, governing their entitlements and enabling secure access to clinical applications. A well-designed Identity and Access Management (IAM) programme connects these responsibilities without automatically replacing existing tools or making day-to-day clinical work harder.

Discuss your HospiConnect IAM roadmap Explore the IAM workstreams

The Ariovis capabilities involved

HospiConnect goes beyond rolling out strong authentication

The HospiConnect programme aims to make access to sensitive hospital digital services and national digital healthcare services both more secure and easier for professionals. The French Digital Health Agency, the Agence du Numérique en Santé (ANS), explicitly brings together a reliable national sector identity, appropriate two-factor electronic identification methods, IAM solutions to improve entitlement management, and Single Sign-On (SSO) to simplify access. Choosing a badge, smart card or additional authentication factor is therefore only one part of a much larger identity-to-access programme.

The ANS structures this transformation into five complementary areas: identity lifecycle management, digital service inventory, identity rights and access, electronic identification means, and governance and awareness. These areas need to work together. Strong authentication does not resolve duplicate identities, excessive entitlements or accounts that remain active after a professional leaves an organisation.

For the hospital, the operational objective is to give each professional the access required for their actual duties, at the time they need it, without retaining unnecessary permissions. This balance starts with real clinical workflows, trusted identity sources and the application landscape. Only then can the organisation define processes, connectors, access rules, user journeys and meaningful controls.

Hospital situations that should drive the design

Scroll the table horizontally to see every column.

Hospital situations, operational issues and expected IAM and access responses
Situation	Operational issue	Expected IAM and access response
A medical resident starts work	The identity and permissions must be ready for the first session	Reliable matching, coordinated account creation and service-specific access
An unexpected on-call shift needs cover	Critical access cannot depend on a lengthy enrolment process	A controlled emergency path, time-limited authorisation and rapidly usable identification means
A nurse works across several units	Shared workstations and frequent context changes	Smooth sign-in and sign-out, controlled sessions and entitlements aligned with assignments
A professional moves to another department	Previous access must not accumulate indefinitely	Recalculate permissions, remove obsolete rights and document exceptions
A locum or contractor works for a few days	End dates and ownership of access are essential	A named accountable sponsor, time-bound access and verifiable revocation
An electronic identification method is lost	Clinical work must continue without uncontrolled bypasses	A documented fallback process, suspension or revocation, and appropriate re-issuance
An administrator accesses a critical system	Higher exposure than standard clinical access	Robust MFA, limited privileges, reviews and appropriate audit trails

These are illustrative design scenarios drawn from the categories used in ANS operational guidance. They are not customer references or claims of delivered hospital projects.

Establish trustworthy workforce identities and reliable RPPS matching

The same hospital professional may appear in HR data, a directory, several application accounts and a national healthcare sector identity. These objects are not interchangeable. The local identity reflects the professional's relationship with the hospital; national identifiers and attributes support recognition across the healthcare ecosystem; application accounts enable access to individual systems. IAM must correlate these records while keeping decisions about local entitlements under the hospital's own governance.

The ANS maturity framework begins with a professional identity directory and the identification of an authoritative source (PROC-01A and PROC-01B). It then assesses creation processes for internal and external professionals (PROC-02A and PROC-02B), matching a local identity with the national Répertoire Partagé des Professionnels de Santé (RPPS) identity (PROC-03A and PROC-03B), matching coverage (COUV-03C), and the management of unresolved or inconsistent matches (PILOT-03D and PILOT-03E). This allows a hospital to go beyond simply declaring that its identities are synchronised.

Pro Santé Identité (PSI) provides an operational entry point for registration and management processes relating to national healthcare workforce identities; the RPPS holds the corresponding national reference records. Pro Santé Connect (PSC) is a federation service used to authenticate professionals for connected services. A coherent design can therefore link local identity sources, RPPS matching, IAM and PSC, provided data ownership, reconciliation and synchronisation rules are explicitly defined.

Identity questions worth resolving before integration

The hospital needs to identify the trusted source for an employee's start or end date, department assignment and external engagement, as well as the information that must be matched with national records. It must also define how to handle two local accounts belonging to the same individual, missing national identifiers, failed matches, or an RPPS activity record that no longer reflects the person's local situation. Such exceptions should be traceable and assigned to a resolution workflow, rather than being permanently maintained in separate spreadsheets.

Apply RPPS matching only to the relevant workforce population

RPPS matching must be measured against professionals registered in RPPS, not every account held by the hospital. The ANS indicator guide (PROC-03A and COUV-03C, pages 31 and 33) explicitly excludes professionals without RPPS registration from that denominator. Other staff still require a named local identity, a traceable engagement source and appropriate access governance. The absence of an RPPS record must not become an excuse for shared accounts or unmanaged access.

The ANS webinar of 24 March 2026 describes Pro Santé Identité as a registration gateway intended to support professional self-service and, where interfaces are made available, automation through APIs connected to local IAM. It also addresses local-to-national activity synchronisation. Actual availability and API eligibility must be checked for the project date: a March 2026 target architecture is not evidence that every feature is live for every hospital. Matching is an operated reconciliation process, not merely an RPPS field stored in a directory.

Manage joiners, movers and leavers without disrupting care delivery

A hospital workforce extends well beyond permanent employees. It includes residents, doctors, nurses, temporary staff, on-call cover, contractors, practitioners working across sites and other authorised users. Their onboarding and offboarding events may originate in HR, departmental management, clinical operations or a third party. An IAM platform cannot compensate for a departure event that is never reported: reliable sources and accountable processes are prerequisites for successful automation.

For a scheduled arrival, the goal is to prepare accounts, rights, identity matching and the authentication journey before the first shift. For an urgent arrival, the organisation needs an abbreviated but controlled authorisation and activation path. During a move, access must be separated into rights to retain, grant and revoke. When an engagement ends, the relevant accounts and privileges need to be disabled, with a mechanism to identify access that remains active beyond the defined deadline.

ANS indicators PROC-04A through PILOT-04G specifically assess leaver procedures, reliable triggers, coverage and deactivation time. The framework also addresses generic accounts used by individuals (PROC-05A through PILOT-05D), technical and service accounts (PROC-05E), and account reviews, including sensitive and privileged accounts (PROC-06A through PILOT-06G). The aim is not to ignore hospital-specific constraints but to make necessary exceptions visible, justified, limited and subject to review.

Govern what professionals can access, not only how they sign in

Correctly identifying a professional does not establish which records, features or systems they may access. A physician, a nurse, a ward manager, an administrative employee and a contractor can all have a verified identity and strong authentication while requiring very different application entitlements. Hospital information systems must connect access to professional duties, departmental assignments, legitimate business needs and application-specific policies, with a controlled approach to exceptions.

The ANS framework distinguishes a structured role or profile model (PROC-12A), entitlement updates throughout the identity lifecycle (PROC-12B), entitlement monitoring (PILOT-12C), exceptions (PROC-12D), external workforce coverage (PROC-12E), and the breadth of application coverage (COUV-12F). It separately addresses excessive rights and entitlement discrepancies (PROC-13A, COUV-13B and PILOT-13C). Useful governance is not a permissions spreadsheet written once: it is a continuously operated process of deciding, applying and verifying access.

An IAM / IGA capability that actually reaches applications

Six ANS indicators focus specifically on IAM tooling: an IAM solution used for identity lifecycle management (PROC-07A), automated provisioning and deprovisioning (PROC-07B), automation of leaver actions (PROC-07C), application coverage (COUV-07D), identity population coverage (COUV-07E), and ongoing operational monitoring (PILOT-07F). Together they support practical questions: which applications are connected, which identities are actually governed, which changes still require manual work and who resolves synchronisation failures?

An achievable roadmap may start with authoritative data, a directory and a few critical applications, then extend coverage. Access decisions can combine professional profiles with attributes such as department or assignment, without creating a permanent role for every exception. The Identity Governance and Administration (IGA) capability governs entitlements and records approval and execution. The identity provider authenticates the user. The clinical application, including the electronic patient record, remains responsible for enforcing its own authorisation rules on data and functions.

What the hospital should be able to demonstrate

For each priority process, the team should be able to explain what initiated the request, who approved it, which rule was used, what account or entitlement was created, changed or removed, and whether the target application executed the action. Discrepancies — unfulfilled grants, unmatched accounts, failed removals or excessive privileges — must lead to tracked remediation. This continuity from the decision to its execution and verification is what makes IAM operationally valuable within HospiConnect.

Make access smoother without weakening authentication

Healthcare professionals move between applications and often between shared workstations or clinical units. Access architecture must support this mobility while protecting sessions. Single Sign-On can reuse authentication when applications and assurance requirements permit. Multi-Factor Authentication (MFA) requires more than one factor, while electronic identification means — moyens d'identification électronique (MIE) — are the mechanisms professionals use to authenticate. None of these capabilities replaces identity proofing, lifecycle management or entitlement governance.

The starting point is the hospital's application inventory and sign-in patterns. Which services support delegation to a local identity provider? Which can be connected to Pro Santé Connect? Which still depend on enterprise SSO (eSSO) or legacy methods? How do shared workstations constrain the design? ANS indicators PROC-08A through COUV-11D address the application inventory and authentication capabilities. PROC-16A through PILOT-16E cover eSSO as a transitional approach that should be managed, while PROC-17A through COUV-17E and PROC-18A through COUV-18D address delegation to local identity providers and to PSC.

Pro Santé Connect and local identity: complementary responsibilities

Pro Santé Connect is the national identity federation service for connected healthcare applications. A hospital may also have a local identity provider serving its own applications. Delegating authentication between PSC and a recognised local provider within the PSC trust framework is a specific capability: it depends on reliable identity linking and compliance with ANS technical, organisational and security requirements. At the time of writing, rollout is progressive and operational eligibility depends on ANS-published criteria and solution recognition. It must not be described as a standard feature available automatically with any IAM or identity provider product.

Select electronic identification methods around real workflows

Unplanned on-call cover, shared workstations, remote access and administrative privileges have different operational requirements. Appropriate design criteria include authentication strength, enrolment speed, usability, revocation, renewal, fallback arrangements and distribution logistics. French CPS smart cards, e-CPS and other compatible or local methods can address different situations, subject to the applicable rules. A badge or FIDO2 security key is not compliant solely because of its underlying technology: the enrolment and authentication scheme and its operating processes also matter.

The ANS webinar of 24 March 2026 also distinguishes CPS cards linked to a verified national RPPS identity from historical CPE cards based on an identifier derived from the organisation. Holding a professional card does not, by itself, establish that its underlying identity meets the intended assurance level. This must be assessed against the user's status, intended workflow and applicable current rules.

The ANS separately measures MFA availability and actual use (PROC-14A through PILOT-14K), privileged account coverage (PROC-15A through COUV-15C), the choice and rollout of electronic identification methods (PROC-22A through COUV-22F), PSC compatibility (PROC-23A and COUV-23B), and identification methods used for non-healthcare local critical services (PROC-24A through COUV-24D). Deploying hardware or enabling an MFA option is not the same as demonstrating that it is used by the populations concerned.

Four electronic identification and SSO pathways illustrated by ANS

The ANS webinar of 24 March 2026 compares architecture pathways with different implications for hospital IAM. These are documented illustrations, not an approved-product list. The key distinction is between compliance of a local electronic identification scheme, compatibility of an identification method with Pro Santé Connect (PSC), and the additional recognition required for a third-party identity provider (FI tiers) to bridge local and national services.

Scroll the table horizontally to see every column.

Four electronic identification and SSO pathways illustrated by ANS (webinar of 24 March 2026)
ANS pathway	Local and national access	Main hospital IAM dependency
Local MIFARE DESFire badge without a PSC third-party IdP	The badge serves local workflows; e-CPS/PSC remains a separate national-service pathway	Assess and document the local scheme under RIE, and operate two coherent access journeys
PSC-compatible FIDO2 key without a third-party IdP	The key can serve compatible local login and PSC if officially recognised	Verify current compatibility and the complete local enrolment and authentication scheme
DESFire badge via a PSC third-party IdP (FI tiers)	A qualified bridge may link a hospital's local authentication with PSC	Robust local identity matching, recognition of both solution and organisation, and fulfilment of ANS FI tiers requirements
FIDO2 key via a PSC third-party IdP	A potentially unified local and national journey through the recognised provider	The same FI tiers eligibility, identity governance, issuance, revocation and assertion controls

The same source separates an achievable initial level from a more ambitious integrated architecture, better suited to larger identity populations and extensive application estates. Hospitals should select their target based on workflows, identity quality, integration capacity, user experience and operations—not assume that the most sophisticated option is mandatory. Do not describe any pathway as universally compliant or available without checking the current ANS requirements and recognition lists.

What IAM architecture supports HospiConnect?

The target architecture depends on the hospital's connected services and operating constraints. A coherent roadmap starts with HR and operational sources that record workforce lifecycle events, moves through a local identity repository and RPPS matching where relevant, and then feeds account and entitlement governance. Local identity providers, SSO, electronic identification means, MFA and Pro Santé Connect handle the appropriate authentication journeys. Clinical applications and national services enforce the rules applicable to their own resources.

HR / operational sources / contractor sponsors
Local hospital workforce identity repository
↳ Reliable matching to national identity / RPPS
IAM / IGA: lifecycles, accounts, entitlements, controls
- Applications / directories
- Local IdP / SSO / MIE / MFA
  ↳ PSC and federated services where eligible, compatible and connected
EHR (DPI) and other services: enforce their access rules

The RPPS matching arrow does not mean that RPPS directly determines local application roles. This model deliberately separates identity governance, professional authentication and authorisation inside applications. The architecture may use existing products and standards wherever they are fit for purpose: a hospital does not need to rebuild its entire identity infrastructure to establish a first reliable end-to-end process.

How does IAM contribute to integrated DMP access?

Accessing the French Dossier Médical Partagé (DMP, shared medical record) through an electronic patient record system — Dossier Patient Informatisé (DPI) — illustrates the distinction between authentication and authorisation. The professional must be correctly identified and authenticated, and the application must establish that access to the relevant information is permitted. In its webinar of 22 April 2026, the French national digital health programme presents five cumulative conditions under the acronym DICAH: D for an AIR-approved DPI, I for qualifying the patient's Identité Nationale de Santé (INS), C for organising patient consent, A for strong professional authentication and preparation for the simplified AIR process, and H for securing access to patient records through an entitlement matrix.

IAM is relevant to professional identities, account reconciliation, lifecycle processes and entitlement governance. Access Management contributes to the authentication journey. These capabilities do not replace DPI approval, INS qualification, patient consent management or the requirements applicable to simplified AIR. Likewise, the HospiConnect IAM maturity self-assessment and the DMP security/interoperability self-authorisation process are distinct exercises, each with its own requirements and expected documentation.

What integrated DMP access must transmit and audit

Under the simplified AIR approach described by ANS on 22 April 2026, the professional authenticates strongly upstream in the DPI (the hospital's electronic patient record software) or its identity provider. The consultation flow must carry, among other identifiers, the initiating professional's RPPS ID and the hospital's geographic FINESS identifier. The source also explains the use of a VIHF token signed with an organisation certificate: the individual initiating the transaction must nevertheless remain identifiable and auditable. IAM and Access Management help supply trustworthy identity context but do not replace DPI access controls, audit logs or DMP policy enforcement.

The ANS documentation distinguishes qualification of the DPI for AIR, the healthcare organisation's self-authorisation under the DMP security and interoperability framework (29 requirements across seven dimensions in the April 2026 source), and the separate contractual process with the French national health insurance body (CNAM). Self-authorisation requires an assessment, documented evidence, a review committee and a signed record kept by the hospital; it is not achieved by completing the 118 HospiConnect indicators. A hospital may define an initial live scope of users and services instead of requiring a whole-hospital rollout at the outset, provided the relevant conditions are met. AIR qualification of a DPI is not synonymous with Ségur wave 2 certification, and applying to HospiConnect does not itself require the hospital to already run Ségur wave 2 DPI software.

Assess IAM maturity using the ANS HospiConnect indicators

The ANS version 1.0 guide, validated in May 2026, contains 118 indicators organised into five areas: 41 on identity lifecycles, 15 on digital services, 39 on identity rights and access, 16 on electronic identification methods and 7 on governance and awareness. Indicator descriptions include maturity levels from 0 to 4 and assessment guidance. The ANS explicitly identifies the questionnaire as a self-assessment and steering tool: submitting the maturity indicators does not itself require documentary evidence.

For an IAM lead, the value does not lie in reproducing all 118 questions on a commercial page. It lies in relating a focused selection to the hospital's actual processes and application landscape. The table below is an operational mapping, not a substitute for the official questionnaire or a certification checklist.

Scroll the table horizontally to see every column.

Focused selection of ANS HospiConnect indicators and related practical questions
ANS reference	What it addresses	Practical question
PROC-01B	Authoritative identity source	Which system is authoritative for workforce status and key attributes?
PROC-03A / COUV-03C	Local identity / RPPS matching	Which professionals are matched and which cases remain unresolved?
PROC-04A / COUV-04E	Leaver process and residual access	Which accounts remain active beyond the agreed end date?
PROC-05A	Generic accounts used by people	Which shared uses remain and how are they controlled?
PROC-06A / PILOT-06G	Account reviews and follow-up	Do reviews result in access removals that are actually completed?
PROC-07A / PROC-07B	IAM tooling and automation	Which lifecycle events currently trigger automated IAM actions?
COUV-07D / COUV-07E	Provisioning coverage	Which applications and populations are actually covered?
PILOT-07F	IAM operations	Who owns incidents, exceptions, retries and synchronisation issues?
PROC-08A / PROC-09A	Application inventory and sign-in methods	Which systems are known, critical, isolated or still unmanaged?
PROC-12A / PROC-12D	Entitlement profiles and exceptions	Are entitlements explainable and are exceptions reviewed?
PROC-13A / PILOT-13C	Excessive entitlements and gaps	How are obsolete permissions identified and removed?
COUV-14E / COUV-14I	MFA use and external workforce	Is MFA actually used by the relevant groups?
PROC-16A / PILOT-16E	eSSO and modernisation	Which applications can move towards identity-provider federation?
PROC-17A / PROC-18A	Local IdP and PSC	Which applications are effectively connected to each pathway?
PROC-19A / PILOT-19B	PSC-recognised local IdP	Is the design eligible, recognised and monitored against ANS rules?
PROC-22A / PROC-23A	Identification method choice and PSC compatibility	Do the methods match the workflow and applicable assurance rules?
GOUV-28B / GOUV-28C	Ownership and governance	Who approves exceptions and tracks corrective actions?

The right way to use the framework is to compare the current state with a realistic target, sequence the dependencies and track progress. Provisioning coverage, timely revocation and MFA adoption are meaningful only when the scope, population denominators and calculation rules are documented.

Four distinctions that make maturity metrics meaningful

The ANS indicator guide provides definitions and quantitative maturity bands designed to prevent misleading KPIs. COUV-03C covers professionals registered in RPPS whose local record has been effectively matched; merely populating an unverified national identifier is insufficient. COUV-07D measures relevant digital services covered by automated IAM provisioning, whereas COUV-07E measures identities whose complete lifecycle is actually automated. Purchasing IAM licences or connecting one application does not establish either result. COUV-14C measures services where MFA is available, whereas COUV-14E measures authentications actually completed with MFA; logs can expose a material difference. Finally, COUV-01E is an inverse risk measure: fewer non-nominative accesses indicate better control.

In the May 2026 ANS guide, ordinary coverage indicators commonly use the bands 0–9%, 10–39%, 40–69%, 70–89% and 90–100% for maturity levels 0 to 4. Risk indicators such as COUV-01E use different thresholds and direction. Process, governance and steering indicators are assessed using qualitative criteria, not invented percentages. Every assessment therefore needs an accurate denominator, the prescribed scope exclusions, reliable local evidence and confirmation that identified access discrepancies are actually resolved.

Where should a HospiConnect IAM programme start?

A pragmatic programme begins by understanding workforce populations and actual clinical workflows, before translating the findings into decisions that can be delivered. The first output is a map covering identities, authoritative sources, applications, entitlements, authentication methods and process owners. It identifies critical applications, hard-to-manage populations and the dependencies on RPPS, PSI, PSC and MFA support.

The hospital can then identify maturity gaps using ANS indicators, confirm authoritative sources, resolve identity mismatches and select a handful of end-to-end processes for the first delivery stage: a joiner, a mover, a leaver and two or three representative applications. Larger-scale automation follows once these paths have been tested and backed by reconciliation controls, failure recovery procedures and operational documentation.

This initial work should lead to a prioritised roadmap, not an assumption that another platform must be purchased. Depending on the existing environment, delivery may involve improving directory data, extending an IAM deployment, connecting additional applications, modernising SSO, correcting entitlement models or stabilising the operating model. Hospital teams should retain the ability to understand the rules, manage exceptions and run the service independently.

Tangible outputs from the engagement

The work can produce an identity and access diagnostic, authoritative source and application maps, a local-to-RPPS matching model, an entitlement and responsibility framework, a target architecture covering IAM, SSO, electronic identification and PSC wherever applicable, and a prioritised backlog with testable acceptance criteria. Implementation can then include configuration, connectors, data clean-up or migration, testing, go-live support, knowledge transfer and appropriate ongoing IAM operations.

Discuss your hospital IAM architecture

Plan at the right level: site, legal entity and hospital group

The Convergence webinar of 6 May 2026 explains how planning may span a geographical hospital site, a legal entity (entité juridique, EJ) and a territorial hospital group (groupement hospitalier de territoire, GHT). Under the 2026 submission arrangements described in that webinar, maturity self-assessment was conducted at EJ level while a GHT could submit a shared project scoping note that documented member-specific differences. Submission rules, dates and maturity aggregation methods depend on the applicable funding window and must be rechecked; they are not permanent technical rules for IAM architecture.

For practical programme design, the HOP'EN 2 scoping-note template described by ANS contains six building blocks: scope; current situation, objectives and roadmap; timeline and milestones; organisation and governance; project indicators; and professional communication and adoption. These remain useful planning dimensions even outside the funding process because they link technical decisions to accountability and sustainable clinical use.

Frequently asked questions about HospiConnect IAM

Does HospiConnect require hospitals to buy a particular IAM product?

No. The ANS describes an end-to-end identity and access transformation rather than requiring a single IAM platform. Appropriate technology depends on the hospital's existing sources, applications, workforce populations and technical capabilities. However, the organisation still needs to govern accounts and entitlements, identify discrepancies and maintain effective access processes across the systems concerned.

How do IAM, RPPS, Pro Santé Identité and Pro Santé Connect differ?

IAM governs local identity lifecycles, accounts and entitlements. RPPS is the national sector register of healthcare professionals. Pro Santé Identité supports registration and management processes for those national identities. Pro Santé Connect is a national authentication federation service for connected applications. They are complementary components, not different names for the same identity platform.

Is successful RPPS matching enough to grant access to an EHR / DPI?

No. Matching establishes a reliable link between the hospital's local identity and the relevant national identity. Access to the DPI also depends on an appropriate local account, authentication and entitlements defined and enforced by the hospital's application environment. Updating a national record must not be confused with automatically granting every application permission.

Is Single Sign-On sufficient to meet the programme's requirements?

No. SSO simplifies login journeys, while strong authentication meets separate security requirements depending on the application and intended use. Neither capability alone resolves onboarding, internal moves, offboarding, generic accounts or excessive entitlements. Compliance of an electronic identification scheme must be assessed against the applicable technical and regulatory framework, not inferred from the presence of SSO.

Can a hospital's local identity provider be federated with Pro Santé Connect?

The PSC trust framework includes a mechanism to delegate authentication to a recognised local identity provider. Its use depends on solution recognition, hospital eligibility, reliable identity linking and compliance with ANS requirements. A local SSO deployment or commercial identity platform does not automatically qualify for this mechanism.

How should temporary clinicians, residents, locums and contractors be handled?

Their identity governance should distinguish the person, the trusted source confirming the engagement, their current assignment, the end date of access and the person accountable for approval. Urgent starts require rapid but auditable activation; time-limited engagements require reliable expiry and revocation. Automation works only when sufficiently trustworthy events can trigger the right actions.

Do the 118 ANS maturity indicators represent HospiConnect certification?

No. The May 2026 ANS guide describes them as a maturity self-assessment and management instrument. They support gap analysis and roadmapping, but completing the questionnaire does not certify the IAM platform or demonstrate compliance with every applicable requirement. Funding mechanisms and DMP self-authorisation processes have separate rules and evidence requirements.

How are HospiConnect, the DMP and simplified AIR connected?

Integrated access to the shared medical record depends on a trusted chain including professional identification and authentication, DPI entitlements, patient identity, consent and the technical conditions governing DPI and simplified AIR. IAM contributes to several of these areas but does not replace the DPI software vendor, clinical process owners or the relevant self-authorisation and approval activities.

Official references

Agence du Numérique en Santé — HospiConnect, CaRE programmeProgramme page (area 4, operational security), in French
ANS — HospiConnect webinar #1 “Périmètre opérationnel” (operational scope)ANS, March 2026 (PDF, in French)
ANS — HospiConnect webinar #2 “Services socles IE” (core electronic identification services)ANS, March 2026 (PDF, in French)
ANS — Pro Santé Connect: delegation to a local identity providerEligibility, solution recognition and identity linking, in French
ANS — Pro Santé ConnectGeneral service documentation, in French
French Ministry of Health — HOP'EN 2 programmeInstitutional programme page, in French
ANS — Convergence platformSteering and self-assessment tool, in French
ANS — Temps forts (key events)Programme updates calendar, in French

Build your HospiConnect IAM roadmap around your existing hospital IT

A useful first conversation starts by identifying which workforce groups are actually covered, which clinical applications matter most, where local and RPPS identities fail to match, which permissions are still handled manually and which authentication services are already deployed. This helps define a first achievable integration scope and success criteria before deciding what to keep, extend or change in the hospital's identity architecture.

Discuss your HospiConnect IAM project Explore identity governance See all use cases