Mobile app for a medical clinic — e-visits, GDPR and legal requirements

Healthcare is one of the fastest digitising sectors in Poland. Patients have grown used to booking an appointment in seconds, an e-prescription on their phone and a teleconsultation without leaving home. For clinics, practices and medical networks a mobile app has stopped being a gadget — today it is a real patient service tool and a competitive advantage.

At the same time it is one of the most heavily regulated areas in which software can be built. A medical app processes special category data (health data), falls under GDPR in its strictest regime, and often also under legislation on the healthcare information system. A design mistake here is not just poor UX — it is the risk of a financial penalty and of losing patients' trust.

In this article we go through what really has to be thought through: the features that make a difference, GDPR requirements for health data, the legal framework for e-visits, and integrations with the e-health ecosystem.

Why clinics invest in mobile apps

The motivation is rarely "technological" — it is operational and commercial:

• Taking pressure off the front desk. Phoning the clinic is a bottleneck. Booking and cancelling appointments in an app takes traffic off the helpline.
• Fewer no-shows. Automatic push and SMS reminders can cut missed appointments by a double-digit percentage.
• Teleconsultations and e-visits. Remote contact with a doctor is a standard patients already expect.
• Patient retention. An app with visit history, results and e-prescriptions ties the patient to the facility.
• Data and efficiency. A digital workflow reduces errors and paperwork for staff.

Key features of a healthcare app

Registration and appointment management

The core of every medical app. The patient sees available slots in real time, picks a doctor and a location, books and cancels. What matters most here is two-way integration with the practice management system (HIS/EMR) — calendars have to stay consistent, otherwise double bookings appear.

E-visits and teleconsultations

Video consultation, chat with a doctor, sending photos or documents. This requires encrypted transmission, a waiting queue and a mechanism for confirming the patient's identity. Recording or note-taking is worth considering only with explicit consent.

E-prescriptions and e-referrals

The app usually does not issue prescriptions itself — it retrieves them from the P1 (e-health) system. The patient sees the prescription code and dosage and can order fulfilment. The integration runs through the practice API or directly with the P1 platform.

Access to records and test results

Laboratory and imaging results, visit history. This is the most sensitive area — it requires strong authentication and precise access control.

Notifications and reminders

Push, SMS, email. Note: the content of a notification must not reveal health data on the lock screen (e.g. a specialty name that suggests a condition).

Payments

Online payments for private appointments, packages and medical subscriptions. Integration with a payment gateway and the facility's billing system.

GDPR and sensitive data — what you must not forget

Health data is a special category of personal data within the meaning of Article 9 GDPR. Processing it is prohibited as a rule, unless one of the narrow conditions applies — most often the provision of health care (Article 9(2)(h)) or the patient's explicit consent.

What that means in design practice:

• Privacy by design and by default (Article 25 GDPR). Data protection has to be built into the architecture from the start, not glued on at the end. Default settings must be the most privacy-protective.
• Data minimisation. Collect only what is necessary for the purpose. Not "just in case".
• Encryption. TLS in transit is the minimum. Sensitive data is worth encrypting at rest as well, with keys kept outside the client app.
• Strong authentication. Access to medical data should require at least two factors or biometrics, with a short session lifetime.
• Access control and accountability. Who accessed what and when — access logs (an audit trail) are required in order to demonstrate compliance.
• Legal basis and consents. Separate consent to the service from marketing consents. Consent must be freely given, specific and revocable.
• Processing agreement (Article 28 GDPR). If the app is built and maintained by a software house, or data is held in the cloud, a data processing agreement is needed with every processor.
• Patient rights. The app must enable the exercise of rights: access, rectification, erasure (subject to the obligation to archive medical records) and data portability.
• Impact assessment (DPIA). Large-scale processing of health data usually requires a data protection impact assessment before launch.

A note on retention. GDPR requires you to delete data you no longer need — but medical records legislation requires you to keep it for a defined period (as a rule 20 years). These two regimes have to be reconciled in a retention policy, not chosen between.

Legal requirements for e-visits in Poland

Teleconsultation is not a legal grey area — it is regulated. The most important frameworks:

• Telemedicine is a lawful health service and is treated as the provision of a health care service. The doctor bears the same liability as in an in-person visit.
• Patient identification. Identity has to be confirmed before advice is given — which affects the design of login and account verification.
• Medical records. Every e-visit has to be documented in the EMR in exactly the same way as an in-person visit.
• Patient consent to the service. It has to be obtained and documented, including consent to the remote format.
• The facility as a healthcare provider. Medical services delivered through an app are provided by a registered healthcare entity or practice — the app itself is a tool, not a "provider".

For a product team this translates into concrete requirements: an auditable record of consents, EMR integration, an identity confirmation mechanism and a secure video channel.

Integration with the e-health ecosystem

A medical app rarely works in isolation. The most common integration points in Poland:

• P1 / e-health — e-prescriptions, e-referrals, the Internet Patient Account.
• Practice management system (HIS/EMR) — calendar, patient file, records.
• Laboratories and imaging centres — test results, often via the HL7/FHIR standard.
• Payment gateways — settlement of private appointments.
• Notification systems — SMS and push providers.

The HL7 FHIR standard is becoming the de facto language for exchanging medical data — if you are planning for interoperability, it is worth basing your data model on it from the outset.

Technology — what to choose

For most medical apps we recommend a cross-platform approach (Flutter or React Native): one team, consistent code on iOS and Android, faster time to market while keeping native performance and access to biometrics and secure key storage.

Native is worth it when the app makes heavy use of specialist medical hardware, advanced image processing, or when security requirements dictate specific SDKs available only natively.

Whatever the stack, the fundamentals are the same: secure token storage, no sensitive data in logs, certificate pinning, session expiry and a well-considered consent onboarding flow.

How to start the project

1. Define the MVP scope. Usually: appointment booking + notifications + visit overview. E-visits and full records come in later stages.
2. Map the data flows. Who processes what, where and on what legal basis — that is the starting point for the DPIA and processing agreements.
3. Plan integrations early. The practice management system's API and P1 usually determine the architecture.
4. Design security from the start. Authentication, encryption, access logs — not at the end.
5. Verify legal compliance. Preferably with a lawyer specialising in healthcare and data protection.

Summary

A mobile app for a clinic is a project in which law and technology matter equally. E-visits, e-prescriptions and access to records give patients real convenience, but all of it rests on a foundation of compliance with GDPR and healthcare legislation. Whoever treats security and privacy as part of the architecture — rather than a formality at the end — will build a product patients trust.

At Mobilesoft we design and build mobile apps for demanding industries, including the medical sector — from an MVP through to integrations with e-health systems. If you are planning such a project, we will gladly help you work through the technical and regulatory requirements. Get in touch to discuss the details and receive a quote.