Hospital management system: choose the slice first

The slice this page draws

This version covers three connected jobs: booking and holding outpatient appointments, admitting patients to a ward bed and discharging them, and billing, with a claim to an insurer where the patient has one. Laboratory work is outside the boundary: the hospital's system sends a test request and receives the results, and what the laboratory does in between belongs to its own system. Stating that boundary in a sentence at the top of a report is worth doing, because every diagram below depends on it.

Use cases: roles, not job titles on a login screen

Four kinds of person use this system, and they are drawn as four actors rather than one "User" because they want different things from it. The receptionist books, checks in, admits and bills. The doctor records consultations, orders tests and discharges. The nurse records vital signs and the medicines given. The patient books appointments, perhaps online. One person can play two roles, a nurse booking her own appointment for instance, and that is fine: an actor is a role, not an employee record.

Admitting a patient always involves assigning a bed, so Admit «include»s Assign a bed, and the bed step is drawn once, where a later use case such as moving a patient could include it too. Claiming from the insurer extends raising the bill, because only some patients have insurance. The two systems on the right are secondary actors: the hospital's system starts the conversation with the insurer and waits for the laboratory to answer.

The data: the appointment is what joins doctor and patient

The obvious first sketch draws Doctor and Patient with a many-to-many line between them, which is true and useless: it has nowhere to say when they met, why, or what happened. The appointment is that meeting, so it becomes an entity with a time and a status, and the consultation is what happens if the patient actually comes. That split matters, because a missed appointment has no consultation and must still be recorded. A consultation takes its appointment's id as its own key, so that line is solid, an identifying relationship; every other entity here has an id of its own, so the rest are dashed.

The same move resolves patients and beds. A bed is used by many patients over the years and a patient may be admitted many times, so the admission records who was in which bed, from when, until when, under which doctor. discharged_at stays empty while the patient is still in, so the patients currently on a ward are simply the admissions for its beds with no discharge time. A patient who moves beds during one stay is the natural next step: give Admission a list of bed moves, each with its own start time.

Patient stores date_of_birth, never an age. An age is out of date a year after it is written, and every report can work it out on the day it runs; the ageOn(day) method in the class diagram does exactly that.

The context diagram: what crosses the boundary

With five outside parties, a level 1 DFD of the whole slice would already be crowded, so this page stops at the context diagram. It is the diagram to show a hospital's own staff when agreeing the scope, because it answers their first question, "what will it send to whom?", in one picture.

Notice that doctors and receptionists appear as external entities even though they work in the hospital. The boundary is the software, not the building. Notice too that only a claim goes to the insurer, not the patient's history: the flow names are where a data flow diagram shows that each party gets what its job needs and nothing more.

Classes: where inheritance helps, and where it bites

Patients and doctors both have a name and a date of birth, so the class diagram gives them an abstract Person to inherit from. That saves repetition and is what most courses expect to see.

It is also worth one sentence of criticism in a write-up, because it earns credit. Inheritance says a Doctor is a Person of a fixed kind for its whole life, so a doctor who falls ill and becomes a patient needs a second object for the same human being. The alternative is one Person with roles attached (patient, doctor, nurse), which handles that case at the cost of a slightly harder diagram. Either is defensible if you say why you chose it. Ward to Bed is composition: a bed record means nothing outside its ward. Admission to Bed is only an association, since the bed outlives every admission.

Booking an appointment

The sequence below books a cardiology appointment at the desk. Its interesting part is at the end. Between offering three slots and the patient choosing one, another receptionist may have booked it. So the booking message is checked when it arrives, and the alt frame shows both answers.

The patient is found by name and date of birth together, because names alone repeat in any large list of patients, and the diagram shows that lookup coming before anything is booked. Online booking by the patient would use the same schedule messages with the reception lifeline removed, which is a good reason to keep the schedule as its own participant.

Mistakes seen again and again

1. The whole hospital in one diagram. Choose a slice, say which, and draw it properly.
2. An age column instead of a date of birth.
3. Doctor and Patient joined directly, leaving appointments and consultations with no home.
4. A bed number on the patient. It loses every earlier admission and cannot show a free bed.
5. One "User" actor standing for receptionists, doctors and nurses alike.
6. Staff drawn inside the context diagram's circle. They use the system; they are not part of it.

Your brief may add wards with visiting hours, a pharmacy, or appointments with more than one clinician. Each of those is another entity joined through a dated record, the same pattern the appointment and the admission follow here.