ORIGAMI, the healthcare business application I develop and maintain in production for emergency-medicine dispatch, now offers digital prescriptions to its prescribers. The wiring was not done directly against the French health insurance teleservices, but through Ordoclic, which exposes its e-health services as an API to integrator editors. The product’s CNDA Digital Prescription certification was obtained on the ORIGAMI side, by going through the CNDA pre-series review in our own name, with Ordoclic providing the underlying technical and functional foundation.
I wanted to document this path because it is poorly known, and it changes the cost/benefit balance for a small editor wondering whether to add e-prescription to their feature set.
The setup: a business application that needs to prescribe
ORIGAMI is a Rails application used by practising healthcare professionals. At some point, electronic prescription stops being optional: paper flows become friction for both the prescriber (who wants to push directly to the pharmacist) and the patient (who does not want to carry a sheet around). The editor needs to generate structured, signed prescriptions, deposit them into the secure database hosted by the CNAM, and let pharmacists retrieve them from an identifier.
Once that need is stated, there are two paths.
The two possible paths
The direct path. The editor registers themselves with the ANS, builds their PKI chain, manages server and software certificates, integrates Pro Santé Connect or CPS cards for professional authentication, talks directly to the digital prescription teleservice, develops and certifies their own Prescription Assistance Software (LAP) with the HAS (including an approved drug database, interaction and contraindication checks, dosing guidance), and goes through the CNDA process on their own. This is the path of large legacy editors. It has a clear logic: you control the chain end-to-end and depend on no one. It also has an entry and maintenance cost that is not absorbable by a one- or two-developer outfit without warping the rest of the product.
The integrator-API path. The editor relies on a partner already connected to the teleservices and already HAS-certified as a LAP, who exposes a simpler API on the editor side and factors out the regulatory plumbing. That is what Ordoclic offers, through its integrator API. The business application consumes the services; the editor still passes their own CNDA Digital Prescription certification, leveraging the Ordoclic stack as a compliant foundation. For the end user (the prescriber), the experience is identical to one offered by a direct-connection editor: they prescribe, it goes out, the pharmacist queries the database, the loop is secured.
The choice between the two is not a matter of technical pride. It is a matter of how much regulatory surface you want to carry in-house.
What Ordoclic takes on
The partner handles most of the friction that makes the direct path heavy:
- Connection to CNAM teleservices and the broader ANS ecosystem, with the associated server certificates and IGC-Santé trust chain.
- Healthcare professional authentication through Pro Santé Connect / e-CPS and CPS card reading, without the editor having to handle these low-level flows directly.
- Electronic signature of the prescription and deposit into the secure database, in the format pharmacists expect, with a unique QR code.
- Dispenser-side retrieval through the prescription identifier.
- The LAP itself: a digital prescription engine certified HAS V2 (ambulatory LAP), CE-marked (medical device), and CNDA-approved for digital prescription. Ordoclic describes itself as “multi-database” and exposes, through its LAP, an up-to-date drug database with alerts (interactions, contraindications) and dosing guidance, exactly the scope the HAS requires of an ambulatory LAP. That is what makes the HAS certification so heavy to carry solo: a demanding framework, an approved drug database to integrate (Vidal on the Ordoclic side), and revalidation at every evolution. On the ORIGAMI side, we consume.
- Guidance through the CNDA pre-series review, the mandatory step for the integrator editor to obtain their own Digital Prescription certification.
The editor remains responsible for everything that is business-specific: modelling prescriptions in their domain, the prescriber-side UX, application-level tracing, cancellations and reissues, and consistency with the rest of the patient record.
What Ordoclic does not replace
The prescriber’s clinical responsibility, and more broadly the editor’s responsibility for their own business application, do not disappear. Alerts produced by the drug database flow back through the API into ORIGAMI, and the prescriber makes the final call. The business application must display those alerts correctly, trace the decision, and handle domain-specific degraded modes. Degraded behaviour must be designed on the editor side: what happens if the API is down during the consultation? The prescriber must be able to continue their work, and the prescription consolidates when the service comes back.
The Rails integration
The wiring is not exotic. Authenticated HTTP calls against the Ordoclic integrator API, from a dedicated service layer. The patterns I use elsewhere in the application apply unchanged: Result objects out of every call, ViewComponent for the prescription screens, ActionPolicy to control who can prescribe, Sentry for traceability. On the UI side, Ordoclic also offers widget and iframe modes, useful when one wants to integrate faster without reimplementing the prescription form. ORIGAMI went for a pure API binding, to keep full control over the prescriber UX.
The real work happens elsewhere.
First, prescriber authentication. On the Rails side, you must know with certainty which user is acting, in which exercise context, and tie that to an identifier usable on the API side (typically derived from the RPPS). That flow is not rebuilt in three lines: it is set up when the practitioner’s account is configured, and it must remain current at every prescription.
Second, signature and format. A digital prescription, in the teleservice sense, is not a signed PDF sent by email. It is structured, signed data, deposited in the CNAM database, queried by the pharmacist from an identifier. Ordoclic handles the technical format; the editor must provide clean, complete, traced data.
Third, prescriber-side UX. That is the invisible stake that separates a usable integration from a deployed-but-avoided one. The prescription screen must fit naturally into the consultation flow, display interaction and contraindication alerts cleanly as they come back from the API, add no useless steps, and behave well when the network is unstable or the service is slow. Those concerns sit entirely with the editor, and that is where adoption is won or lost.
What CNDA certification through Ordoclic actually is
To clarify a point that often gets blurred: CNDA Digital Prescription certification obtained through this path is a certification carried by the integrator editor themselves (ORIGAMI in our case), for a given software version. It is obtained by going through the CNDA pre-series review while relying on Ordoclic’s LAP and digital prescription engine as a compliant technical foundation. It authorises distribution of that version to healthcare professionals for the digital prescription feature. It is traceable, tied to a precise version, and replayed at every significant evolution.
It is neither a solo approval obtained through a direct connection, nor an approval passively inherited from the partner. It is a certification held in your own name, obtained through a path that many business-software editors under-use out of unfamiliarity.
The pattern, for other business-software editors
For a Rails editor maintaining a healthcare business application who wants to add digital prescriptions without absorbing all the ANS paperwork and the development of a HAS-certified LAP in-house, the pattern is viable and comes down to a few points:
- Lean on an integrator partner (Ordoclic is one) rather than aiming at a direct connection plus in-house LAP if the company has no ambition to become a full-time PKI + LAP editor.
- Keep the editor in charge of the business (domain modelling, UX, degraded behaviour, application-level tracing, clinical-alert rendering) and delegate to the partner what is regulatory plumbing and drug-database upkeep.
- Treat CNDA certification as a state attached to a version, not a one-off event: replay compliance at every significant evolution.
It is the same spirit I described for INSi: take the time to wire e-health building blocks in cleanly, leveraging what already exists on the ANS side and through certified partners, instead of rebuilding everything in-house.
If you have this on your roadmap
If you maintain a healthcare business application and digital prescriptions are on your roadmap, you do not have to choose between absorbing everything in-house and giving up. The integrator-API path exists and works. This is the kind of work I take on at SXN Labs: framing the need, integrating the partner cleanly into a Rails application, walking through CNDA pre-series, and leaving behind a system that is operable and pleasant to maintain.