1. How to model a patient ?

Your design, with its Account, User, and the different derivates of users are already a good start.

The Patient could indeed be a special kind of User. However, the Patient is not a Diabetic, Alzheimer or Pregnant. He/she has a disease like Diabetes or Alzheimer, or she has a state like Pregnant. He/she may even have several diseases ate the same time: Alzheimer and Diabetes, for example. Therefore I strongly recommend to go for an association of a Patient with one or more Pathologies. So composition over inheritance.

As you came to this orientation by yourself, I can only confirm that you're one the goo way.

How to model an Assistant ?

The assistant is in the business sense a proxy for a Patient. He doesn't make an appointment for himself: he makes an appointment on behalf of a patient. Other patients may make their appointments themselves.

So the method of making an appointment should be offered by the Doctor (or more precisely, by the doctor's schedule). But this doesn't oppose to also have a MakeAppointment() on the Assistant, that will forward the call to the relevant Doctor.

3. How to represent MVC ?

In fact it depends on the purpose of your design.

If it is a domain model, then it should only contain the domain objects (e.g. Patients, Doctors, Users) and no controllers or views, which would only make the model more difficult to understand.

However, if it is an implementation model, the you may show whatever class you need to build your software, including controllers and views.

More on role model

To come back on the role model, the issue discussed about Pathology exist in reality also for other roles. For instance, a Doctor could as well be a patient, if he breaks his leg.

So one user could have several roles. This would similarly call for a composition design: the User would bear the identity and each user could have several roles. You have then to think about which attributes are general and belong to the user, and which ones are specific to a role.

1. How to model a patient ?

Your design, with its Account, User, and the different derivates of users are already a good start.

The Patient could indeed be a special kind of User. However, the Patient is not a Diabetic, Alzheimer or Pregnant. He/she has a pathology like Diabetes or Alzheimer, or a state like Pregnant. He/she may even have several pathologies at the same time. Therefore I strongly recommend to go for an association of a Patient with one or more Pathologies. So use the principle of composition over inheritance.

As you came to this orientation by yourself, I can only confirm that you're one the good way.

How to model an Assistant ?

The assistant is proxy for a Patient, at least in the business sense. He doesn't make an appointment for himself: he makes an appointment on behalf of a patient. Other patients may make their appointments themselves.

So the method of making an appointment should be offered by the Doctor (or more precisely, by the doctor's schedule). But this doesn't oppose to also have a MakeAppointment() on the Assistant, that will forward the call to the relevant Doctor.

And by the way, a patient also has a schedule: you shouldn't in principle make 2 appointments at the same time for the same patient. This brings le to a further approach: you could very well see MakeAppointment as a "Transaction Script", that checks if schedule of doctor and of patient are free at a given time, then books the appointment on the doctor's schedule, then books it on the patient's schedule.

3. How to represent MVC ?

In fact it depends on the purpose of your UML diagram.

If it is a domain model, then it should only contain the domain objects (e.g. Patients, Doctors, Users) and no controllers or views, which would only make the model more difficult to understand.

However, if it is an implementation model, the you may show whatever class you need to build your software, including controllers and views.

More on role model

To come back on the role model, the issue discussed about Pathology exist in reality also for other roles. For instance, a Doctor could as well be a patient, if he breaks his leg.

So one user could have several roles. This would similarly call for a composition design: the User would bear the identity and each user could have several roles. You have then to think about which attributes are general and belong to the user, and which ones are specific to a role.