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 certification for e-prescription, though, belongs to ORIGAMI: we ran the pre-series in our own name, with Ordoclic as the technical foundation.
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 line-of-business software consumes those services and obtains its own CNDA certification on top of that foundation. For the doctor, the experience is the one a directly connected vendor gives: they prescribe, it goes out, the pharmacist queries the database.
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.
- Support through the CNDA pre-series, the mandatory step for an integrator vendor to obtain its own certification.
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.
When the partner is down
This is what the route costs: if Ordoclic does not answer, nobody prescribes electronically. No degraded mode will produce the prescription later, since signing and filing in the national database both go through the partner. The fallback is a paper prescription.
Better to tell the prescribers before go-live. INSi took an outage better: care carried on, only identity verification stayed pending. Here the feature stops dead, and the availability you announce to doctors is the partner’s, not yours.
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 CNDA certification belongs to the vendor
The CNDA e-prescription certification obtained this way belongs to the integrator vendor, ORIGAMI here, for a given version of the software. It is earned by running the CNDA pre-series on top of Ordoclic’s engine as a compliant foundation, and it authorises releasing that version to health professionals.
So it is neither an approval earned alone through a direct connection, nor one passively inherited from the partner. It is recorded, attached to a precise version, and replayed on every significant change.
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 paper fallback and announce it to prescribers, because the feature’s availability becomes the partner’s.
- Treat CNDA certification as a state attached to a version, replayed on every significant change.
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, seeing the CNDA pre-series through, and leaving behind a system that is workable and pleasant to maintain.