Why We Chose Signal At VitalFlo

Published in

VitalFlo

7 min readFeb 17, 2020

At VitalFlo we work very hard every day to create tools that improve the standard of care for chronic respiratory disease. We are currently focusing on asthma. A crucial component of our system is facilitating communication between care providers and their patients.

Creating a two-way communication system in healthcare

To do this we needed to create a two-way communication system that is:

Simple and intuitive
Usable both in real-time and asynchronously
Capable of file and data sharing (images, pdfs, and other health records)
Configured with the highest privacy and security standards

Users told us the form factor with the least friction would be a text message-based approach. Texting clearly meets our first three criteria. However, standard cell service texting (SMS/MMS ) is not encrypted when sent or received, which violated our privacy and security requirements and disqualified the choice.

Standard email was out for the same reason. You may have seen “secure email” services from your health provider before, these are essentially messages suggesting you log into a webpage (more on that next). However, this version of email is not simple and intuitive or useful if you are trying to have a real-time exchange.

A website with an encrypted login is certainly possible to secure. However, by using a web portal we would be relying on patients accessing a webpage through a mobile phone which is almost always a clunky experience. This works against “simple and intuitive” and is only real-time in a very loose interpretation of that term. This made a webpage a poor user experience choice. Additionally, we discovered the average actual usage rates for web portals in healthcare is very poor (see Fig. 1). Web portals provided an additional challenge in that they cannot provide native smartphone notifications or reminders like a messaging service can. These factors made a webpage a poor user choice.

Figure 1. National Institutes of Health, National Cancer Institute Division Health Information National Trends Survey [12]

While current healthcare providers and other industry players use some of the systems above, we were not satisfied with those options. So we decided to start with first principles and look at what other industries have successfully implemented.

Choosing a chat app for healthcare

After a brief exploration into fields that have genuinely effective customer engagement and communication, we discovered that chat apps were the most effective way to communicate. Chat apps give patients and providers the same experience and benefits of texting but within a secure environment that we chose. There are many messaging services we could have considered, and we looked at a lot of them. At the end of the day we honed in on our final choices by applying the following framework:

Ubiquity/Brand Awareness: Whether it is right or wrong most everyday people trust brands not white papers
Stability: A track record of consistent high-fidelity work by the company putting out the app/protocol
Security: Is the service end-to-end encrypted? What other security measures have been implemented to safeguard data both in transit and at rest?
Country of origin: Beyond basic HIPAA requirements, it was important to us that the company itself, as well as the leadership team, be held accountable to US law
Ability to audit: Many services claim to use the Signal protocol or otherwise implement Double Ratchet algorithm, pre-keys, and a triple Elliptic-curve Diffie–Hellman (3-DH) handshake, but if they would not allow us to audit of their codebase than their claim could not be verified.

This quickly narrowed our search to three top choices:

Data security for our users

It was now time to address those air quotes around secure. End-to-end encryption is the term you will hear the most when it comes to keeping transmitted data secure. There are countless books, blog posts, and excellent videos on how the mechanics of end to end encryption work. The topic has been covered at length so I will link those sources below and keep this very high level.

End-to-end encryption means only two people are able to read the message you send. The “end-to-end” in end-to-end encryption means that for the whole journey from one end (the message point of creation — your phone) to the other end of the service (where you are sending the message — in this case, your doctor), the message is “encrypted” or unreadable to anyone other than you and your intended recipient.

But end-to-end encryption isn’t perfect.

While end-to-end encryption by definition means the only points of access to the message are the endpoints. That doesn’t mean there is no trace of that message in transit. In fact, there can be large amounts of “metadata” gathered and stored on messages as they are passing through the WhatsApp servers. Metadata is just a term for data that is describing some other data. In this case, the content of the message (e.g., “let’s meet at 4pm”) is the data. While the metadata could be as simple as the time the message was sent it could also be as complex as which numbers contacted which over WhatsApp, when, and for how long, as well as the IP addresses and phone identifiers associated with the subpoenaed accounts. Location and contacts data may also be accessible [12].

Signal, on the other hand, has made a concerted effort to reject needless data collection, and continually build new features allowing the service to function with less and less metadata.

What this means in practice is::

If someone were to hack the WhatsApp servers they could access lots and lots of potentially compromising data.
If a sufficiently powerful government or company decided they wanted to force WhatsApp to produce this information they could.

Signal does not have these vulnerabilities because Signal does not have this information.

The vulnerabilities and complexities of the WhatsApp platform are of course much broader than the metadata problem. The metadata problem is only the most well know fault. Regularly there are new reports of questionable infrastructure [13]. Most importantly WhatsApp is not open-sourced so the entire ecosystem is opaque making the security landscape unknowable. Let's face it Facebook purchased WhatsApp for $21.8 billion back in 2014. That is $55 a user.

Faced with a choice between a Russian-based mixed-sourced messenger, a Facebook-owned closed-sourced messenger, and a non-profit run open-sourced messenger, we had a clear winner.

Building and launching the service

Having now resolved the issue of what platform to use we were faced with the task of implementing the platform. The mechanics of which is a very different and far more technical article.

But if you are wondering how it went, here are a few numbers:

Time to prototype — Approximately 2 weeks
Time from prototype to MVP — About 2 more weeks
Time from MVP to First Demo For a Customer — 1 more week (we closed that customer)
Total time from ideation to sale: ~5 weeks.
Costs: Engineering Team time (Job Crowder, our System Architect, and myself) and a smartphone to complete out-of-band handshake ~$100. No other hardware, software, or bureaucratic fees.

Discovering a way to effectively engage patients, protecting their health data, and creating a tool powerful enough to rapidly evolve with our company is an exciting challenge. It involved balancing usability with security, flexibility with fidelity, and… the hardest part of any innovation in healthcare: creating a tool sufficiently advanced to create genuine value while maintaining the trust and confidence of patients and doctors.

Epilogue: Why Didn’t You Just Build Your Own App?

Short answer: it’s a lot more complicated than that.

Long answer: A native app is an attractive choice from a design and user experience perspective, it allows us to control the entire experience. However, the major drawback is that creating a native app takes a lot of money, time, and bureaucracy. Not only would we have a large development cycle, but our deployment would also be gated by Apple and Google’s approval.

Digital health apps are currently heavily scrutinized by both phone manufacturers and governmental agencies [13]. This didn’t scare us away from creating a native app altogether. As you are reading this we are designing, coding, and filing paperwork for the next-generation platform for respiratory health. Regulation even when it’s opaque (as it often is) is part of the process in healthcare but for our first product on the market, there was no reason to assume the risk involved with a native app.