Resilient Engineer: Improve QOL for Your Healthcare Service Team with MS Teams, an Azure Bot, AWS, and SnapLogic
My career and mindset are both fortunate to have been shaped by so many clever, adaptable, out-of-the-box thinkers. All of the teams I’ve worked with have helped shape how I approach modern problem solving. Over the past month, I’ve been reminded that my current team and colleagues are right up there at the top. Recently, we were presented with a problem to solve. The gist of it was this: shave seconds off of our Service Teams’ (call center agents for a healthcare company) member interactions by providing them a lookup service to query drug NDCs directly in Microsoft Teams.
As we started solutioning, we realized there may be a few wins here if we solved the problem correctly. There would definitely be a win for the Service Team if we could reduce their interactions by ~15–30 seconds. There may even be a win if we could figure out some resilient, repeatable architecture for the technology team, maybe some time-to-market metric we could reduce like overall API development time. At the end of the day, we ended up finding three wins, one of which isn’t even mentioned yet. Read on to find out perhaps the best win of all at the TL;DR section.
In the title of this post, I mention a Bot. So why a bot? And why Microsoft Teams? The bot wasn’t actually in the original idea; we didn’t start solving the problem with technology like so many other teams do. We had to understand the real problem before we could go to technology. MS Teams was in the original idea, however, and that approach intrigued me.
In the past, when end users needed a new tool it meant building a new screen and API endpoint in an existing web app/API, or building a brand new one. Our end users didn’t want to use yet another tool or another screen they had to log in to, even if it was SSO, but instead wanted to interact directly with this new NDC query service directly in the UI they’re in all day: Microsoft Teams. The idea of extending custom UIs on top of MS Teams was clever, albeit new to our team. Researching how to do that led us down the path of using a Bot and some other remarkable technologies.
Bots and our reference architecture
Bots ended up being a revolutionary idea for us because they allow users to interact with our web services through text, interactive cards, and task modules. We’d used them before for DevOps/NoOps and technical tasks, but not for end users outside of IT. In addition to the basics, messaging extensions allow users to interact with our web services through buttons and forms in the Microsoft Teams client. They can search, or initiate actions, in an external system from the compose message area, the command box, or directly from a message. MS Teams ends up being the unified frontend and UI that all our teams can use, rather than some homegrown or other low-code/no-code custom UI.
In addition to MS Teams and an Azure Bot, some other technologies landed organically. AWS because we’re all in there (even though we’re multi-cloud for resiliency), SnapLogic because of it’s simplicity and broad integration platform, Datadog because of it’s superiority in chomping and digesting data to give meaningful insights, and some others. Our reference architecture looks something like what is shown below.
There are several callouts to be aware of in this above architecture:
- MS Teams becomes the unified UI through which team members interact with backend services to get data from our data warehouse, data lake, or other data stores
- Azure Bot Services powers the Bot and provides simple integrations with MS Teams Apps
- AWS API Gateway and Lambda provide the secure API and middleware to handle the Bot requests
- Within the AWS Lambda function(s), we do not store any business logic; it’s purely to handle middleware and call SnapLogic APIs (triggered tasks in SnapLogic)
- Business logic for querying the actual data warehouse, data lake, or other datastore is handled outside of the Lambda middleware in a tool called SnapLogic
- Using SnapLogic normal and ultra pipelines for CRUD and other business logic simplifies and drastically reduces time-to-market development timelines using low-code/no-code platforms to free up developers’ time
- We securely store service configs and parameters in AWS Systems Manager Parameter Store (just SSM from here on) and we push all service logs to AWS CloudWatch for centralized logging
- Amazon SQS and SNS services are used for “better practice” message broadcasting
- We ship all logs to Datadog, in addition to CloudWatch, for simple trending analysis and advanced insights
How do users enable the Bot functionality?
To enable the Bot in MS Teams, users need to follow a few simple steps to “opt-in” to use it. This is the quickstart guide we provide our end users for this particular Bot.
1. Open up the MS Teams desktop client, and click the … on the left navigation bar of the desktop client.
2. Click the More apps > link on the slide out menu.
3. Find the Teams app and associated bot named Drug List Bot (NP) under the Built for CBG, LLC section.
4. Click the Teams app and then click Install to follow the wizard as the app and bot install to your MS Teams client.
5. Once installed, then right-click the app that is showing up on the left navigation bar of the desktop client.
6. Click Pin on the app to lock it to the left navigation bar.
7. Click in the Chat tab of the app and bot to start using the bot.
8. Each time you click in the Type your questions here text box, you will be prompted with what commands are available to you. You can see them all by clicking on the What can I do? option that appears when you click in that text box.
10. After each command you run, the results will always include the SQL statement that was used to get the data being returned. You can use this or pass it along to help debugging or troubleshooting as issues are encountered.
TL;DR
So back to the original problem we were trying to solve: shave seconds off of our Service Teams’ (call center agents for a healthcare company) member interactions by providing them a lookup service to query drug NDCs directly in Microsoft Teams. This clever team has seen several wins by going this route. First, we’ve been able to shave ~15–30 seconds off of each NDC lookup for our Service Team which translates to improved call metrics. Second, our technology team has been able to speed up the development and release of low-latency APIs by days through use of low-code/no-code pipelines for API CRUD and business logic functionality. Lastly, we had a ton of fun with this bot architecture and it’s generated exponential excitement about our internal digital transformation journey that’s being seen across the entire company. It’s a win, win, and a big WIN in my book!
