Software Architecture Document
-
Documentation Roadmap
- Purpose and Scope of the SAD
- How the SAD is Organized
- How a View is Documented
-
Architecture Background
- Problem Background
- Solution Background
-
Views
-
Profile
- View Description
- Architecture Background
- Variability Mechanism
- State Diagram
-
Appointment
- View Description
- Architecture Background
- Variability Mechanism
- State Diagram
-
Doctor Perspective
- View Description
- Architecture Background
- Variability Mechanism
- State Diagram
-
-
Relations Among Views
- Profile to Appointment
- Profile to Doctor Perspective
- Appointment to Doctor Perspective
-
Directory
- Index
- Glossary
The primary purpose of this Software Architecture Document (SAD) is to provide a comprehensive understanding of the software architecture within the defined scope. The SAD specifies the software architecture for the microservices: the Patient Profile, Appointments Manager, and Medical Professional Perspective. They are the critical components of the system’s architecture, structure as well as interaction. The architectural decisions for the use cases focus on the elements that are crucial to end-user interactions, appointment management or healthcare workflows. The SAD emphasizes different, unique structures related to each use case. The SAD also addresses how the behaviour of each element contributes to the functionality of the overall system.
The SAD is organized into the following sections:
-
Documentation Roadmap: The Documentation Roadmap is a section that outlines the purpose, scope and structure of the component, providing an overview of the system. This initial section outlines the purpose and scope of the SAD. It serves as a guide for readers, providing them with an overview of the document's contents and organization.
-
Architecture Background: This section describes the problem and solution background which drove the development of the software architecture. It also explicitly outlines the constraints and factors that influence the architectural design decision of our system.
-
Views: This section provides distinct viewpoints of the various components within the system. The Profile View, Appointments View, and Doctor Perspective View, document and describe the architectural background, variability mechanisms, and state diagrams of each component.
-
Relations Among Views: This section defines the relationship and connections between the individual views. It clarifies the interdependencies and interactions that are made between components.
-
Directory: This section provides additional information by sourcing referenced materials and displaying a glossary of technical terms that may be unknown to the reader.
In the Software Architecture Document, each individual view is documented using a structured format as the following:
-
View Description: Provides a description of the functionalities and features of each microservice and how they are presented.
-
Architecture Background: Describes the design patterns and technologies used within the microservices software architecture.
-
Variability Mechanism: Describes how the system can be reconfigured using the technologies and design patterns to achieve different outcomes within the microservice.
-
State Diagram: It is an important component of the documentation as it captures the state and transitions of the microservices. A UML state diagram representation of the microservice, as well as a textual description of what is required within the system to transfer between states.
The healthcare industry in Canada faces a challenge with the lack of a unified Electronic Health Record (EHR) system, prompting the need for a solution that combines common healthcare tasks into a cohesive platform. This proposed EHR system focuses on providing a streamlined system accessible to patients with a valid Canadian Personal Health Number (PHN) or medical professionals. Once logged in, users are able to view the availability of medical professionals available to them, book or manage upcoming appointments, or see their appointment history. Medical professionals are also able to update their availability, view and edit patient information, or refer patients to other medical professionals.
Aims to tackle the challenge of the absence of a unified platform. Patients can easily view available medical professionals, manage appointments while medical professionals can modify patient information, update schedule and refer patients to other doctors as needed. This solution brings a more integrated efficient healthcare system in Canada or even worldwide.
In software architecture, a "View" refers to a representation of a system that focuses on specific concerns or perspectives. Views are created to address the diverse needs and interests of stakeholders by providing a way to understand and analyze different aspects of the system's architecture.
Now, let's consider three specific viewpoints:
-
Profile View: The profile view provides a detailed representation of user profiles, outlining attributes, roles, and permissions associated with each profile. This view helps ensure that the system is designed to accommodate the diverse needs and roles of its users.
-
Appointments View: The appointment view offers a representation of the scheduling process, including the allocation of time slots and resource availability. This view helps in organizing appointments efficiently, providing a smooth workflow for both healthcare providers and patients.
-
Doctor Perspective View: The doctor perspective view presents a tailored representation of the system, emphasizing features and functionalities relevant to healthcare providers. This includes an interface for accessing patient records, managing appointments, and other tools that support medical professionals in delivering effective care.
The Profile View in software architecture offers a focused perspective on the user profile management within a system. Tailored to address concerns of system administrators, user experience designers, and security personnel, this view provides a visual or documented representation of user attributes, roles, and access privileges. It encompasses crucial components such as user characteristics, assigned roles, and specific permissions, aiding in security planning, user experience design, and administrative configuration. The Profile View ensures that the system aligns with diverse user needs, promotes effective communication among stakeholders, and plays a vital role in security implementation and user interface design. By presenting a clear, comprehensive overview of user profiles, it is faster for users to update and follow the system.
The architecture of the Profile View is designed to efficiently manage user profiles within a software system, with a primary focus on user experience, and seamless administrative configuration. Leveraging the Decorator design pattern, the Profile View employs a modular and extensible approach to enhance user attributes, roles, and access privileges dynamically. Implemented in Django, a Python web framework, this API-based architecture ensures flexibility and ease of development. The system is hosted on Vercel, providing scalability and performance, while the PostgreSQL database, hosted on Railway, serves as a robust and relational data store for storing user-related information. The Django ORM (Object-Relational Mapping) seamlessly integrates with PostgreSQL, enabling efficient data retrieval and manipulation. This architecture ensures a cohesive and scalable solution for managing user profiles with the added benefits of a decorator pattern, Django's framework capabilities, and reliable hosting on Vercel and Railway. By following this architecture background structure, it ensures that our system provide a user-friendly, easy experience for users to navigate.
Incorporating a dynamic configuration file approach enhances the variability of the Profile View. The system can be configured through external files that specify user attributes, roles, and permissions. Employing the Decorator pattern, these configuration files can dynamically modify or extend the behaviour of the Profile View without altering the core codebase. Each configuration file corresponds to a specific set of attributes or roles, enabling administrators to customize the system behaviour based on varying user requirements. The approach facilitates easy adaptation to evolving user needs without the need for code redeployment. Additionally, the Django framework's settings module and Vercel's environment variables can be utilized to seamlessly integrate and manage these dynamic configuration files, ensuring a highly adaptable and maintainable Profile View architecture.
The Profile Microservice state model starts in a state of being signed out. From here there are two options, sign in or sign out. In the event of signing in, the user must input a valid username and password to move into the signed-in state but if their request to sign in is invalid, they are sent back to the start, the not signed-in state. In the event of signing up, the user will have to input a valid Date of Birth and Personal Health number which will then be verified. If this request is not met the user will be sent back the not signed-in state. If the request is met, an account will be created for the user and they will be prompted to input contact information to finalize the creation of their account. After the user has done that, they will be redirected to the signed-in state.
The Appointment View in software architecture provides a dedicated perspective for managing and representing the scheduling and administration of appointments within a system. This view is designed to address concerns related to the lifecycle of appointments, encompassing creation, modification, and cancellation. Stakeholders, including healthcare providers, administrators, and patients, benefit from the Appointment View's representation of the scheduling process. The view outlines key aspects such as time slot allocation, resource availability, and the overall coordination of appointments. This visual or documented representation aids in organizing appointments efficiently, contributing to a streamlined workflow for both healthcare providers and patients. The Appointment View plays a crucial role in ensuring that the system's architecture aligns with the dynamic and time-sensitive nature of appointment management within various contexts, such as healthcare systems or service-oriented platforms.
The architecture of the Appointment View is crafted to proficiently handle the scheduling and management of appointments within a software system, with a primary emphasis on flexibility, user experience, and seamless database interaction. Utilizing the Decorator design pattern, the Appointment View creates a commutable advance to further appointment-related functionalities dynamically. Developed in Django, and deployed as an API on Render, the architecture ensures responsiveness, and ease of integration with other services. The PostgreSQL database, also hosted on Render, serves as a strong relational data store, efficiently storing and retrieving appointment data. The Django ORM (Object-Relational Mapping) integrated with PostgreSQL, providing a high-performance and maintainable solution for appointment management. This architecture, hosted on Render, offers a reliable and scalable platform for the Appointment View, ensuring a seamless and responsive experience for healthcare providers, administrators, and patients interacting with the appointment scheduling system.
Within the Django application's settings.py file, a variability mechanism revolves around the DEBUG boolean setting. This setting dictates whether the application is in debug mode, with DEBUG set to True enabling detailed error pages on the web interface. For the appointment view, developers can leverage this mechanism by incorporating a conditional check in the relevant view or template. This allows for the conditional display of appointment details based on the application's debug mode, ensuring that sensitive information remains hidden in a production environment. By simply toggling the DEBUG setting in the settings.py file, developers can seamlessly control the level of error information displayed. This facilitates effective debugging during development while upholding security standards in a production setting.
The Appointment Microservice state model shows that the microservice begins in an idle state waiting for a request. From this state, the microservice can be requested to search the appointment database by the current posted schedule or by patient or doctor ID. The requested information is then fetched from the database and displayed. If an error occurs during the fetching state, the system will switch to the error state and then return to idling. From the display state, the microservice can either return to idle, or send a request to post various information to the database. This includes booking an appointment, updating appointment details, or canceling an appointment. The system enters the posting state, and the information is entered into the correct endpoint in the database. If an error occurs, the system will enter the error state and then return to idling. If posting the information is successful, the system will return to idling.
The Doctor Perspective View in software architecture offers a specialized lens for healthcare providers within a system, concentrating on their unique concerns and requirements. This view is intricately designed to address the needs of medical professionals, emphasizing features such as seamless access to patient information, efficient appointment management, and an overall user experience tailored to the intricacies of healthcare workflows. Stakeholders, primarily comprising doctors and medical staff, benefit from this view's representation of the system, which highlights functionalities critical to delivering effective care. This View provides a detailed depiction of interfaces for accessing patient records, managing appointments, and tools specific to healthcare providers, ensuring a user-friendly and intuitive experience aligned with the distinct workflows of medical professionals within the broader software system.
The architecture underpinning the Doctor Perspective View is intricately tailored to meet the distinctive needs of healthcare providers within the software ecosystem. Meticulously designed with a focus on a singular, globally accessible instance, the implementation embraces the Singleton design pattern to ensure optimized resource management and state coherence. Developed using Next.js and deployed as an API on Vercel, the architecture emphasizes not only the responsiveness and scalability demanded by healthcare workflows but also the seamless and dynamic nature of user interactions. The PostgreSQL database, hosted on Render, stands as a reliable and relational repository, managing crucial patient information and appointment data. The integration of Next.js with Vercel ensures a robust and performant foundation for the Doctor Perspective View, offering an intuitive, personalized interface tailored for healthcare providers engaging with patient records and streamlined appointment management tools.
The Doctor Perspective View incorporates a dynamic availability management mechanism, leveraging Prisma's 'upsert' API to efficiently handle updates and creations of doctor availability. This mechanism allows for the seamless modification of availability records tied to a doctor's account. When a doctor's availability needs to be updated, the system uses the 'upsert' functionality to check if the record exists. If it does, the record is updated with the new availability information; if not, a new availability record is created. A key constraint is that the doctor's account must exist, ensuring the availability data is correctly linked. This approach provides a flexible and adaptive solution for managing doctor availability within the Doctor Perspective View, facilitating real-time updates and ensuring accurate representation of the dynamic schedules of healthcare providers. The integration of Prisma with Next.js further enhances the efficiency of database interactions, contributing to a seamless and responsive user experience for healthcare providers.
This state model of the Medical Professional Microservice shows that the microservice begins in a signed out state, and after valid credentials are entered and verified, the microservice enters a signed-in state. If a patient profile or the availability is selected, the service will enter a fetching state while it gets the data from its respective end point. If the service cannot fetch the data and encounters an error, it will enter an error state before returning to the default signed-in state. If the data is successfully fetched, the service will then display the data. If the user chooses to update the data they are viewing, the system will enter a posting state while it posts the new data to its respective end point, otherwise they can return to the default signed-in state. If the service encounters an error and cannot post the data, it will enter an error state before returning to the default signed-in state. If it successfully posts the data, it will return to the default signed-in state. By logging out, the service will re-enter a signed-out state, and from there the service can be exited.
The Profile, Appointment, and Doctor Perspective Views form a cohesive triad within the software architecture, each playing a distinct yet interconnected role. The Profile View focuses on user attributes and permissions, influencing the Appointment View, which manages the dynamic scheduling of appointments. Simultaneously, the Doctor Perspective View builds upon both, tailoring the interface for healthcare providers, ensuring seamless access to patient information and efficient appointment management. Together, these views create a comprehensive and user-centric system, addressing diverse stakeholder concerns, from general users to healthcare professionals, and facilitating a integrated representation of the software's functionality.
The relationships that exist between the Appointment and Profile Views create a smooth software system integration. Users can view personalized information about themselves, including appointment schedules, in the Profile View. The Appointment View, where users may make new appointments and cancel old ones, is dynamically linked to this data. In order to provide a consistent and real-time representation of scheduled activities, the reciprocal relationship makes sure that changes made in the Appointment View, such as making or cancelling appointments, are reflected in the user's profile. Through the centralization of appointment-related tasks inside the Appointment View and the provision of a comprehensive dashboard for managing and reviewing personal data and planned appointments within the Profile View, this interplay improves user experience.
A regulated information flow inside the software system is established by the interaction between the Profile and Doctor Perspective Views. Patients, as seen in the Profile View, are not very visible and cannot obtain doctor information. On the other hand, physicians have complete access to patient profiles through the use of the Doctor Perspective read, which allows them to read relevant information and take notes. Doctors and patients are linked to one another through this process, which enables doctors to relate notes to particular patients. Furthermore, the schedule of appointments acts as a vital link between patients and doctors by arranging their meetings in advance. Doctors are guaranteed to have the information they need to treat patients effectively because to this complex interconnectedness, and patient privacy is protected by regulated access within the Profile View. This integrated approach enhances the efficiency of the healthcare operation system.
The link between the Appointment and Doctor Perspective Views is essential. Through the use of the Doctor Perspective View, doctors can modify or cancel patient appointments, which directly affects the Appointment View. At the same time, physicians can start the appointment-setting process by using the Appointment View to make new appointments with patients. A dynamic and well-organized appointment management system is ensured by this bidirectional connection, which enables medical professionals to effectively arrange appointments, make required modifications, and deliver the best possible care. The way these perspectives interact creates a strong foundation for the software system's cooperative, patient-focused appointment scheduling management.
| Term | Definition |
|---|---|
| Application Programming Interface (API) | A software link that allows to applications to talk to each other |
| Vercel | A frontend cloud that provides the infrastructure to build a web application |
| Django | A high-level Python web framework for development |
| Next.js | A React web framework for development |
| Prisma | A Server Library for database access for developers |
| PostgreSQL | A type of SQL database |
| Render | Cloud application hosting service for developers |
| Railway | Cloud Application to build, deploy, and monitor applications |