En sundhedsapp er et af de få områder, hvor „vi bygger hurtigt et MVP og ser, hvad der sker" kan være en dårlig idé. Ikke fordi teknologien er sværere — den er stort set den samme. Men fordi du fra dag ét er omfattet af regler, som ikke kan sættes på bagefter. Denne artikel er et praktisk kort over mdr software development: hvad du reelt skal opfylde, før du lancerer et e-health-produkt i Polen og EU.
1. Sundhedsdata er en særlig kategori af personoplysninger under GDPR
GDPR opdeler personoplysninger i almindelige data og data omfattet af artikel 9 — særlige kategorier. Oplysninger om helbred hører til den sidste gruppe. I praksis betyder det, at „samtykke i handelsbetingelserne" ikke er nok: du skal have et klart retsgrundlag, dokumentation for behandlingen og et højere sikkerhedsniveau.
Det minimum, enhver revision spørger til:
- Kryptering af data under transport (TLS) og i hvile (database, backups).
- Adgangsstyring og roller — lægen ser sine egne patienter, receptionen ser ikke diagnoser, administratoren læser ikke sundhedsdata uden en begrundelse.
- Hændelseslog (audit log) — hvem der hvornår har tilgået hvilke data. Det er et af de første spørgsmål ved et tilsyn.
- Dataminimering — indsaml kun det, der reelt er brug for. Hvert ekstra felt er en ekstra risiko.
- Databehandleraftaler (DPA) med enhver leverandør, der rører data: hosting, backup, overvågning, e-mail.
EN ANTAGELSE, der sparer dig for besvær: hav data hostet i EU. Cloud uden for Europa er muligt, men kræver standardkontraktbestemmelser og en analyse af overførslen — for et lille produkt er det en unødvendig komplikation.
2. Er din app medicinsk udstyr?
Det er et spørgsmål til titusinder af euro. Forordningen MDR (2017/745) siger, at software er medicinsk udstyr — software as a medical device — hvis producenten har bestemt det til bl.a. diagnosticering, monitorering, behandling eller lindring af sygdom.
I praksis:
- Er ikke medicinsk udstyr: tidsbestilling, klinikkens kalender, SMS-påmindelser, en simpel dagbog over velbefindende, en informationsportal, afregning.
- Er medicinsk udstyr: en app, der beregner en medicindosis, analyserer EKG eller billeder, foreslår en diagnose, klassificerer sygdomsrisiko eller styrer medicinsk udstyr.
Er produktet medicinsk udstyr, venter der dig klassificering (oftest klasse IIa for software), et kvalitetsledelsessystem (ISO 13485), risikoanalyse (ISO 14971), klinisk evaluering og et bemyndiget organ. Det er en proces, der måles i måneder og i et budget på højde med selve udviklingen af appen — og nogle gange større.
Praktisk konklusion: grænsen mellem „udstyr / ikke udstyr" afgøres først og fremmest af det erklærede formål. Derfor kan det betale sig bevidst at blive på den sikre side i første version af produktet: en app, der „hjælper med at registrere målinger og vise dem til lægen", er ikke det samme som en app, der „vurderer risikoen for et hjerteanfald".
3. Cybersikkerhed og tekniske standarder
Også uden for MDR er det værd at holde sig til standarderne, for hospitaler og klinikker spørger stadig oftere til dem i udbud:
- ISO 27001 — informationssikkerhedsledelse (formel certificering kræves nogle gange af større kunder).
- HL7 / FHIR — standarden for udveksling af sundhedsdata; uden den er integration med hospitalssystemer smertefuld.
- e-recept, e-henvisning, P1 — skal produktet røre ved det polske økosystem, er integration med P1, Polens nationale e-sundhedsplatform, et selvstændigt og veldokumenteret emne.
4. Hvad koster det?
Ved markedspriser (hos os: udvikling 46 €/t, design 35 €/t ekskl. moms):
Eurobeløb er omregnet til NBP's midtkurs den 14.09.2026 (1 € = 4,3391 zł) og afrundet. Vi fakturerer i PLN.
Registrering, patient- og lægekonti, kalender, dokumenter, administrationspanel, fuld overholdelse af GDPR.
Audit log, kryptering, roller, dokumentation af behandlingen, sikkerhedstest, DPA'er med leverandører.
ISO 13485, teknisk dokumentation, klinisk evaluering, bemyndiget organ. Her har du også brug for en regulatorisk konsulent — vi står for softwaren, ikke for certificeringen.
5. Sådan kommer du i gang
Før du skriver en linje kode, så svar på tre spørgsmål: hvilke data har du reelt brug for at indsamle, stiller produktet en diagnose eller foreslår det behandling, og hvem bliver dataansvarlig. De tre svar afgør arkitekturen, budgettet og om du havner på MDR-sporet.
Hos CodePort bygger vi systemer til sundhedssektoren og e-health netop i den rækkefølge: først fastlægger vi det regulatoriske omfang, derefter designer vi. Den omvendte rækkefølge kan blive dyr.
Denne artikel er af informativ karakter og udgør ikke juridisk rådgivning. Ved projekter omfattet af MDR bør du samarbejde med en regulatorisk konsulent.