... | @@ -2,8 +2,6 @@ |
... | @@ -2,8 +2,6 @@ |
|
|
|
|
|
Because of the COVID-19 outbreak and its recent occurrence in the Netherlands, friends and family might soon be unable to visit patients in hospitals. Upon Reinier de Graaf's initiative, the idea is to set up an ad-hoc-project group made up of collaborators from multiple faculties and universities.
|
|
Because of the COVID-19 outbreak and its recent occurrence in the Netherlands, friends and family might soon be unable to visit patients in hospitals. Upon Reinier de Graaf's initiative, the idea is to set up an ad-hoc-project group made up of collaborators from multiple faculties and universities.
|
|
|
|
|
|
To see the current page flow, click [here](Page Flow).
|
|
|
|
|
|
|
|
#### Stakeholders (Potential Users)
|
|
#### Stakeholders (Potential Users)
|
|
|
|
|
|
Since this lockdown will in its essence mean that patients will be reliant on online communication, our target users are the ones who cannot facilitate this themselves, i.e. those that do not have smartphones / tablets / etc. nor the knowledge of how to use them. These patients are also split into two groups capable of two levels of communication:
|
|
Since this lockdown will in its essence mean that patients will be reliant on online communication, our target users are the ones who cannot facilitate this themselves, i.e. those that do not have smartphones / tablets / etc. nor the knowledge of how to use them. These patients are also split into two groups capable of two levels of communication:
|
... | @@ -12,19 +10,6 @@ Since this lockdown will in its essence mean that patients will be reliant on on |
... | @@ -12,19 +10,6 @@ Since this lockdown will in its essence mean that patients will be reliant on on |
|
|
|
|
|
**Asynchronous**: some patients are not in a healthy enough state to carry out full conversations with their friends and family at the time slot that the family chooses (an asynchronous solution needs to be devised)
|
|
**Asynchronous**: some patients are not in a healthy enough state to carry out full conversations with their friends and family at the time slot that the family chooses (an asynchronous solution needs to be devised)
|
|
|
|
|
|
#### Constraints
|
|
|
|
|
|
|
|
- Privacy, think at least:
|
|
|
|
- Medical information
|
|
|
|
- Patient-medical staff communication;
|
|
|
|
- Other patients (in the same room)
|
|
|
|
- No “horror stories” (invasive treatments, patient’s last moments, etc.)
|
|
|
|
- GDPR
|
|
|
|
- Security policies from our IT department
|
|
|
|
- Cleaning policy of the solution (we don’t want a device that could possibly become the "carrier" of infections)
|
|
|
|
- Accessibility of the solution (most preferred a kiosk-like solution, meaning the device cannot be used for other means)
|
|
|
|
- i18n/l10n not all of our users (not even in NL) are Dutch, so from the start we need to keep i18n & l10n in mind
|
|
|
|
|
|
|
|
### Solution Outline
|
|
### Solution Outline
|
|
|
|
|
|
The current solution we are working on is built around Jitsi: an open-source conferencing software. We chose it based on the following requirements we determined that the meeting app / website must comply to:
|
|
The current solution we are working on is built around Jitsi: an open-source conferencing software. We chose it based on the following requirements we determined that the meeting app / website must comply to:
|
... | @@ -73,46 +58,33 @@ The family will receive the ID of the created room through this waiting room web |
... | @@ -73,46 +58,33 @@ The family will receive the ID of the created room through this waiting room web |
|
|
|
|
|
This way, the maintenance of the rooms stays on the hospital side of things and can be organized by them.
|
|
This way, the maintenance of the rooms stays on the hospital side of things and can be organized by them.
|
|
|
|
|
|
#### Administration
|
|
#### User Stories
|
|
|
|
|
|
Each hospital will have a different amount of tablets and will probably want to set constraints on which rooms / wards / departments can share a single tablet. Therefore, we want to make an admin UI, where a manager at each hospital can:
|
|
##### Patient
|
|
- create "Areas"
|
|
|
|
- appoint tablets to areas
|
|
|
|
- select the active tablets
|
|
|
|
- set time slot length
|
|
|
|
- set transition time between time slots
|
|
|
|
- set the amount of time slots per day
|
|
|
|
- set the amount of time slots claimable per patient per day
|
|
|
|
- set the maximum time that a family can book a slot in advance
|
|
|
|
|
|
|
|
#### Database Design
|
|
Upon arrival to the hospital, a patient is asked whether they want to be added to the We/Visit system. If they agree, the admin adds them into the database of patients and keeps track of the area the patient is staying in throughout the whole stay in the hospital.
|
|
|
|
|
|
The following database schema has been created so far:
|
|
Their contact person then receives a personalized token to be able to claim time slots through the hospital's We/Visit website.
|
|
|
|
|
|
```
|
|
##### Admin
|
|
----------- ------------
|
|
|
|
| Patient | -------------------< | Timeslot |
|
|
An admin is responsible for all the data in the database and keeping it updated. This includes:
|
|
----------- ------------
|
|
- patient *adding / editing / deleting*
|
|
v v
|
|
- area *adding / editing / deleting*
|
|
| |
|
|
- tablet *adding / editing / deleting*
|
|
| |
|
|
- time slot configuration per day (this can also be set as default for all days and kept on repeat)
|
|
-------- ----------
|
|
|
|
| Area | >---------------------< | Tablet |
|
|
##### Team Tablet
|
|
-------- ----------
|
|
|
|
```
|
|
The Tablet Team is responsible for finding the correct patient that is scheduled next on the tablet they are manning. In the calendar app of the tablet, they open the next time slot, click the link and are redirected to the Jitsi app where they start the call.
|
|
|
|
|
|
|
|
##### Visitor
|
|
|
|
|
|
|
|
A Visitor opens the hospital's We/Visit website and inputs the token they received in the hospital. They can then:
|
|
|
|
- view the reserved time slots
|
|
|
|
- reserve a new time slot
|
|
|
|
- enter the waiting room to wait for the call initiated by the member of team tablet
|
|
|
|
|
|
|
|
#### Page Flow
|
|
|
|
|
|
- Patient
|
|
To see the current page flow, click [here](Page Flow). |
|
- name
|
|
\ No newline at end of file |
|
- token given to contact person
|
|
|
|
- area [Area] (a.k.a. department / ward / section)
|
|
|
|
- Area
|
|
|
|
- name
|
|
|
|
- patients [Patient]
|
|
|
|
- Tablet
|
|
|
|
- id / name
|
|
|
|
- areas [Area]
|
|
|
|
- Timeslot
|
|
|
|
- start time
|
|
|
|
- end time
|
|
|
|
- tablet [Tablet]
|
|
|
|
- patient [Patient] |
|
|
|
\ No newline at end of file |
|
|