This project aims to explore and implement innovative solutions to streamline healthcare processes through digital transformation, leveraging modern technologies to address real-world challenges in the industry. This project was enabled by the University of Applied Sciences and Arts Northwestern Switzerland (FHNW).
Video480.mp4
The contributing members of the AS24TeamPulse team are listed in Table 1, with their names and contact information.
| Name | |
|---|---|
| Andreas Braun Ponce de Leon | andreas.braunponcedeleon@students.fhnw.ch |
| Jetlinda Krasniqi | jetlinda.krasniqi@students.fhnw.ch |
| Joëlle Höchle | joelle.hoechle@students.fhnw.ch |
| Nicolas Bopp | nicolas.bopp@students.fhnw.ch |
Table 2 shows the names of the supervisors who provided guidance and expertise in the context of healthcare digitalization throughout the project.
| Name | |
|---|---|
| Andreas Martin | andreas.martin@fhnw.ch |
| Charuta Pande | charuta.pande@fhnw.ch |
| Devid Montecchiari | devid.montecchiari@fhnw.ch |
- Project Description 👑
- AS-IS Process 🚩
- TO-BE Process 🚩
- Knowledge Base 📚
- Usage of AI 🤖
As a Swiss health insurance company, we automate the process of receiving and processing pharmaceutical invoices. This includes extracting invoices from email attachments and checking various conditions for payment approval or rejection. Using a large language model, the customer receives a generated decision letter that completes the process.
The current process is very time-consuming for the administrative assistant. For each invoice, he or she has to check if the client is a customer and if the drug has a valid GTIN number. And finally, they have to do a risk assessment based on a comparison with the official 'Spezialitätenliste,' which doesn't currently have an API.
Internal:
- Insurance: Administrative Assistant
- Insurance: Financial Controller
External:
- Healthcare provider
- Client
The current state of cost approval in the Swiss health insurance system includes many tasks that are not yet automated. It takes a considerable amount of time and effort to either accept or reject the process of drug cost validation. This state is modeled in Image of the As Is Process and can also be found as bpmn-model.
The process starts with the insurance company's administrative assistant receiving an email with an invoice attached. The assistant reads the invoice and checks the client table to see if the person named on the invoice is a client of the insurance company.
The first gateway shows two different scenarios:
- If the person is not a client, the assistant informs the healthcare provider about the invalid claim, and the process ends.
- If the client exists in the table, the assistant checks the external Swiss Spezialitätenliste for the validity of the medication. If the medicine is invalid, the healthcare provider is informed and the process ends. For valid medicines, the process proceeds to the risk calculation stage:
- If the risk is low, the assistant checks the invoice and enters the information into the invoice table in the database.
- If the risk is high, the process moves to the Financial Controller who decides whether to approve or reject the case:
- If approved, the invoice information is sent back to the assistant, who inserts the data into the invoice table.
- If rejected, a message is sent to inform the provider of the rejection, and the process is terminated.
The best case is that the invoice is approved, which completes the process after notifying the healthcare provider and sending the notification and invoice to the client.
As described in this workflow, there are many tasks for the Assistant, which could be automated and proceed more efficient.
The aim of this project is to create a faster and more automized process for the approval or denial of payments and the calculation of pharmaceutical invoices.
The main stakeholder is our insurance company, especially the administrative assistant, who gets a lot of support in performing repetitive, boring standard tasks. In addition, the client benefits from a very fast process cycle, receiving feedback on calculations and decisions. Finally, the doctor gets quick feedback if there is an error in the invoice, with a description of the error.
User Story 1: Administrative assistant - invoice automation I am an administrative assistant at an insurance company, I would like the system to automatically process medication invoices from email attachments, so that I can save time and focus on other administrative tasks.
Acceptance criteria:
- The system retrieves email attachments and identifies valid PDF invoices.
- PDF invoices are parsed into JSON objects, extracting key fields (e.g., client ID, medication, cost).
- Invalid or incomplete invoices are flagged with a reason and a notification is sent back to the healthcare provider.
User Story 2: Client - Fast response for drug approval As a client with health insurance, I want to receive timely feedback on whether my medication costs have been approved or rejected, so that I can manage my medical expenses without unnecessary delays.
Approval criteria:
- Client receive approval or denial letters via email within a pre-defined SLA (e.g., within 24 hours of invoice submission).
- Denial letters clearly explain the reason (e.g., non-member, medication not on formulary).
- Approval letters include payment details and next steps for reimbursement.
User Story 3: Financial Controller - Risk Escalation Management As a financial controller, I want to review high-risk drug invoices flagged by the system, so that I can make informed decisions and ensure compliance with cost approval policies.
Approval criteria:
- The system flags high-risk invoices based on pre-defined rules (e.g., risk of drug abuse, high cost).
- Financial controllers are notified and provided with all relevant invoice and medication details.
- Controllers can approve or reject the invoice, with the system generating an appropriate letter to the client.
This chapter describes the innovations in business process automation of the To Be Process. The aim is to reduce costs and save time in the approval process of our Swiss health insurance company pulse. Provide insight into the workflow and automation of tasks. It also serves as a guide for reproducibility.
Key features:
- Automatically retrieves invoices from email attachments.
- Reads and parses text from invoice PDFs into JSON objects
- API to send invoice data to Camunda and start the process
- Stores client, invoice, and medication data in a structured SQLite database.
- Storage of medication invoices in PDF format in Google Drive
- Supports integration with external systems such as Deepnote and make.com for automated workflows
- Generates and returns decision letters to the client
The image below visualizes the automated workflow in MAKE, including the modules. The process starts with the Gmail module monitoring incoming emails. Then the emails are filtered if the email attachment is a PDF.
The PDF files are routed to two actions, firstly uploading them directly to the digitbp.pulse.team@gmail.com Google Drive storage. This is used as a database to keep track of incoming invoices. The other path sends the PDF file to the PDF.co module. This module converts the information in the PDF file to JSON format, which is then passed to the JSON module to create a JSON object suitable for sending to an API using the HTTP post request module.
The MAKE pipeline passes the JSON object to Deepnote with an HTTP request. The API extracts the information from the JSON object and creates an entry in the Invoice table. The extracted values from the JSON object are then sent to the Camunda endpoint, which finally starts the Camunda To Be process.
| Endpoint | Method | Description | Request Body | Response |
|---|---|---|---|---|
| /create_invoice | POST | Creates an invoice and starts a Camunda process |
{
…
}
|
{
"status": "success",
"message": "Invoice created and process started",
"process_instance_id": "id",
"invoice_id": 12345678
}
|
| /check_client | POST | Checks if a client exists based on their insurance number |
{
"insurance_number": 12345678
}
|
{
"found": true,
"client": { ... }
}
|
| /check_medication | POST | Checks if a medication exists based on its GTIN |
{
"gtin": 7680481641027
}
|
{
"found": true,
"medication": { … }
}
|
| /send_email | POST | Sends an email based on the invoice and reason provided |
{
"invoice_id": 12345678,
"reason": "reason"
}
|
- |
For this project, the medical billing and insurance management system designed specifically for the Swiss healthcare environment is represented by three tables, which are shown in SQLite tables. The first table on the left is the Medication table, which stores details about medications, including a unique identifier (GTIN), manufacturer, description, substances, public price, and a drug abuse risk indicator. Using the GTIN number, the Invoice table in the middle links to the Medication table. This table records invoice data such as a unique invoice ID, an insurance number, a drug identifier, the date, the biller's email and the total amount. The Client table on the right is linked to the Invoice table via the insurance number and holds information about the client, including first and last name, address details, email, and a risk score.
Finally, we arrive at the To-Be BPMN Workflow in Camunda. The start is triggered by the HTTP request from Deepnote, which introduces the model with the invoice parameter from the invoice from the email. After receiving the invoice information from the API as JSON objects, the system checks if the client is a customer of our health insurance. If the client is in our database, it retrieves the drug information from the drug formulary and checks if the drug exists. If any of the checks fail, a rejection message is generated with an LLM giving the healthcare provider an overview of why the invoice cannot be processed.
There is also a risk assessment where the invoice is reviewed. To calculate the risk/benefit of approving the cost of the drug, and if the invoice is reasonable, the information goes through a Decision Tree to automate this task (see SL_decision.dms). If there is a high risk, the task is escalated to a higher authority who will review the case and decide whether to approve or deny the cost, with an LLM generated letter to the customer. If the higher authority finds the invoice for reasonable or the decision is low risk, the system sends a positive response generated by LLM before closing.
The DMN-based decision service for medication validation evaluates the following:
- Client eligibility and risk profile
- Price validation against published rates
- Drug abuse risk assessment
The service adheres to Switzerland's 'Spezialitätenliste' (SL) rules for medication reimbursement approval.
- Ensures that the client is a valid client within the system.
- Compares the medication price to the published rates based on the SL.
- Assesses the risk based on the client profile and the potential for medication abuse.
- Returns the final approval based on all validations passing.
The decision table is presented below. In this instance, the blue section illustrates the procedure for addressing a high-risk situation. This indicates that the invoice will be reviewed by the finance controller.
A Large Language Model (LLM), specifically Zephyr 7B β by HuggingfaceH4, was trained to generate letters for cost approval or denial (see Deepnote.com). Should the process determine that the costs of the medication invoice are to be approved, the LLM will generate an approval letter and send it via an API to MAKE.com. This will then automatically forward the letter to the client's email address using the Webhooks and Email modules.
If a cost approval is denied, this will be due to one of the following reasons:
- The client is not a member of our health insurance scheme.
- The medication is not included in our database.
- In the event of a high-risk detection, a higher authority may determine that the cost approval is not reasonable.
In each of the above cases, a letter of individual denial will be generated using the LLM, clearly stating the reason for denial. Once the letter has been generated as a PDF, it will be sent to an API, which will then forward it to Make using the Webhooks module. Subsequently, the Email module will automatically dispatch the denial letter to the client's email address (see Figure below).
- The email must be empty and have the format of the Swiss TARMED invoices (use provided templates on Google Drive).
- Due to time issues the project is limited to medication that have the "Tarif" 402 (GTIN code), even though "Tarif" positions in the TARMED system are not specific defined.
- The module PDF.co in MAKE provides only limited tokens and expires on the 5th January 2025, and limited tokens (should be enough until it expires).
- The Gmail module in MAKE expires on the 5th June 2025.
- The make scenario fetches all incoming emails every 15 minutes.
The project automated the medication invoice processing workflow for a Swiss healthcare insurance company. By implementing automated email processing, PDF parsing, risk assessment, and LLM-generated decision letters, we have been able to significantly reduce the manual workload for administrative staff while accelerating response times for clients. The combination of multiple technologies (make, Camunda, Flask API) resulted in the creation of an end-to-end automated solution.
- MAKE
- Camunda 7
- Deepnote (Python 3.9)
- Google Mail
- Google Drive
- Google Cloud Platform: Projectnr. 49695570445 (log in with the provided email in the chapter Setup Instructions)
- Flask library
- SQLite database
- PDF.co
- Webhook
- LLM: Zephyr 7B β
Step-by-step guide to run the workflow in Camunda:
Good case scenario:
-
First check if the MAKE.com scenarios are running (1. Integration Gmail, 2. Send e-Mail).
-
Check if deepnote.com is running.
-
Check if the Camunda workflow engine is running.
-
Sending an empty e-mail with an invoice PDF attachment to the address digitbp.pulse.team@gmail.com (in the format of Swiss invoices, TARMED—example invoices are provided on the Google Drive on the digitbp.pulse.team@gmail.com account)
-
Go to the task list in Camunda.
-
Based on the risk evaluation, the assistant, or the finance controller can approve the invoice.
-
After approving the invoice, two emails are generated.
-
one for the client and one for the healthcare provider—the emails that are used are in the database and the one in the invoice for the healthcare provider
-
When the email is sent, the process ends.
Bad-case scenario:
-
Repeat the first four steps of the good case scenario but with an error in the invoice.
-
After starting the Camunda process, the system will generate an email, which informs the healthcare provider to check his invoice again.
For this project, the following email address was created and used as our healthcare insurance mail: digitbp.pulse.team@gmail.com The password is provided in Moodle. As a second address to send / receive mails: digibp.pulse.peer@gmail.com with the same password
AI (particularly Claude, ChatGPT, and DeepL) was used as support for coding, writing and developing this solution. Despite the support, our team has dedicated significant effort to developing this result.