This study project digitizes and automates a pharmacy prescription workflow using Camunda 7 and Python External Task Workers. The main goal is automated prescription processing with a strong focus on locker pickup, enabling patients (customers) to collect their medication outside pharmacy opening hours.
Patients submit prescription data digitally (prototype). The system validates the input, checks stock availability, handles ordering if necessary, supports pharmacist preparation, and (planned) notifies the patient when the medication is ready in a locker.
video.mp4
This project was developed as part of a university study project focusing on Business Process Management (BPM) and process automation.
The primary objective is to design, model, and technically implement a realistic TO-BE business process using Camunda BPMN and external microservices. The project emphasizes process orchestration, automation logic, and system interaction, rather than production-ready software or a complete frontend solution.
| Name | |
|---|---|
| Feline Weger | feline.weger@students.fhnw.ch |
| Lukas Kamber | lukas.kamber@students.fhnw.ch |
| Semih Eryilmaz | semih.eryilmaz@students.fhnw.ch |
| Sivanajani Sivakumar | sivanajani.sivakumar@students.fhnw.ch |
We would like to thank our supervisors for their guidance and support throughout this project.
| Name | |
|---|---|
| Andreas Martin | andreas.martin@fhnw.ch |
| Charuta Pande | charuta.pande@fhnw.ch |
| Devid Montecchiari | devid.montecchiari@fhnw.ch |
The locker option is the primary delivery method in this project:
- Medication is prepared by the pharmacist.
- The medication is placed in a secure locker box.
- The patient receives locker details (via Make.com notification).
- The patient can pick up the medication 24/7, even when the pharmacy is closed.
The AS-IS process represents the current manual prescription workflow and is modeled as a BPMN diagram in Camunda.
Figure 1 illustrates the AS-IS process model.
The corresponding BPMN file can be found in the repository under
Prescription_Filing_AS_IS.
Figure 1: AS-IS BPMN model of the current manual prescription process.
External
- Patient
Internal
- Pharmacist / Pharmacy staff
The current prescription process is largely manual:
-
The patient submits a prescription physically (or sometimes via email).
-
The pharmacist manually validates the prescription.
-
Stock availability is checked manually.
-
If the medication is not in stock, the pharmacist places a manual order and informs the patient that it will be available the next day (or later).
-
The patient then either:
- returns to the pharmacy to pick it up during opening hours, or
- waits for home delivery if shipping is arranged.
- Manual coordination and manual status handling
- Pickup is typically tied to pharmacy opening hours, resulting in limited flexibility for patients
- No standardized locker pickup (no locker assignment, pickup code, or secure handover)
Reduce manual effort, make processing traceable, and enable patients to receive or collect medication independently of pharmacy opening hours.
User story 1 (Pharmacist): As a pharmacist, I want to process medication orders digitally and efficiently to avoid manual document handling. I want the system to automatically check stock availability and handle ordering when medication is out of stock, so that patients receive their medication as quickly as possible.
Acceptance criteria
- The system validates the prescription and checks medication stock automatically.
- The pharmacist approves or handles orders when medication is out of stock.
- The pharmacist marks medication as ready, triggering a patient-ready notification (planned).
User Story 2 (Patient):
As a patient, I want to receive a notification when my medication is ready and be able to collect it from a secure locker outside pharmacy opening hours,
so that I can pick up my medication flexibly and without waiting.
Acceptance criteria
- The patient is informed when the medication is ready.
- If locker pickup is selected, the patient receives locker details and a pickup code.
- The medication can be collected independently of pharmacy opening hours.
This chapter describes the redesigned and automated prescription handling process. The TO-BE process reduces manual work, shortens waiting times, and provides a reproducible architecture using Camunda 7 and external Python workers.
Figure 2 illustrates the TO-BE process model.
The corresponding BPMN file can be found in the repository under
Prescription_Filling_TO_BE.
Figure 2: TO-BE BPMN model of the automated prescription process with locker-based pickup.
The TO-BE process introduces several functional and technical improvements compared to the manual AS-IS workflow. The following features summarize the core capabilities of the automated prescription process:
-
Digital prescription submission (prototype)
Patients submit prescription data digitally, which triggers the start of the BPMN process. -
Automated validation
The system validates required fields, prescription date, quantity, and selected delivery option. -
Stock check and ordering support
If the medication is in stock, it is reserved automatically.
If it is not in stock, an ordering task is created and the process continues after delivery registration. -
Multiple delivery options
The process supportslocker,pickup, andhomedelivery, selected via thepreferredDeliveryprocess variable. -
Patient-ready notification
Patient notification via Make.com with QR-Code to open Locker. -
Structured data handling
The use of process variables and a database layer ensures traceability and supports future system integrations.
The AS-IS and TO-BE processes are orchestrated using Camunda 7 and modeled as BPMN workflows. Camunda serves as the central process engine and coordinates the interaction between system tasks, user tasks, and external microservices.
The BPMN models define the complete process logic, including the control flow, gateways, and task types:
- System Tasks are implemented as External Service Tasks and executed by Python workers.
- User Tasks represent manual pharmacist interactions, such as ordering medication, preparing prescriptions, and marking medication as ready.
- Process instances are started programmatically when prescription data is submitted and passed to Camunda as process variables.
Both BPMN models are included in this repository and represent the central artifacts of this project:
-
AS-IS BPMN model:
Represents the current manual prescription handling process.
File:./bpmn/Prescription_Filing_AS_IS.bpmn
(see Figure 1) -
TO-BE BPMN model:
Represents the redesigned and automated prescription process, including system tasks, user tasks, and gateways.
File:./bpmn/Prescription_Filling_TO_BE.bpmn
(see Figure 2)
The BPMN diagrams shown in this README are direct visual representations of these models.
All process logic, gateways, and task types described in the text are derived from the BPMN definitions stored in the bpmn folder.
While the process supports multiple delivery options, the locker pickup scenario represents the primary use case of this project. It demonstrates how automated processes can enable secure, flexible, and time-independent medication pickup using BPMN-based orchestration.
This section describes the execution of the TO-BE process as defined in the BPMN model (see Figure 2) and the corresponding
BPMN file.
The process starts when the patient submits prescription data via an external system (frontend, form, or API — prototype).
The submitted data is passed to Camunda as process variables, including the selected delivery option (locker, pickup, or home).
The system validates the prescription data, including required fields, quantity, prescription date, and delivery option.
If the prescription is invalid, the process is terminated.
The system checks medication availability using the inventory database and stores the result in the process variable inStock (boolean).
Immediately afterwards, a DMN decision table (FulfillmentDecision) is evaluated
(see DMN model: diagram_2.dmn).
Based on inStock, it sets the process variable action:
- If
inStock = true:action = "RESERVE" - If
inStock = false:action = "ORDER"
An exclusive BPMN gateway then routes the process according to action:
- If
action = "RESERVE", the process continues with reservation and preparation (Step 3a). - If
action = "ORDER", an ordering task is created and the process continues after delivery registration (Step 3b).
Note: This decision could also be modeled directly as an XOR gateway.
The DMN was intentionally included for learning and demonstration purposes and to separate decision logic (DMN) from process flow (BPMN). Figure 3 shows the BPM Process without a DMN and with a XOR Gate.
Figure 3: PM Process without a DMN and with a XOR Gate.
If the medication is available, the process continues without manual intervention.
First, a system task reserves the required medication quantity in the database.
Next, additional system tasks prepare the pharmacist order details and create a preparation user task.
This preparation task is then assigned to the pharmacist for manual execution (Step 4).
If the medication is not available, the process enters an ordering phase.
A system task creates an ordering user task for the pharmacist.
The pharmacist orders the medication, receives the delivery, and registers the delivery in the system.
After the delivery is registered, system tasks update the stock in the database and reserve the required medication quantity.
The process then continues with preparation.
Based on the preparation task created by the system, the pharmacist prepares and packages the medication. The preparation task contains a structured summary of the prescription, medication details, and the selected delivery method.
Once preparation is completed, the pharmacist marks the medication as ready in the system. This action triggers a parallel continuation of the process.
After the medication is marked as ready, the process continues in parallel system tasks. One branch handles patient notification, while the other branch handles the selected delivery or pickup logistics.
Patient notification:
Patient notification is via Make.com.
Depending on the selected delivery option, the patient will receive:
- Locker pickup details, including locker ID and QR-Code
- Pickup confirmation during pharmacy opening hours
- Home delivery status and delivery date
Logistics handling (conceptual):
In parallel, the medication is either placed into a locker, prepared for in-store pickup, or handed over to a delivery service, depending on the selected delivery option.
Patient notifications are implemented using Make.com as an external integration platform. Camunda triggers a Webhook Connector once the medication is marked as ready. The webhook forwards all relevant process variables to Make.com, where message generation and delivery are handled.
This approach was chosen to:
- decouple notification logic from the BPMN process,
- avoid direct email logic inside Camunda,
- allow flexible message formats (HTML email, QR codes, attachments),
- simulate real-world integration scenarios.
The Make.com scenario is included in the repository as a blueprint. Figure 4 illustrates the Make.com-based notification workflow used in the TO-BE process.
Figure 4: Make.com scenario for delivery-specific patient notifications (locker pickup, pharmacy pickup, and home delivery).
Depending on the selected delivery option (preferredDelivery), different notification messages are generated and sent to the patient.
For locker pickup, the patient receives a QR-code based notification:
- Locker ID
- QR code to open the locker
- No PIN is sent (QR replaces PIN for improved usability)
Email example:
Hello {{patientName}},
Your medication is ready for pickup.
Locker ID: {{lockerId}}
Scan the QR code below to open your locker.
You can collect your medication 24/7.
Best regards,
Your Pharmacy
The QR code is generated dynamically in Make.com and embedded directly into the email body.
If Pharmacy pickup is selected, the patient receives a confirmation message informing them that the medication is ready for collection at the pharmacy counter:
Email example:
Hello {{patientName}},
Your medication is ready for pickup at the pharmacy.
Pickup window: Mon–Fri 08:00–18:00.
Please collect it during regular opening hours.
Order: {{orderID}}
Best regards,
Your Pharmacy
If home delivery is selected, the patient receives a delivery status notification:
Hello {{patientName}},
Your medication has been prepared and will be delivered to your address.
It will be delivered tomorrow.
Best regards,
Your Pharmacy
- Notifications are triggered via a Camunda HTTP Connector
- Make.com receives process variables such as:
{
"patientEmail": "${patientEmail}",
"patientName": "${patientName}",
"preferredDelivery": "${preferredDelivery}",
"orderId": "${orderId}",
"message": "Your medication is ready to pick up.",
"lockerId": "${lockerId}",
"lockerCode": "${lockerCode}"
}
- No direct email configuration is required in Camunda
- This setup simulates real-world event-driven system integration
All automated logic is implemented using Python External Task Workers. Each worker listens to specific Camunda topics and completes tasks via the Camunda REST API.
The microservices communicate only via Camunda process variables and can be executed independently (e.g., in Deepnote).
This service is responsible for validating prescription data, checking medication availability, and reserving medication when sufficient stock is available at the beginning of the TO-BE process.
Worker ID: python-worker-main
Topics: validatePrescription, checkStock, reserveMedication
Responsibilities
- Validate prescription data (mandatory fields, insurance number, date rules, quantity, delivery option)
- Check medication stock in the database
- Reserve medication if sufficient stock is available
Key outputs (process variables)
prescriptionValid,validationMessageinStock,availableQuantityreservationId,reservationSuccess,reservedMedicationName,reservedQuantity
This service handles the ordering phase of the TO-BE process when medication is not available and ensures a seamless continuation of the process after restocking.
Worker ID: python-worker-ordering
Topics: createOrderingTask, updateStockAndReserve
Responsibilities
- Create an ordering task if medication is not in stock
- Generate a structured ordering description for the pharmacist
- Update stock after delivery registration and reserve medication
Key outputs
orderId,orderDescription,orderingTaskCreated
reservationId,reservationMessage,reservationSuccess
This service prepares all relevant information required for the pharmacist to perform the manual preparation step within the TO-BE process.
Worker ID: python-worker-pharm
Topics: preparePharmacistOrder, createPreparationTask
Responsibilities
- Create a compact pharmacist order summary
- Generate internal preparation instructions
Key outputs
pharmacistOrderId,pharmacistOrderSummarypreparationTaskId,preparationInstructions
The project includes a lightweight database layer to support medication stock management, reservations, and ordering within the TO-BE process. The database is used by the Python external task workers and serves as a technical foundation for process automation.
Figure 5 shows the database schema used in this project.
Figure 5: Database schema for medication stock, reservations, and orders.
The database supports the following core functionalities:
- Checking and updating medication stock levels
- Creating and managing medication reservations
- Handling medication orders in out-of-stock scenarios (prototype)
In the context of this project, the database is minimally populated. The primary focus lies on process automation, BPMN orchestration, and system interaction, rather than on comprehensive data modeling or large-scale data persistence.
Nevertheless, the database schema reflects a realistic pharmacy setup and provides a solid foundation for future extensions.
In a more comprehensive production-ready system, additional database entities such as Patients, Prescriptions and Lockers would typically be introduced. In particular, a dedicated Prescription table would allow structured storage of prescribed medication and dosage information and would also enable more advanced scenarios such as parallel processing of multiple prescriptions.
For the scope of this project however such entities were intentionally not modeled in the database. This decision was made to keep the data layer lightweight and focused on process execution, while still allowing all necessary information to be available to downstream tasks and workers.
Despite these simplifications, the chosen schema remains realistic, coherent and extensible.
The microservices in this project do not communicate directly with each other. Instead, all data exchange is performed via Camunda process variables, which ensures loose coupling and clear separation between process orchestration and technical logic.
Process variables are used to transfer information between system tasks, user tasks, and external workers throughout the TO-BE process.
The most relevant process variables are grouped as follows:
Process input variables (provided at process start):
insuranceNumbermedicationNamequantitydoctorNamepreferredDeliveryprescriptionTextdatePrescribed
Validation variables:
prescriptionValidvalidationMessage
Stock and availability variables:
inStockavailableQuantity
Reservation variables:
reservationIdreservationSuccessreservationMessage
Ordering variables:
orderIdorderDescription
Pharmacist preparation variables:
pharmacistOrderSummarypreparationInstructions
-
Start the Camunda 7 engine.
-
Start the Python workers (e.g., in Deepnote):
python-worker-mainpython-worker-orderingpython-worker-pharm
-
Start the process instance in Camunda with initial variables (currently manual start; frontend trigger planned).
-
Complete pharmacist user tasks in the Camunda Tasklist.
-
Observe automatic progression of system tasks.
- Patient upload frontend is not part of this implementation (process start is manual or API-based).
- Locker hardware integration is conceptual.
- Database content is minimal and intended for demonstration purposes.
- Camunda 7 (BPMN, External Tasks)
- Deepnote Python 3.9
- REST APIs
- Make.com
- ChatGPT (AI-assisted coding and documentation support)
- DeepL (language refinement)
The following artifacts are included in the repository:
-
Note: we also did a video with voice over, which you can access over this link. click here:
Artificial intelligence tools were used as supportive aids during the development of this project. In particular, ChatGPT, Animaker and DeepL were used to assist with coding, text formulation, language refinement, video creation and conceptual clarification.
All architectural decisions, BPMN models, process logic, and implementations were designed and validated by the project team. The use of AI served as a productivity and quality support tool and does not replace the team’s own work.
