Preventing Runaway Patients With IoT

The Scenario

Max reads a newspaper while waiting in his doctor's examination room. He's engrossed in an article that takes up all of his attention. Recently, there was a patient diagnosed with an infectious disease who tried to run away from an isolated facility.

That makes him think, "Not only is the hospital going to lose the time and cost of treatment, but more than that, there's a possibility that disease will spread throughout the population."

With that in mind, he comes up with a simple idea of tracking a patient using a cheap NodeMCU board. The basic idea is to keep the patient inside the Wi-Fi coverage area. Once he tries to run out of that area, an associated system will alert security to follow up.

The NodeMCU is a small microcontroller board with built-in Wi-Fi. In this case, we can use it as a part to build a bracelet. As illustrated in the picture below, the device must be plugged in to become a bracelet and to turn it on (but still remain inactive). It will be turned off if the patient tries to take it off.

The basic device structure consists of three LED lights:

1. Red: Indicates that the device is inactive, or active but not reachable by the system (out of coverage area). An alert will be sent to security or other responsible department.
2. Yellow: A warning light that indicates the device is (temporarily) not reachable. Patient must return to the coverage area immediately.
3. Green: A signal that the device is active and inside the coverage area.

Simple functionalities will be planted into this device: a lightweight web server to handle the request from the main system and logic to turn on/off the LED lights. The main system is residing in a REST service, which we'll build by using Mule ESB.

Arduino Sketch

The Arduino Sketch turns on/off the LED lights by validating the counter/timer:

1. Initially, the red LED light is turned on along when the device is turned on. Its status is still inactive. It requires manual intervention from the administrator to activate it.
2. Once the activation request is sent, the green LED light will be turned on. Other LED lights will be turned off. At this state, the device will be actively monitored by the main system.
3. The green LED light will be kept on as long as the patient is in the coverage area. Once he tries to leave, the main system will recognize that fact and turn on the yellow LED light. After a certain attempt or validation, if the patient is still not reachable. The red LED light will be turned on. The main system will notify the responsible department to follow up.

The following is the snippet sketch:

void loop() {
  if (isActive) {
    validateCounter();
  }

  WiFiClient client = server.available();
  if (!client) {
    return;
  }

  Serial.println("New client");
  while (!client.available()) {
    delay(100);
  }

  String request = client.readStringUntil('\r');
  Serial.println(request);
  client.flush();

  String response = "HTTP/1.1 200 OK\r\nContent-Type: text/html\r\nConnection: close\r\n\r\n";
  if (request.indexOf("/get") >= 0) {
    response += isActive ? "1" : "0";
    client.println(response);
    counter = 0;
  } else if (request.indexOf("/post") >= 0) {
    setStatus(true);
    client.println(response);
  } else if (request.indexOf("/delete") >= 0) {
    setStatus(false);
    client.println(response);
  }

  delay(100);
  client.stop();

  Serial.println("Client disconnected");
  Serial.println("");
}

Then, the Mule ESB itself has five main functionalities

1. Activate the Device

By default, the device is inactive (although it is turned on). It must be activated through this system as a centralized control. Although a patient could take the device off and turn it on again, it still needs intervention from the hospital administrator to activate it. Mule ESB provides an API interface (and console) for this purpose.

2. Deactivate the Device

Provide an option to deactivate the device, for example when the treatment is over.

3. Get the Device's Status

Scan or monitor the device status: active vs. inactive.

4. Ping the Device

Mule ESB periodically, in this case every 30 seconds, collects all devices and validates their existence. It sends a ping request to the device through a REST service over the Wi-Fi connection.

5. Validate the Device Status

If a device cannot be reached (or the patient takes the device off), Mule will prepare another evaluation attempt. This approach is taken to consider a false flag. However, if it exceeds the maximum attempt (three attempts) an alert will be sent and the device will be deactivated.

In general, this proposed solution is already tested. For the real implementation, it might need a day or two for development. However, while awaiting the review from a stakeholder, Max keeps refining this idea.