In a world of remote work, remote medical visits, and remote everything, the concept of completely unified communications is growing quickly. Omnichannel conversations with your bank or your doctor have moved beyond the conceptual phase and can now be implemented in a variety of ways, including via the Vonage Communications APIs.
Our team at WebRTC.ventures has been using the Vonage Communications APIs for a long time. We were one of the first development partners for the original Tokbox video tools that are now part of the Vonage Video API. Since 2015, we’ve been building web and mobile WebRTC applications which not only use Vonage Video, but also Messaging and Voice capabilities.
Until now, each of these communication tools have been mostly siloed within an application. Tying together a text message with a video call, for example, was a bit disconnected.
The Vonage Conversation API can connect these messages together in a way that was not possible before. In this blog post, I’ll explore what this could mean for a telehealth provider, though the concepts apply to many use cases. I’ll use examples from our telehealth starter kit, SimplyDoc, as it was built on top of the Vonage APIs. Our healthcare clients can license SimplyDoc as a base upon which to build their custom telehealth solution and bring it to market faster.
The Old Way of Unifying Communications
We’ve traditionally followed a useful but simplistic pattern when combining Vonage Communications APIs into a telehealth solution. We most commonly use three different APIs for three distinct purposes:
1. SMS – We use the Vonage SMS API to send reminders to patients and medical professionals when a visit is about to occur, or as notifications to medical professionals that a patient is in the waiting room. These messages are standalone and typically one-way, i.e., we are pushing information to the recipient but not really engaging with them in a conversation.
2. Voice – Our preferred mode for a telehealth visit is video, but sometimes a patient is unable to connect by video. Most likely it’s because they don’t have a strong internet connection, so they would rather have the telehealth visit by the phone. Using the Vonage Voice API, our SimplyDoc application can dial out to the patient and bring them into the telehealth visit via a traditional phone call. The patient is then on the telephone call while the doctor is still in the SimplyDoc web application, allowing the doctor to stay in one tool regardless of the situation.
3. Video – The most common use of the Vonage Communications APIs in telehealth applications is to connect the patient with the medical provider by video. The Vonage Video API is a wonderful way to do this. It allows for a secure video connection across different browsers and mobile devices, and our clients’ applications are able to leverage the global network of media servers that powers Vonage Video.
What’s wrong with this “old way”? There’s nothing necessarily bad about it and it works well for our current clients. Telehealth workflows like this powered the early phase of this major global transition we are in due to the coronavirus pandemic. But there is something missing from the equation.
Omnichannel Communications
Terms like contextual communications and omnichannel communications have been around for a while. They have even been the subject of TADHack projects our team has done in the past. The basic idea is that you should be able to have a conversation with someone in one communication channel (let’s say, a text chat in a tool like Facebook) and then seamlessly continue the conversation in another communication channel (such as SMS or text chat within your application).
These sorts of omnichannel applications are very cool in theory and make fun weekend hacks. However, most of us have not encountered them in the real world yet. If you’ve started a conversation with a business in one communication channel (ie, WhatsApp), why would you switch to another channel (let’s say SMS) just to continue the conversation?
There are, in fact, many practical reasons why you might need to switch channels in the conversation leading up to, during, and after a telehealth visit. In this blog post I’m going to describe at a high level how that could be implemented in a telehealth visit like SimplyDoc provides. I’ll describe it with the Vonage Conversation API as the backbone behind these interactions. In future blog posts, we’ll show examples of how it could be implemented as Vonage continues to roll out more functionality to this new API.
An Omnichannel Telehealth Visit
A truly omnichannel telehealth visit would go beyond offering multiple modes of communication. It would tie them together into a single cohesive experience.
Let’s look at an example before the time of the appointment. In this workflow, our system contacts the patient to remind them of their visit and gathers data from them over a combination of SMS and Voice, depending on the patient’s preference.
Let’s walk through an example of this pre-visit workflow in more detail.
First, let’s assume the telehealth appointment has already been set up in the system and the day of the telehealth visit has arrived. Our patient will follow a similar process to an in person visit, except all information will be communicated over various communication channels based on what may be most useful to the patient at that moment.
When the patient wakes up in the morning, a text message has been sent to their phone reminding them of the doctor visit today.
In the first part of this messaging, the patient responded in a timely fashion to the text message. If they don’t respond to the text message by a certain time, we could also give them a phone call and have the Vonage Voice API ask them those questions verbally. The responses can be collected via Voice Recognition and stored in our database.
Our patient is tired of typing, or perhaps they need to start walking to work and now they prefer a phone call. The system dials them to complete the conversation and an automated agent asks them some questions:
The automated assistant confirms the address and then their insurance provider, then connects them to a live person for the last step.
The patient is put on hold momentarily while the system connects them to a member of the medical office staff to ask them about their medications. As the nurse connects from their tablet or computer, they see the patient’s information, the purpose of the visit, and the questions answered so far with the automated agent.
We could have had the patient fill out an online form, or maybe view some summary information and confirm it. But for the sake of discussion, we’ll assume that this medical practice prefers to handle prescription medication conversations by phone with a live person since the terminology is complex.
As the nurse discusses current medications with the patient, the call is being transcribed. The call concludes and the patient hangs up.
After the phone call is complete, the patient receives this text message:
The patient now goes about their day. Shortly before their visit starts, the system contacts them to begin the telehealth visit. The following workflow shows how this portion of the encounter may work:
Again, let’s walk through this in a bit more detail. First, the patient receives a text message a few minutes before the scheduled time for their appointment. Since the patient chose to have a Video visit instead of a Voice visit by phone, we will continue to describe the Video visit flow.
Either way, once the patient connects, they are put into a virtual waiting room. The doctor receives a text message to their phone as well as a desktop notification if they are on their tablet or computer conducting other visits.
Dr. Ramirez chose to use a standard reply and then typed an additional message. Both are sent to the patient on whatever device they are connected to. These messages are shown in the regular text chat of the virtual visit window. Any replies the patient types are also sent to the doctor in the application, as well as to their phone if that’s how they messaged the patient.
As the virtual visit begins, the doctor and patient now have a typical video telehealth visit experience. They can see each other and talk in real-time. The text chat window contains any conversation that was exchanged prior to the visit whether or not it came in via SMS messaging. The doctor can also see a transcription of the conversation with the nurse earlier in the day about their medication.
We’ll stop our example here for now. But there’s still much more we can do in this scenario. If the video quality degrades due to bad connectivity, the system could automatically dial the patient back into the conversation. If the doctor needs to have the patient e-sign a document, this can be done over SMS or by sending the patient a link to a webpage that lets them draw their signature. Everything is adding back into the conversation flow.
After the visit, if the doctor indicates a follow up visit is needed, this could be handled by the automated agent flow or by the patient arranging a callback from the office staff at a convenient time. Allowing the patient to choose which communication channel they prefer makes it as easy for everyone involved.
Vonage Conversation API
The above workflow is all possible with current technology. However, it requires multiple subscriptions to different services and a lot of code in our telehealth app to tie it all together.
The beauty of the Conversation API that Vonage has built is that we can simplify this process and create a workflow that handles much of the interaction for us.
The Conversation Studio is available via your Vonage/Nexmo account. It provides a canvas that can connect different Vonage endpoints together in a single workflow. We will explore this more in the next blog post, but for now I’ll just describe some of the capabilities it can give us.
We can add in recordings that we upload or supply text for a bot to read. Listen nodes allow us to gather input from the user and built-in Automatic Speech Recognition (ASR) allows the Conversation API to store input from the user as parameters which can feed into subsequent Entities in the workflow.
For specific use cases, there are certain words that a patient might be most likely to use. The Studio allows us to supply Context Keywords which are prioritized by the ASR to make the conversation as accurate as possible to our use case.
A canvas currently always starts with a phone call. From there, many different actions can be set up in the canvas, based on input from users. Sending an SMS, connecting to a nurse, and sending an email are all possible.
Much of what I’ve described so far can be configured with little to no code on the canvas in the Studio tool. Vonage has done the hardest work of connecting all these items together for us and provided an easy way to modify and improve the workflow over time.
When you need to connect to your own custom application in order to store data, trigger actions, or do things like start the video call, all that can be done by adding in custom WebHooks which make it easy to connect the Studio canvas to your application via secure API calls.
You can also configure Context Switches, if we want to allow our patient to jump out of the prescribed workflow at any point to call the medical office staff directly. They simply say a phrase like “speak to an agent” or “operator”.
The Vonage Conversation API and the Studio canvas tool give us a tremendous amount of flexibility in how we change a traditional phone call into a full omnichannel experience, utilizing capabilities across the Vonage APIs. This comprehensive set of APIs with enterprise-ready functionality, security, and reliability, is something that sets Vonage apart in the CPaaS marketplace.
You don’t have to build it all on your own. There are templates for typical scenarios built into Studio that you can use as a starting point or as inspiration for your custom canvas. If you don’t find a feature you want, your development team can build and integrate it into that workflow via WebHooks, giving you a powerful combination of prebuilt functionality and the flexibility of custom code.
Combining Vonage Conversation with Telehealth
At the time of this writing, the Vonage Conversation API is in beta and is based primarily around Voice calls as a starting point. It also supports Whatsapp and HTTP agents so that chatbots can be implemented. We can still implement the complete workflow above in our own application and then apply the Conversation API to Voice calls with our patients. Over time, as Vonage releases more features into the Studio beta, we’ll be able to build out more and more of this workflow using their canvas.
Our team is excited to further explore the capabilities of the Vonage Conversation API. In future blog posts in this series, we’ll show you implementation examples of specific parts of the workflows described above.
In the meantime, if you are considering an omnichannel enterprise communications application for healthcare or any industry, let our team of experts at WebRTC.ventures build it for you! Contact us for more information and a quote.
