Imagine walking into a hospital for the first time. You have an appointment, but you don't know which block or floor it's on. You queue at the information desk, or ask the person next to you. You go up to the wrong floor. Added together, these small losses noticeably increase both the patient's time and the hospital's workload.
This was the question behind the project I led under the TÜBİTAK 2209-A programme:
Can a system built on image processing and a Raspberry Pi get patients to their appointments more accurately and faster than manual guidance?
Why it matters
In a study of 319 patients across 10 specialities that we used as a reference, the average waiting time was 64.2 ± 3.45 minutes, while the average service time was 9.85 minutes. In other words, patients spend more than six times as long waiting as they do in the examination. Finding the way is a small but entirely preventable part of that time.
The idea: show your face, find your way
A Raspberry Pi 4 and a camera module placed at the hospital entrance. The patient looks at the device, the system recognises them, finds their appointment in the database and shows on screen: "Block A, 2nd floor, your doctor is …"
How it works
- Capture: The camera image is read with OpenCV.
- Detection: dlib-based face detection finds the coordinates of the faces in the image.
- Encoding: The CNN-based model in the
face_recognitionlibrary computes an encoding for each face. - Matching: That encoding is compared with the encodings of registered patients in the MySQL database.
- Routing: If there is a match, the appointment is fetched and the patient is directed; if there is no appointment, the screen says so.
If face detection fails, the system doesn't leave the patient stranded: it falls back to manual routing with their national ID number. In biometric systems, this fallback path matters as much as the main one.
Real time on a small device
The Raspberry Pi has limited processing power. One of the most effective decisions for running in real time was to keep the reference images in the database at low resolution. Encoding got faster, and we lost nothing noticeable in recognition quality.
The database doesn't live on the Pi; it connects to a MySQL server remotely. That way patient and appointment records stay in the same place as the hospital's existing systems, and the device acts only as an "eye".
What I learned
This project showed me that hardware constraints are a good teacher. Fitting a problem that could be solved with unlimited cloud resources onto a single board forces you to separate what is truly necessary from what isn't. The same discipline helps me today in the systems I build at Jet Kampüs.