PraxisConnect

Inspiration

PraxisConnect started from a simple question: how many visits and phone calls to a medical practice are actually necessary? For many routine administrative interactions, patients still need to call the practice, wait for someone to answer, or sometimes visit in person. This creates friction for patients and adds repetitive administrative work for medical practices. The goal of PraxisConnect is not to replace the doctor or automate medical decisions. It is to create a simple digital communication channel between patients and their medical practice.

## What it does

PraxisConnect currently supports three common workflows:

• Sick leave requests
• Repeat prescription requests
• Appointment requests

Patients submit structured information instead of relying on a phone call. The practice receives the request in one central interface, reviews it and decides what happens next. If additional information is needed, the patient and practice can communicate directly through the request. Both sides receive visible indicators when a new message is waiting, so they do not need to repeatedly check conversations manually.

For sick leave requests, the practice can review the patient's information, communicate with the patient when necessary, set the sick-leave period and mark the request as completed. For repeat prescriptions, patients can provide their insurance information, medication and dosage and the practice can review the request and respond.

For appointments, patients can describe what they need and optionally communicate general availability such as "morning" or "after 4 PM". The practice remains responsible for proposing the actual appointment.

The core principle is simple: The software organizes the communication. The medical practice makes the decisions.**

Why it matters

PraxisConnect is designed around reducing unnecessary friction. A routine request should not automatically require another phone call or another person in the waiting room. For patients, this means fewer calls, less waiting and potentially fewer unnecessary trips to the practice. For practices, it means that routine requests arrive in a structured format and can be processed according to priority rather than constantly interrupting the workflow through incoming phone calls. The practice interface also visually distinguishes request types, making it easier to triage sick leave requests, appointments and repeat prescriptions during a busy working day.

How I built it

PraxisConnect was built as a functional MVP using Base44. The application contains two connected sides: a patient interface and a medical-practice interface. I focused first on the complete request lifecycle:

Patient request → Practice review → Two-way communication → Practice decision → Patient update

Rather than adding many features, I repeatedly tested the application from both perspectives and removed or changed elements that created unnecessary complexity. The result is intentionally a focused MVP rather than a complete practice-management system.

Challenges

One of the main challenges was designing communication that works naturally in both directions. It was not enough for the practice to receive a request. Patients also needed to know when the practice had replied, and practice staff needed to immediately see when a patient had sent a new message. Another challenge was deciding what not to automate. Because this is a healthcare workflow, PraxisConnect deliberately does not diagnose patients, recommend medication, or make decisions about sick leave, prescriptions or appointments. Those decisions remain with the medical practice. The project therefore focuses automation on administrative friction rather than medical judgment.

## What I learned

Building PraxisConnect reinforced an important lesson for me: useful automation does not necessarily mean automating everything. Sometimes the better solution is to identify the repetitive steps around a human decision and make those steps faster and clearer. I also learned how much product design comes from testing a workflow rather than simply building features. Several decisions in PraxisConnect came from using the application as both a patient and a practice user and noticing where communication or navigation created unnecessary effort.

What's next

PraxisConnect is currently a working proof of concept. A production version would require a significantly stronger security, privacy and compliance architecture appropriate for healthcare data, as well as validation with real medical practices. Future development could also explore integrations with existing practice systems and other administrative workflows.

The long-term idea remains the same:

-reduce administrative friction while keeping healthcare decisions where they belong — with healthcare professionals.

Hackathon development disclosure

PraxisConnect began as a pre-existing prototype focused on a basic sick-leave request flow. During the MunichTech EXPO hackathon period, I used that prototype only as a foundation and substantially expanded the product by building the repeat-prescription and appointment-request workflows, improving two-way patient/practice messaging and unread indicators, refining request triage and the practice interface, and preparing/testing the application as a public functional demo. The pre-hackathon work and hackathon-period additions are clearly separated here in accordance with the event rules.

Practice Area demo credentials Email: [email protected] Password: PraxisDemo26!

The Patient Area can be accessed without login. These credentials are required only for the Practice Area.

Built With

• base44
• javascript
• low-code
• react
• web