Borne: The Patient Check-In Kiosk That Builds the Clinical Worklist Itself

Try the live demo ↗

When the patient triggers the exam record directly

In most clinics and hospitals, a patient’s arrival sets off a small chain of invisible but costly actions: a receptionist identifies them, checks their appointment, opens their record, and a clinician then decides which exam to run and creates the corresponding order. The self check-in market has digitised the first half of this chain, registration, but almost always stops at the door of the clinical record.

Borne is the patient check-in kiosk application we built at transtorm.ai for an ophthalmology practice, and it crosses exactly this boundary (see also our Patient Kiosk use case). When a patient confirms their presence on the touchscreen, the application does more than notify the front desk: it locates the appointment, identifies the patient, infers the type of consultation from their most recent follow-up, and automatically creates the worklist item in the patient record (the practice’s EHR). All of it self-hosted, multilingual, and without any account or SMS.

This article describes how it works, the technical choices behind it, and, honestly, what it adds compared to an already mature market.

Tuesday, 9:02 a.m. Mrs. Leroy arrives for her glaucoma follow-up and steps up to the touchscreen kiosk by the door. She confirms her appointment time and her initials, nothing else: no card, no code, no SMS. At that moment, with no receptionist touching a keyboard, her worklist is written into the record, ready for the orthoptist and then the ophthalmologist: visual field, OCT, eye pressure, refraction, consultation. The right sequence of exams, inferred from her last visit, already queued.

What Borne actually does

The home screen offers four simple actions on a 1080p touch panel: I have an appointment, Book an appointment, Emergency, Request a document. Behind that apparent simplicity sit several workflows.

1. Confirming presence without a code or SMS

Rather than a PIN code or a link received by SMS, Borne identifies the patient through a combination that is low-friction yet surprisingly robust:

• The appointment time (HH:mm), entered through a column picker in 10-minute increments, far more ergonomic for an older audience than 60 successive choices.
• The initials (2 to 4 characters), with deliberately flexible matching: order doesn’t matter, compound first names are tolerated (cm can match cmf), and an incomplete name in the calendar is still acceptable.
• The year of birth alone when the calendar already contains the date of birth (fast entry), or the full date otherwise, typically for patients who booked online.

The search queries four of the practice’s Google calendars in parallel (main, miscellaneous, and per-practitioner calendars) and stays resilient: if one fails, the others still answer.

2. Automatically detecting the type of consultation

This is one of the most distinctive points. Once the patient is identified in the EHR, Borne retrieves their most recent follow-up and extracts the procedure to perform: a glaucoma follow-up, a keratoconus check, a routine consultation… The visit type is thus pre-filled with no extra input, falling back to “Routine” if nothing is detected.

3. Creating the worklist end to end

Borne searches for the patient in the EHR by similarity (last name, first name, date of birth) with a dynamic threshold (stricter when there is no date of birth). If the patient cannot be found, it falls back to a legacy scheduling system, then creates the patient in the EHR from the retrieved data. An anti-duplicate check prevents multiple records, and an already-registered patient is shown the number of scheduled exams.

The worklist item is then created with the right provider (the doctor inferred from the day’s calendar), the detected procedure and the requested time. Arrivals more than 15 minutes late are flagged with a specific status. On success, a 20-second countdown returns to the home screen, cancellable with a single tap.

4. Booking a new appointment via Cal.com

For new appointments, Borne displays a branded Cal.com iframe: choose the doctor, then the type of consultation among those specific to them (one doctor offers several consultation types, another a smaller set). Assignment cross-references the calendar and the day of the week according to the practice’s real business rules.

5. The mobile companion: the QR code as proof of presence

On a TV screen in the waiting room, Borne displays a QR code pointing to a mobile application. The trick: the URL contains a daily token computed as SHA-256(secret + date) in the Europe/Brussels timezone, truncated to 12 characters. It changes every day at midnight, depends on no database, and can only be read by scanning the physical screen in the practice.

The mobile middleware (Edge-compatible via the Web Crypto API) recomputes the token on every request and rejects stale URLs. As a result, the QR code is not a shareable URL launcher but a cryptographic proof of on-site presence: no account, no login, no SMS. A nice hardware-aware detail: the QR rotates 90° every minute and the text alternates between languages every 15 seconds to prevent OLED burn-in.

6. Touch-friendly, multilingual, and observable

Borne offers a virtual keyboard with five layouts (AZERTY, initials, numeric, e-mail, phone) with touch targets of 56 to 72 px suited to older patients, and six native languages (FR, EN, NL, DE, IT, ES) on both server and client. A calendar-exploration page and an analytics dashboard round out the set. The architecture is a monorepo (kiosk, mobile and shared), containerised with Docker and self-hostable.

How much time does Borne save?

Let’s put some numbers, field estimates, on the chain Borne automates. At a classic front desk, registering a patient ties up the receptionist from end to end:

With Borne, the same registration takes on average ~30 seconds (the appointment time, the initials, the year of birth) and uses zero seconds of front-desk time. The patient goes from ~85 to ~30 s; above all, the receptionist gets back ~85 s per patient, multiplied by the day’s arrivals.

The second effect matters even more: parallelisation. With a single receptionist, five patients arriving together represent roughly five times 85 s of serialised registration, a queue several minutes long in which the person at the desk is the bottleneck. With the kiosk, and the mobile app shown in the waiting room, those five patients register at the same time. Throughput is no longer capped by a single human resource: the registration wait disappears rather than being managed with tickets.

Finally, the automation is designed to fail cleanly. If the algorithm cannot identify the patient with confidence, it does not guess and never creates an erroneous worklist: it simply redirects to the front desk. The worst case is therefore not bad data in the record, but a return to the classic path: exactly the safety net a practice expects.

What the market offers vs. what Borne does

The market is solid and deserves credit for what it does well. The US intake leaders (Phreesia, Clearwave) excel at rich clinical forms, insurance verification and payment. European flow players (Qmatic, ESII, ZORGI) master queue management and waiting-room display. German kiosks (CGM, medondo) integrate the eGK insurance card tightly. Borne claims none of that: no payment, no insurance verification, no complex intake forms.

Its value lies elsewhere: filling a precise blind spot.

The bridge from “patient self check-in → clinical worklist with procedure inference” is, to our knowledge, rare. Intake platforms don’t touch clinical scheduling; the classic DICOM Modality Worklist, for its part, presupposes an order already entered by a human. The IHE Core Eye Care Workflow reference profile confirms as much: the worklist is generated by the EHR after registration, never by the patient in self-service.

The real differentiators, without overselling

End-to-end automation. The main differentiator is not an isolated feature but their chaining: identification → procedure detection → patient creation (or retrieval) → worklist creation, with no human intervention on the nominal path. The trade-off is that it requires clean clinical data and inference logic to maintain: this is a business system, not a simple form.

Mobile security through physical presence. Where the market rests security on a link sent over an uncontrolled channel (SMS, e-mail) or on circumventable geolocation, Borne makes being physically in front of the screen the condition of access. It’s elegant and anti-phishing by design. The core idea is not the token’s brute-force strength but the coupling of “read on site” and “daily rotation”: the token length, and therefore its entropy, is simply a parameter, trivial to increase if the context calls for it. The model is calibrated for local use, and that sizing remains a design choice, not a structural limitation.

Sovereignty. Borne runs on the practice’s own infrastructure, including a machine on-site: the data never leaves the premises. That is what avoids the Cloud Act exposure inherent to US vendors and removes the per-kiosk subscription. The flip side, which must be owned, is real: maintenance, updates and backups fall on the practice or its provider.

Native multilingualism and open-source integration. Six languages out of the box and a booking flow built on Cal.com (open-source, AGPLv3) rather than a proprietary calendar: the practice controls its booking foundation and its data.

Conclusion

Borne does not try to rival Phreesia on intake richness, nor Qmatic on queue management. It occupies a niche those players leave vacant: a lightweight, single-specialty, multilingual and sovereign kiosk that turns presence confirmation into an automated clinical act: the exam worklist is created by the patient themselves, with the right consultation type already inferred.

It’s a deliberate stance: less functional surface, but deeper vertical integration, more control over data, and the elimination of redundant daily data entry. For a practice that already controls its patient record and its calendar, it’s an approach that favours useful automation and sovereignty over the promise of an all-in-one suite. As with any self-hosted solution, the operational burden remains to be owned, an increasingly worthwhile trade-off as health-data sovereignty concerns take hold across Europe.

Beyond ophthalmology: a transferable pattern

Same week, in a bank branch. Mr. Martin has an appointment about his loan application. Rather than wait at the counter, he scans the QR shown at reception: the app opens on his phone, with no account or login, the mere fact of being able to scan that on-site screen enough to prove he is there. He confirms his presence. Right away, his advisor sees the right file open: the expected client, the purpose of the visit, his loan request, already routed to the right desk. Here too, no one at reception had to direct him.

While the application was born for an ophthalmology practice, its real asset is the underlying pattern: “on-site self-identification → a business action triggered automatically in the downstream system”, paired with a mobile companion secured by physical presence alone. This scheme transfers to any context where people show up for an appointment and a back-office task should follow.

• Other medical and allied-health specialties: the same “presence → exam creation” chain applies to radiology/imaging (generating the DICOM worklist), analysis labs (sampling orders), physiotherapy or dentistry (preparing the session and the quote).
• Hospital care: pre-admission and routing by department, with automatic creation of the visit record.
• Public services and government offices: town halls, prefectures, benefits agencies, where the citizen confirms their appointment and the matching case is opened and routed to the right desk, with no queue or paper ticket.
• Banking, insurance, services: branch reception with automatic opening of the client file and assignment to the day’s advisor.
• Garages, workshops, logistics: checking in a vehicle or a delivery that directly creates the repair order or the stock receipt.
• Beauty, wellness, fitness: class or treatment check-in that decrements a subscription and notifies the practitioner.

In all these cases, the two key innovations still hold: saving a human resource by automating the downstream task rather than merely “registering”, and securing mobile access through physical presence rather than an account or a shareable link. The technical foundation (multilingual touch kiosk, QR-based mobile companion, integration with a business system via API, GDPR-friendly self-hosted deployment) is itself already domain-agnostic.

At transtorm.ai , this is exactly the kind of reliable, measurable micro-process we design: useful automation, integrated with your tools, keeping a human in the loop where it matters.

Could this pattern fit your operation?

See Borne in action on the demo: transtorm.ai/demos/kiosk.

On-site presence, a back-office task triggered automatically downstream: this pattern reaches well beyond ophthalmology. If people show up for an appointment in your line of work and an action needs to follow, let’s talk. Book a call with transtorm.ai .