When someone tells me they need Qualified Electronic Signatures for online prescriptions, I start by asking two questions:

How many people are going to be signing?

And where are those people based?

That might sound almost too simple. It is not, as those two answers usually tell us whether we are dealing with a straightforward local signing flow, a small group of doctors generating a very high volume of prescriptions, or a cross-border setup that needs to work across several markets.

They also tell us which questions need to come next.

How often will each doctor sign? Where will the prescriptions be dispensed? How should the doctors be onboarded? What should they have to do each time they sign? And which countries are likely to come after the first launch?

This is why I think ePrescription platforms need more than an eSignature provider.

They need a signing setup that fits the way their doctors actually work.

A recent conversation summed it up nicely

I was recently on a call with a healthcare company preparing to launch in Germany.

The business itself was based elsewhere in Europe. Germany was the immediate priority, but the team was already thinking about the markets that might come next.

Their developer had also done some homework. Before we had even spoken, he had tested one of our signing flows locally in the sandbox.

So this was not a conversation about whether an electronic-signature API existed.

The real questions were:

• How would each doctor receive a qualified certificate?
• Would they have to verify their identity for every prescription?
• Would they need to choose a signing provider every time?
• What would the signing step look like inside the existing platform?
• Which provider made sense for their expected prescription volume?
• Would the same integration still help when they expanded into another country?

The legal requirement was only the start of the discussion.

For electronic prescriptions in Germany, Section 2 of the Arzneimittelverschreibungsverordnung, or AMVV, expressly requires the Qualified Electronic Signature of the prescribing person. That gives platforms a clear reason to look for QES. It does not automatically tell them which provider, certificate model, user experience, or commercial setup will work best for their product.

That is the part we normally work through together.

Why do signer count and location matter so much?

The practical answer is that an ePrescription platform does not just need an API endpoint that produces a signature.

It needs a trust-service setup that fits:

• The number of prescribers
• The countries those prescribers are in
• The country where the prescription will be used
• The expected number of prescriptions
• The frequency with which each person signs
• The certificate and identity-verification process
• The experience required for each individual signature
• The platform’s expansion plans

The location of the business itself is not always the most important location.

A company might be headquartered in Austria, employ doctors in Germany, and issue prescriptions intended for German pharmacies. Another company might have doctors across several EU countries but initially serve only one market.

Those are different setups.

The prescriber’s location can affect which identity and certificate methods are available to them. The dispensing market determines which prescribing, signing, transmission, and pharmacy requirements the workflow needs to meet.

Then there is volume.

That is where the maths gets interesting.

Few doctors can still mean a very large signing operation

The number of signers in an ePrescription business can sound small at first.

Ten doctors. Fifteen doctors. Perhaps twenty.

But that does not mean the signing use case is small.

I have seen setups where a group of roughly 15 doctors was responsible for hundreds of thousands of prescriptions a year.

That is very different from a platform where thousands of consumers each sign one document and then disappear.

In an ePrescription workflow:

• The signers are known professionals.
• The same people sign repeatedly.
• Signing happens as part of their daily work.
• A small amount of friction gets repeated thousands of times.
• A small difference in transaction cost can become significant at scale.
• Certificate expiry or provider downtime can affect a live clinical workflow.

The number of doctors may be modest.

The operational importance of the signing process is not.

This is why I always separate two questions that are often bundled together:

How many people are signing?

And:

How many signatures will those people create?

A provider that works well for occasional consumer signing may not be the right provider for doctors issuing prescriptions throughout the day.

What makes ePrescription signing different from ordinary document signing?

Most people think about electronic signatures in terms of documents.

A contract needs to be signed. A customer receives an email. They open the document, identify themselves, sign once, and move on.

ePrescription signing has a different rhythm.

The doctor is already inside a clinical or prescribing platform. They have completed a consultation, made a clinical decision, and prepared a prescription. Signing is the last regulated step before the prescription continues into the pharmacy or national infrastructure.

The signature should therefore feel like part of the prescription workflow, not like a separate administrative task.

That changes what a platform should look for.

The right setup needs to answer questions such as:

• Can the signing method be embedded into the existing journey?
• How much interaction is required for each prescription?
• Does the doctor need to leave the platform?
• Can the method support frequent repeat signing?
• What happens when authentication fails?
• How quickly does the signed result return?
• How are certificate expiry and renewal handled?
• What does the platform receive for audit and validation purposes?
• Who helps when something stops working?

The best provider on paper is not necessarily the best provider inside a live prescribing product.

Doctor onboarding is part of the product

This is one of the areas that gets underestimated.

To create a Qualified Electronic Signature, the doctor needs an appropriate qualified certificate and a signing method that remains under their control.

That means there is an onboarding process.

The doctor’s identity must be verified according to the provider’s requirements. A qualified certificate must then be issued or activated. Depending on the provider and certificate model, that certificate may remain available for repeat signing until it expires or needs to be replaced.

The doctor does not normally complete the entire identity-verification process from the beginning for every prescription.

They do, however, need to authorise each signature through the mechanism required by the provider. That might be an app confirmation, PIN, redirect, strong-authentication step, or another prescriber-controlled action.

The exact experience differs by provider.

And that experience matters.

A platform should know:

• Who invites the doctor to begin onboarding?
• Is onboarding self-service?
• Who pays for the certificate?
• Can the platform cover that cost for the doctor?
• Can voucher codes or invitations be distributed centrally?
• What happens when a new doctor joins?
• What happens when a doctor leaves?
• How is certificate renewal communicated?
• Who supports the doctor if verification fails?
• Can onboarding be managed efficiently when the prescriber group grows?

A technically clean signing API can still produce a painful rollout if doctor onboarding is treated as an afterthought.

Put more bluntly:

If onboarding ten doctors requires ten improvised email chains, the API is not the only part of the workflow that needs attention.

Should doctors choose a signature provider every time?

No.

At eID Easy, we provide access to a worldwide network of more than 80 trusted eSignature and electronic-identity methods through one API. That network currently covers more than 160 countries and territories.

But that does not mean a doctor should see a catalogue of 80 options whenever they issue a prescription.

The network is there to give the platform flexibility behind the scenes.

The platform should configure the provider or small set of methods appropriate for its prescribers and workflow. The doctor should see the experience relevant to them.

That might be:

• One preselected provider for all doctors
• A different method based on the doctor’s country
• One provider for the German prescription workflow and another for a separate market
• A primary method with a suitable fallback
• An existing local eID for some users and a newly issued certificate for others

The important distinction is this:

Provider choice belongs in the platform architecture. It should not become a new decision for the doctor every time they prescribe.

The value of a large provider network is optionality, not more buttons.

What makes a QES provider suitable for ePrescriptions?

There is no single best Qualified Trust Service Provider in the abstract, there is only a provider that fits a particular workflow better or worse.

For an ePrescription platform, I would normally look at:

1. Prescriber coverage

Can the provider onboard the doctors or veterinarians in the countries where they are based?

2. Certificate model

Does the provider issue a certificate suitable for recurring professional use? How long does it remain valid? What triggers renewal or replacement?

3. Per-signature experience

What does the doctor actually have to do each time? Is the flow realistic for someone signing repeatedly during a working day?

4. Technical integration

Does the provider support the required file or signature format? Can the signing journey be embedded, redirected, or handled through the platform’s own interface?

5. Reliability

What happens during a provider outage? How are errors surfaced? Is there an escalation path? What support and service commitments are available?

6. Commercial structure

Are there setup fees, access fees, certificate costs, minimum commitments, or per-signature charges? How does the total cost behave as volume grows?

7. Geographic usefulness

Does the provider solve only the first country, or can it remain useful when the platform expands?

That last question is easily overlooked when everyone is focused on an upcoming German launch.

Six months later, it can become the main question.

8. The cheapest signature is not always the cheapest setup

At high volume, per-signature pricing matters.

There is no point pretending otherwise.

When a platform expects hundreds of thousands of prescriptions, even a small difference in transaction cost can have a real effect.

But the transaction price is only one part of the calculation.

The full cost can include:

• Provider setup and API-access fees
• Minimum annual or monthly commitments
• Certificate issuance
• Prescriber onboarding
• Internal support work
• Integration and maintenance
• Certificate renewal
• Failed signing attempts
• Direct provider management
• Additional integrations for new markets

A low transaction price can look attractive until the platform discovers that onboarding is awkward, doctors need too many steps, or the method only works for one part of the expansion plan.

The opposite is also true. A provider with a small certificate cost may be very economical when a doctor uses that certificate to sign thousands of prescriptions.

The right comparison is therefore not:

Which provider has the lowest price per signature?

It is:

What is the total cost of making this work for our actual prescribers, volume, workflow, and expansion plan?

That is a much more useful question.

Germany may be the launch, not the destination

Germany often creates the immediate need because the AMVV explicitly names QES for prescriptions issued electronically.

But many of the companies we speak with do not intend to remain Germany-only businesses.

They may already operate in Austria. Czechia may be next. Another customer opportunity might suddenly make France, Spain, or a non-EU market relevant.

Under eIDAS, a Qualified Electronic Signature based on a qualified certificate issued in one EU Member State must be recognised as a QES in the other Member States. A QES also has the equivalent legal effect of a handwritten signature.

That cross-border recognition is valuable.

It does not mean one signing setup automatically makes every prescription acceptable in every country.

Each market can still have its own rules concerning:

• Who may prescribe
• Which professional credentials must be checked
• What information the prescription must contain
• Which medicines may be prescribed remotely
• Which national system receives the prescription
• Which technical format is required
• How the pharmacy retrieves and validates it

Recognition of the signature and acceptance of the prescription are related, but they are not identical.

That is why I tend to describe the sensible approach as:

Germany first, Europe ready.

Solve the requirement that is holding up the launch now.

Just avoid solving it in a way that forces the platform to rebuild its signing layer when the next country becomes relevant.

One API is useful. One operational relationship may be even more useful.

The obvious benefit of an aggregation platform is the API, instead of integrating directly with several providers, the platform completes one core integration and enables the methods it needs.

For many customers, aggregation can also reduce the number of:

• Provider contracts
• Billing relationships
• Data-processing reviews
• Support desks
• Onboarding processes
• Technical dependencies
• Provider-specific maintenance tasks
• Escalation paths

That matters when something goes wrong.

When a doctor cannot sign a prescription late in the afternoon, the platform does not want to work out which provider owns the issue, which support portal to use, or which integration team needs to investigate.

It wants one place to go.

A useful aggregation layer should therefore do more than route API requests.

It should help the platform select an appropriate method, understand the onboarding model, add new providers, investigate problems, and adapt as the product enters new markets.

The API is the technical connection.

The operational relationship is what keeps that connection manageable.

I like it when the developer tests before the sales call

On the recent call I mentioned earlier, the developer had already tried the sandbox before we spoke.

Honestly, that made the conversation easier.

We did not need to spend half the call describing what an authentication redirect might look like. He had seen the flow. He had tested it locally. He already understood the basic integration pattern.

We could focus on the questions that actually needed discussion:

• Which provider should be enabled?
• How would doctor onboarding work?
• What would the commercial model look like at the expected volume?
• How would the setup support the next market?

That is generally a healthier buying process.

eID Easy supports several implementation approaches, including a hosted signing page, API-based signing, browser-side components, and flows where only the file hash is sent for signing rather than the full document contents. The standard API process is to prepare the content, let the user complete the provider-specific signing flow, and retrieve the signed result.

Testing early helps the developer answer practical questions:

• Does the redirect fit our product?
• Can we keep the interface inside our platform?
• What information does the provider ask the doctor to enter?
• How do callbacks and success states work?
• What happens after a failed attempt?
• What signed output do we receive?
• Can we use a file-hash flow for privacy-sensitive content?

It also means the commercial conversation can focus on the real setup rather than a generic demonstration.

High volume is not only about throughput

When people say they need a high-volume signing solution, they often mean the provider needs to process a large number of signatures.

That is true.

But the number of API calls is only one part of high-volume readiness.

At scale, the platform also needs to think about:

• Provider availability
• Failed authentication attempts
• Redirect and callback handling
• Timeouts and retries
• Certificate expiry
• Certificate revocation
• Signature validation
• Audit evidence
• Monitoring and alerting
• Support response times
• Provider escalation
• Sudden increases in prescription volume

A cheap signature is not very useful when the doctor cannot complete it and prescriptions are waiting.

A technically valid signature flow is not enough if the platform has no clear way to understand failures, retrieve the signed result, or support the prescriber.

High-volume readiness is really about operational predictability.

The signature needs to work consistently enough that it becomes a normal part of the prescribing journey rather than an exception the operations team keeps dealing with.

What I ask before recommending a setup

The first two questions are still the most important:

How many people will sign?

Where are they based?

Then I normally want to know:

1. Where will the prescriptions be dispensed?
2. How many prescriptions do you expect per month?
3. What might that volume look like in twelve months?
4. Are the prescribers employees, contractors, or a mixture of both?
5. Do any of them already have suitable qualified certificates?
6. Who will manage onboarding and certificate renewal?
7. What should the doctor have to do for each signature?
8. Do you want a hosted flow, embedded component, or fully controlled interface?
9. Which pharmacy or national infrastructure comes after signing?
10. Which country is likely to come next?
11. What is the real launch date?
12. What support and service expectations do you have?

A perfect five-year forecast is not necessary, Aa reasonable estimate is enough to avoid selecting a provider based on the wrong assumptions.

What about European Digital Identity Wallets?

I am cautious with the phrase “future-proof.”

Technology changes. Regulations change. Providers change. Anyone promising that an integration will never need attention again is making life sound tidier than it is.

But platforms can still avoid unnecessary rebuilding.

The amended eIDAS framework requires European Digital Identity Wallets (EUDIW) to support qualified electronic signatures. That creates another potential route through which professionals may authenticate and sign as wallet ecosystems become available and relevant to their workflows.

I would not design today’s ePrescription product around the assumption that wallets will instantly replace every existing method.

I would design it so that adding a wallet-based method later does not require rebuilding the entire prescription platform.

That is the useful version of future readiness:

Keep the core integration stable while allowing the signing methods behind it to evolve.

The point is not to have the longest provider list

A large provider network is useful.

But provider count is not the final outcome.

The outcome is that the right doctor can sign the right prescription, using an appropriate method, without the platform having to build and maintain a separate trust-service integration every time something changes.

For Germany, the QES requirement gets the conversation started.

The real product decision is how to make that requirement work for:

• The doctors
• The expected prescription volume
• The launch timeline
• The user experience
• The operational team
• The countries that come next

That is why I ask about signer count and location before talking about providers.

Those two answers usually reveal the shape of the whole problem.

Frequently asked questions

Why does an ePrescription platform need more than an eSignature provider?

Because the provider is only one part of the workflow.

The platform also needs to consider prescriber identity verification, qualified-certificate issuance, recurring authentication, integration design, certificate renewal, transaction volume, support, national prescription requirements, and expansion into new markets.

The right provider must fit that complete setup.

Does every doctor need an individual qualified certificate?

A Qualified Electronic Signature is linked to an identified natural person and is based on a qualified certificate.

In a prescription workflow, the individual prescriber therefore needs an appropriate certificate or qualified signing credential connected to their identity. The exact issuance, storage, and renewal model depends on the selected Qualified Trust Service Provider.

Does a doctor need to verify their identity for every prescription?

Normally, the doctor does not repeat the complete identity-verification and certificate-issuance process for every prescription.

Identity verification usually takes place when the qualified certificate is issued or activated. Each individual signature still requires the doctor to authenticate, approve, or consent through the process specified by the provider.

The precise interaction varies between providers and certificate models.

Should doctors choose a QES provider every time they prescribe?

Generally, no.

The platform should configure the provider or signing methods appropriate for the workflow. The doctor should see the relevant signing experience rather than a full provider catalogue.

A unified API gives the platform flexibility to add or change supported methods behind that experience.

Is integrating directly with a QTSP always cheaper?

Not necessarily.

A direct integration may be appropriate for a stable, single-provider workflow. But the comparison should include more than the per-signature price.

Platforms should also consider access fees, minimum commitments, certificate costs, development, onboarding, maintenance, support, and the cost of adding another provider or country later.

Can one QES setup support several EU countries?

A QES based on a qualified certificate issued in one EU Member State must be recognised as a QES in the others.

However, that does not automatically mean the prescription itself satisfies every country’s professional, clinical, technical, transmission, and dispensing rules. Each national workflow still needs to be reviewed.

What information should we prepare before speaking with eID Easy?

The most useful starting information is:

• The number of doctors or veterinarians
• The countries where they are based
• The market where prescriptions will be used
• Expected monthly and annual volume
• The intended launch date
• The countries likely to follow
• The preferred doctor experience
• Any integration work already completed

That is normally enough to begin narrowing down the suitable signing setup.

Can our developer test the signing flow before we select a provider?

Yes.

Testing the flow early allows the development team to understand the authentication experience, redirects, callbacks, integration options, and signed output before a production setup is agreed.

eID Easy provides hosted, API-based, component-based, and file-hash signing approaches for different technical and privacy requirements.

Already know your signer count and expected volume?

Send us:

• How many doctors or veterinarians will sign
• Where they are based
• Your expected monthly prescription volume
• Your target launch date

That is usually enough to start a useful conversation about the provider, certificate model, onboarding flow, and technical setup.

Talk to me →

Explore the API Documentation →

This article provides general information about electronic signatures and ePrescription workflows. It is not legal or medical advice. Applicable requirements depend on the country, prescription type, medicine, prescriber, and technical workflow.