Backend Architecture solutions - TelemedDevGroup/TelemedProtoApp GitHub Wiki

@TODO add textual description.

Note: to edit diagram please use Online editing in Draw.io link

Chat functionality based on the rooms, this gives the ability to have any number of participants and manage other stuff in the same place, like video calls and etc. Also in the service that handles messages supported polling for retrieving immediate updates. So when someone sends a message it will immediately notify other participants of the room if they online or send notifications to the devices in the future.

Required actions to start chatting:

1. Create a room, need to specify other participants on this step too
2. Send a message to that room

To receive an immediate updates need to subscribe for updates. This part implemented as polling, which means that you need to send a request to the specific endpoint each time when you received a response. This is will not be something like flooding as if there are no updates for the current user this request will be put on hold for 25 seconds, but once some data will appear you will receive a message immediately. This concept is an alternative to the web sockets and supported even in old browsers when sockets are not. The concept for viewing chats and receiving immediate updates:

1. Retrieve the list of rooms
2. Send a polling request
3. Handle polling response and if there are exists some messages they should be handled accordingly
4. Send another one polling request

Retrieving of rooms possible only with pagination, so you will actually receive not a list, but page object which will contain information about a number of all rooms and other stuff. All endpoints with pagination support parameters like "page" and "size". For polling supported and correctly handled cases when participants have multiple devices at the same time and new messages will not be lost between requests. For cases when there were some connection issues and polling requests weren't sent more than 5 seconds chat and room data should be reloaded completely, as the server holds messages in memory for subscribers only for that short period and in this case possible to miss some messages (can be improved with loading from database all updates, but for now this is decided to leave as is). All these timeouts configurable and can be changed after discussion.

Read/unread messages works based on the following:

1. When someone sends a message (text message from the user only) for all participants of the room increased counter of unread messages, the participant which sent a message will have counter to be set to zero.
2. When someone sends a request about marking messages as read for the specific room it will reset this counter only for him.
3. In the room object also exists info about unread messages for all other participants

@TODO

---

• Calendar model shall support two core entity types: Appointment and AvailabilitySlot. for all types of the accounts.
• Calendar UI component shall support two representation modes:
• • basic mode (work with appointments): in this mode an user can see his calendar with grayed out areas of his non-availability and colored blocks of all associated appointments. in this mode he can only update appointments (change details, propose shift or cancel). creation of new appointment is possible via special component only.
• • mode for managing availability. ! available only for Doctors. in this mode all availability slots are represented as colored blocks at the calendar. Doctor can create new slot, edit existing by clicking on it or delete one.
• By default all patients receive one recurrent availability slot relevant to working week time, Doctors by default have no available slots and would need to create their schedule.
• Calendar model shall work with absolute time. Adaptation to user's timezone shall be done on API level, on the level of service calls.
• status and decisioning of every participant shall be tracked in the model. E.g. in case of a shifting proposal the another participant would need to accept or reject proposal.
• in the config we shall define a minimal slot for appointment increment. For the first version of app it will be 15 mins interval. appointments shall be selected in correlation to this interval, with a start time to be correlated to such a breakdown. E.g. for availability slot 10:00 10:50 and interval of 15 the start of slots can be at 10:00, 10:15 and 10:30.
• Appointment creation is a dedicated component. Available for patients only. When user selected doctor he has an action button to create an appointment. In that component he select day from data-picker and duration of an appointment, after that the component makes a call to backend to identify list of possible slots to be used at that date (based on Availability schedule and non-booked slots of that doctor). After that the user can select one of proposals to be converted into an appointment, or check another day\options.

Note: to edit diagram please use Online editing in Draw.io link