How it Works
Combining visual maps with simple stories to explain every part of the SQMS system.
Patient Joining Journey
In this part, we show how a patient uses their phone to join the waitlist. First, the phone asks the system for a spot. The system checks if the patient is already there. If everything is okay, it gives them a new number. Then, the phone shows the patient how long they need to wait to see the doctor.
1. First, the patient opens the mobile app on their phone to start the process.
2. They look for the department they want to visit, like the heart clinic or general doctor.
3. The patient clicks the button to join the digital queue from anywhere inside the hospital.
4. The app sends a small request to the Node.js server to ask for a new token ID.
5. The server checks the database to see if the patient already has an active token there.
6. If everything is okay, the server calculates the next available token number for that clinic.
7. The server updates the record in the MongoDB database to save the patient's information safely.
8. A unique code is assigned so the system knows exactly which patient is currently waiting.
9. The patient immediately sees their new token number appearing on their mobile phone screen.
10. Finally, the app shows the current position and estimated waiting time so the patient stays calm.
Clinician Calling Story
This section explains how the doctor calls the next patient. The doctor clicks a button on their screen. The computer checks who has been waiting longest. It then sends a loud chime to the big TV screen in the hallway to call the patient's number. At the same time, the doctor sees all the patient's information on their own screen.
1. The doctor or medical staff logs into the Premium Dashboard using their clinic credentials.
2. They verify which clinic room they are sitting in, such as "Clinic Room 5" or "Room 10".
3. When the doctor is ready for the next patient, they click the large "Call Next" button.
4. The web dashboard sends an instruction to the API layer of the Node.js server to fetch a patient.
5. The server runs a priority check to see if any emergency or senior patients are waiting first.
6. It picks the patient who has been waiting the longest in the highest priority category available.
7. The server marks that specific token as "Currently Serving" in the central MongoDB database.
8. The database updates the clinic status so other staff can see the room is now occupied.
9. The server then sends a signal to the Public TV to announce the new token number loudly.
10. Finally, the staff's dashboard shows the patient's details so the doctor knows who is entering the room.
TV Display Update Flow
This part shows how the big TV screens in the hospital stay up to date. The main computer sends messages to all the TVs at the same time. This way, whether a TV is in the hallway, the lab, or the lounge, they all show the same patient numbers. Everything happens instantly, so no patient goes to the wrong room.
1. The Public TV display is connected to the internet and stays open in the main waiting area lounge.
2. It maintains a constant connection to the server so it can receive updates without refreshing.
3. When a token is called, the TV hears a special "Update" event sent by the Node.js server.
4. The screen immediately changes to show the token number in large, bright colors on the board.
5. An automated voice or a pleasant chime sound plays to catch the attention of the patients waiting.
6. The TV also shows which clinic room the patient should go to, like "Room 3" or "Doctor A".
7. In the sidebar of the TV, the next few tokens are shown so people can get ready for their turn.
8. If a patient does not show up, the TV removes that token number after the staff clicks "No Show".
9. The TV also displays helpful health tips or news between calling patients to keep people informed.
10. This real-time synchronization makes sure that nobody misses their appointment or goes to the wrong room.
Admin Management Process
This guide explains how the system manager sets everything up. The manager uses a special website to add new departments or change the rules. The system checks to make sure the manager is allowed to make these changes. If okay, it saves the new rules and tells all the doctors' computers about the changes right away.
1. The administrator enters the secure system management area to configure the hospital settings.
2. They can create new departments easily, such as adding a "Dental Care" section to the queue.
3. The admin changes how many tokens can be issued per hour to prevent the clinic from being too busy.
4. When they save a change, the request goes through a security layer to ensure only admins can do this.
5. The Node.js server receives the new settings and validates the data for any common errors.
6. The server then writes these new rules and department codes into the MongoDB cloud database.
7. All active staff dashboards receive an update automatically so they know about the new department.
8. The admin can also reset the token counter at the end of the day to start fresh tomorrow morning.
9. They can monitor live reports to see how many patients each doctor served during the day.
10. This flow ensures the whole hospital system stays organized and works perfectly for everyone involved.
Cloud Data Story
Here we explain how we keep all patient data safe in the cloud. Think of it as a giant, super-fast digital filing cabinet. Every time something happens, like a patient arriving, the computer writes it down in a file. This cabinet is hidden and locked so that only the hospital computer can read the information.
1. All the data from the app and dashboards is sent to the MongoDB cloud database for safe storage.
2. MongoDB is a high-speed database that allows the system to save thousands of tokens very quickly.
3. Every time a patient joins or a staff member calls someone, a new log is created in the cloud.
4. This data is stored in "Collections" so the server can find it again in just a few milliseconds.
5. Using a cloud database means that the hospital does not need to maintain its own physical data server.
6. The system uses secure SSL encryption when sending data back and forth to keep patient info private.
7. If the server ever goes offline, the cloud data stays safe and can be accessed when the server restarts.
8. The database also stores the history of how long each patient had to wait before being served.
9. Advanced indexing is used so that the system doesn't slow down even with millions of past records.
10. This central storage engine is the brain of the system that keeps everything running smoothly and securely.
Mobile Alert Story
This part tells the story of how your phone tells you it's almost your turn. The main computer monitors the list and sees when you are next. It sends a message through the air directly to your phone. Your phone buzzez to tell you to come back to the waiting room. This way, you don't have to watch the screen the whole time.
1. When a patient's turn is coming soon, the server sends a "Near Ready" alert to their phone.
2. The system calculates when there are only 3 people ahead of that patient in the current queue.
3. A request is sent to the Google Firebase Cloud platform to route the message to the mobile app.
4. The patient's phone vibrates or plays a notification sound to let them know their turn is close.
5. When the clinician finally calls the token, a second critical alert is sent to the patient's phone.
6. This message tells them exactly which door or clinic room they should enter right now.
7. Even if the app is closed, the push notification will appear on the patient's lock screen.
8. This prevents patients from standing in long lines and lets them wait comfortably in the coffee shop.
9. The notification system is linked to the unique token ID so no wrong alerts are ever sent out.
10. Using this cloud alert flow, the hospital creates a premium experience that respects every patient's time.