When operating in the Healthcare space, we work with a massive amount of structured and unstructured data, but almost everything comes from the caregiver side. What if we create a solution, where patients provide their symptom information, directly to the caregiver. This would enable more insights in what symptoms could lead to certain type of diseases.
Another title for this post, could have been: Create a patient self service symptom form, automated in Teams via Power Automate and the Microsoft Bot Framework, that allows integration with your EMR via FHIR. But this seems somewhat to declarative, nevertheless, this is what I am going to explain in this post.
When patients visit their general practitioner or specialist, they experience different symptoms that are often not registered in the Electronic Medical Record. Capturing this information could help future research, or it would allow the caregiver to triage in a more efficient way.
For that reason, my good friend and colleague Mathias Ekman and myself have put our heads together and created a proof of concept that could mitigate this problem via current available technologies.
In this post I am going to cover how we architected the solution, what technologies we used and how they interact with each other.
In the upcoming weeks I will focus on the different steps of the process and explain how this was done in a more technical way.
Below you can find an overview of the different elements that we are going to discuss
For this project I started with tools from the PowerPlatform.
The PowerPlatform consists out of different elements, such as PowerApps, Power Automate and the Common Data System. With these tools I created a patient form, a storage layer and a business flow, in a couple of hours, without having to code anything!
Personally I have a coding background and I would love to create this in one of my preferred languages/frameworks such as Angular or React, with .Net, but the problem with this, is that this needs to be maintained and followed up by developers.
With the PowerPlatform, I can work directly with the business, where they can understand, extend and further develop the application, without having to rely on developers. An amazing step forward in generating value.
Let’s have a closer look on the different elements of the solution:
- With the PowerPlatform I created a patient entry form, this form can be given to the patient in the waiting room or at home.
With the help of PowerApps, I did not need to code anything, as this is a low code tool, that allows every person to create their own applications in a visual way.
You can see this as having the power of PowerPoint and Excel combined, to create beautiful but effective applications.
- The data that the patient provides in the form is being stored in the Common Data System. This is a very easy and powerful way of storing data, and this data can then be easily shared between your Office, Dynamics or Azure workloads. It also allows features such as creating new business workflows, adding business rules, …
- Power Automate is a low-code, easy to use platform, that allows users to create workflows based on actions or triggers.
In this case I created a workflow based on a trigger. The trigger here is when a new record has been created in the Common Data System.
The Power Automate engine will send the data to an Azure function, that will run it through an open source medical NLP engine, called cTakes. This information is then securely send to a Bot in Azure, which will notify the caregiver in Teams with all the information provided by the patient.
- I created the Bot with the Microsoft Bot Framework V4. I could not help myself to code something, thats why I chose the new V4 Bot framework, that has interesting integrations with the Teams platform. I could easily create this with the Microsoft Health Bot, but for this project, I wanted to see what the V4 version of the Bot Framework had to offer.
The bot will create an adaptive card, with all the needed information that allows the caregiver to asses if this information needs be stored in the Azure API for FHIR.
A small but important remark, when the patient submits the form, the bot will proactively notify the caregiver via Teams with the Adaptive card, which is pretty neat, if you ask me.
- When using Teams as our collaboration tool, we can easily integrate Bots and applications in our projects. In this scenario, the bot sends proactive messages to the caregiver, when a patient has submitted the form.
Because we are using Adaptive cards, we can also add actions to these cards, such as a manual validation button to send to the data to the EMR.
- The last part in this solution is the storage of the patient information in a secure and standardized way, more specific via the FHIR specification. For this we are using our Azure API for FHIR, which is a secure, compliant and salable, out of the box FHIR server.
For this project I started from the FHIR sample project, which has an out of the box dashboard, where I can visualize the patient information
To summarize this post: I created a patient entry form that can be handed to the patient in the waiting room. When the patient has submitted their symptoms, we trigger a flow that structures the symptom information and sends the data to a Bot. The Bot then sends a proactive message to the caregiver in Teams, who then evaluates the information and sends it to the Azure API for FHIR via an action button on the Adaptive card.
The data in the Azure API for FHIR can then be synced with the Electronic Medical Record.