The next step after gathering requirements is to find the entities in our conversation. What are these entities, and how do we find them?

An entity is anything about which we may want to store some information or data. For example, based on our conversation in the previous post: a Patient. And what do we want to store about a patient? Name, address, and so on — these are called attributes.

The best way to find the entities is to look for the nouns in the conversation. If we go through our chat with the doctor, these are the nouns of interest:

AppointmentAppPatientPracticeClinicsUsersRolesPermissionsDoctorStaffPatient RecordsPrescriptionsSchedulingAdministrative TasksAppointment DetailsHistoryInformationNotesSymptomsAdviceTestsPrivate NotesMedicinesDatabaseQuantityAvailabilityWorking DaysAddressStaff MembersSystemSecurityLogin SystemSensitive InformationEncryptionAccessPatient Data

Our entities are going to be part of this list. Why can't we use all nouns as entities? Because we don't necessarily need to store information about everything in the system we want to design. Only the items about which we need to collect and store information — with respect to the system we want to design — are called entities.

Tip: You can use an AI tool such as ChatGPT or Claude to find all the nouns for you!

Now let's work out what qualifies as an entity from the set of nouns above, and describe each one. This is also the next step in system design.

Appointment
The central entity for managing doctor–patient interactions.
App
Not an entity itself — it refers to the system being built.
Patient
Key entity representing the patients treated by the doctor.
Clinic
Represents the different locations where the doctor operates.
User
Represents anyone who uses the system (doctor, staff, patient).
Role
Represents the permissions different users have in the system.
Doctor
An entity for the doctor's information and their role in the system.
Staff
Represents the staff members who manage administrative tasks.
Patient Records
Could be part of a broader Patient entity, but it's essential to track each patient's medical history.
Prescription
Key entity for tracking what medicines are prescribed during appointments.
Scheduling
Can be part of the Appointment entity — it refers to the times and availability of the doctor.
Appointment Details
Not a separate entity, but part of the Appointment entity, capturing notes and status.
Notes
A sub-entity under Appointment for capturing the doctor's notes.
Medicine
Represents homeopathic medicines stored in a database and linked to prescriptions.
Availability
Linked to the Clinic entity, referring to the doctor's working days at each location.
Address
Linked to both Patient and Clinic entities, for patient home addresses and clinic locations.
Private Notes
Part of the AppointmentNote entity that only the doctor can see.
System
Refers to the app itself — not an entity.
Security
A non-entity concept, ensuring secure access to the system.
Login System
A functionality, not an entity.
Sensitive Information
Related to data security, but not a distinct entity.
Access
Tied to roles and permissions — part of the User and Role entities.

Tip: An AI tool can write these definitions for you, too!

The final list of entities

The next step is finalizing the list. Based on our conversation and the analysis above:

AppointmentPatientClinicUserRoleStaffPatient RecordPrescriptionMedicineAppointment NoteAvailabilityAddress

Note: It takes a little practice to quickly think of entities and their attributes. This method is very detailed, so even if you have no experience, you can follow the steps outlined here. Go through the conversation in the previous post and how we arrived at these entities a few times — it will help you build this muscle.

We will discuss these entities and their possible attributes in the next part.