Team 36 PEACH Project

Prototype / Proof of Concept

We believe that our proof of concept (PoC) shows exactly how the application should behave and why our design so far meets the our client’s expectations. After careful research, we came up with the right prototype, which proves all the functionalities that our system will have.

What our PoC shows

Our final product should include a working authentication system, preferably with Apache Shiro, which allows users to access certain features within the app. A new account has to be created or approved by an admin, since we need to assure that all accounts are to be trusted. This would be done by approving a certain request of account creation or by sending an email invitation with a specific token for the creation of a new account. Moreover, when creating an account, each user is given a certain role within the platform, which handles all the permissions within the website. For this, we will use Active Directory to set, get and modify roles for users. Then, at each login, from the database where the users are stored, we get all the user information needed, including the token that gives access to the Active Directory data from where we get the user role. Depending on the role, the other teams in the PEACH project can define different app flows for users, with different availabilities within the platform.

Moving forward, our PoC shows how the internal messaging system should work, by allowing people to chat 1 to 1, or in groups. By using Rocket.Chat, an open-source alternative to Slack, we allow users to also exchange files and other important information, which will be highly valuable for everyone using PEACH. We definitely believe that the prototype shows how useful this tool is and why it meets the requirements set by the client.

Apart from these, the collaborative editing tool should simply allow people write simultaneously on a note, while discussing a patient. Then, by simply clicking a save button, the notes should be saved in a central database which will be provided by another team within the project. FirePad was our chosen method and it will surely be easy to use since it already provides built-in functionality of collaborative editing. Then, with a simple back-end code, we can persist all of these in the database. This idea is enough to show how the system should work and why it meets the requirements.

Prototype

Our prototype shows a general idea of how the product should behave. It presents mock-up authentication with Role-Based Access Control and how they should behave in the final product. Users can simply authenticate with their credentials and, after logging in, depending on their role, they can see different pages. For the purpose of this prototype, you can see the flow of the page after authentication and how your role is assigned. You can also request a new account and wait for admin approval. All of these are shown just hypothetically, without the actual back-end implementation.

After authentication, the other two features (internal messaging and collaborative editing) are available with one click. By accessing them, you see a raw idea of how they should behave and how they will be used in the final prototype.

Therefore, the prototype is a mock-up version, meant to show how a final system should behave and how pages can be accessed with the specified role the user has.