Summary of Achievements

Requested functional requirements and user cases,
priority, the completed status and contributors

Authentication - RBAC

Requirement Description Priority Type Completed
A1 Good security Must Have Functional/Non-functional Yes
A2 Registration started by admin and sent by email invitation Must Have Functional Yes
A3 Only admins can start a new registration Must Have Functional Yes
A4 Integration with RBAC / ABAC Must Have Functional Yes
A5 Forgotten password Must Have Functional Yes
A6 Provide users with specific role Must Have Functional Yes
A7 Admins can change roles if necessary Must Have Functional Yes
A8 Roles provide different permissions and page flow on the website Must Have Functional Yes
A9 Support for different roles in different apps Must Have Functional No
A10 Change password or other features in an user dashboard Should Have Functional No
A11 Users can request registration or role change Should Have Functional Partially
A12 Blockchain like authentication / IOTA technology for authentication, etc. Could Have Functional No
A13 Simple registration option where user can directly sign-up Won't Have Functional No

Internal Messaging

Requirement Description Priority Type Completed
IM1 Functional text messaging system between clinicians and patients Must Have Functional Yes
IM2 Functional text messaging system among clinicians Must Have Functional Yes
IM3 Group chat inside the web app Must Have Functional Yes
IM4 Storing history in a database Must Have Functional Yes
IM5 Different access permissions Must Have Functional Yes
IM6 Access to patient records inside chat Should Have Functional/Non-functional No
IM7 Sending images and files Should Have Functional Yes
IM8 Real time Should Have Functional Yes
IM9 Offline access to messages Should Have Functional No
IM10 Scalable to store terabytes. Should have Functional Yes
IM11 Videochat Could Have Functional Partially
IM12 Integration with the ChatBot Could Have Functional/Non-functional No
IM13 Flexibility for creating mobile apps Could Have Functional Partially
IM14 Messaging between patients Won't Have Functional Yes

Collaborative Editing

Requirement Description Priority Type Completed
CE1 Multiple users must be able to edit the data simultaneously Must Have Functional Yes
CE2 The entered text must update in real time for all users Must Have Functional Yes
CE3 The input field must be available as a component that can be embedded on any form Must Have Functional Yes
CE4 A submit button which stores the input in a DV_PARSABLE data type field in openEHR Must Have Functional Partially
CE5 Text formatting Should Have Functional Yes
CE6 Input should be saved with formatting Should Have Functional/Non-functional Yes
CE7 When a form is reopened, the previously entered text should be reloaded Should Have Functional Yes
CE8 Marker indicating the cursor position of other concurrent users Could Have Functional No
CE9 No need to see the previous editing history Won't Have Functional/Non-functional Yes

Challenges and associated solution

For the athentication system, there were two main challenges: deployment on Azure and customizing Keycloak. These problems resulted from the fact that the Keycloak documentation is not very well structured and hard to understand. However, through some effort and time spent on different tutorials, we managed to solve the challenges.

For Rocket.Chat, one of the main challenges was to deploy the app. Even with the tutorial that we provided it is very easy to get it wrong. Therefore, automated deployment is vital for the future of the project.

One of the main challenges is to integrate all of the components into the main PEACH platform. For example, the collaborative editing document tool has to be embedded on different patient pages, which should be created by another PEACH Teams.

Moreover, the tool should be linked to the main database, so it can save the pads on the main PEACH system database. At the moment, it is using a MySQL database but for the integration with the main platform it should be using and accessing the same data/roles for the medical staff and patients.

A list of known incomplete features and bugs

There are no known bugs so far of the authentication system. However, there are still some functionalities which are not yet done, such as: Blockchain authentication or a complete integration and availability for the PEACH applications. Apart from this, most of the things were achieved and there are no critical bugs.

Rocket.Chat’s videochat is currently in beta version and it may or may not work for different browsers’ different versions with different plugins. Its chatbot integration feature is also in beta therefore, may create problems in production. As the incomplete feature, offline access to messages needs to be enabled by allowing users to download their messages.

The Collaborative Document Editing could have had a marker indicating the position of other concurrent users. This was one of the "could have" features that we did not deliver in the final solution. However, we do have a colour that associated with the text when another person is contributing to the file/pad. For the moment, we thought that this is satisfying partially the "could have" requirement. In the future, the feature could be improved so the position marker is added.

Work packages of term 2 and contributors

1. Create the three different tools of our project Login& RBAC System - Horatiu Ilie
Internal Messaging System - Berat Baran Cevik
Collaborative Document Editing Tool - Georgiana Birjovanu
2. Create/Update the final website Georgiana Birjovanu
3. Create the video of our team Horatiu Ilie, Georgiana Birjovanu, Berat Baran Cevik
4. Create the poster of our team Berat Baran Cevik
5. Create the presentation of our team Horatiu Ilie

Critical evaluation of the project

1. Architecture design

2. User interface design and user experience

The authentication and messaging systems are specificaly built with responsive design and full browser UI compatibility. There should be a bit more customization in the future to meet the specific design guidelines, but overall everything is user-friendly and good looking.

The collaborative editing tool is a component that will be embedded on specific pages (as the page of a patiet where many details can be found about the patient's state). This is why, the tool is offering a pad with different buttons for text formatting, settings or exporting methods.

3. Functionality

Regarding functionality, all our components are meeting more than 90% of the required functionality. Furthermore, they are of high quality, relying on strong frameworks and good tools. Possibly, there is further integration to be done in the future, but, overall, this is good as a Proof of Concept and final solution.

4. Stability

During our final tests, the three main components were responding fine to the users' actions. The users could register and log in on the platform with no difficulties, the messages on the internal chat were sent successfully, while the collaborative texts on the pads were updated in real-time with no delays.
None of the components crashed during the final tests, they performed well and stable after the Azure server deployment.

5. Efficiency

Regarding efficiency, the tools are highly efficient, both on the technical side and on the cost side (we use open-source tools and sponsored VMs for them). They rely on scalable cloud architecture and they are implemented following clear Design Patterns and principles, which makes them suitable even for rapid growth.

6. Compatibility

As mentioned in the "Testing" section, all the compatibility testing was successfull, so we are confident there are no problems in this area with any of the 3 components.

7. Maintainability

Since the 3 tools use separate VMs and databases, they are easy maintainable, since a failure of one does not break the others. Moreover, they rely on the highly scalable structure of the Azure cloud, which is easy to maintain, update and scale.

8. Evaluation of Testing

We did a high amount of testing, from Test-Drive Development to unit testing for all our components (see "Testing" section). Therefore, we consider everything was done at a high standard, though we could automate the proces more in the future.

9. Project management

Regarding the managment, we did a great job, from team communication to evenly splitting tasks. We coul have started the actual development a bit earlier, but, in the end, everything turned out as we expected, as we provided core, highly-valuable functionalities.

Future work

The authentication system should integrate all the PEACH applications and secure all of them in the future, providing the user roles and details to everyone with permission. Moreover, an SSL certificate should be installed in the near future so that every communication with the server is encrypted and secure.

Automated deployment: To make the development and integration testing with the other components of the PEACH project faster, the deployment should be automated. This can be done through an online source such as GitHub or GitLab or running a script on the development machine to deploy the new version to the server.

Login integration: This task is vital for PEACH project since all components need to be integrated at the end. The internal messaging system currently uses its own login system. This should be replaced with Keycloak login instead.

Production and testing servers: A mature server environment mainly consists of at least two production servers and at least one testing server. So that the users do not experience any downtime during the deployment of the new version of the app. More importantly, the users will not have access to the development version of the app while developers are working on it. Therefore, a testing server needs to be set up for development purposes. Once a stable version is built, it should be uploaded to the first production server. When the app is up and running on the first production server, it can be uploaded to the second production server. A load balancer needs to be set up to direct all traffic to the other server when one server is getting deployed. In this way, none of the users will have inaccessibility issues. The number of the servers can be increased or decreased depending on the traffic.

Database backup: In order to protect user information and chat history, all data needs to be constantly backed up to a backup database. A back-end service that is going to run on a separate server should be created to automate this backup. This service should preferably back up the data at least once a day to provide good data protection.

For the Collaborative Editing Tool, the future work consists of the integration of the component in the main platform. The other teams creating the platform with the patient page should provide access to the platform in order to include the real-time collaborative pad on the patient page, by making use of the provided API.