Architecture Review Document

Purpose of Review

This review aims to validate that our site, "Mister ED," is satisfactory, supports virtual triage, patient information, and doctor appointments, and is usable by Doctors, Patients, Nurses, Receptionists, and Pharmacists.

Questions:

• Does the architecture adequately address accessibility for patients of varying technical literacy?
• Are security measures in place to protect private health data?
• Does the architecture support its stack holders (Doctors, Patients, Nurses, Receptionists, and Pharmacists)?

Subject of Review

We are going to concentrate our review mainly on the following artifacts:

• Use cases are all created and logical
• Triage is supported
• Patients can access their data
• Doctors approve appointments
• Receptionists book appointments
• All actors can view the data necessary to their job and only the data necessary to their job

Question Set

We will use the following questions to assess our design:

• Have all relevant stakeholders (patients, doctors, nurses, pharmacists, receptionist) been identified?
• Does the documentation explicitly address their key concerns (e.g. usability for patients)?
• Does the deployment view illustrate scalability under load spikes?
• Are all critical workflows, such as patient registration, triage results, and data uploads, fully documented?
• Are failure recovery and redundancy mechanisms specified?
• Are encryption and authentication mechanisms compliant with legal and ethical standards?
• Is data storage and transmission in line with HIPAA or GDPR?
• Extra comments?

Review Plan

The participants for the reviewers will be the creators of the alternate "Mister ED" designs. These are crucial stakeholders in the design of "Mister ED" as they too are trying to benefit from the implementation of this design. Furthermore, they have a good understanding of the requirements of this design.

We will conduct three separate reviews with two groups on the 19th and 22nd from 11:30 to 12:30. Each group will ask the other team if their design meets the requirements they established in the abovementioned part.

Review Results

We discussed our design with Group 5 on the 19th and Group 11 on the 22nd. The following are the answers to our questions:

• Have all relevant stakeholders (patients, doctors, nurses, pharmacists, receptionist) been identified?

Both teams stated that we did indeed identify all relevant stakeholders. Team 11 specified that they could be found in Access Control.

• Does the documentation explicitly address their key concerns (e.g. usability for patients)?

Both teams stated that their key concerns were addressed. Team 11 specified that they found their concerns addressed in the Sequence Diagram however, they also thought that the documentation would benefit from a specific section that stated everything more clearly

• Does the deployment view illustrate scalability under load spikes?

As both teams pointed out, we had yet to implement a deployment view when we conducted the review sessions.

• Are all critical workflows fully documented, such as patient registration, triage results, and data uploads?

Both teams pointed out that our architecture design was lacking critical workflows.

• Are failure recovery and redundancy mechanisms specified?

We need to add failure recovery and redundancy mechanisms.

• Are encryption and authentication mechanisms compliant with legal and ethical standards?

This was included, however, Team 11 pointed out that it was hard to find as they had to control F 'hippa' to find it.

• Is data storage and transmission in line with HIPAA or GDPR?

Both teams found that this was stated in the architecture design.

• Extra comments?

Team 11 mentioned that our architecture design would be improved if it was easier to navigate.

Analysis of Results

There were two main takeaways from these review sessions:

1. We need to better organize our document in an easier way to navigate. For example, the key concerns could be more clearly explained and would even benefit from their sections in the document. Furthermore, the encryptions and authentication mechanisms could be easier to find in the document by being stated more clearly.

2. Furthermore, our document requires additional crucial sections to our architectural design: Deployment View, Critical Workflows, Failure Recovery and Redundancy Mechanisms.