Healthcare app development is one of the few areas where "let's build an MVP quickly and see what happens" can be a bad idea. Not because the technology is harder — it is much the same. It is because rules apply to you from day one, and you cannot bolt them on later. This article is a practical map: what you genuinely have to meet before you release an e-health product in Poland and the EU.
1. Health data is a special category of data
GDPR splits personal data into ordinary data and the Article 9 categories — special category data. Information about health belongs to the second group. In practice that means a "consent in the terms and conditions" is not enough: you need a clear legal basis, processing documentation and a higher standard of security.
The minimum set that any audit will ask for:
- Encryption of data in transit (TLS) and at rest (database, backups).
- Access control and roles — a doctor sees their own patients, reception does not see diagnoses, an administrator does not read medical data without a reason.
- Audit log — who accessed what data and when. This is one of the first things an inspection asks about.
- Minimisation — collect only what you genuinely need. Every extra field is extra risk.
- Data processing agreements (DPAs) with every supplier that touches the data: hosting, backup, monitoring, email.
ONE ASSUMPTION that saves trouble: host the data in the EU. Cloud outside Europe is possible, but it requires standard contractual clauses and a transfer assessment — for a small product that is a complication you do not need.
2. Is your app a medical device?
This is a question worth tens of thousands of euros. The MDR (2017/745) regulation states that software is a medical device if the manufacturer intends it for, among other things, diagnosing, monitoring, treating or alleviating disease.
In practical terms:
- Not a device: appointment booking, a practice calendar, SMS reminders, a simple wellbeing diary, an information portal, billing.
- Is a device: an app that calculates a drug dose, analyses ECGs or images, suggests a diagnosis, classifies disease risk or controls a medical device.
If your product is a device, you face medical device software classification under MDR (most often class IIa for software), a quality management system (ISO 13485), risk analysis (ISO 14971), clinical evaluation and a notified body. That is a process measured in months, with a budget comparable to building the application itself — and sometimes larger.
The practical conclusion: the line between "device" and "not a device" is set above all by the stated intended purpose. That is why, with the first version of a product, it is worth deliberately staying on the safe side: an app that "helps you record measurements and shows them to your doctor" is not the same as an app that "assesses your risk of a heart attack".
3. Cybersecurity and technical standards
Even outside MDR it is worth sticking to standards, because hospitals and clinics increasingly ask about them in tenders:
- ISO 27001 — information security management (formal certification is sometimes required by larger clients).
- HL7 / FHIR — the standard for exchanging medical data; without it, integration with hospital systems is painful.
- e-prescriptions, e-referrals, P1 — if your product is to touch the Polish healthcare ecosystem, integration with the national P1 platform is a separate and well-documented topic.
4. How much does it cost?
At market rates (ours: €46/h for programming, €35/h net for design):
Euro amounts converted at the NBP mid-market rate of 14 September 2026 (€1 = 4.3391 zł) and rounded. We invoice in PLN.
Registration, patient and doctor accounts, calendar, documents, admin panel, full GDPR compliance.
Audit log, encryption, roles, processing documentation, security testing, DPAs with suppliers.
ISO 13485, technical documentation, clinical evaluation, a notified body. Here you also need a regulatory consultant — we are responsible for the software, not for certification.
5. Where to start
Before you write a line of code, answer three questions: what data do you really need to collect, does the product make a diagnosis or suggest treatment and who will be the data controller. Those three answers determine the architecture, the budget and whether you enter the MDR route.
At CodePort we build systems for medicine and e-health in exactly that order: first we establish the regulatory scope, then we design. The reverse order can be expensive.
This article is for information only and does not constitute legal advice. On projects covered by MDR, work with a regulatory consultant.