Every e-commerce business eventually finds the step that won’t move.
Usually it’s the one where a human has to make a judgement, and the law says a human has to make it. You can put a beautiful funnel in front of it and a slick fulfilment operation behind it, and none of that changes the fact that everything queues at the same door.
For an online pharmacy, that door is the prescription signature.
We spent a long stretch of last year building the system that sits around that door for DrHair. This is what we learned. Most of it applies to anyone running a regulated operation where one step is legally required to stay human.
The problem is not the signature
This is the part that took us longest to see clearly.
When a client says “signing is our bottleneck”, the instinct is to make signing faster. That instinct is wrong, and following it produces a system nobody can defend in an audit.
A prescription needs a prescriber’s signature. Not a scanned image of one, but a signature that is legally attributable to a named clinician, that proves the document hasn’t changed since they approved it, and that holds up if a regulator, an insurer or a court comes asking. That requirement isn’t friction to be designed away. It’s the point.
So we drew a line. The clinical decision doesn’t get touched. Everything else is fair game.
And once you draw that line, you notice how much “everything else” there is:
- Generating the prescription document from the order
- Getting it in front of the right clinician
- Storing it somewhere durable
- Getting the signed copy to the dispensing pharmacy
- Recording who signed what, when, and proving it later
Not one of those is a clinical judgement. All of them were being done by hand. That’s the actual bottleneck: not the two seconds of decision, but the twenty minutes of handling wrapped around it.
Why “just add e-signatures” fails
Most e-signature implementations are theatre.
An image of a signature is composited onto a PDF. It looks right. It satisfies nobody. There is no cryptographic link between the signature and the document, so there is no way to prove the document wasn’t altered afterwards, and no way to prove which human approved it. In a regulated setting that’s not a weak control. It’s the absence of one.
What you need instead is a signature that is mathematically bound to the exact bytes of the document.
For prescriptions, that isn’t best practice. It’s the law. Under the Human Medicines Regulations 2012 (Regulations 217 and 219), an electronic prescription is only valid if it carries an advanced electronic signature: one unique to the prescriber, under their sole control, and linked to the prescription so that any later change can be detected. A typed name or a pasted image doesn’t meet that bar.
What counts as “advanced” is defined by eIDAS: Regulation 910/2014, as retained in UK law after Brexit. It defines three tiers of electronic signature, and the difference between them is not cosmetic.
- Simple SES
- Any electronic mark. A typed name qualifies. Weak evidentially.
- Advanced AdES
- Uniquely linked to the signatory, capable of identifying them, created under their sole control, and linked to the document so that any later change is detectable.
- Qualified QES
- An AdES created on a qualified signature creation device using a qualified certificate. Legally equivalent to a handwritten signature.
DrHair’s prescriptions carry an Advanced Electronic Signature (AdES), issued through Digidentity, a qualified trust service provider, over the Cloud Signature Consortium (CSC) API, the open standard for requesting signatures from a remote signing service.
That distinction is worth stating precisely, because it gets blurred constantly in marketing copy. The provider is qualified. The signature is advanced. Both statements are true, and conflating them into “qualified electronic signature” would be a materially different legal claim, and in our case an unsupported one.
The hashing standard matters as much as the signature tier. The NHS has phased out legacy SHA-1 signatures across its Electronic Prescription Service, and prescribing software must now use SHA-2 or higher, primarily SHA-256, for generating digital signatures. We built DrHair’s signing to that standard.
Concretely, for each prescription:
- Hash. The document is hashed with SHA-256, producing a fingerprint unique to those exact bytes.
- Sign. That hash is signed with RSA-SHA256 using the clinician’s credential, held by the trust service provider.
- Timestamp. The signature is stamped with an RFC 3161 trusted timestamp, so the time of signing comes from an independent authority rather than from our server clock.
The consequence is the thing worth understanding: alter a single character of that PDF afterwards and the signature stops validating. Not “we’d probably notice”. It stops validating, verifiably, for anyone who checks.
That’s the difference between a record you’re asked to trust and a record you can verify. In a regulated business, only one of those is worth having.
The audit trail problem nobody warns you about
Here’s a subtlety that cost us real time, and which we’d expect most teams to get wrong.
When you sign through a remote trust service provider, the identity attached to the signature is the identity the provider holds. That’s correct and necessary. It’s what makes the signature legally meaningful.
But it isn’t sufficient for an internal audit trail. Your logs need to answer a different question: which of our users, logged into our system, initiated this? Those two identities are related but not the same, and if you conflate them you end up with an audit log that says a credential was used without saying who reached for it.
We solved it at the database layer. A trigger fires on the transition from unsigned to signed, looks up the authenticated user who initiated that specific signing action, and writes it to the record. The signature carries the legal identity; the audit trail carries the operational one. Both are true, and they’re stored separately on purpose.
Decide early which identity your audit trail is actually recording, and be able to explain the difference.
Most of the engineering was failure states
The happy path took a fraction of the time. Almost all of the real work went into what happens when things break.
A signing operation touches a lot of infrastructure that can fail independently: object storage, a database, a third-party signing service, a timestamp authority. Any of them can be slow, unavailable, or die mid-request. And the failure modes are asymmetric in a way that matters. Losing a signature is recoverable and annoying. Duplicating one is a compliance incident.
So the system is built to be resumable. Work is tracked in explicit states rather than held in memory, so an interrupted operation picks up exactly where it stopped rather than starting again or half-completing. Every signature is written to an append-only table before anything downstream depends on it. Nothing is inferred from the absence of a record.
Sixteen schema migrations went into getting that right. Almost none of them added features. They added the ability to know, with certainty, what state something was in when a process died.
That ratio, a little feature and a great deal of certainty, is what building in a regulated space actually feels like.
The part that changed the business
The signature was the interesting engineering. The handoff was the interesting outcome.
Before, the dispensing pharmacy received prescriptions at unpredictable times, in inconsistent formats, needing manual checking before anything could be picked. Their throughput was hostage to how organised the upstream process happened to be that day.
Now the signed, timestamped document reaches the pharmacy the moment it’s signed, in the same structure every time, already verified. The pharmacy stopped being an inbox that someone had to remember to check and became a queue that could simply be worked.
That’s worth dwelling on, because it’s the part that generalises. We improved the pharmacy’s operation without changing anything in the pharmacy. The upstream system got disciplined, and the downstream partner inherited the benefit. Most process improvement projects would have gone looking for savings inside the pharmacy’s four walls and found far less.
Where it stands
At the time of writing: 33,552 prescriptions processed, 31,069 signed. Zero re-keyed by hand.
Those numbers matter less than the property underneath them. Compliance in this system is not something a person maintains by being careful. It’s a consequence of how the thing is built. Nobody has to remember to log the signer. Nobody has to remember to timestamp. Nobody can quietly alter a signed document and have it still look valid.
What generalises
If you’re building in a regulated space, four things transfer.
- (01)Separate the step that must stay human from the handling around it. They get conflated constantly, and the handling is usually where the cost actually sits.
- (02)Prefer verifiable to trusted. Any control that depends on someone being conscientious will fail on the day they’re busy. Cryptographic guarantees don’t have off days.
- (03)Decide what your audit trail is recording. Legal identity and operational identity are different questions. Answer both.
- (04)Budget for failure states, not features. In a normal product, an edge case is a bug. In a regulated one, it’s an incident. Price the work accordingly.
Regulated industries don’t reward clever. They reward boring, provable and repeatable. And boring is considerably harder to build than it looks.
Built by Vsual for DrHair