Data Flow Models - SENG-350-2024-fall/Team-11 GitHub Wiki

Develop a Level 0 Data Flow Diagram (DFD) that illustrates the overall flow of information across the platform, providing a high-level view of how data moves between different components.

Then, break down the primary processes into a more detailed Level 1 DFD to show each process's specific interactions and finer details. As part of this breakdown, identify the data stores and data flows to ensure a comprehensive understanding of how information is stored, accessed, and transferred within the system.

Please add a textual explanation (not just the diagrams).

Level 0 Data Flow Diagram for the Mister ED System

DFD0-Unavailable

The Level 0 DFD provides a high-level view of how data flows through the Mister ED virtual triage system, which is designed to reduce emergency department (ED) overload by directing patients to the most appropriate care options. The diagram illustrates the interactions between patients, healthcare entities, and various system processes.

1. Process 1.0: Emergency Cases

  • The patient undergoes virtual triage through Process 1.0, where the system assesses their symptoms and determines the urgency of their condition. The patient's case is then sent to the Emergency Department (ED) if the system deems it necessary. The ED uses this process to allocate a time for the patient, prioritizing urgent cases to reduce wait times.

2. Process 2.0: Provide Medication

  • Once a diagnosis or treatment recommendation is made, Process 1.0 shares the patient's information with Process 2.0. If medication is required, this process sends prescription details to the Chemist, who dispenses the necessary medication. This helps patients manage symptoms remotely or as part of their treatment plan, reducing unnecessary visits to the ED.

3. Process 3.0: Regular Check-Up

  • For non-emergency cases, the system may recommend a regular check-up. In Process 3.0, the Clinic contacts the Patient to schedule a follow-up. Information about the check-up, such as the date, location, and time, is provided to the patient, ensuring proper coordination between healthcare providers.

4. Process 4.0: Provide Care

  • If the virtual triage determines that care from a Nurse is required, the ED sends a request for patient care to Process 4.0. This process then passes the request to the Nurse, who contacts the Patient to arrange an appointment. Through this process, patients receive timely care without the need to visit the ED unless necessary.

5. Process 5.0: Manage Users

  • Process 5.0 handles user management across the platform. All entities, including ED, Admin, Nurse, Patient, Clinic, and Chemist, use this process to register, log in, or log out. The Admin entity has additional permissions, allowing them to manage user accounts (add or delete users) and view Audit Logs to monitor system activity.

Level 1 Data Flow Diagrams

1. Process 1.0: Emergency Cases

DFD-1.0

This Level 1 Data Flow Diagram describes the Virtual Triage Process, which includes the following subprocesses: Collect Symptoms (1.1), Assess Symptoms (1.2), Determine Urgency (1.3), and Submit to Emergency Department (1.4). The database serves as a key data source, storing patient information, triage results, and clinical criteria, which help guide the assessment and prioritization of cases.

The process begins with 1.1 Collect Symptoms, where the patient accesses the website and enters their symptoms into the system. This data is temporarily stored and prepared for assessment.

Next, in 1.2 Assess Symptoms, the system uses the Triage Criteria information from the Database to evaluate the patient’s symptoms. This step involves applying specific algorithms and guidelines to determine potential conditions and associated risk levels.

In 1.3 Determine Urgency, the system categorizes the patient's case based on urgency, determining whether immediate care is necessary or if a regular consultation would suffice. This process is based on the results of the assessment and triage criteria.

If deemed necessary, 1.4 Submit to Emergency Department sends the patient's case to the Emergency Department (ED) for further action. This step involves notifying the ED of the patient's condition and prioritizing them within the ED’s scheduling system. Additionally, the patient is notified of the care recommendation and provided with ED facility details.

2. Process 2.0: Provide Medication

DFD-2.0

This Level 1 Data Flow Diagram covers the Provide Medication process, which consists of the following subprocesses: Receive Prescription (2.1), Dispense Medication (2.2), Offer Advice (2.3), Filter Prescriptions (2.4), Coordinate with Providers (2.5). The Prescription Database is used to store prescription information that can be updated by the emergency department or the pharmacy (Chemist).

This process begins after the patient has completed the virtual triage process and it is determined that they require medication. The prescription is submitted to 2.1 Receive Prescription, where the system captures prescription details and stores them in the Prescription Database. The prescription is then processed by 2.2 Dispense Medication, where the prescription is filled and provided to the patient.

After, the Chemist has the opportunity to 2.3 Offer Advice if further guidance or over-the-counter options are required. They offer advice on medication usage for managing the patient's condition.

To effectively manage prescriptions, 2.4 Filter Prescriptions organizes prescriptions to ensure patients receive their medication promptly, and that high-priority prescriptions are addressed first.

Finally, 2.5 Coordinate with Providers ensures ongoing communication with GP (Clinic), nurses, or the Emergency Department regarding the prescription. This step resolves any issues such as missing information or conflicting medications, and allows for the modification or updating of a prescription in the Prescription Database

3. Process 3.0: Regular Checkup

DFD1.3.0

This Level 1 Data Flow Diagram covers the Regular Check-Up process, consisting of the following subprocesses: Receive Referrals (3.1), Access Patient History (3.2), Provide Care (3.3), Update Patient Records (3.4), and Communicate with ED (3.5). The Patient Database is used to store patient information, including registration details, triage results, and care records, which can be updated by the clinic staff.

The process begins when the clinic receives notifications about patients who have been directed to them instead of the Emergency Department (ED) through 3.1 Receive Referrals. The clinic logs these referrals into the Patient Database for future reference.

Next, the system moves to 3.2 Access Patient History, where clinic staff retrieve and review the patient's historical data and triage results from the Patient Database. This information helps the staff to understand the patient's medical background and assess their current needs.

Following this, in 3.3 Provide Care, the clinic staff offers appropriate medical care based on the patient's needs and historical data.

After providing care, 3.4 Update Patient Records is completed to ensure that the patient's records reflect the most recent medical interventions and observations. This step keeps the Patient Database current and accurate.

Finally, 3.5 Communicate with ED facilitates ongoing communication between the clinic and the Emergency Department. This ensures that any necessary follow-ups or referrals are addressed promptly. During this process, any updates regarding patient care or issues such as missing information are communicated, allowing for modifications or updates in the Patient Database.

4. Process 4.0: Provide Care

DFD1-4.0

5. Process 5.0: Manage Users

DFD1-5.0-Error

The Level 1 Data Flow Diagram (DFD 1) outlines the Manage Users process, which consists of five key subprocesses: Register User (5.1), Login User (5.2), Manage User Accounts (5.3), View Audit Logs (5.4), and Logout User (5.5). The system utilizes two primary databases: the User Database, which stores essential information like usernames, passwords, and roles, and the Audit Log Database, which records user activities for monitoring and compliance.

In this process, when a user submits their registration information, it is directed to 5.1 Register User, where their data is stored in the User Database. For logging in, users provide their credentials through 5.2 Login User. The system validates these credentials against the User Database and logs the login attempt in the Audit Log Database. If an admin requests to add or delete user accounts, this action occurs in 5.3 Manage User Accounts, with updates made to the User Database and corresponding logs recorded in the Audit Log Database.

When admins want to review user activities, they can access the Audit Log Database via 5.4 View Audit Logs. Lastly, when users decide to log out, they initiate 5.5 Logout User, which terminates their session and records the logout information in the Audit Log Database.