The Problem
One of the biggest complaints from medical professionals is lack of patient compliance with recommended or prescribed treatments for diseases such as diabetes and congestive heart failure. Along with the rising medical costs associated with treating these diseases, home care givers feel helpless without full access to the doctors and care guide. With insurance companies refusing to pay hospitals for re-admissions, especially due to preventable relapses, it is clear the current way of managing chronic conditions is archaic. Looking at all angles, we searched for a solution that would encourage patients to be more compliant and healthy while allowing care providers and managers to be able to monitor the patient better, keeping doctors more tuned in to what is going on with their patients. The goals are earlier intervention in negative trends and reducing the number of unreimbursed hospital re-admissions, all without adding more stress on the patient. Because nothing is more natural than spoken language, we thought that providing patients with an Amazon Echo and a creative, custom Alexa Skill could help them take their medications properly and keep their care team in the loop, too.
Alexa Skills are voice experiences that add to the capabilities of any Alexa-enabled device. They are written in the Amazon Developer Console, and the code that Alexa will trigger to run is stored on Amazon Web Services (AWS) as a Lambda function, see below:
Our Approach with Alexa
You can develop and host your own cloud-based web service, but it is just a lot easier to use Amazon’s AWS Lambda; which is free for the first million calls per month. The Amazon AWS Command Line Interface allows use of the terminal to quickly publish the Lambda functions. Anyone developing Alexa Skills should use the Alexa Skills Kit SDK for Node.js (alexa-sdk). Amazon’s security also requires a custom IAM Role (an AWS identity with permission policies that determine what the identity can and cannot do in AWS) to allow the Lambda function and DynamoDB to communicate with each other.
One Alexa Skill we developed uses the Iodine.com API to allow users to ask Alexa about medications by name and to see if there are any side effects that concern them. In the background, Amazon’s DynamoDB collects and stores the user session, user ID, timestamp, and medication name requested. This information then gets pushed to the HealtheMe© dashboard for display.
HealtheMe© is the medical application on our LEAF (Light Enterprise Application Framework) Platform. LEAF is a super versatile platform that we can modify to meet just about any need for our clients; healthcare-related or otherwise. For the patient, using Alexa to get the information into the dashboard in real time is helpful, but for the doctors and care managers having this kind of information displayed in real time is an invaluable tool in managing patient health. Currently I am building a survey type Alexa Skill for collecting diabetes patient information, and one for Congestive Heart Failure patients will follow shortly.
Inspired by the Amazon Echo (Alexa) platform and its potential in Healthcare
- Voice communication is natural for people
- The new UI is “no UI” i.e. VOICE
- Echo is a customizable, programmable platform
KRM has built several Amazon Echo “skills” as proof-of-concepts
The patient survey skill allows for the Amazon Echo platform to gather any information from the patient using speech to text and load those discreet data points back into a DynamoDB which is then accessed to the HealtheMe Care Management Platform. But the data could be interfaced with any other platform if desired.
Lessons Learned
When I started my Alexa Development process, I hoped that it would be a relatively simple process. I assumed that Amazon, a large company dominating the tech market, wanted people to develop Alexa applications and would provide clear-cut instructions on how to proceed. However, I quickly became frustrated and overwhelmed with the outdated or non-functioning examples provided by Amazon. Their documentation has gotten better, but it is still poor. You have to hunt high and low for answers when questions arise. The good news is that the Alexa Developer field is growing rapidly, so there are more and more developers to answer questions on a number of different forums. Amazon does provide their own developer forum, which is usually the first place to start researching a question. The second best place is on the Alexa Github page, under issues, where the documentation layout is better than on Amazon’s website. Neither is transparent, but you can piece the answers together using them both. I looked to many developers’ code for Alexa Skills on Github until I could finally start to see how they worked with each other. Other helpful tips include:
- I highly recommend investing in ACloudGuru for a fantastic training tutorial.
- When giving your skill an invocation name, make sure you use a phonetic spelling. For instance, our clever, techie application name is HealtheMe. Alexa doesn’t know how to pronounce HealtheMe, so I had to think like a computer and give it a phonetic spelling that would be easy for Alexa to pronounce and understand. In this case, I chose Healthy me.
- The node.js request-promise module ended up being the perfect solution to the trouble I had accessing the Iodine API. It is the clearest way to make http requests I have come across.
- Since I was building a healthcare skill, I really struggled to find existing market APIs that were complete. Iodine is pretty good, but not perfect: it sometimes omits side effects without any real pattern. I had to use the npm lodash library to check each medication first to see if they were null before assigning them to a variable to avoid an error since a null value can’t be read.
- Since Amazon is always updating things, it can become frustrating that your skill works one minute and the next it doesn’t. Amazon is adding better features, but they are slow to tell you what is going on. Patience is key; I find the answers usually show up under the Alexa Github issues within 24 hours. One example is that I spent a day testing my Alexa skill via the developer portal instead of through the actual Echo. It failed all day. I thought I had broken my code, but couldn’t figure out why. After a day, a coworker or two spent time trying to help me only to find out it was an issue with Amazon’s Developer Portal and not the actual service. If I had just tested it via the physical Echo, I could have saved all of us a giant headache.