Case study

MediCare: a hospital management database, rebuilt for the web

A Microsoft Access database that ran a hospital's admissions, patients, blood bank and staffing, rebuilt by AccessToWeb.app as a browser-based application. Every screen below is the delivered software, running on demo data.

MediCare dashboard showing a new admissions workflow board across bed allocation, clinical assessment, and treatment and billing stages, task tiles for bed requests, pharmacy orders, lab results, billing review, discharge notes and follow-up calls, a scheduled procedures table, and admitted versus discharged charts — The dashboard: every admission tracked stage by stage, with the day's tasks counted beside it.

Admissions became a board everyone can see

The dashboard turns a new admission into a visible pipeline: bed allocation, clinical assessment, then treatment and billing, each step assigned to a named doctor or nurse and ticked off as it completes. Beside the board, the day counts itself: 4 bed requests with 2 urgent, 7 pharmacy orders, 5 lab results with 2 pending, 3 billing reviews with 1 overdue, plus discharge notes due today and follow-up calls due this week. In the old database, that picture existed only in whoever ran the right queries that morning.

Underneath, scheduled procedures sit in one table with status, start and end times and the staff member responsible, and a pair of live charts keeps the admitted and discharged split current without anyone compiling it.

MediCare patient register listing patients with age, gender, mobile number, assigned room, admission and discharge dates and a paid or pending fee status, with one-click discharge buttons and tabs for all, admitted and discharged patients — The patient register: room, dates, fee status and a one-click discharge per row.

One register instead of a form per question

Every patient is one row that answers the questions the front desk actually gets: which room they are in, when they were admitted, whether their fee is paid or pending, and a discharge action right on the row for the day they leave. Tabs split the register into admitted and discharged without running a filter, and the record keeps ICU, private and general ward rooms in the same list. What used to be an Access form, a subform and a saved query is one screen anyone on shift can read.

MediCare blood bank screen showing stock for all eight blood groups in litres and units, a donors table with blood group, mobile number, last donation date and amount, and an issue log recording recipient, group, amount and issue date — The blood bank: stock for all eight groups, with donations in and issues out.

The blood bank balances itself

Stock for all eight blood groups sits across the top in litres and units, and the two tables below it are the whole story of how those numbers move: donors on one side with their group, last donation and amount, the issue log on the other with recipient, amount and date. Recording a donation or issuing blood is one action that updates the stock cards immediately, so the count on screen is the count in the fridge, not the count as of the last stocktake.

MediCare staff screen showing headline counts of 24 total staff, 9 doctors and 15 nurses, above a roster listing each person's designation, gender, mobile number, address, day or night shift and admin or staff role — The staff roster: 24 people, their shifts, and who holds admin rights.

Staffing on one screen, permissions included

The roster opens on the headline counts (24 staff, 9 doctors, 15 nurses) and lists every person with their designation, contact details and day or night shift. It also carries the thing a shared Access file never could: a real admin and staff role split, because a multi-user web application can give the administrator and the ward nurse different rights over the same records.

What changed underneath

One shared application in the browser instead of a file that opens on machines with Access on them.
Admissions tracked as an assigned, ticked-off workflow instead of a status field somebody remembers to update.
Blood stock, patient counts and the day's task load computed live instead of on demand.
Per-user accounts with admin and staff roles instead of one shared database file.
The client owns the source code. No per-user licence, no subscription, no platform it cannot leave.

Curious what your own database would look like on this side of a rebuild? The free Migration Blueprint maps every form, query and module and comes back with a fixed quote within 24 hours.

About the data in these screenshots: client work here is covered by an NDA by default, so every patient, staff member, donor and figure shown is fictional demo data. The software is the real delivered application.