Applying IoT: Automating Hospital Check-In

DZone 's Guide to

Applying IoT: Automating Hospital Check-In

See the Internet of Things in action with a proposed method of cutting down lines at the doctor's office by automating the check-in process.

· IoT Zone ·
Free Resource

Patient dissatisfaction is a huge issue for hospital services, and plenty of factors can contribute to it. Let's say our hero, Max, has to wait in a long line to sign in and register at the hospital. He is upset because he thinks he needs immediate treatment.

Of course, every patient wants immediate health care. Unfortunately, they spend most of their time in long waits during registration. Indeed, there is a machine/dispenser that provides the registration ticket. However, patients still have to wait.

There's also the possibility that a patient is waiting for other patients to go ahead of them, even if they're going to different doctors. For example, maybe 10 people in front of Max will go to a general practitioner, whereas Max wants to go to a cardiologist. He still has to wait in the long line, even though he is the only patient for that doctor.

Therefore, while stuck in line, Max thinks about how to solve the problem. He wants to cut the queue by automating the registration process. The new procedure he cooks up is still similar to the existing one. Here's how he does it.

The Basic Registration Procedure

Just like the current procedure, once a patient comes to the hospital, he/she has to go to the registration machine.

Current Procedure

Proposed Procedure

Patient selects the preferred queue by pressing a certain button, for example:

  • General Patient
  • Insurance
  • Employee

Patient puts his/her id card into the card reader.

Gets a printed queue number

Choose the preferred examination, by pressing a button for a specific examination:

  • General Practitioner
  • Cardiologist
  • Etc.

Waits in a long queue

Goes to the examination room

Goes to the registration counter

Goes to the examination room

The New Proposed Procedure

The difference is, the patient does not need to go to the registration counter anymore. He just needs to go to the examination room. As mentioned in the story case above, the patient can directly go to the cardiologist without waiting for the other 10 patients who came earlier.

Image title

To enable the proposed solution, we have to prepare three things:

1. Arduino or NodeMCU Board for User Input

To support the proof of concept, Max used a NodeMCU board with built-in Wi-Fi modules. Then, he applied three different buttons with three different LED lights as the input. Each button represents a request for a specific doctor:

  • General practice
  • General surgery
  • Emergency (a registration for unknown patient)

Before the user/patient is able to request a registration, he must put in his ID card. In this case, it's an RFID card. Another Arduino/NodeMCU board will handle this event for reading the ID (MR Number). Once a button is pressed, NodeMCU will create an HTTP request through its built-in Wi-Fi. Then Mule ESB will handle this request.

Image title

The Arduino Sketch simply creates an HTTP request once a button is pressed:

void loop() {
  readButton1 = digitalRead(pinButton1);
  if (readButton1 == HIGH) {
    Serial.print("Button 1: ");


  readButton2 = digitalRead(pinButton2);
  if (readButton2 == HIGH) {
    Serial.print("Button 2: ");


  readButton3 = digitalRead(pinButton3);
  if (readButton3 == HIGH) {
    Serial.print("Button 3: ");



2. Mule ESB as the Middleware

Max created a simple REST server in Mule ESB, utilizing RAML. This server is responsible for evaluating, transforming, or dispatching the request to the Hospital Information System (HIS). After the request is dispatched to HIS, it will wait for acknowledgment. 

When HIS sends an acknowledgment, Mule ESB will dispatch that response through email and/or SMS to inform the patient.

Image title

The RAML code also route the HTTP request to HIS' API:

#%RAML 0.8
title: Registration API
            example: |
              {"status": "success", "serviceCode": "SV01"}

3. An HIS API to Create the Registration

To enable this scenario, a new interop point must be created in an HIS app for the registration. It will listen to the request and create the registration accordingly. Whatever the result, successfully created or failed (fully booked or no schedule for the doctor) it will notify the Mule ESB as a final response. As mentioned at step 2, Mule ESB will handle this response and dispatch the information to the patient through the ack endpoint.

In general, this proposed solution is applicable for Max's company. For a quick test, he created a mock-up service. However, for the real implementation, it might about three days for development.

automation, iot, iot development, mulesoft

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}