Mister ED Software Architecture Document

Documentation Roadmap and Overview

Purpose and Scope of SAD

The Software Architecture Document (SAD) outlines the high-level architecture and design decisions for the Mister ED system. This document serves as a comprehensive guide to understanding the system’s structure, components, and interactions. It aims to ensure that all stakeholders (e.g., developers, project managers, and clients) have a clear and shared understanding of the system’s architecture. The document defines the system’s key components, the processes involved, and how they relate to each other.

Key Objectives:

• To present the overall structure of the system from multiple views (Logical, Process, Physical).
• To explain how various modules and components interact and depend on each other.
• To document the system’s behavior, including role-based access control and data flows.
• To guide the implementation of the system by providing clear architectural guidelines.

Scope:

• The SAD covers all core modules and processes involved in the Mister ED system, which includes functionalities for patient management, medical staff interactions, role-based access control, and prescription management.
• It does not cover lower-level implementation details but focuses on high-level architecture and system design decisions.

---

How SAD is Organized

The Software Architecture Document (SAD) is organized into several distinct sections, each focusing on a different aspect of the system. This structure ensures clarity and provides a systematic approach to understanding the system’s architecture. Below is an overview of the sections:

1. Documentation Roadmap and Overview

   • Provides an overview of the document’s purpose, scope, and the system’s high-level goals.

2. Architecture Overview

   • Presents a summary of the system architecture, including key components and how they relate to each other.

3. Views

   • Describes the various architectural views that represent different perspectives of the system:
     • Logical View: Represents the system’s functional modules and their interactions.
     • Process View: Focuses on system processes, workflows, and their execution.

4. Mapping Between Views

   • Demonstrates how elements from different views are related to each other, showing the flow of information and dependencies across views.

5. References and Glossary

   • Referenced materials and a list of terms.

---

How a View is Documented

Each view in the Mister ED system is documented following a structured approach, ensuring that all relevant aspects of the system are covered in sufficient detail. The documentation of each view includes the following:

1. View Description:

   • A high-level description of the view, explaining what it represents in the context of the system and its role in the overall architecture.

2. Components or Elements:

   • A detailed breakdown of the key components or elements involved in the view. This could include modules, systems, processes, or hardware components depending on the view.

3. Interactions:

   • Describes how components in the view interact with each other. This can include both internal component interactions (e.g., between modules) and external interactions (e.g., with users or external systems).

4. Diagrams:

   • Visual representations of the components and their interactions. Diagrams can include:
     • Component Diagrams (Logical View)
     • Process Flow Diagrams (Process View)
     • Sequence Diagrams for specific user scenarios

5. Mapping to Other Views:

   • Shows how the components or processes in the view map to other views. This can be done via mapping tables or cross-view diagrams to show relationships between views.

6. Variability:

   • Any role-based or configuration-specific variability in how the system behaves in this view, based on different user roles (e.g., patient, doctor, pharmacist) and interactions with the system.

Each view is documented with an emphasis on clarity, completeness, and consistency, ensuring that the system’s architecture can be easily understood and implemented by all stakeholders.

Architecture Background

Problem Overview

Healthcare workers and patients collectively have expressed their dissatisfaction with the current way that emergency departments operate. Patients will come to the emergency department with low-priority ailments, wasting emergency department resources. The patients are also dissatisfied with the amount of time they have to wait for cursory assessments and low-effort analyses from doctors.

System Overview

The Mister ED system is designed to support healthcare environments, focusing on managing interactions between different types of medical staff (e.g., doctors, nurses, pharmacists, receptionists) and patients. It serves as a central platform for the secure management of patient information, prescriptions, appointments, and triage status, with a particular emphasis on role-based access control.

The system is modular and role-based, with each user type (patient, doctor, nurse, pharmacist, receptionist) having distinct access privileges and responsibilities. Key features of the system include:

• Secure user authentication and role management.
• Prescription management, allowing doctors to prescribe medications and pharmacists to fulfill those prescriptions.
• A triage management system, enabling nurses and receptionists to manage patient queues and triage statuses.
• A communication module that facilitates interaction among medical staff and patients, ensuring that all data exchanges occur within the boundaries of role-based access control.

The system aims to streamline healthcare operations by providing an intuitive interface for medical staff and patients while maintaining the security and confidentiality of medical data.

Context

The Mister ED system is intended for use in hospitals or clinics that manage a high volume of patient data and interactions. The system operates within a controlled environment where confidentiality, accuracy, and efficiency are paramount. It is designed to integrate with existing medical and administrative systems, offering secure access to various stakeholders involved in patient care.

The context in which this system operates involves:

• Multiple users with different roles accessing a centralized system for managing patient data.
• Strict regulations around privacy and security (e.g., HIPAA compliance in the U.S.) that influence the architecture's design.
• A dynamic environment where patient status, medical records, and staff availability can change frequently, requiring real-time updates and interactions.
• Scalability to support a growing number of users and patient records over time.

The system must also integrate with existing hospital infrastructure, such as appointment scheduling systems, electronic medical records (EMR), and prescription fulfillment platforms.

Driving Requirements

The architecture of the Mister ED system is driven by the following key requirements:

1. Security and Privacy:

   • Ensure that patient data is handled securely, in compliance with regulations such as HIPAA or GDPR.
   • Implement role-based access control (RBAC) to restrict access to sensitive information based on the user’s role (e.g., patients cannot modify their medical records; pharmacists can only access prescriptions).

2. Usability:

   • The system must provide an intuitive interface for different user types (patients, doctors, nurses, pharmacists, receptionists), with clear and easy-to-navigate workflows.
   • It should minimize the need for extensive training by the end users, ensuring ease of adoption and use in high-pressure environments like hospitals.

3. Scalability and Performance:

   • The system should handle an increasing number of users (medical staff and patients) and records without significant performance degradation.
   • Real-time updates must be supported, especially for critical data such as patient status or prescription requests.

4. Reliability and Availability:

   • The system must be highly available, with minimal downtime, as healthcare operations require continuous access to patient data and medical records.
   • It should include features like data backup and recovery mechanisms to safeguard against potential data loss.

5. Flexibility and Extensibility:

   • The system should be adaptable to support future feature extensions (e.g., adding new roles or integrating additional medical systems).
   • It should be flexible enough to accommodate potential changes in regulations or hospital policies.

6. Interoperability:

   • The system must be able to integrate with other hospital management systems (e.g., appointment scheduling, electronic medical records, pharmacy systems).
   • It should support standard healthcare data formats (e.g., HL7, FHIR) for seamless exchange of information with external systems.

These driving requirements ensure that the system meets the needs of the healthcare environment while maintaining high standards of security, usability, and performance.

Solution Overview

Architectural Approaches

The Mister ED system architecture adopts several key architectural approaches to address the identified requirements and constraints, ensuring that the system is secure, scalable, reliable, and easy to maintain. The main architectural approaches employed are:

1. Modular Architecture:

   • The system is divided into independent functional modules, each handling a specific area of responsibility (e.g., authentication, prescription management, triage management). This approach allows for easier development, testing, and maintenance, as well as flexibility in scaling specific components independently.

2. Role-Based Access Control (RBAC):

   • The system’s access control is based on roles, ensuring that users can only access data and functionality that are relevant to their role. Roles such as patients, doctors, nurses, and receptionists are defined, each with distinct privileges regarding the data they can view and modify. This approach ensures data security and prevents unauthorized access.

3. Event-Driven Architecture:

   • An event-driven approach is employed to facilitate real-time updates and interactions. When a change occurs (e.g., a prescription is filled or a triage status is updated), events are triggered, which can update related components or notify other users in the system (e.g., notifying a pharmacist when a prescription is ready to be filled).

4. Service-Oriented Architecture (SOA):

   • The system is built using a service-oriented approach, where each functional module (e.g., authentication, prescription management, etc.) is exposed as a service. This enables integration with external systems, such as electronic medical records (EMR) systems or third-party prescription fulfillment platforms, ensuring the system is interoperable and can grow over time.

5. Microservices:

   • Where feasible, the system follows a microservices approach, deploying smaller, independently scalable services that correspond to specific business functionality (e.g., appointment scheduling, prescription tracking). This ensures that each service can be scaled and updated independently, improving the overall flexibility and maintainability of the system.

6. Cloud-Based Deployment:

   • The system is designed for deployment in a cloud environment, enabling scalability, high availability, and disaster recovery. Cloud services also offer the flexibility to manage infrastructure as needed, without being dependent on physical hardware, and can easily accommodate growing user numbers and patient records.

7. High Availability and Fault Tolerance:

   • Given the critical nature of healthcare data, the architecture incorporates redundancy, load balancing, and automated failover to ensure that the system remains available even in the event of a failure. This approach is essential for providing continuous access to the system in healthcare settings.

Failure Recovery and Redundancy Mechanisms

Description

Failure recovery and Redundancy mechanisms ensure the application is able to keep working in the case of failures. This is implemented using architecture tactics.

Tactics

• Removal From Service: Removal From Service is a tactic that involves temporarily removing features that either need to be updated, require maintenance, or are unavailable, either due to user restrictions, or unmet requirements. For instance, if a user is creating a password, the 'Save' button should be greyed out until all the boxes have been filled.

• Retry: The retry tactics ensure the system keeps running if none or incorrect information is given. It does so by retrying until the correct information is given/fetched. This makes sure that the system is running how it should and incorrect information doesn't cause the system to stop working as intended, hence can recover from possible failure.

• Exception Management: Exception management is an availability tactic that makes sure the system runs smoothly and stays available despite unexpected input. It catches an invalid input and handles it by throwing an exception, which prevents faulty input from proceeding and avoids system crashes.

Critical Workflow

Description

The workflow begins with the patient logging into the system, and providing their symptoms. Once completed they choose a hospital of their liking and convenience. Once their information has been confirmed, and only if it's correct they can proceed to the virtual triage with a nurse. Based on the triage the patient is either asked to come to the hospital, be put on the waitlist, or be given an appointment with the doctor to come later.

Actors

• Patient: provides symptoms and selects given services.
• Nurse: Conducts virtual triage and determines the severity of symptoms.
• Receptionist: Provides support during registration and verifies information.
• Doctor: provides patient with treatment.

Steps in workflow

Patient Login

1. The patient uses their username and password to log in.
2. The application checks the information and logs in the patient.

Symptom Reporting

1. Patient enters their symptoms.
2. The application saves the symptoms entered.

Hospital Selection

1. The application displays nearby hospitals.
2. The patient selects a hospital from the given list.

Information Confirmation

1. The receptionist is given the patient's information.
2. The patient confirms information with the receptionist.

Virtual Triage

1. A nurse is connected with the patient.
2. The nurse takes the patient through a virtual triage.
3. Depending on the symptoms and severity the patient either: goes to the hospital immediately, is added to the waitlist, or can book an appointment.

Treatment

1. The patient arrives at the hospital.
2. The doctor is given all information that was taken through Mister ED.
3. The doctor treats the patient accordingly.

Activity Diagram

Analysis Results

The analysis of the Mister ED system’s architectural requirements has led to several important conclusions and insights that guide the design decisions:

1. Security Is a Priority:

   • Protecting patient data and ensuring that only authorized personnel have access to sensitive information are top priorities. The implementation of role-based access control (RBAC), encryption, and secure communication channels addresses this need.

2. Scalability Concerns:

   • As the healthcare environment can grow and evolve, scalability is crucial to ensure that the system can handle increasing numbers of users, patient records, and real-time interactions. The adoption of a modular architecture, cloud-based deployment, and microservices enables scalability.

3. Real-Time Updates:

   • Real-time updates are essential for improving workflow efficiency in a medical environment. An event-driven architecture was chosen to ensure that critical events, such as changes in patient status or prescription updates, are communicated immediately to the relevant users.

4. Usability and Flexibility:

   • Ensuring the system is user-friendly and adaptable to various user roles was another key consideration. The design of clear and distinct user interfaces for each role (e.g., patients, doctors, nurses, pharmacists) ensures usability, while the modularity of the system allows flexibility in extending functionality as new needs arise.

5. Integration with External Systems:

   • The system’s ability to integrate with other healthcare systems (e.g., electronic health records, third-party medical systems) is critical. The use of service-oriented architecture (SOA) allows seamless integration through well-defined service interfaces.

Mapping Requirements to Architecture

The architectural approaches described above directly map to the system requirements identified in the earlier sections. Below is a mapping of key requirements to the architectural components:

Requirement	Architectural Component
Security and Privacy	Role-Based Access Control (RBAC), Encryption, Secure Communication
Usability	Modular architecture, Role-based User Interfaces, Simplified Workflows
Scalability	Microservices, Cloud-Based Deployment, Event-Driven Architecture
High Availability	Redundancy, Load Balancing, Failover Mechanisms
Interoperability	Service-Oriented Architecture (SOA), External System Integration
Performance	Event-Driven Architecture, Cloud Infrastructure, Load Balancing
Reliability and Availability	High Availability, Fault Tolerance, Cloud Deployment
Flexibility and Extensibility	Modular and Microservices-Based Design, Service-Oriented Architecture

This table shows how the architectural decisions address the functional and non-functional requirements of the system. By employing these strategies, the architecture supports the goals of the Mister ED system while ensuring long-term sustainability, performance, and security.

Views

Logical View

Primary Presentation

Below is the logical view of the Mister ED system. This diagram illustrates the functional modules and their interactions:

Element Catalogue

Element	Description
Authentication Module	Handles login and role verification
Role Management Module	Access control and changes to GUI based on user
Prescription Management Module	Ensures secure assignment of prescriptions
Communication Module	Allows specified roles to communicate with each other

Variability Guide

User interface:

• Patients can only see medical information pertaining to them
• Receptionists are only able to see triage results and queue data
• Doctors can see medical information pertaining to each of their patients
• Nurses can only see triage information and immediately relevant information pertaining to patients undergoing triage
• Pharmacists can see doctor recommendations and information about patients requiring prescriptions

Process View

Primary Presentation

Below is the process view of the Mister ED system. This sequence diagram illustrates the functional modules and their interactions:

Element Catalogue

Module	Description
User	The individual interacting with the system, such as a Patient, Receptionist, Doctor, Nurse, or Pharmacist.
System	The main system that handles user authentication, data access control, and responds to user actions.
Patient Dashboard	Displays medical information, but with view-only access. Patients can send messages to medical staff.
Receptionist Dashboard	Allows the receptionist to schedule appointments and add patients to the queue.
Doctor Dashboard	Displays patient medical data and allows the doctor to modify patient records and prescriptions, and submit recommendations.
Nurse Dashboard	Displays triage-related information and allows the nurse to update triage status.
Pharmacist Dashboard	Displays prescriptions and allows the pharmacist to add new prescriptions and confirm fills or refills.
Medical Staff Communication	Facilitates communication between patients and medical staff by sending messages.
Appointment Scheduling	Manages the scheduling of appointments by receptionists, storing them in the system.
Patient Queue Management	Allows receptionists to manage the queue and add patients to it.
Prescription Management	Handles the management of prescriptions, including modifications and confirmations by doctors and pharmacists.
Triage Management	Handles triage status updates by nurses for patients undergoing triage.
Logout Process	The system handles user logout and returns the user to the login page.

Variability Guide

Access control:

• Patients are only able to send and receive information to and from the medical staff. They are unable to make any changes to existing stored data.
• Receptionists are able to schedule appointments based and add patients to a queue
• Doctors are able to change all patient data and prescription data and submit recommendations for other staff
• Nurses are able to change triage status
• Pharmacists are able to provide prescriptions and confirm prescription orders, fills, and refills

Deployment View

Deployment Diagram

Element Catalog

• Patient device: a device owned by the prospective Mister ED users (patient), that is capable of installing and using Mister ED.
• Patient Records: a database consisting of the patient's medical records and personal information.
• Waitlist: a database consisting of the current waitlist of patients.
• Virtual Triage: A server where patients are triaged virtually by nurses.
• Receptionist Device: a device owned by the prospective Mister ED users (receptionist), that is capable of installing and using Mister ED.
• Nurse Device: a device owned by the prospective Mister ED users (nurse), that is capable of installing and using Mister ED.
• Doctor Device: a device owned by the prospective Mister ED users (doctor), that is capable of installing and using Mister ED.
• Mister ED: the Mister ED application.
• Notification: a feature in the Recoptions Mister ED that lets them send notifications to patients.
• Scheduler: a feature in the Recoptions Mister ED that lets them create appointments.
• Schedule: a feature in the Doctor Mister ED that lets them view their appointments.

Related Views

Logical View is the parent view of Process View

Mapping Between Views

Logical View Component	Process View Component
Authentication Module	User Login Process
Role Management Module	Role-based Access Control Flow
Prescription Management Module	Prescription Handling Process
Communication Module	Staff Messaging Process
Patient Dashboard	Patient View Access
Doctor Dashboard	Doctor Interaction Process
Receptionist Dashboard	Appointment Scheduling Process
Nurse Dashboard	Triage Status Update Process
Pharmacist Dashboard	Prescription Fulfillment Process

Referenced Materials

https://wiki.sei.cmu.edu/confluence/display/SAD/Software+Architecture+Documentation+Template

Glossary and Acronyms

• Actors: Any entity that interacts with the system.
• Authentication: The process of verifying a user's identity to give access to the system.
• ED: Emergency Department.
• Emergency Department (ED): A medical facility dedicated to providing immediate care for urgent and emergency cases.
• GUI: Graphical User Interface.
• Notification: A message sent to a patient to inform them of their next steps, such as arriving at the hospital or confirming an appointment.
• Virtual Triage: An online assessment done by a nurse.