Fra idé til marked: roadmap for udvikling af medicinsk software

Udvikling af medicinsk software fra idé til marked tager typisk 18–36 måneder, hvis produktet er medicinsk udstyr i klasse IIa eller højere. Tiden går ikke kun med at skrive kode. Den går med at afklare klassen, bygge et kvalitetssystem, dokumentere krav og risici, samle klinisk evidens og få et bemyndiget organ til at vurdere det hele før CE-mærkningen.

Denne guide gennemgår rejsen i den rækkefølge, du møder spørgsmålene, med vores estimater for tid og pris. Tallene er bon.do’s egne estimater fra projekter og tilbud, ikke garantier.

Hvor lang tid tager det at bringe medicinsk software på markedet?

En fokuseret MVP tager 2–4 måneder, en reguleret app med validering 6–12 måneder, og en CE-mærkning af klasse IIa-software tager typisk 18–36 måneder fra idé til mærke. Det bemyndigede organs vurdering kommer oven i udviklingen og afhænger af organets kapacitet. Ifølge Team-NB’s undersøgelse fra maj 2026 tager selve vurderingen typisk 13–18 måneder.

Faserne overlapper. Kvalitetssystemet og den tekniske dokumentation bygges parallelt med softwaren, ikke bagefter.

Er din software medicinsk udstyr?

Din software er medicinsk udstyr, hvis du som fabrikant tilsigter, at den skal diagnosticere, forebygge, overvåge, forudsige eller behandle sygdom hos den enkelte patient. Det er det tilsigtede formål, ikke teknologien, der afgør det. Spørgsmålet er det vigtigste i hele roadmappet, fordi svaret styrer tid, pris og krav til din partner.

Klassen følger af regel 11 i bilag VIII til forordningen om medicinsk udstyr (EU) 2017/745:

Software til in vitro-diagnostik klassificeres efter IVDR. Brug MDCG 2019-11 rev.1, som blev revideret i juni 2025, og Lægemiddelstyrelsens vejledning til fabrikanter om software og apps. Er du i tvivl, så få klassen vurderet af en regulatorisk rådgiver eller et bemyndiget organ tidligt. Er softwaren ikke medicinsk udstyr, gælder GDPR for sundhedsdata stadig, når den behandler helbredsoplysninger. Bruger produktet AI, kan AI-forordningen gælde oven i MDR; se vores guide til AI i medicinsk udstyr.

Fase 1: valider problemet, før du skriver kode

Før den første kodelinje skal du vide, at du løser et reelt problem for nogen, der vil betale. Det koster mindre at kassere en idé nu end efter en MVP.

• Problemet. Hvilket konkret problem har klinikere, patienter eller forskere? Hvor ofte opstår problemet, hvor alvorligt er det, og hvad bruger de i dag?
• Brugerne. Interview klinikere, observer arbejdsgangen, og skriv brugerbehovene ned. De danner grundlag for kravene og dokumentationen om brugervenlighed.
• Markedet. Hvem køber? I Danmark er det ofte regionerne gennem udbud, og beslutningen involverer klinikere, IT, indkøb og økonomi. Beregn markedets størrelse ud fra købernes faktiske budgetter, ikke ud fra antallet af brugere.
• Klassen. Lav en foreløbig klassificering efter tabellen over regel 11 i afsnittet om, hvorvidt din software er medicinsk udstyr. Den afgør resten af planen.

Hospitalernes og regionernes innovationsenheder er en god vej til klinikere, der vil teste en idé.

Fase 2: prototype og krav

En klikbar prototype viser, om klinikerne forstår produktet, før det koster udviklingstimer. Byg den i fx Figma, og test den med 5–8 brugere fra målgruppen. Det er formativ evaluering af brugervenlighed efter IEC 62366-1, og resultaterne skal dokumenteres, hvis produktet er medicinsk udstyr.

Skriv samtidig kravene ned:

• Brugerkrav fra fase 1, fx “Som kardiolog vil jeg se patientens trend, så jeg kan justere behandlingen.”
• Funktionelle og ikke-funktionelle krav: ydeevne, sikkerhed, tilgængelighed (WCAG 2.2 AA er et godt mål).
• Regulatoriske krav, hvis produktet er medicinsk udstyr.

Valget af teknologi har også regulatoriske konsekvenser. Biblioteker og frameworks er SOUP (Software of Unknown Provenance) efter IEC 62304 og skal opføres på en liste, vurderes og holdes opdateret. Vælg velunderstøttede værktøjer og en hostingløsning i EU, hvis I behandler helbredsoplysninger.

Fase 3: MVP med kvalitetssystemet på plads

En MVP i life science er den mindste version, der kan bevise den kliniske eller forretningsmæssige værdi, og som er bygget, så den kan blive til det regulerede produkt. “Move fast and break things” virker ikke, når patientsikkerheden står på spil, men det gør korte iterationer med dokumentation.

Hvis produktet er medicinsk udstyr, skal kvalitetssystemet være der fra starten:

• Design controls efter ISO 13485: input, output, verifikation og validering.
• Softwarelivscyklus efter IEC 62304 og risikostyring efter ISO 14971.
• Sporbarhed fra brugerbehov over krav og risici til test.
• Ændringsstyring, så ændringerne i hver version kan forklares.

Agil udvikling og regulering passer fint sammen, når Definition of Done indeholder dokumentationen, og test kører automatisk i CI.

Vær opmærksom på, at en MVP uden CE-mærke ikke må bruges til et medicinsk formål på patienter uden for en klinisk afprøvning. En klinisk afprøvning kræver tilladelse fra Lægemiddelstyrelsen og en etisk vurdering. Test af brugervenlighed og test med syntetiske data kan du udføre uden denne tilladelse og vurdering.

Fase 4: teknisk dokumentation og CE-mærkning

CE-mærkning af medicinsk software kræver teknisk dokumentation efter MDR’s bilag II og III og for klasse IIa og derover en vurdering hos et bemyndiget organ. Dokumentationen beskriver produktet, designet, risikostyringen, verifikation og validering, den kliniske evaluering og brugsanvisningen.

Til valideringen hører typisk:

• Valideringsplan og -rapport med testresultater.
• Sporbarhedsmatrix fra krav til test.
• Summativ evaluering af brugervenlighed.
• Klinisk evaluering, der viser, at produktet har den kliniske effekt, du angiver.

Du vælger selv det bemyndigede organ. Kendte organer, der er udpeget under MDR, er fx TÜV SÜD, BSI, DNV, SGS og DEKRA. Tjek altid i EU’s NANDO-database, at organet er udpeget til netop din type udstyr. Kapaciteten hos organerne er begrænset, så tag kontakt tidligt. Et MDR-certifikat gælder i op til fem år.

Hvad koster det at udvikle medicinsk software?

Hos bon.do lander en fokuseret MVP typisk på 30.000–150.000 DKK, og en kompleks eller reguleret platform fra 250.000 DKK, leveret i faser, som på vores prisside. Beløbene dækker udviklingen. De regulatoriske omkostninger kommer oveni og varierer meget med klasse og produkt.

Se også vores guide til, hvad en app koster.

Hvordan finansierer man medicinsk software i Danmark?

De fleste life science-startups finansierer rejsen med en blanding af offentlige midler og privat kapital. Bind gerne finansieringsrunderne til regulatoriske milepæle, fx klassificering, MVP og CE-mærke, så investorerne kan se, hvad pengene skal bruges til.

• Innovationsfonden: Ifølge Innovationsfonden støtter InnoBooster udviklingsprojekter i små og mellemstore virksomheder med 200.000 kr. til 5 mio. kr. og dækker op til 35 % af projektets omkostninger.
• EIFO (Danmarks Eksport- og Investeringsfond): Den tidligere Vækstfond er fra 2023 en del af EIFO, som tilbyder lån og medinvestering.
• EU: EIC Accelerator under Horizon Europe støtter deep tech-virksomheder med tilskud og egenkapital.
• Private investorer: Business angels og nordiske venturefonde med fokus på sundhed og medtech.

Tjek altid de aktuelle opslag og beløb hos den enkelte ordning.

Lancering og drift efter CE-mærket

CE-mærket giver adgang til EU- og EØS-markedet, men arbejdet stopper ikke ved lanceringen. Som fabrikant skal du overvåge produktet efter markedsføring, indberette alvorlige hændelser til Lægemiddelstyrelsen og for klasse IIa og derover lave periodiske sikkerhedsopdateringsrapporter.

• Pilotsteder. Start med to eller tre klinikker eller afdelinger, træn brugerne grundigt, og saml data om brug og fejl.
• Salg. Salg til det offentlige sundhedsvæsen tager tid og går ofte gennem udbud. Tag højde for lange salgscyklusser i planlægningen.
• Udvidelse. De nordiske lande er et naturligt næste skridt. USA kræver en separat godkendelse hos FDA.

Sådan vælger du en udviklingspartner

De fleste life science-startups har ikke et fuldt softwareteam fra start, og partneren afgør, hvor fleksibel roadmappen er bagefter. Stil disse spørgsmål:

• Hvilke projekter med medicinsk software har I leveret, og kan vi tale med kunden?
• Hvordan arbejder I med IEC 62304, ISO 14971 og jeres eget eller vores kvalitetssystem?
• Hvilket materiale leverer I til den tekniske dokumentation?
• Hvordan håndterer I ændringsstyring og validering?
• Hvem ejer koden, data og dokumentationen? Læs mere om ejerskab af software.
• Hvad sker der efter lanceringen: drift, opdateringer og support?

Hvad bon.do gør

Vi er et softwarehus i Svendborg, der bygger regulerede apps, platforme og forbundne enheder. Kirsten har mere end ti års erfaring med farmaceutisk kvalitetssikring, og Morten har mere end 22 års erfaring med at bygge software. Vi byggede blandt andet backenden til et CE-mærket medicinsk udstyr, hvor hvert resultat kan spores tilbage til den rå måling.

Hos os ejer du koden, data og IP fra dag ét. Vi arbejder efter ISO 13485-principper og leverer det materiale, der skal indgå i din tekniske dokumentation.

Næste skridt

Start med to ting: afklar klassen, og beskriv det mindste produkt, der kan bevise værdien. Vil du have hjælp til begge dele, kan du booke en gratis projektvurdering. Du får et konkret roadmap, et overblik over risici og et skriftligt prisestimat uden forpligtelse.