|
|
[Requirement MoSCow style](requirements) |
|
|
\ No newline at end of file |
|
|
# HealthTech: WalkyTalky
|
|
|
|
|
|
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.
|
|
|
|
|
|
#### 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:
|
|
|
|
|
|
**Synchronous:** live-chat is possible and even preferred
|
|
|
|
|
|
**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)
|
|
|
|
|
|
### 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:
|
|
|
|
|
|
1. It must be self-hosted for GDPR compliance.
|
|
|
2. It must be either free of charge or quite cheap, because of the budget.
|
|
|
3. It preferably has some way for our service to communicate a password and room name to it.
|
|
|
|
|
|
Jitsi also has the added benefit of an already existing mobile app which can easily be downloaded into tablets. This app has the ability to import events from the in-built calendar of the device and to schedule Jitsi meetings based on them.
|
|
|
|
|
|
This combination of features gives us the solution on the patient's side of the story. For the family, there needs to be a user interface created to claim time slots and a whole system developed around that to manage the whole process with privacy (not allowing just anyone to contact a patient in the hospital).
|
|
|
|
|
|
#### Architecture
|
|
|
|
|
|
For this, the following architecture has been created:
|
|
|
|
|
|
```
|
|
|
---------------- -------------------
|
|
|
| Jitsi server | ----------- | Jitsi App / Web |
|
|
|
---------------- -------------------
|
|
|
| |
|
|
|
------------------------ | | -----------------------
|
|
|
| tablets w/ Jitsi app | ----- ----------- | time slot selection |
|
|
|
------------------------ -----------------------
|
|
|
| |
|
|
|
| ------------------- |
|
|
|
-------- | calendar server | -----------
|
|
|
-------------------
|
|
|
```
|
|
|
|
|
|
- A nurse / helping hand carriers the tablet around in the hospital based on the calendar that has been loaded into the device she is working on.
|
|
|
- A Jitsi server is set up per hospital along with a calendar server which provides ICS files through an ical link.
|
|
|
- A user interface (webpage) for families to claim time slots based on a token / username + password they received upon the patients entrance to the hospital. (Each patient has a contact person on their "file" and this would be the trustworthy one to receive the token. Afterwards, they could distributed further to other friends and family.)
|
|
|
- The family can use either the app or the browser Jitsi UI on their side of the communication.
|
|
|
|
|
|
#### Jitsi Connection
|
|
|
|
|
|
Our application will have time slots to be selected by families. At the moment a family selects a time slot we setup two different URLs to be used in the future:
|
|
|
|
|
|
1. The URL you could call 'the waiting room' which, for the family, shows as a basically empty page.
|
|
|
2. The URL for use within the tablet, which will be clicked by the nurse / helping hand.
|
|
|
|
|
|
The first link will contain only information about what they are waiting for and when their time slot starts. The second link, when clicked within some time frame, will create a new Jitsi room and set a password for it.
|
|
|
|
|
|
The family will receive the ID of the created room through this waiting room web page and we can redirect them to a Jitsi page from there.
|
|
|
|
|
|
This way, the maintenance of the rooms stays on the hospital side of things and can be organized by them.
|
|
|
|
|
|
#### Administration
|
|
|
|
|
|
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:
|
|
|
- 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
|
|
|
|
|
|
The following database schema has been created so far:
|
|
|
|
|
|
```
|
|
|
----------- ------------
|
|
|
| Patient | -------------------< | Timeslot |
|
|
|
----------- ------------
|
|
|
v v
|
|
|
| |
|
|
|
| |
|
|
|
-------- ----------
|
|
|
| Area | >---------------------< | Tablet |
|
|
|
-------- ----------
|
|
|
```
|
|
|
|
|
|
- Patient
|
|
|
- name
|
|
|
- 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 |