Evaluation
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.
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.
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.