Resilient Engineer: Improve QOL for Your Healthcare Service Team with MS Teams, an Azure Bot, AWS, and SnapLogic — Part 2
Back in February, I posted an article on how to 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. Consider this previous as part 1. Now it’s time for part 2 and this time around we’re going to try to save MINUTES!
At Cooperative Benefits Group (aka CBG), we innovate on the concept that healthcare can be improved for everyone, even more than many in the already crowded PBM industry. We know how to do it; we’ve built one from the ground up in 4 months with amazing partners to form RealRx in 2020. While our focus for innovation is to improve overall member experiences, we also realize incredible opportunities to help our internal teams become more efficient, thereby gaining more time in each interaction to help our members.
Part 2 continues with the theme defined in part 1, but we took it to the next level with time savings, cloud architecture, and functionality. This post will focus on how we were able to partner with our internal Service Team, led by a very talented young leader named Toni Bell, and help them shave minutes off their interactions by building them a “Claim History” chat bot in Teams using MS Teams, Azure, AWS, and SnapLogic.
Bots and our reference architecture
Bots have already ended up being a transformational idea for our teams because they allow users to interact with our web services through text, interactive cards, and task modules right in the unified GUI they’re in all day anyway: Microsoft Teams. They don’t need to remember another set of credentials, and IT doesn’t need to built yet another SSO handshake they need to maintain.
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 S3 Object Lambda functions and access points for tranform-in-transit features, S3 Lifecycle Configuration rules to expire sensitive data in a timely manner, 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 remains 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 with remarkable resiliency and availability configurations
- AWS API Gateway and Lambda provide the secure API and middleware to handle and scale inbound Bot requests like a pro
- Within the AWS Lambda function(s) in the API middleware stack, 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 that is quickly enabling our in-house citizen developers to help build our APIs
- 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 use Amazon Aurora for PostgreSQL for the data warehouse currently and have enjoyed 100% uptime, instant scalability, and almost zero management
- Claim history reports are generated by SnapLogic PostgreSQL Execute snaps and stored in S3 which expire thanks to S3 Lifecycle Configuration rules
- SnapLogic CSV file writer snap events trigger an s3:ObjectCreated:* event in AWS and drives the event trigger in our S3EventCsvToPdf Lambda Function used to convert and store PDFs from the previously generated CSVs
- Claim history reports stored in S3 need to be available in chat responses in simple CSV and PDF formats, so we use S3 Object Lambdas to perform transform-in-transit on the CSV files to PDFs
- 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 and loose coupling of our bot components
- 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 Claim History Bot (NP) or Claim History Bot (P) under the Built for CBG, LLC section. NP and P are our designations for nonprod and prod.
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. We’ve also found the SQL helps get other started on more complex SQL queries used in other research.
TL;DR
So back to the original problem we were trying to solve: shave MINUTES off of our Service Teams’ (call center agents for a healthcare company) member interactions by providing them a lookup service to query member claim histories directly in Microsoft Teams. This clever team has seen several wins by going this route. First, we’ve been able to shave ~30–60 seconds off of each claim history report 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!
