Skip to content

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.

Last updated:

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.

It reads. It never 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 a list of databases and table structures, the same information any read-only reporting tool sees, and scores them for clinic-shaped table names. It does not read patient rows to decide.

The whole process is structurally read-only: it cannot modify, delete, or write anything to the existing database. A queue system is a bad reason to take a risk with the system a clinic has been running for years, and this one is built so the question does not arise.

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, or a schema with no recognisable patient table — these exist, and 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.

Guides for clinics

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