MSSanté secure health messaging: how software editors integrate it

Direct answer

MSSanté is France's trust space for secure health messaging: operators approved by the national digital health agency (ANS) provide the mailboxes, and clinical software (LPS, hospital EHRs, social care records) connects to them. Since the second MSSanté framework, the standard integration is the API LPS: IMAP and SMTP with STARTTLS, Pro Santé Connect authentication for personal and organisational mailboxes, and an ORG AUTH_CLI certificate for application mailboxes. A clinical document travels as an IHE XDM archive containing CDA, alongside its PDF, with dedicated MSSanté headers.

MSSanté in plain terms

MSSanté is not a single product. It is a set of rules that lets hundreds of messaging services exchange encrypted health data with each other, while restricting access to professionals the law allows to share health data (article L.1110-4 of the French public health code). According to the ANS MSSanté page, the space has more than 800,000 mailboxes, more than 300 operators and more than 28 million messages sent in May 2025.

Three mailbox types exist:

• Personal (nominative): one professional, identified by their RPPS number.
• Organisational: shared by a team or department, under a named person's responsibility.
• Application: used directly by software for automated sending, and sometimes for automatic integration of received documents.

Using MSSanté is not mandatory, but securing health data exchanges is. Patients also have an MSSanté mailbox inside Mon espace santé, the national patient portal, with restricted uses.

Who does what

Framework #1 and framework #2

Framework #1 (référentiel #1) covers operators and has existed since 2014. Its version 1.5, published in April 2022, made the API LPS mandatory for operators. The oversight scheme for this framework is being revised: the ANS MSSanté doctrine page announces a public consultation in Q2 2026 and an adoption order (arrêté) in Q4 2026.

Framework #2 for messaging clients, v1.0, dated 31 January 2023, covers editors. It defines two client families:

• clients that only use application mailboxes, possibly with no user-facing message view (a lab system sending its reports, for example);
• clients that give access to personal or organisational mailboxes and therefore offer a reading and sending interface.

Applicable requirements differ by family; the summary table in chapter 6 of the framework is the list to copy into your backlog. Operator-specific proprietary interfaces are still allowed, but they tie you to that operator.

The API LPS: IMAP, SMTP and two entry points

Each operator publishes Thunderbird-format autoconfiguration at https://autoconfig.<emailaddressdomain>/mail/config-v1.1.xml, describing both entry points. Your client should query it from the mailbox address instead of hard-coding host names.

For a personal mailbox the sequence is: open the TLS session with STARTTLS, send AUTHENTICATE XOAUTH2 over IMAP or AUTH XOAUTH2 over SMTP with a base64-encoded string, wait for the operator to accept, then send commands. The string carries the mailbox address and the PSC access token:

// Synthetic values: build the SASL XOAUTH2 initial response for the API LPS
const mailbox = '[email protected]';
const pscAccessToken = '<access_token from Pro Santé Connect>';

const xoauth2 = Buffer.from(
  `user=${mailbox}\x01auth=Bearer ${pscAccessToken}\x01\x01`,
  'utf8'
).toString('base64');

// IMAP: A1 AUTHENTICATE XOAUTH2 <xoauth2>
// SMTP: AUTH XOAUTH2 <xoauth2>

The framework states that an intermediate LPS server is required, even for desktop software: each workstation cannot be registered individually as a PSC client. That server runs the OIDC flow (redirect, or CIBA, which confirms the login on the phone holding the e-CPS) and passes the token on. The flow itself is covered in the Pro Santé Connect integration article.

One detail to plan for: a PSC access token lives two minutes. Use a fresh token for every new IMAP or SMTP session, and test with your operator what happens to an IMAP session that is already open when the token expires; behaviour is not documented the same way everywhere.

For an application mailbox, the IGC-Santé ORG AUTH_CLI certificate must carry the national identifier of the organisation that owns the mailbox in the OU field of its DN.

Sending a clinical document: IHE XDM, CDA and PDF

A message carrying a clinical document must, under requirement ECO.2.1.1:

• concern a single patient;
• contain a ZIP archive in IHE XDM format with one or more CDA R2 level 1 or level 3 documents, following the CI-SIS document exchange specification;
• contain the same documents as PDF/A-1, generated from the CDA, so they can be read without clinical software.

The receiver identifies the patient from the patientId metadata (INS number) in the archive's METADATA.XML, not from the subject line. The subject starts with the XDM/1.0/DDM+ prefix, which the receiving LPS must hide on display. Three SMTP headers are expected:

From: DOE Jane <[email protected]>
To: [email protected]
Subject: XDM/1.0/DDM+CR d'examens biologiques DOE Jane 01/01/1970
X-MSS-CODECDA: 11502-2
X-MSS-INS: O
X-MSS-NIL: REF-PRODUIT-EXEMPLE

X-MSS-CODECDA repeats the CDA document code (multi-valued when several documents are attached), X-MSS-INS is O when the archive contains a qualified INS and N otherwise, and X-MSS-NIL carries the product reference declared on the ANS Convergence platform, on every message. The first two are only set when an XDM archive is attached. CDA structure rules come from CI-SIS; if you convert these documents to FHIR, the C-CDA to FHIR article covers the mapping traps, and FR Core, INS and CI-SIS covers identity.

Patient messaging through Mon espace santé

When a Mon espace santé account is created, the patient gets an address built on their 15-character INS number: <matricule INS>@patient.mssante.fr. There is no patient mailbox directory. In practice:

• only build the address from an INS with qualified status;
• a patient may have opted out of Mon espace santé or closed it, so a send can fail legitimately;
• patients cannot start a conversation, except to send a prescription to a pharmacy; they can reply, under conditions;
• your LPS must visually separate patient messages and show the patient's birth name, first given name and INS number (ECO.3.1.1 and ECO.3.1.2).

Finding recipients: the Annuaire Santé

The Annuaire Santé publishes professionals' MSSanté addresses, except those on the opt-out list. Three access methods exist: an LDAP interface dedicated to MSSanté data, open-data file extracts (including an MSSanté mapping file) and a FHIR API. For an address book inside the LPS, the extracts or the FHIR API avoid hitting LDAP on every keystroke.

Ségur and timeline

The ANS doctrine plans to generalise LPS and social care software interoperability with all operators along the Ségur wave 2 timelines, and for Mailiz to retire its legacy interfaces in favour of the API LPS. The Mailiz page for editors confirms the DST IMAP/SMTP and web service interfaces will be decommissioned. If your software still relies on them, plan the API LPS migration now.

Integration checklist

• Client family identified (application mailboxes only, or personal and organisational mailboxes) and framework #2 requirements copied into the backlog.
• Pro Santé Connect onboarding done and an intermediate LPS server in place.
• Autoconfiguration read from the mailbox domain, with no hard-coded host.
• ORG AUTH_CLI certificate ordered from IGC-Santé for application mailboxes, with the organisation identifier in the OU.
• Consistent IHE XDM archives and PDF/A-1 files, one patient per message.
• X-MSS-CODECDA, X-MSS-INS and X-MSS-NIL headers set, subject prefix hidden on receipt.
• Automatic filing into the patient record driven by the INS in METADATA.XML, with a reconciliation queue for unqualified identities.
• Patient messages flagged on screen, patient addresses built only from a qualified INS.
• Tests run in a test environment against at least two different operators.

Common pitfalls

MSSanté mailboxes hold health data, and so do the components you host yourself (intermediate LPS server, integration queue): HDS certified hosting belongs in the design from day one.

If you are planning an API LPS migration or automatic filing of CDA documents received over MSSanté, I offer support in digital health interoperability.