Human-Computer Interaction

System Architecture

Our system architecture is easy to understand and very powerful for a system with multiple separate apps such as the PEACH Project. Basically, we provide a central authentication tol which provides user data to all the other services within PEACH, either by direct request, or by OpenID Connect / OAuth authentication. Then, each app, even future PEACH apps, can use these details as it is suitable within their apps. Moreover, we have 3 different types of databases, due to the fact that some of the tools had better functionality for some databases. In addition, having different databases does not have a bad influence due to our structure, as we tend to think of each app as a "microservice", thinking which might be suitable for a system with a large number of differently built apps.

Design Patterns

Messaging Design Pattern: allowing change of information between components and applications (highly used)
Read-Write Lock: provides simultaneous read access to data, but only one write access at a time (used in messaging and doc editing)
Monitor Object: ensures no data is wrongly used at the same time
Template Method: used to provide design and object templates within the used frameworks
Command Pattern: encapsulates requests as objects with parameters

Sequence Diagram

Development tools: communication, file storage, UI design, version control, IDE

  • Keycloak: Authentication Tool
  • Etherpad: Collaborative Document Editing Tool
  • Rocket.Chat: Messaging App
  • Git: Source Control Tool
  • GitHub: Source Control Platform
  • GitLab: Source Control Platform
  • Bitbucket: Source Control Platform
  • Sublime Text: Text Editor
  • Atom: Text Editor
  • Brackets: Text Editor
  • Ryver: Communication Platform
  • Facebook Messenger: Communication Platform
  • Google Drive: Storing Files
  • Diagram Creation Tool

Implementation details of Key functionalities

Login System with RBAC

The login system was implemented using Keycloak and provides two types of authentication for applications: direct authentication for applications (realms) registered under the Keycloak server and OpenID Connect / OAuth authentication for smaller, 3rd party applications.

Moreover, the design is made in such a way that it is scalable, as the login is not dependent on certain apps and vice-versa. Everything is built to be highly customizable and with as little friction as possible between components. We really consider that by respecting our System Diagram, we have a good overall architecture, which implements most of the requirements really well/

Internal Messaging System

The internal messaging system that we developed meets all must have requirements which are the foundation of the chat platform. These are text messaging between patients and clinicians, text messaging among clinicians, group chat, storing chat history securely in a database, different access permissions for patients and clinicians. We managed to achieve 3 out of 5 should have requirements. The requirements that we satisfied are sending images and files, real-time chat and scalability to terabytes and petabytes of storage in the future. Also, we succeeded to partially meet 2 of the could have requirements.

Videochat is present inside the internal messaging system but it is still in beta version therefore, it does not always work properly. There is usually a lag and connectivity problem and also a browser compatibility issue. Once these problems are solved by Rocket.Chat or future developers of this project this feature will be fully implemented. Rocket.Chat currently has hybrid apps for Android and iOS platforms and the native versions are currently being built by the open source community. The chat platform we created can be integrated with the mobile version using the API provided in Rocket.Chat documentation.

Collaborative Document Editing Tool

    By using Etherpad the following features were made possible:
    • Users are able to edit the data simultaneously
    • Text is updated in real time for all users
    • Text formatting
    Even more, the following are possible:
    • Input field is available as a component that can be embedded on any form
    • Text is reloaded
    • Saving the notes