Evolve and Alexa on FHIR
I mentioned in a previous post about my recent experiences with Alexa. One of the great things about Alexa and the Echo is the open developer ecosystem. I was interested to find out what the developer experience was like when creating a skill so I decided take advantage of the API’s provided within the Evolve Integrated Care platform to build a simple skill that would allow a practitioner to find out what their schedule was for a particular day.
If you’re not interested in the detail and just want to see what the skill looks like, you can watch the video below.
For anyone who wants a bit more detail read on. I don’t want this to be an Alexa tutorial as there are already many good tutorials online but there is some terminology worth summarising before I go on.

- Each Alexa Skill is comprised of an “Invocation” name which is essentially the name of your Skill or App. My Skill and Invocation name is Evolve.
- A set of “Intents”, which are the actions that fulfill the users spoken request. You map one or many “Utterances” to each intent. Utterances are phrases that you expect people to say when they use your skill. Some Utterances I defined include “Get my schedule for tomorrow”, “what have I on tomorrow”, “whats my schedule like for” etc.
- You can use a concept of “Slots” to pass arguments to your intents. I could use slots to define things like today, tomorrow or a specific date.
The high level architecture of my skill is summarised in the diagram below.

- Alexa Skills Kit — this is where I define the key configuration around what I want Alexa to do when a user says certain things. Key to this are the things I mentioned above.
- Lambda — Lambda is AWS’s event-driven serverless platform allowing you to run code without provisioning or managing servers. I used Lambda to link my skill to an AWS Lambda function that I wrote in Node.js. This Lambda function provides the handlers for the different intents and from here I call onto the Evolve API’s to perform the action related to a particular intent. This was the first time I’d properly used Lambda and I was impressed by how easy it was to get up and running however more thought is needed to access if and when we could use Lambda for production workloads.
- Evolve — When a new session is started I call out to the Evolve Auth service to authenticate the user. The token I get back from this request is then used to authenticate subsequent Api requests.
- FHIR — FHIR is the latest standard from HL7, leverging the best elements of previous standards such as v2, v3 and CDA, but designed for modern mobile applications that demand analytics. In Evolve we are big users of FHIR and our Integrated Care Platform leverages it signifcantly for its core data model and integration platform. For my skills I call onto the Evolve FHIR API from my Lambda function and in this example I’m performing a search against the Appointment resource to fetch a list of appointments for the logged on practitioner for the appropriate date. An interesting use case for FHIR and a great example of how FHIR makes it simple to get access to information like this from any device.
In total it took me a flight to Philadelphia and a few nights in the hotel to build this skill which for a first skill on a new platform is not bad going and is a statement of how well integrated each of the Amazon services are, how easy they are are to use and how well documented they are. Ultimately this all bodes well for a vibrant developer ecosystem around Alexa in the future.
All the code is here on GitHub and for the avoidance of doubt this is a personal project, not an official Evolve product.
