DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Big Data
  4. Preventing Runaway Patients With IoT

Preventing Runaway Patients With IoT

Patients fleeing from hospitals can pose a danger not only to themselves, but others around them. See how the Internet of Things can help.

Sulthony H user avatar by
Sulthony H
·
Nov. 29, 16 · Tutorial
Like (5)
Save
Tweet
Share
3.08K Views

Join the DZone community and get the full member experience.

Join For Free

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.

Image title

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.

Image title

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.

Image title

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.

Image title

2. Deactivate the Device

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

Image title

3. Get the Device's Status

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

Image title

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.

Image title

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.

Image title

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.

Light (web browser) LEd IoT

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Asynchronous HTTP Requests With RxJava
  • The Importance of Delegation in Management Teams
  • Why You Should Automate Code Reviews
  • Writing a Modern HTTP(S) Tunnel in Rust

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: