ORIGAMI, the line-of-business software I build and keep in production for medical dispatch, now offers electronic prescribing to its practitioners. The connection was not built directly against the national health insurance services, but through Ordoclic, which exposes its e-health services to integrator vendors through an API. The CNDA e-prescription certification remains in ORIGAMI’s name. We filed the CNDA application, Ordoclic handled the procedure through the final audit, and we ran the e-prescription pre-series directly with the national health insurance service.

I am writing this path down because it is poorly known, and because smaller vendors give up on it believing they have to absorb everything themselves.

Software that has to prescribe

ORIGAMI is a Rails application used by practising clinicians. At some point electronic prescribing stops being optional: paper becomes an irritant for the doctor, who wants to transmit straight to the pharmacist, and for the patient, who does not want to carry a sheet around. The software has to produce structured, signed prescriptions, file them in the secure database hosted by the national health insurance fund, and let pharmacists retrieve them from an identifier.

Two paths, two regulatory surfaces

The direct path. The vendor registers with the national digital health agency, builds its PKI chain, manages its server and software certificates, integrates the national identity federation or CPS smart cards to authenticate professionals, talks to the e-prescription state service, builds and certifies its own prescribing engine with the health authority, drug database, interaction checks, contraindications and posology included, then files its own CNDA application. This is the route the large incumbent vendors take, and it holds together: the chain is controlled end to end, with no dependency. Its entry and maintenance cost distorts the product of a one or two developer shop.

The integrator API path. The vendor leans on a partner already connected to the state services and already certified as a prescribing engine, which factors out the regulatory plumbing behind an API. The vendor files its CNDA application, then the partner handles the procedure through the final audit. The e-prescription pre-series follows a separate path, directly with the national health insurance service. For the doctor, the experience is the one a directly connected vendor gives: they prescribe, it goes out, the pharmacist queries the database.

Two columns comparing a direct connection, where the vendor carries the agency registration, PKI chain, identity federation, certified prescribing engine and CNDA file, with the integrator API path, where Ordoclic carries those building blocks and handles the CNDA procedure after the vendor files its application. The vendor runs the e-prescription pre-series with the national health insurance service. — With the integrator API, the vendor files the CNDA application and runs the pre-series with the national health insurance service. Ordoclic handles the CNDA procedure through the final audit.

What Ordoclic carries

The connection to the national health insurance services and the wider agency ecosystem, with the server certificates and health PKI chain that go with it.
Practitioner authentication through the national identity federation, soft certificates and CPS card readers, without the vendor touching those low-level flows.
Signing the prescription and filing it in the secure database, in the format pharmacists expect, with a unique QR code.
Retrieval on the dispensing side from the prescription identifier.
The prescribing engine itself: certified by the health authority for ambulatory care, CE-marked as a medical device, CNDA-approved for e-prescription, backed by a maintained drug database with interaction, contraindication and posology alerts. This is the heaviest piece to carry alone: a demanding certification framework, an approved drug database to integrate, and revalidation on every change.
The CNDA procedure after the vendor files its application, through the final audit attended by an Ordoclic technician.
Activation of the workstation traces required for e-prescription.

What stays with the vendor

Prescribing does not happen inside ORIGAMI. The doctor clicks a button that opens Ordoclic’s prescribing engine with the context already set, and that is where they prescribe, in front of the interaction and contraindication alerts of the drug database. Once they are done, ORIGAMI receives the secured prescription as a PDF by webhook, files it on the patient record, and sends it to the patient over a secure channel.

That split pushes the vendor’s work to both ends. Upstream, sending the right context: which practitioner is acting, under which national registry number, in which practice context, for which patient. That flow is set up when the doctor’s account is configured and has to stay current on every prescription. Downstream, receiving the webhooks: an endpoint that answers fast, tolerates a replay without creating a duplicate, and records what it filed.

The prescriber’s clinical responsibility is delegated nowhere. The engine displays the alerts, the doctor decides, and the prescription that lands back on the record carries that decision.

On the regulatory side, the vendor files the CNDA application and runs the e-prescription pre-series directly with the national health insurance service. Those steps follow separate processes. After the application is filed, Ordoclic handles the CNDA procedure through the final audit.

When a service is unavailable

An outage affecting Ordoclic itself blocks access to its prescribing engine. Ordoclic reports a minimum SLA of 99.6% and actual availability usually closer to 99.9%, making this a rare incident rather than the normal operating cost of the integration.

The other possible outage affects the national health insurance e-prescription service, an external dependency of Ordoclic. While it is unavailable, an e-prescription cannot be completed. Ordoclic’s degraded mode still lets practitioners issue standard prescriptions, without systematically forcing them back to paper.

Prescribers need this distinction before go-live. E-prescription availability depends on both the partner and the external state service, but a state-service outage does not remove every way to prescribe.

The Rails side

The code holds no surprises: authenticated HTTP calls against the integrator API from a dedicated service layer, and an endpoint that receives the webhooks. The patterns from the rest of the application apply unchanged.

The webhook is the piece that takes the most care. It arrives after the fact, on a server that did not follow the prescribing session: it has to find the right record, check the prescription was not already filed, and answer fast enough not to trigger a pointless replay.

An e-prescription in the sense of the state service is a set of structured data, signed and filed in the national database, that the pharmacist retrieves by identifier. The PDF the patient receives is a copy of it, and no pharmacist ever reads it.

Delivering that copy stays the vendor’s job. ORIGAMI sends an email carrying a tokenised link, and the patient confirms their identity with their initials before the document opens. Medical labs and Doctolib have already made that gesture familiar, which saves writing instructions for it.

The path of a prescription: from ORIGAMI a button opens Ordoclic's prescribing engine with the context, the doctor prescribes there, the prescription is signed then filed in the national database and the pharmacist queries it by the QR code identifier. A return arrow brings the prescription back into ORIGAMI by webhook. Below, a state-service outage suspends e-prescription while standard prescriptions remain available in degraded mode, and the PDF goes to the patient while the pharmacist queries the database. — The vendor holds both ends, the button that opens the engine and the webhook that brings the prescription back. The act itself happens elsewhere.

The CNDA file and the pre-series follow separate paths

The CNDA e-prescription certification obtained this way remains in the integrator vendor’s name, ORIGAMI here, for a given version of the software. The vendor’s CNDA action is to file its application. Ordoclic then handles the whole procedure through the final audit, with an Ordoclic technician attending that audit.

The e-prescription pre-series is a separate step. The vendor runs it directly with the national health insurance service, while Ordoclic supplies the engine and activates the required workstation traces. The certification remains recorded against a precise version of the software.

The pattern, for other domain vendors

Lean on an integrator partner rather than aim for a direct connection and an in-house prescribing engine, unless you intend to become a full-time PKI and prescribing-engine vendor.
Keep the vendor responsible for what surrounds the act (context sent to the engine, webhook handling, filing on the record, secure delivery of the PDF to the patient, traceability) and delegate the regulatory plumbing, the drug database and prescribing itself.
Plan the degraded mode that keeps standard prescriptions available when the e-prescription state service is down, and distinguish that case from an Ordoclic outage.
File the CNDA application, let Ordoclic handle the procedure through the audit, then run the e-prescription pre-series directly with the national health insurance service.

If this is sitting in your backlog

If you build health software and e-prescription is on your roadmap, the integrator API route exists and works. This is the kind of work I take on at SXN Labs: framing the need, integrating the partner into a Rails application, running the pre-series with the national health insurance service, and leaving behind a system that is workable and pleasant to maintain.