--- canonical: https://queue.care/guides/connect-clinic-queue-to-existing-system language: en updated: 2026-08-29 site: QueueCare contact: https://wa.me/962782533233 email: support@queue.care --- # Can a queue system connect to the patient database we already have? **Often, yes — QueueCare ships a local bridge that reads an on-premise SQL Server or Oracle database, so file numbers and names come across instead of being retyped.** _By ATA ATA, practising optometrist. Published 2026-08-29, last updated 2026-08-29._ ## Retyping is the cost nobody prices A clinic that already runs a patient system does not have a data problem. It has a double-entry problem: the patient exists in the old system, and the receptionist types the name again to put them in the queue. Twice a minute, all morning. That is where the errors come from, and it is the reason queue systems get abandoned three months in. A second place to type a name is a second place for a name to be wrong. ## What the bridge actually is A small agent that runs on the clinic's own server, inside the clinic's own network. It is not a cloud connector reaching into the building, and there is no port to open for it. On installation it performs a one-time, read-only structural scan of the local database to find the tables that hold patients. After that, it synchronises only the fields the clinic has explicitly mapped and approved, over an encrypted connection. The database credentials it needs are supplied by the clinic's own IT administrator and stay on the clinic's own server. They are not sent anywhere. ## What it reads, and the one thing it writes This is the part worth being precise about, because it is the part a clinic's IT person will ask first. The detection step reads names only. It queries the standard system catalogue for databases and table structures, the same information any read-only reporting tool sees, then scores them for clinic-shaped names. It does not read patient rows to decide. Looking a patient up is read-only too: the bridge searches by file number or name and hands back the fields the clinic mapped. Nothing about that path can alter the source. There is exactly one write, and it is deliberate. When reception registers a patient who is not in the clinic's system yet, that patient is written into the clinic's own database. That is where a patient record belongs. Editing them afterwards updates that one row, matched on its file number. No schema is altered, nothing is deleted, and no bulk update is ever issued. It is the reason the record does not accumulate in our cloud instead: the clinic's database stays the system of record, and we keep the queue. None of it happens unless the clinic has configured the bridge with its own address and key. Without those the call does nothing at all — and a clinic that wants the queue and no writing simply does not turn the bridge on. ## When it does not fit Sometimes it does not, and the honest answer is worth more than a demo. A bespoke system with no accessible database, a hosted product whose vendor exposes nothing, a schema with no recognisable patient table — these exist. The bridge will not conjure a connection that is not there. Tell us what you run and you will get a straight answer about whether it fits before anybody installs anything. A clinic can also run QueueCare with no bridge at all. Patients check in from their own phone by scanning a QR code, which means the queue can fill itself without reception typing anything and without touching the old system. ## Questions clinics ask before they start ### Which databases does the bridge support? SQL Server and Oracle are the ones it is used with most; MySQL and PostgreSQL are also on-premise databases it can read. What matters more than the engine is whether the schema has a patient table it can be pointed at. ### Does the bridge send our whole database to the cloud? No. It synchronises only the fields explicitly mapped and approved during setup — typically a file number and a name. Everything else stays where it is. ### Where do the database credentials live? On the clinic's own server, entered by the clinic's own IT administrator during installation. They are not transmitted to QueueCare. ### Can we start without the bridge and add it later? Yes. Most clinics start with phone check-in and reception entry, and add the bridge once the queue itself is part of the daily routine. ## Related guides - [What data privacy laws apply to clinic patient queues, and is the data safe in the cloud?](https://queue.care/guides/clinic-patient-data-privacy) - [How long does it take to set up a clinic queue system?](https://queue.care/guides/clinic-queue-system-setup-time) - [What should I ask before choosing a clinic queue system?](https://queue.care/guides/choosing-a-clinic-queue-system) - [Can a clinic queue system be customised to our workflow?](https://queue.care/guides/custom-features-for-your-clinic) ## See it with your own queue in it. Open the demo and you are standing inside a working clinic — doctors mid-session, patients in line, screens calling names. Nothing to install, nothing to sign. - Open the live demo: https://queue.care/demo - Guides for clinics: https://queue.care/guides --- This is the Markdown rendering of https://queue.care/guides/connect-clinic-queue-to-existing-system, also at https://queue.care/guides/connect-clinic-queue-to-existing-system.md. The whole site in one file: https://queue.care/llms-full.txt