Salesforce Rounds

High Level Architecture & Naming Convention

Inspiration

Hospital personnel are doing daily rounds on their patients. Many of those are infectious, requiring time to scrub up and don PPE, but many of those patients are also unconscious, meaning the worker doesn't have much to do aside from marking off no change and moving on. Our goal is trying to minimize waste by setting a first pass to identify unconscious patients through a remote monitoring system with no infrastructure, and using disposable android devices as the video units.

What it does

A small disposable android device is placed in the patient's room with the patient. It's aimed for the camera to see the patient, and an app is installed on it that will trigger a video call via WhatsApp when it receives a signal. A hospital worker then in a remote location (either in hospital or remote workers) can press a button which will send a signal to the device. The disposable android device will then call that worker directly and initiate a video call with zero interaction from the patient (who may be unconscious). The worker can determine if an in-person round is unnecessary and hopefully a significant percentage of gear and time will be saved.

How I built it

What we built was a combination of Heroku Redis, Node.js services, and a websocket communication framework called Socket.io. It’s a simple fan-out pattern to do distributed messaging to a number of end clients, those clients being the disposable android devices. Upon receipt of a WAKEUP signal, the device initiates an outbound WhatsApp call to the worker, which allows for a zero-interaction scenario. When the worker terminates the call, the android service goes back to listening for another request.

The high-level architecture diagram is attached in the image gallery, this paragraph will use the naming convention in it to explain in more depth.

STRANDs are individual android devices. Each will have an ID put into it by a manual user identifying the device’s location and function. These STRANDs will, at startup, attempt to connect to a KNOT server. The KNOT is a websocket (socket.io (http://socket.io/)) server which will keep track of which STRANDs are connected to it (as you will scale horizontally to many KNOTs) and communicates any WAKEUP requests it receives down to the appropriate STRAND connected to it. The KNOT subscribes to a CENTRAL Redis channel for WAKEUP requests, and when STRANDs connect to them, the KNOT will publish their status (connected, disconnected, etc) to Redis as well. LUDEN keeps track of all the STRANDs through Redis, and identifies which have been created, and which are active/disconnected in real-time. Finally, PORTER is an API endpoint for Salesforce to call when you want to WAKEUP a STRAND - it checks the database to validate the requested STRAND is alive, and if so, publishes the WAKEUP call to Redis.

Challenges I ran into

The biggest was likely figuring out how to initiate a call from a device with zero interaction from a user. It's like something out of a spy movie - and my colleague on the project, Arup, tested a few iterations before landing on a WhatsApp outbound call.

Beyond that, planning for as resilient a structure as possible. Devices need to reconnect to a distributed set of socket servers, and you need to keep checking on them to know if they've been lost, so when someone submits a request, they immediately know if that phone is going to call them back or not.

Accomplishments that I'm proud of

This should be a very scalable pattern, and is mainly built with nothing proprietary. We were able to build the messaging structure on Heroku mainly due to sheer speed to delivery. It took about 4 hours for the initial tests, and another day or so for a prototype. That said, this pattern of a KV store with pub-sub fanning out to a series of socket servers is a known one. Anyone could stand this up with anything they had handy.

What I learned

Apparently all that time trying to build a chat app comes in handy sometimes.

What's next for Salesforce Rounds

Implementation-wise, it could use some serious scale testing, requirements gathering, and security added into the mix. Team-wise, figuring out how else something like this could help hospitals save folk.