Healthcare apps: why development is more complex than other projects

When we finished the first version of the Doktor v kapse ("Doctor in your Pocket") project back in 2013, we admitted something to ourselves: developing a healthcare application is a different kind of challenge. Not because it's technically impossible – but because technology is only one part of the equation. The second part is regulation, the third is patient data, and the fourth is the user who, in difficult moments, needs an application that never fails.

1. The regulatory landscape: what you must know before starting

EU countries are governed by the MDR (Medical Device Regulation) and national medical authority guidelines. Not every health-related application automatically qualifies as a medical device – but if the app helps with diagnosis, monitoring or treatment, it likely falls under regulation.

In practice, this question comes up in virtually every app focused on treatment adherence – anywhere we are helping patients stick to a prescribed therapy. That very function sits on the regulatory boundary. We therefore dedicate a significant portion of the pre-development phase to consultations with legal and regulatory experts before writing a single line of code.

The good news is that with the right architecture and feature scoping, it is often possible to keep an application outside the definition of a medical device – avoiding a costly MDR certification process. We help clients identify this boundary during the specification phase and design functionality that delivers maximum value to patients without unnecessarily inflating the project cost.

2. GDPR and medical data: double-strength requirements

Health data falls under GDPR's special categories of personal data (Article 9), meaning stricter consent rules, more limited processing options, and higher security requirements than ordinary personal data. In practice, this shapes the entire application architecture.

When building a patient portal for a private clinic, we connected the clinic's primary clinical system and its proprietary information system – two environments that were never designed to talk to each other. Every data flow needed a legal basis – consent type, processing purpose, retention period. The architecture had to account for users revoking consent at any time, with data genuinely deleted from all layers of the system.

Practical impact: plan for data pseudonymisation at the database level, at-rest and in-transit encryption, audit logs, and separation of identifying data from health data. This isn't paranoia – it's the standard.

3. Healthcare system integrations: everyone speaks a different language

Healthcare IT is fragmented everywhere. Hospitals, clinics and insurers use different systems, each with its own data formats and varying appetite for integration. Take DASTA, the proprietary data standard in Czech healthcare: without deep hands-on experience, you simply cannot integrate with it. Every country has its own version of this problem.

An app we built for midwives reads patient insurance card data according to the standard used in Germany and Austria, then synchronises it with the operator's own information system. No third-party connections are required – but precise compliance with the card format is what makes the whole system reliable.

Our recommendation: assume integrations will take 30–50% of total project time. And never sign a contract without sandbox access to the target system.

4. UX for patients: humility and simplicity

A patient using your application is probably not having the best day. They may have just been diagnosed with a chronic condition. They may be anxiously awaiting test results. The user experience must be designed with extraordinary care.

When developing an attack diary for patients with a chronic neurological condition, we tested the UI with real patients. We discovered that during an acute episode, users need to input information as quickly as possible – clear buttons, no unnecessary steps, one-handed operation. This insight reshaped the entire app design.

• → Accessibility is a requirement, not a bonus. Older patients, people with visual or motor impairments – design for them from the start. If your project requires compliance with the European Accessibility Act (EAA), we can deliver that as part of development.
• → Error states are critical. What happens when the app loses connectivity mid-entry? Offline-first approach, auto-save, clear status communication.
• → Notifications can save a treatment. A medication reminder isn't enough – it must be reliably delivered even in battery-saver mode, with delivery confirmation.
• → Localisation is more than translation. Our apps run in more than 10 countries and languages – each version adapted for local insurance systems, country-specific regulations, and cultural differences in how patients are addressed.

5. What this means for your project

A healthcare application is a more demanding project than the average commercial app – but it's not unachievable. The key is to come to us for a consultation as early as possible, not after the functional specification is complete. Regulatory and GDPR requirements affect architecture from the ground up.

Over 20 years we've worked through 8+ healthcare projects – from patient-facing apps to physician portals to middleware integrating hospital systems. We're happy to share our experience and help you think through a project before development begins.