Hospital System OOD: Stop Modeling IDs—Model Relationships

Too many designs start by naming fields: patientID, staffID, appointmentID. Those are storage details, not domain concepts. In object-oriented design (OOD) — especially in interviews — model the relationships and business rules first. Let IDs be an implementation detail you add only after you understand ownership, lifecycle, and invariants.

The principle

Design around domain relationships and responsibilities, not around unique identifiers. A relationship-first model forces you to answer important questions:

• Who owns what? (ownership)
• When can something be created/removed? (lifecycle)
• What rules must always hold? (invariants)

Once those are clear, tables and APIs follow trivially.

Common relationships in a hospital system

• Patient has many Appointments
• Staff (doctors, nurses) has many Appointments
• Patient has many MedicalRecords
• Patient has many Bills
• Appointment references exactly one Patient and exactly one Staff

Modeling these explicitly makes you define ownership: e.g., MedicalRecord is conceptually owned by a Patient (who can have multiple records); an Appointment is a relationship between a Patient and Staff with its own lifecycle.

Example invariants and lifecycle rules

• Appointment must reference exactly one Patient and one Staff.
• Appointment status transitions: Scheduled → (Completed | Cancelled). Some transitions may be forbidden (e.g., Completed → Scheduled).
• MedicalRecord entries are append-only; edits require explicit amendment records or versioning.
• A Bill belongs to a Patient; payment state transitions (Unpaid → PartiallyPaid → Paid) should be explicit.

Explicitly listing these invariants helps you reason about validation, transactions, and concurrency.

From relationships to APIs and tables (an approach)

1. Draw the domain relationships (boxes + lines). Annotate multiplicities and ownership.
2. For each entity, define lifecycle events and allowed state transitions.
3. Implement business logic in domain methods that enforce invariants.
4. Map to persistence: add IDs and foreign keys to represent relationships.
5. Expose REST/GraphQL APIs that mirror domain operations rather than raw CRUD on IDs.

Example pseudo-classes (conceptual):

class Patient

• name
• contactInfo
• appointments: List
• medicalRecords: List

class Staff

• name
• role
• appointments: List

class Appointment

• patient: Patient
• staff: Staff
• scheduledAt
• status // Scheduled, Completed, Cancelled
• reschedule(newTime) { / validate transitions / }
• complete() { / set status and enforce rules / }

And the persistence mapping is straightforward once relationships are clear:

appointments table

• id
• patient_id -- FK to patients
• staff_id -- FK to staff
• scheduled_at
• status

medical_records table

• id
• patient_id
• record_data
• created_at

bills table

• id
• patient_id
• amount
• status

Note: IDs appear here as implementation details (primary keys / foreign keys), but your domain design should have been done before you decide on these columns.

Interview tips

• Start by drawing relationships, not tables. Use boxes for aggregates and arrows for ownership.
• Call out invariants and allowed state transitions on your diagram.
• Describe who owns deletion rights: can a Patient be deleted? What happens to their MedicalRecords and Bills?
• Explain how your domain methods enforce invariants (do not rely solely on DB constraints).
• Only after the model is clear, sketch the APIs and persistence schema.

Benefits of this approach

• Clearer reasoning about business rules, ownership, and consistency.
• Fewer surprises when you implement workflows or enforce validation.
• APIs that reflect real use cases (e.g., cancelAppointment(patient, appointmentId) instead of deleteById).
• Easier to spot transactional boundaries and concurrency issues.

Summary

Stop leading with IDs. Model relationships, lifecycles, and invariants first. Once the domain is explicit, IDs, tables, and APIs are just a straightforward mapping from that model.

#ObjectOrientedDesign #SystemDesign #SoftwareEngineering