Over a million developers have joined DZone.

Improving Alerts With Reverse Ajax (Part 1)

DZone's Guide to

Improving Alerts With Reverse Ajax (Part 1)

Using an example of a hospital, follow along one hypothetical dev's journey to make a low-impact scheduling and alert system for users to keep an eye on.

· IoT Zone ·
Free Resource

The Story Continues...

Finally, Max has convinced his boss to apply IoT by automating checking in at the hospital. This concept can be implemented smoothly. All associated sides (the existing system, the new API, the patients, and all hospital staff) easily adopt the new approach.

As part of his first report, Max wants to show the success by providing actual data. He provides a short questionnaire regarding this new service. It would be impressive if he can prove that everyone is happy with the system.

Unfortunately, the patient satisfaction score is less than the expected target. Indeed, it has increased compared to the previous survey (before the new implementation). That's pretty depressing for Max. He can't believe it! He then rereads the questionnaire results. He focuses on the comments in particular one more time, slowly and carefully.

Then he finds a problem. One specific comment makes him stare out his cubicle window: “It doesn’t matter how long the queue is. I just want to know when it's my turn.

He then starts thinking. Basically, the current system already provides a specific schedule during the registration. Once registered, a patient will be informed of the queue number and the examination time, e.g.: at 12:30. Still, this schedule can be totally changed when there is an unpredicted event. For instance, a doctor might have to handle an emergency patient, or some patients' exams might take longer than expected.

The Proposed Solution

After a short assessment, Max then comes to his boss to propose another solution. He will provide a new API to serve user requests regarding the patient examination schedule. The new API will return some information for each examination service, such as the current queue number, average examination time, and a prediction of the wait until the next turn.

With this new API, the hospital can provide a big screen monitor to send the information to the patients so they can be better prepared. In addition to that, patients are also allowed to request the information through their mobile devices from anywhere. That means the long line doesn’t matter anymore.

Image title

Technically, the new API is a REST service, which will return the information in a JSON message on request — for example, it could return the entire queue number status, or it could limit it to the queue number of a specific examination service. This JSON message itself contains the following information:

  • serviceCode: the examination service ID.
  • serviceName: the examination service.
  • serviceStart: the time when the current examination is started.
  • currentNo: the recent queue number which is examined.
  • timeAvg: the time average of an examination. This value will be kept updated based on previous examination duration. It might be increased or decreased. However, this value can be used to predict the next examination period.
    "serviceCode": "SV01",
    "serviceName": "General Practitioner",
    "serviceStart": "13:10",
    "currentNo": 5,
    "timeAvg": 20
    "serviceCode": "SV02",
    "serviceName": "General Surgery",
    "serviceStart": "10:00",
    "currentNo": 1,
    "timeAvg": 30

In general, a monitor can be put on each doctor’s waiting room. This monitor will show the specific information for the associated examination service. Optionally, a centralized monitor can be put in a strategic place, which, alternatively, displays the queue information of all examination services. The information will be displayed over a certain time period. As shown in the picture number 1, this is only one-way communication.

Image title

Hopefully, with this new solution, patients can better enjoy the wait — because they can access that information through their mobile devices. Patients do not need to stay in the waiting room while waiting, they can access it from anywhere. For instance, they might want to pass the time in a café near the hospital, a library, a garden, or any other cozy places.

As shown in the picture number 2 below, patients can request information for a certain examination service. They can also input their own queue number as a request parameter to get their prediction. For example, say a patient has a queue number of 10.

  • The current queue number is 5
  • The time average is 20 minutes
  • So, the patient's turn for the examination is in the next 100 minutes, at 14:50.

Image title

The Challenge

In short, after his long explanation for the new proposal, his boss denies this solution, especially considering the fact that the current system is struggling with several performance issues. Therefore, additional server load can't be allowed.

Although this new API will not consume much memory due to its simple data processing, it might still hurt performance. There are at least two possible events that might unnecessarily add to the server load:

1. Periodic Requests

This request comes from the client in each doctor’s waiting room. A frequent call will be executed for updating the latest examination queue status. Doing that more often will reduce the possibility that patient misses the information.

But that means more frequent calls. More frequent calls mean more server load, whereas that call might be unneeded. Let’s say the call will be executed every 1-5 minutes. If the average examination time is 20 minutes, there will be at least three unnecessary calls.

You might extend that frequency to something closer to the average wait, but then you run the risk of patients probably missing their turn — say, if the previous examination was only conducted in 10 minutes. From a customer satisfaction perspective, the first choice makes the most sense, but that leaves an increased load on the server.

2. Unpredicted Request

This is the hardest part of this challenge. Patient requests are unpredictable. They might send the request every minute — or even worse, every second in the hopes that their turn is close. This obviously hurts the server’s performance.

Even if the system limits user requests, it will not solve the issue. Remember, the main focus is customer satisfaction. Patients want the exact schedule for their examination at all times.

The Conclusion

Max has to propose a refined solution, which copes with that issue. His boss agrees with the idea of providing the examination queue information as long as he can convince him there is no significant server load. After all, the current system must allocate most of its resources for examination services.

Max returns to his cubicle, turns on his radio, sets the frequency to his favorite broadcaster, and hopes he can listen to some enjoyable music. He really needs some deep relaxation to find the best solution for this idea.

(To be continued in part two.)

iot ,api ,user requests ,reverse ajax

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}