How QES Developer Unified Signing Layer enabled Medentic to deliver regulated dental workflows

Two dental workflows enabled by QES

Medentic needed to support two high-value workflows for dental clinics.

The first was an end-to-end patient document workflow. Dentists could prepare treatment agreements, informed-consent forms, and other clinic documents digitally. Patients could sign them in the clinic, the dentist could automatically finalize the document with a qualified electronic signature, and Medentic could keep the completed document inside the normal clinic workflow.

This replaced a paper-heavy process where signed patient documents had to be printed, manually stored, and retained physically for long periods. For medical documentation in Bulgaria, 15 years is a minimum retention period.

The second was a compliance workflow. Dentists needed to sign and submit electronic dental and medical documents to Bulgarian national healthcare systems, including HIS.bg, the Bulgarian National Health Information System operated as a Ministry of Health platform, and NHIF/RHIF workflows. NHIF is the Bulgarian National Health Insurance Fund. RHIFs are the Regional Health Insurance Funds through which NHIF operates across the country.

The real clinic environment

Dental clinics do not all run the same technical setup. A dentist may use a local hardware token on a desktop or laptop, custom signing software from a certificate provider, a cloud QES provider, or a mixed environment across Windows, macOS, and Linux.

Those differences matter in production. Hardware tokens need drivers. Provider software changes. Desktop signing tools need to keep working after operating-system updates. Dentists should not need to understand which driver to install, where to download it from, or how to maintain every manufacturer-specific component.

What QES simplified

QES gave Medentic a unified signing layer instead of a collection of provider-specific integrations.

QES simplified the operational side as well. Instead of asking dentists to understand drivers, token manufacturers, provider software, and operating-system differences, QES provided a single desktop application that could scan the machine, detect the available QES setup, connect local hardware tokens used on desktops or laptops, and keep the required manufacturer components current so signatures continued to work.

Medentic could then request signatures, receive signing events, track completion or failure states, and continue the business workflow without building separate logic for every token, provider, and operating system.

The same layer also supported optional cloud QES flows and positioned Medentic for stronger identification patterns, including future wallet-based identity flows as European digital identity infrastructure matures.

Outcome

QES became the infrastructure layer that let Medentic provide regulated dental workflows across real clinic environments.

Dentists could digitalize patient agreements and treatment documents, apply qualified electronic signatures when needed, and submit regulated healthcare documents without being forced into an expensive cloud-only model or a single approved hardware setup.

Medentic could focus on the dentist and patient journey while QES handled the signing infrastructure, desktop bridge, provider differences, hardware-token support, and signature events behind the scenes.

End-to-end digital patient document workflows for treatment agreements, informed consent, and clinic forms

Reduced dependence on paper storage for medical documents with 15-year minimum retention requirements

Qualified electronic signatures for regulated dental and medical documents

Submissions to Bulgarian national healthcare systems, including HIS.bg and NHIF/RHIF workflows

One signing layer across local hardware tokens, desktop signing software, optional cloud QES, and multiple providers

Signature events returned to Medentic instead of provider-specific signing logic living inside the product

Foundation for stronger identity workflows, including future wallet-based identity flows