3

I have school project where me and my team have to build a health care system. It consists of different modules including :

A module for doctors : It allows a doctor to access the medical records of his patients, send indications to them, consult his agenda...

A module for patients : A patient can take an appointment with his doctor, signal an emergency or send indicators (glycaemia level, weight, blood pressure). There are three types of patients that must be taken care of by the system : Women with a risky pregnancy, Diabetics and people suffering from Alzheimer. The latter are assisted by people from their family or medical staff.

A module for transportation : To affect and dispatch an ambulance at the location where a patient signaled an emergency.


Upon trying to model the solution through an UML class diagram (which is actually a due document for the project), we came across three problems/dilemmas :

  1. How to model a patient ?

Our first thought was to create a User class from which inherit the other classes like this :

Class diagram - inheritance from User.

But then this wouldn't allow a patient to be pregnant and diabetic for example. Which is bothersome.

After searching on the internet, we found out about role-based access control, we didn't delve into it because we thought it was intended for account management and permissions, not business related stuff like a patient having different roles (diabetic and pregnant for example).

We finally agreed on creating a Pathology class and adding a list of pathologies for each patient. Does this violate any good design principle ? Is there a standard or better way to do this ?

Another similar problem appears with the assistant. Since he can be a member of the patient's family or the medical staff, we would have an him either falling in the Assistant class under User or in the MedicalAssistant class under MedicalStaff. But I think this is the same problem as for the patient's pathologies.


  1. How to model an assistant ?

Again with the assistant, he is here to assist a patient suffering from Alzheimer : he makes doctor appointments for him and is notified if he wanders off too far (we've included a wearable bracelet equipped with a GPS in the solution). This raised up the issue of redundancy since we have classes Assistant and Patient which implement the method MakeAppointment(Doctor, Date). This raised two possibilities :

-Should this method be in the Doctor class instead ?

-Should we have an IAppointement interface containing the method ?

I personally think the method should be moved to the Doctor class (maybe this is even a basic OOP thing).


  1. How to represent MVC ?

We're going to make a website and a mobile app supporting the system. We've thought about using ASP.NET to get a hand on it and get to know about the MVC design pattern. After a little bit of documentation (mainly from the "MVC In PHP series" from Tom Butler and "GUI Architectures from Martin Fowler (both on their websites), We've come to ask ourselves if the Controller and View layers should be represented in a class diagram like this :

Class diagram - some controllers.

We've found this post on stackoverflow that asks a similar question :

How to create UML class diagrams for MVC

It says that only the model (business related classes) should be represented. But is that a general rule ? Should the Controller and View classes be represented ? How would that translate into a sequence diagram ?

I'm sorry for the post being so long and the questions quite heterogeneous. Thanks in advance for any help, advice or remarks you might give us.

  • Separate the concerns of using the application, who can do what in the interface, from the domain logic. Also, for tricky multi inheritance situations, you'll want to use Interfaces (pure virtual abstract) instead of inheritance. – RubberDuck Apr 29 '17 at 13:49
  • Thanks for answering, @RubberDuck. I'm not sure I completely understood your answer though. When you say separate the concerns, do you mean I should put the user actions like MakeAppointment in the Views and Controllers only ? As for multi inheritance, I guess you're referring to the issue with a patient having multiple diseases. I hope I'm not saying something stupid, but I don't see how Interfaces could solve the problem. Making a class implement an interface would oblige a diabetic to have the method of a pregnant woman. Sorry again, the comment is way too long. – PolarCrow Apr 29 '17 at 15:48
  • In C# you can't inherit from multiple base classes, but you can implement multiple interfaces @PolarCrow. As for separating application from domain logic... you'll inevitably run into a situation where a person is both an assistant and a patient. So it's best to separate the concept of "User with these permissions" from "A person of type X my domain cares about – RubberDuck Apr 29 '17 at 15:54
  • It's clearer now. I should separate the classes of the application itself from the classes of the medical domain. Thanks ! – PolarCrow Apr 29 '17 at 16:33
4

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.

  • Thanks you ! You took away most of the ambiguities we had concerning the project. Now we're going to tweak the design in order to improve it. – PolarCrow Apr 29 '17 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.