Læs guiden her - Medico Innovation

DANSK 

VERSION 1.1 

Medico apps 

A practitioner’s guide 

Af 

Uri Duvald Andersen 

Jens Peter Andersen 

Martin Stenfeldt 

Redaktion 

Morten Gjøl 

www.medico-innovation.dk

DANSK 

VERSION 1.1 

Medico apps 

A practitioner’s guide 

Af 




Redaktion 

Morten Gjøl 

www.medico-innovation.dk 

Medico apps – A practitioner’s guide. 

Dansk version 1.1, januar 2012. 

Udgivet af MEDICO INNOVATION. 

ISBN 978-87-995083-0-3 

Gengivelse af denne udgivelses indhold eller dele deraf er ikke tilladt uden forudgående skriftlig aftale med MEDICO INNOVATION. 

Guiden kan downloades gratis på www.medico-innovation.dk

1. Indledning 4 

2. Formål og afgrænsning 6 

3. QA og regulatory for medicoindustrien 7 

Formålet afgør om det er medicinsk udstyr 8 

Markedsføring og CE-mærkning af medicinsk udstyr 8 

Lovgivningens formål 9 

Direktiver 10 

Klassificering af udstyr og krav til kvalitetsikring 10 

De væsentlige krav og harmoniserede standarder 11 

USA – Federal Drug Administration (FDA) 13 

4. Cases 15 

TV2 case: TV2 førstehjælp 16 

AMBU case: Airway Management E-learning 19 

MIM software case: Mobile MIM 22 

5. Før udviklingsprocessen - Afdækningsfasen 25 

Forretning 26 

Formål 26 

Målgruppe 27 

Teknologi 28 

Ressourcer 30 

Jura 31 

6. Udviklingsprocessen - En fremgangsmåde i 5 trin 33 

Specifikation 33 

Design 35 

Udvikling 36 

Test 40 

Lancering 41 

7. Efter udviklingsprocessen Markedsføring og drift 45 

Markedsføring 46 

Opdatering 47 

Videreudvikling 47 

8. Efterord 48 

9. Begreber og terminologier 49 

10. Om folkene bag guiden 54 

MEDICO APPS - A PRACTITIONER’S GUIDE 

3

1. 

Indledning 

Stort set alt medico teknologi gennemgår i øjeblikket en elektronisk forvandling og udvikling. Efterspørgslen 

efter sundheds-IT/e-health/telemedicin stiger kraftigt, og udbredelsen af mobile enheder 

stiger ligeledes støt. Når e-health og mobile enheder bringes sammen, opstår der et kæmpe potentiale 

for dem, som forstår at udnytte muligheden. 

Figur 1. 30% af alle smartphone-brugere forventes i 2015 at benytte e-health applikationer. 

Der ligger i krydsfeltet mellem appudvikling og medicoteknologi mange muligheder for at udvikle en 

helt ny dansk niche-kompetence, som efter vores mening bør opsøges aktivt. Danmark har allerede et 

godt internationalt ry i medico-branchen, og det kan vi udnytte ved at tænke ud af boksen og arbejde 

tværdisciplinært i udviklingen af innovative og værdiskabende medico apps. Derfor har MEDICO IN- 

NOVATION taget initiativ til at udgive denne guide, der forhåbentlig vil være både en inspiration og et 

praktisk værktøj. 


4

MEDICO INNOVATION er et offentligt-privat initiativ, der arbejder på at styrke rammerne for innovation 

i den medico-tekniske branche i Danmark. Dette sker gennem igangsættelsen af offentligt-private innovationspartnerskaber, 

kompetenceudvikling og dannelsen af faglige netværk. Således har Medico 

Innovation taget initiativ til at etablere interesse-netværket ”Devices n’ Apps” (DNA), som har til formål 

at dele viden om udvikling af medico-tekniske apps mellem virksomheder, forskere, sundhedsfagligt og 

teknisk personale samt IT folk med interesse for emnet. I dette forum opstod tanken om at skrive en 

praktisk anlagt guide om udviklingen af medico apps. 

DNA netværket har i skrivende stund besluttet at fortsætte i 2012 og arbejde på at samle kompetencer 

i hele landet på tværs af discipliner. I MEDICO INNOVATION støtter vi op om dette initiativ og hjælper 

gerne alle, der går med en god idé til en banebrydende ny medico app, videre med relevante kontakter 

inden for industrien, sundhedsvæsenet eller de tekniske videnskabers verden. 

MEDICO INNOVATION takker forfatterne for deres kompetente bidrag og følgende personer for deres 

aktive indsats med at pudse guiden af: Jacob Schlundt for dine drilske spørgsmål, konstruktive feedback 

og altid gode humør. Karsten Dyresberg for dit bidrag med praktiske erfaringer. Thomas Tscherning for 

konstruktiv korrekturlæsning og gode bidrag. Rikke Arendt Christiansen for kyndig og konstruktiv bistand 

i korrekturlæsning af det regulatoriske afsnit, samt ikke mindst AMBU, TV2 og MIM Software for at stille 

op til interviews om jeres praktiske erfaringer med medico app udvikling. 

Vi har lært meget på denne rejse og håber, det vil komme vores læsere til gode på en konstruktiv måde. 

God fornøjelse 


Director, MEDICO INNOVATION 


5

2. 

Formål og afgrænsning 

Formål & målgruppe 

Denne guide er henvendt til medicinalbranchen. Den er primært skrevet til medico virksomheder, 

sundhedsfagligt og -teknisk personale, forskere, IT folk og app-udviklere, der ønsker at øge forståelsen 

for udviklingen af mobile applikationer (apps) inden for medico-området. 

Ønsket med guiden er at inspirere og motivere udviklingen af medico apps ved at synliggøre værdiskabelsen 

i apps og lette arbejdet ved at dele erfaringer fra andre, der allerede har gjort det. 

Målet har været at opstille en praktisk guide. Den har fra starten haft en praktisk vinkel og beskæftiger 

sig med proces og retningslinjer for udvikling af apps, som brugeren interagerer med. Udviklingsprocessen 

har vi opdelt i et før-under-efter forløb, hvor faserne i guiden gennemgås med centrale overvejelser, 

tips og tjeklister. 

Herudover omhandler guiden områder særlig relevant for medicobranchen. Herunder det regulatoriske 

område (RA), kvalitetssikring (QA), konkrete medico cases samt immaterielle og materielle rettigheder 

(IPR). 

Afgrænsning 

Det har været fristende at inkludere business-cases, innovationsteori, tendenser og statistik mv. i guiden. 

Samtidig har det også været et bevidst valg at udgive guiden inden for en givet tidsramme og fokusere 

på, hvordan man kommer godt i gang med app-udvikling. Det betyder, at guiden koncentreres om udvikling 

af medico apps og derfor ikke beskæftiger sig med: 

! Idéudvikling / -kvalificering 

! Teknologi i relation til konkret udvikling. Vi behandler ikke værktøjer til udvikling, eller hvordan man 

udvikler en app. 

! Specifikke tekniske udfordringer i relation til apps. Dette er ikke en manual. 

! Apps, der rummer spil, håndbøger, brugsanvisninger, opslagsværker el. simple handlingsanvisninger. 

! Mobile websites, responsive webdesign og andre teknologier til håndholdte enheder. 

MEDICO APPS - A PRACTITIONER’S GUIDE 6

3. 

QA og regulatory for medicoindustrien 

I dette kapitel ser vi nærmere på kvalitetssikring (Quality Assurance; QA) og de regulatoriske krav gældende 

for apps, der kan betegnes som medicinsk udstyr. Det er her, vi oplever den største forskel mellem 

”almindelig” appudvikling og appudvikling til medicinsk udstyr. QA og RA er også det emne, der har haft 

størst interesse i DNA netværket. Målet med afsnittet er at afmystificere de forskellige lovgivningsmæssige 

krav og vise vej gennem denne del af processen. 

Software og herunder apps, der betegnes som medicinsk udstyr, skal opfylde en række lovgivningsmæssige 

(regulatoriske) krav. Alt efter, hvordan udstyret klassificeres, er kravene mere eller mindre omfattende. 

Klassifikationen tager udgangspunkt i en risikobetragtning i forhold til bruger- og patientsikkerhed. 

Høj risikoklasse medfører omfattende regulatoriske krav til dit udstyr. Lav risikoklasse medfører mindre 

omfattende krav til udstyret fra myndighedernes side. Her er det værd at bemærke, at medicinsk udstyr 

omfatter alt lige fra elastikbind og vatpinde over høreapparater, pulsmålere til ultralydsskannere. 

De enkelte lande opererer med forskellige klassificeringssystemer, som har mange lighedspunkter men 

desværre også væsentlige forskelligheder, og der er ingen vandtæt omsætningstabel fra det ene system 

til det andet. Heldigvis er det sådan, at det samme klassificeringssystem anvendes inden for hele EU. 

USA har sit eget system. Det samme gælder for væsentlige lande som Kina, Japan og Brasilien. Software 

kan være medicinsk udstyr eller indgå i det på flere måder: 

1. Den kan være et tilbehør til medicinsk udstyr, som ikke er software. Fx et program som man bruger til 

indstille et høreapparats forstærkning af lyden, så den bliver tilpasset den aktuelle bruger. Softwaren 

skal i tilfælde som disse betragtes som medicinsk udstyr. 

2. Den kan være medicinsk udstyr i sig selv. Fx beslutningsstøtte software til at fastlægge en diagnose. 

3. Den kan være inkorporeret i det medicinske udstyr, f.eks. som indlejret software. I denne guide 

vil denne type af software ikke blive taget i nærmere betragtning, idet eksekveringsenheder som 

smartphones og tablets typisk ikke bliver leveret som medicinsk udstyr. 

Apps vil derfor være stand-alone software som eksekveres på en enhed, der har en mere generel specifikation 

end medicinsk udstyr. Det samme gælder for internettet. I det efterfølgende vil vi betragte 

disse komponenter som infrastruktur, som ikke skal godkendes som medicinsk udstyr. Dette fritager 


7

dog ikke fabrikanten fra at lade infrastrukturen ude af betragtning, når appen udvikles. Det samlede 

system skal være effektivt og sikkert. 

En medicoapp adskiller sig fra medicinsk udstyr i klassisk forstand i dens afgrænsning som medicinsk 

udstyr ved ikke på forhånd at være fast defineret. Hvis man fx betragter to stykker medicinsk udstyr; En 

operationsskalpel og en app, anvendt på en tilgængelig håndholdt enhed med tilslutning til en server 

på internettet, så er det for skalpellens vedkommende på forhånd lettere at definere det medicinske 

udstyrs fysiske afgrænsning, end det er for appen. 

Godkendelsesmæssigt vil det da også være meget op af bakke, hvis man eksempelvis skal have internettet 

godkendt som en del sit medicinske udstyr! Derfor er det afgørende, at der indføres en hensigtsmæssig 

arkitektur og et softwaremæssigt design, så det er veldefineret, hvilke moduler og enheder, der er del 

af det medicinske udstyr, og hvilke der ikke er det. 

Formålet afgør om det er medicinsk udstyr 

Medicinsk udstyr skal anvendes til det, det er beregnet til. Det er fabrikantens ansvar at specificere, 

hvad udstyret er beregnet til. På den anden side kan fabrikanten i hovedreglen ikke stilles til ansvar, hvis 

udstyret anvendes på en måde, der ligger uden for denne specifikation. 

Et af de mest centrale begreber i forhold til lovgivningen er det medicinske udstyrs intended use (tiltænkte 

anvendelse). Som fabrikant af medicinsk udstyr skal man også tage hensyn til alternative anvendelser, 

som ikke er tiltænkte, men som er forudsigelige. Det gælder især med hensyn til hvilke skademæssige 

konsekvenser, den alternative anvendelse kan have for patient og bruger. Den tiltænkte anvendelse er 

afgørende for, om der overhovedet er tale om medicinsk udstyr. Hvis ikke, kan man spare de omkostninger, 

der vil medgå til myndighedsgodkendelsen af det. 

Definitionen af medicinsk udstyr 

Ethvert instrument, apparat, udstyr, software, materiale eller anden genstand anvendt alene eller 

i kombination, herunder software, som af fabrikanten er beregnet til specifik anvendelse til 

diagnostiske og/eller terapeutiske formål (se Definitioner i ordlisten), og som hører med til korrekt 

brug heraf, og som af fabrikanten er beregnet til anvendelse på mennesker med henblik på: 

! Diagnosticering, forebyggelse, overvågning, behandling eller lindring af sygdomme 

! Diagnosticering, overvågning, behandling, lindring af eller kompensation for skader eller handicap 

! Undersøgelse, udskiftning eller ændring af anatomien eller en fysiologisk proces 

! Svangerskabsforebyggelse 

og hvis forventede hovedvirkning i eller på det menneskelige legeme ikke fremkaldes ad farmakologisk, 

immunologisk eller metabolisk vej, men hvis virkning kan understøttes ad denne vej. 

Markedsføring og CE-mærkning af medicinsk udstyr 

Hvis den tiltænkte anvendelse ikke ligger inden for eller har en mere general karakter end beskrevet 

i ovennævnte definition, er der ikke tale om medicinsk udstyr. Tag fx et videokamera, der sat op på 

en operationsstue med det formål, at en ekstern læge kan fjerneovervåge operationer. Formålet med 

kameraet vil da sandsynligvis have noget med behandling og overvågning at gøre. Men det gør ikke 

videokameraet til medicinsk udstyr, idet det jo er et videokamera markedsført til generelle billedoptagelses 

formål. Det bliver først medicinsk udstyr i det øjeblik fabrikanten specificerer det som sådan, 


8

altså når det ligger inden for ovenstående definition. Her er det afgørende, hvad der påstås fra fabrikantens 

side i forbindelse med markedsføringen. Hvis det fx påstås, at udstyret er specielt velegnet til 

fjernovervågning under en operation, så kan bordet fange og fabrikanten er forpligtet til at CE-mærke 

udstyret som medicinsk udstyr (se senere). 

Det er ikke svært at overføre ovenstående eksempel til en app på en mobil-enhed med et kamera. Hvis 

appen har den egenskab, at den kan sende et billede taget med kameraet til lægen, så er der ikke tale 

om medicinsk udstyr. Men hvis den også kan analysere billedet og generere en diagnose på f.eks. en 

hudsygdom, så er der tale om medicinsk udstyr. 

Markedsføring er et centralt og skelsættende begreb i lovgivningen vedr. medicinsk udstyr. Markedsføring 

finder sted i det øjeblik fabrikanten stiller sit udstyr til rådighed for andre. Eksempelvis ved distribution 

af en app. Det er dog lovligt, at stille sin app til rådighed til demonstrationsformål m.m., men det skal 

tydelig fremgå, at den ikke må anvendes som medicinsk udstyr. 

Hvis man har CE-mærket sin app efter forudgående myndighedsgodkendelse, må man markedsføre den 

over hele EU. De enkelte lande kan dog stille krav om oversættelse. Fx ledetekster i skærmbilleder og 

andet tekstmateriale, der er nødvendigt for, at man kan anvende appen, som medicinsk udstyr på den 

tiltænkte måde. Danmark er et af de lande, som kræver oversættelse. Derfor er det værd at overveje 

en sprogvalgs option i appen, hvis den skal distribueres inden for EU’s område. 

CE-mærkning giver kun lov til at markedsføre inden for EU. Man har altså ikke lov til, at stille appen 

til rådighed inden for fx USAs grænser medmindre man har fået grønt lys fra FDA, som forvalter USAs 

lovgivning indenfor området. 

EU har truffet forholdsregler mht. markedsovervågning således, at medicinalpersoner og hospitaler 

har pligt til indberetning, hvis udstyret svigter, således at det forårsager død eller alvorlig forværring 

af patientens eller brugerens helbredstilstand. Tilbagetrækning af appen fra markedet kan være konsekvensen 

af dette. 

Den person, der er ansvarlig for markedsføringen skal registreres hos den kompetente myndighed. Det 

vil i Danmark sige Lægemiddelstyrelsen. 

Bemærk at lovgivningen gælder fabrikanter af medicinsk udstyr. Hvis man fx laver softwareudvikling for 

ét hospital markedsfører man ikke nødvendigvis medicinsk udstyr. 

Lovgivningens formål 

Den centrale sigte med lovgivningen, uanset hvilket land det drejer sig om, er at få dokumenteret: 

! Sikkerhed for udstyrets ydeevne 

! Beskyttelse af bruger og patient mod skader, som kan forvoldes af udstyret. 

Myndighederne forlanger dokumentation for udstyrets ydeevne, som matcher state-of-the-art, samt at 

den resterende risiko, der måtte være forbundet med at anvende udstyret, skal være minimeret mest 

mulig og ligge inden for et acceptabelt niveau i forhold til udstyrets tiltænkte anvendelse. 

Hvert land har sin egen lovgivning inden for området, som har store ligheder og måske også store 

forskelligheder. I denne guide vil lovgivningen indenfor EU blive brugt som det gennemgående og med 

referencer til lovgivningen i USA, hvor denne afviger i forhold hertil. 


9

Direktiver 

Indenfor EU defineres den lovgivningsmæssige ramme for det medicinske udstyr, man er ved at udvikle, 

af det direktiv, som udstyret henhører under. Det kan være et af følgende: 

! Medico-direktivet: Rådets Direktiv 93/42/EEC om medicinsk udstyr og Rådets Direktiv 2007/47/EC. 

! Rådets Direktiv 90/385/EEC om aktivt, implantabelt medicinsk udstyr og Rådets Direktiv 2007/47/ 

EC. 

! Rådets Direktiv 98/79/EØF af 27. oktober 1998 om medicinsk udstyr til in vitro-diagnostik. 

Noget at det første, man skal gøre sig klart er, hvilket direktiv udstyret hører under. Direktiverne er alle 

implementeret i de nationale lovgivninger i EU. Direktivet vedr. aktivt, implantabelt udstyr kan være 

relevant i forhold til software, hvis den er tilbehør til fx en pacemaker. Selv om software er aktivt udstyr 

kan det næppe være medicinsk udstyr i sig selv. En app kan næppe implanteres direkte i den menneskelige 

krop. Software kan være inkorporeret i det aktive implantat. Bemærk, at det, der gør et implantat 

aktivt, er, at det har sin egen iboende energikilde, som ikke hidrører fra kroppen. 

In vitro-diagnostik direktivet kan appen være omfattet af, som tilbehør til medicinsk udstyr, der anvendes 

på prøvemateriale, som er udtaget af det menneskelige legeme. In vitro diagnostisk udstyr anvendes 

aldrig direkte på mennesker. 

CE-mærket på udstyret angiver, at udstyret ikke blot overholder et af de ovennævnte direktiver men 

alle relevante direktiver. Fx direktivet om beskyttelse af persondata og radio teleterminal direktivet. 

Myndighederne i de enkelte EU-medlemslande er forpligtet til at samarbejde, så direktiverne anvendes 

på ensartet måde. Det vil i reglen være Medico-direktivet, der skal bringes i anvendelse. Derfor handler 

resten af guiden om dette. 

Klassificering af udstyr og krav til kvalitetsikring 

I EU opdeles medicinsk udstyr i en af følgende produktklasser: 

! Klasse I er den produktklasse, hvor der er mindst risiko for patient og bruger forbundet med anvendelsen 

af det medicinske udstyr. For denne klasses vedkommende skal fabrikanten indsende en 

overensstemmelseserklæring til det kompetente organ i det land (i Danmark Lægemiddelstyrelsen), 

hvor produktet skal CE-mærkes, hvorefter mærkning er tilladt. Det er ikke nødvendigt med et bemyndiget 

organs medvirken for CE-mærke produkter i denne klasse medmindre, der tale om udstyr 

med målefunktion eller udstyr som bliver markedsført i steril tilstand. Apps med målefunktion er en 

realistisk mulighed man som udvikler skal have i mente: Er der tale om målefunktion eller tendensindikation. 

Der er omkostninger vedr. godkendelsesforløbet til forskel. 

! Klasse IIa omfatter fx aktivt terapeutisk udstyr som høreapparater og diagnostisk udstyr til rutine 

overvågning og selvmonitorering vitale fysiologiske processer blodtryk og hjerterytme. En blodstryksmåler 

til hjemmebrug er et godt eksempel. Apps kan tilhøre denne klasse, hvis de kan stille en 

diagnose. Denne produktklasse kræver et Bemyndiget organs medvirken for, at man må markedsføre 

og CE-mærke udstyret. 

! Klasse IIb. Denne produktklasse kræver, at et Bemyndiget organ fører tilsyn med konstruktion og 

fremstilling. Denne produktklasse omfatter fx diagnostisk udstyr til ikke-rutinemæssig overvågning. 

Udstyr i denne klasse skal CE-mærkes. 

! Klasse III omfatter de mest risikoforbundne udstyrstyper som fx implantater. Et Bemyndiget organs 

medvirken kæves selvsagt også her. Udstyr i denne klasse skal CE-mærkes. 

EU har defineret et sæt af vejledninger, som er nyttige. Software er defineret som aktivt udstyr og skal 

derfor klassificeres efter de tilhørende regler. For alle typer af udstyr skal der laves en overensstemmelseserklæring 

som beskrevet i Medico-direktivet. Udstyrsklassen fastlægges ved en forhandling mellem 


10

fabrikanten og et Bemyndiget organ – fx Dansk Godkendelse af Medicinsk Udstyr (DGM). Ved tvister er 

det det kompetente organ, der afgør sagen. Undtagelsen er klasse I udstyr, som før nævnt. 

Klassificering af medico apps 

Ved klassificering af appen skal man være meget opmærksom på følgende (jf. Medico-direktivet): 

Edb-programmel, som styrer en anordning eller påvirker anvendelsen af en anordning, klassificeres 

automatisk i samme klasse som den pågældende anordning. 

Bemærk at der er to scenarier: 

! Appen styrer noget medicinsk udstyr. Det kunne være en app, der tilpasser et høreapparat. Appen 

bliver da medicinsk udstyr af samme klasse - i dette tilfælde IIa. 

! Appen påvirker anvendelsen af noget medicinsk udstyr. Dette er måske den situation, der kræver 

mest omtanke. Det kunne være en arbejdsgang, der bliver omlagt pga appen, der gør den til medicinsk 

udstyr og dermed påvirker anvendelsen af noget medicinsk udstyr… 

I skrivende stund er EU undervejs med en klassificeringsguide for stand-alone software. Det er bl.a. lagt 

op til, at software kan klassificeres på modul niveau. Guiden kommer også til at indeholde regler for, 

hvornår software skal betragtes som medicinsk udstyr, selvom det er integreret med anden software, 

der er medicinsk udstyr. 

Nedbrydningen i moduler bør i så fald udføres på softwareniveau, idet nogle moduler da sikkert kan lades 

ude af betragtning som medicinsk udstyr. De resterende vil opdeles i risikoklasser på software niveau 

jf. den harmoniserede standard DS/EN 62304:2006. Hvis ikke man får lavet denne opdeling risikerer 

godkendelsesprocessen at blive unødig omstændelig, derfor: Design for safety - design for approval! 

De væsentlige krav og harmoniserede standarder 

EU har opstillet en række såkaldte væsentlige krav (essential requirements) som al medicinsk udstyr 

skal opfylde. Disse er en del af Medico-direktivet. Kravene er for manges vedkommende formuleret på 

et forholdsvis overordnet niveau. Men det er netop disse krav udstyret skal opfylde set fra myndighedernes 

side. 

Når man udvikler software er der et sæt af standarder som typisk kommer i spil: 

Standard Titel 

EN ISO 13485:2003 Medical devices - Quality management systems - Requirements for regulatory purposes 

DS/EN ISO 14971:2009 Medical devices - Application of risk management to medical devices 

DS/EN 62304:2006 Medical device software - Software life-cycle processes 

EN 62366:2008 Medical devices - Application of usability engineering to medical devices 

EN 980:2008 Symbols for use in the labeling of medical devices 

EN 1041:2009 Information supplied by the manufacturer of medical devices 

DS/EN ISO 14155:2011 Clinical investigation of medical devices for human subjects - Good clinical practice 

Udstyret skal konstrueres og fremstilles med sikkerhed for øje - princippet om sikkerhedsintegration - i 

videst mulig omfang. Alarmer skal integreres i udstyret i det omfang, at konstruktionen ikke kan gøres 

100% sikker. 


11

Ovenstående kræver en effektiv risk management proces i udviklingsforløbet. Dette gælder også for det 

endelige udstyrs betjeningsegenskaber, hvor risikoen for betjeningsfejl, der kan forvolde personskade, 

skal minimeres mest muligt. I denne forbindelse skal der tages hensyn til brugernes teknologiske viden. 

Det er således et krav, at en app har et sikkert betjeningskoncept, hvor der er taget hensyn til brugernes 

forudsætninger: 

Det skal være klart angivet på anordningerne, hvorledes betjeningspaneler og indikatorer virker. 

On-going risk management er motoren, der driver dette. 

Den anførte ydeevne skal også dokumenteres. Hvis appen fx bruger det indbyggede kamera i den 

håndholdte enhed til at tage et billede af fx et modermærke eller øjet og derudfra giver et bud på en 

diagnose, så skal det dokumenteres med hvilken statistisk sikkerhed, dette sker. 

Der skal gennemføres klinisk evaluering gennem hele produktets livscyklus, hvilket betyder, at kliniske 

data skal underbygge, at udstyret har den ydeevne, som er specificeret af fabrikanten. I den forbindelse 

skal der: 

! Gennemføres et litteratur-studium, som dokumenteres i den kliniske evalueringsrapport. Litteraturstudiet 

baseres på tidligere offentliggjorte og/eller egne undersøgelser. 

! Om nødvendigt gennemføres en klinisk afprøvning, hvis datagrundlaget ikke er tilstrækkeligt. Det er 

vigtigt at få klarlagt i starten af produktudviklingsprojektet, idet klinisk afprøvning kræver forholdsvis 

store ressourcer til planlægning og afvikling. 

! Løbende indsamles kliniske data om udstyrets anvendelse over hele dets livscyklus. 

Det kliniske evaluering spiller sammen med risk management processen: Risici evalueres som en del af 

den kliniske evaluering og på den måde identificeres risici i den kliniske evaluering. 

Det skal sikres, at appen ikke ændrer egenskaber undervejs i processen fra download til installation på 

det håndholdte device og videre frem. En app er i sin natur som medicinsk udstyr, som skal anvendes 

sammen med andet udstyr. Her er kravet systemet betragtet som en enhed skal være sikkert. Hvis fx 

den håndholdte enhed og appen markedsføres samlet, er der tale om en systempakke og kravene for 

sådanne skal være opfyldt. 

Udstyr med målefunktion skal overholde særlige krav mht. stabilitet, nøjagtighed og tolerancer samt 

ergonomiske principper. Kravene til sidstnævnte er defineret i EN 62366:2008. Den udviklede app skal 

have en kvalitet, der matcher formålet. Der betyder bl.a., at softwaren skal håndtere fejlsituationer på 

en måde, så de hermed forbundne risici begrænses mest muligt. En medico app skal: 

valideres i overensstemmelse med det aktuelle tekniske niveau, idet der tages hensyn til principperne 

for udviklingslivscyklus, risikostyring, validering og verificering. 

For at matche det krav anbefales det, at man opfylder kravene i EN 62366:2008, som er den mest software 

specifikke af de harmoniserede standarder. Den har veldefinerede krav til udviklingscyklus og risk 

management samt verifikation og validering. 

Udstyr, der overvåger en eller flere kliniske parametre, skal være forsynet med ’passende’ alarm systemer. 

En app, der kører på udstyr, der er afhængig af en energikilde, det være: 

! Intern i form af et batteri. Hvis det er tilfældet skal der være en batteriindikator 

! Ekstern i form at net-tilslutning. Hvis sådant udstyr er afgørende for patientens sikkerhed, skal der 

være indbygget alarmsystem. 


12

Det medicinske udstyr skal leveres med de oplysninger, der skal til for at det kan anvendes sikkert og 

korrekt. Det skal også være muligt at spore udstyret tilbage til dig som fabrikant. Der skal også følge en 

brugsanvisning med udstyret, hvilket der dog kan ses bort fra, hvis udstyret er i klasse I eller IIa og det 

kan betjenes sikkert uden anvisninger. Hvis man udvikler en medico app kan følgende være påkrævet: 

! Batchkode, hvilket svarer til den installerede apps buildnummer. Angives med symbolet LOT. 

! Hvis appen er bestemt til klinisk afprøvning (se Definitioner) skal det fremgå. 

! Advarsler og forholdsregler. 

! Fremstillingsår. Angives med symbolet for fremstillingsår. 

! Oplysning om hvilke enheder appen kan afvikles sikkert på. De er nok, at angive deres karakteristika. 

Formålet er at opnå en sikker kombination. 

! Oplysninger om hvordan brugeren sikrer sig, at appen er installeret korrekt samt vedligeholdelses 

og evt. kalibreringsforskrifter. 

De harmoniserede standarder EN 1041:2009 og EN 980:2008 definerer forventningen til ovennævnte 

type af information og anvendelsen af symboler. 

USA – Federal Drug Administration (FDA) 

Som nævnt har USA sit eget system til godkendelse af medical devices – inkl. apps som er inden for 

området. Da FDA (sundhedsmyndighederne i USA, der godkender udstyr og medicin) kun har publiceret 

draft guidelines (det vageste første udspil til en bekendtgørelse på det specifikke område omhandlende 

apps; se reference nedenfor), er der en del spekulationer om, hvordan FDA vil behandle specifikke 

eksempler. Indtil der er lagt en juridisk (regulatorisk) standard, må man gå ud fra de (få) cases, der allerede 

er behandlet samt anvende beskrivelsen ovenfor (fra EU) som benchmark. Nedenfor følger en 

del figurer, der forklarer behandlingen af apps i USA. 

Figur 2. Alt efter hvor stor en risikoen for skader en bruger af appen (patienten) udsætter sig selv og andre for (inkl. ved selv-forskyldt 

fejlbrug af appen), bliver appen (+evt. device) klassificeret, og skal udvise grader af validerende studier (ref. MobiHealthNews.com). 


13

Figur 3. Den (potentielle) risiko ligger på et kontinuum, og bestemmes bedst ved samarbejde med rådgivere på området – og evt. 

ved diskussion med FDA sent i udviklingsprocessen (ref. MobiHealthNews.com). 

Figur 4. ISO er en del af kvalitetskontrollen, men FDA går ud over disse krav ved at kræve dokumentation for validering 

(fx er den hævdede effekt dokumenteret?, er der et system til at tage hånd om Adverse Events? (AE, bivirkninger), etc) 

(ref. MobiHealthNews.com) 


14

4. 

Cases 

Da et af formålene med denne guide er at dele erfaringerne fra 

nogle af dem, der allerede har udgivet medico-app, følger her tre 

cases på apps udgivet inden for det seneste. 


15

Case 

TV2 Førstehjælp 

Navn TV2 Førstehjælp 

Udgiver TV2 

Platforme iPhone + Android 

Udgivet Oktober, 2011 

Målgruppe Den brede befolkning. B-t-C 

Downloads til d.d. 20.000 stk. 

Samlet budget Omk. 300.000 kr. 

Udviklingstid Ca. 4 mdr. 

Største udfordring Kvalitetssikring af de sidste 2%, der gør 

appen fuldstændig fejlfri, hvilket er nødvendigt 

for apps, der handler om liv og død. 

Største læring Medical apps kræver mere QA. Derfor er 

tydelig definition af kvalitetskrav fra starten 

og et struktureret test set-up vigtigt. 

Bedste råd Hellere én funktionalitet, der sidder i 

skabet, end en masse, der virker halvt. 

Skabt for at redde liv 

TV2 er Danmarks største kommercielle public service tv-station med fem kanaler. Stationen har udgivet 

flere forskellige mobile applikationer fra events til nyheder, vejr mv. som en del af TV2s strategi om at 

være repræsenteret stærkt også på de digitale medier. 

I september 2011 blev den gribende dokumentarserie ”Tak fordi du reddede mit liv” lanceret. I serien 

møder man almindelige mennesker, der er trådt i karakter, når uheld har ramt tilfældige personer, de 

ikke kender. Mennesker med mod og hjerte på rette sted til at rede andre folks liv. 

I forbindelse med serien opstod med hjælp fra Tryg Fonden mulighed for at skabe en mobil applikation, 

der lagde sig op ad seriens tema om at redde liv. Grundidéen til den app, der senere skulle gå hen og 

blive appen for førstehjælp i Danmark, blev født. 

Appens idé er, at hjælpen skal være ét tryk væk, og allerede fra begyndelsen stod det klart, at ambitionen 

var at skabe en app, der kunne mere end de eksisterende førstehjælps apps på markedet. Som 

tv-station tænker man naturligt i billeder, og derfor blev video medtænkt fra starten. Det stod også klart, 

at siden appen drejede sig om liv og død, måtte det faglige indhold være i absolut top, baseret på den 

nyeste viden, og det måtte komme fra en ekspert på området. Derfor teamede TV2 op med overlæge 

og formand for Dansk Råd for Genoplivning Torsten Lauritsen med speciale i førstehjælp. Stationen 

vidste, at når de havde Danmarks førende læge på området med på holdet, ville appen blive bedre og 

opnå større troværdighed. 

Formål og succeskriterier 

Formålet med TV2 Førstehjælp var enkelt, selvom målgruppen var bred. Mange har på et eller andet 

tidspunkt modtaget undervisning i førstehjælp - og glemt det igen. Og endnu flere har måske aldrig 

lært det... 


16

Appen skulle gøre to ting: 

1) Være en her og nu guide i førstehjælp til folk, der stod i en ulykkessituation. 

2) Opkvalificere interesserede i førstehjælp, når de har tid, gennem instruktionsvideoer. 

Der blev ikke sat direkte succeskriterier op for appen, da den ikke havde et kommercielt sigte. På trods 

af dette var appen tre måneder senere downloadet 20.000 gange. 

Udviklingsprocessen 

Selve udviklingen og indholdsproduktionen blev gennemført af underleverandører, mens TV2 forestod 

projektledelsen. Underleverandørerne blev valgt efter sondering og ud fra deres kendskab til den tekniske 

løsning. 

Processens faser var flg.: 

1. Idékatalog 

Herunder: Idéudvikling, indsamling af viden og markedsresearch, kondensering af det væsentlige i 

ideerne, formulering af grundidé. 

2. Specifikation 

Herunder: Beskrivelse af appen og opstilling af præspecifikationer, indhentning af tilbud fra leverandører, 

tilpasning og organisering af funktionaliteter, opstilling af flowchart samt prototype og udarbejdelse af 

detaljeret kravspecifikation. Prototypen blev opbygget i Powerpoint. 

3. Artwork og design 

Herunder: Fastlæggelse af designmæssige retningslinjer (ej fancy), designoplæg, tilretning og godkendelse. 

4. Udvikling 

Herunder: Iterationer med feedback og tilretning, fejlbeskrivelser, udarbejdet på to platforme samtidig. 

5. Testforløb 

Herunder: Struktureret test set-up med afprøvning på egne testtelefoner. 

6. Lancering 

Herunder: On air promotion, PR-kit sendt ud til diverse medier. 

7. Drift 

Appens indhold er statisk, og der gøres ikke mere ved den pt. 

Udfordringer og læring 

TV2 største udfordring i produktionen var de mange iterationer, der var nødvendige for at sikre appens 

kvalitet og fejlfrihed. Projektet blev mere omfattende for alle interessenter, fordi kvalitetskravene ikke 

havde været klart defineret fra starten. Nul-tolerancen for fejl kostede ekstra ressourcer, og projektet 

blev forsinket ca en måned, hvilket fordyrede opgaven i både interne timer og eksterne omkostninger. 

Derfor var den største læring også, at medical apps kræver mere kvalitetssikring, end TV2 var vant til 

fra deres tidligere apps. Og mere kvalitetssikring kræver en mere struktureret styring af test set up. 

Herudover oplevede TV2, at Android platformen voldte særlige udfordringer pga de mange forskellige 

enheder, der er på markedet. Det faktum, at en applikation afvikles på en enkelt smartphone eller tablet 

giver ikke sikkerhed for at sikre, at appen virker på alle telefoner. 


17

Særlige forhold for medical apps 

TV2 vurderer, at særligt tre forhold gør sig gældende for medical apps: 

1. Der er ingen plads til fejl. 

2. Kvalitetsstyring er mere krævende. 

3. Appen skal være opdateret. 

Tre lavpraktiske råd 

1. Medico apps kan rumme mange fagudtryk. Tænk derfor i at formidling og terminologi skal matche 

målgruppen. 

2. Medico apps er meget følsomme for fejl. Sæt tid af til at teste. Det tager tid og kan være meget 

omstændeligt. 

3. Hellere én funktion, der sidder i skabet, end en masse, der virker halvt. 


18

Case 

Airway Management E-learning 

Navn Airway Management eLearning. 

Udgiver Ambu A/S. 

Platforme iPhone + iPad + Android. 

Udgivet Maj, 2011. 

Målgruppe Anæstesilæger, globalt. B-t-B. 

Downloads til d.d. 9.000 stk. 

Samlet budget Omk. 200.000 kr. 

Udviklingstid Ca. 5 mdr. 

Største udfordring Konvertering og nedskalering af større 

onlineplatform til et begrænset brugerinterface, 

der fungerer godt og intuitivt 

på en lille håndholdt enhed. 

Største læring Mobile applikationer er sit eget medie 

med eget forretningsmæssige formål, sin 

egen distribution og egen målgruppe. 

Tænkt og brugt rigtigt kan en app udgøre 

stor markedsføringsmæssig værdi og nå 

helt nye markeder og målgrupper. 

Bedste råd Opdateringsmuligheder er 

afgørende for appens levetid. 

Skabt for at uddanne læger 

Virksomheden Ambu blev stiftet i 1937, har hovedkvarter i Danmark, og er en global spiller med salg 

i ca. 80 lande. Ambus firmafilosofi har altid været at gøre livet lettere for læger og udvikle innovative 

produkter, der redder liv. Ambu A/S udvikler, producerer og markedsfører således diagnosticerings- og 

livredningsprodukter til hospitaler og redningstjenester. 

Ambu aScope er et innovativt produkt fra Ambu til placering af luftveje ifm. operationer for anæstesilæger. 

3% af alle patienter har nemlig det, der hedder svære luftveje, hvor lægerne traditionelt må 

bruge et langt og meget dyrt skop som hjælpemiddel. Problemet med de traditionelle skoper er, at de 

er dyre, der er få af dem på hospitalet, de skal repareres og rengøres, og at de skal transporteres rundt 

mellem operationerne. Det kan i yderste konsekvens betyde, at skoperne ikke er tilgængelige, og derfor 

udviklede Ambu et billigere engangs-scope. 

Fordi Ambu aScopet bruges på de sværeste 3% af patienter, er det et spørgsmål om liv og død, at apparaturet 

benyttes korrekt. Og derfor er træning af høj interesse hos lægerne. Tidligere blev uddannelsesopgaven 

løftet af Ambus sælgere, hvor udfordringen dog var, at lægerne ikke altid har mulighed 

for at være til stede eller har tid til at deltage i en trænings-session. Ambu vidste om anæstesilægerne, 

at de typisk har en del tid under operationerne til at videreuddanne sig. Samtidig ville Ambu gerne eksponere 

mere af deres kliniske dokumentation og økonomiske beregninger overfor lægerne. Desuden 

var formålet også at være medvirkende til, at flere anæstesilæger blev mere rutineret i håndteringen 

af vanskelige luftvejs-situationer, da de i praksis ikke forekommer særlig ofte. 

Ambu besluttede sig derfor for at udvikle en online trænings-platform på nettet, der var mere fleksibel 

end den personafhængige uddannelse samt en mobil app, der kunne imødekomme lægernes timeslots. 

Tanken var, at jo flere der er trænet, jo flere vil købe produktet. 


19

I maj 2011 lancerede Ambu deres Airway Management eLearning app til iPhone, iPad og Android som 

supplement til den eksisterende onlineplatform. Og det viste sig at være en ret god idé. Responsen på 

de håndholdte enheder blev nemlig ni gange så stor som på onlineplatformen. 


Appen er henvendt til anæstesilæger globalt. Onlineplatformen rummer mere interaktion og informationsdybde, 

mens appen, der er tilpasset i både form og indhold, handler om bekvemmelighed og 

primært rummer video upload. Appen giver let tilgang, lige her og nu til produkttræning, når det passer 

lægen bedst. 

Formålet var: 

At skabe en mobil kanal til træning af anæstesilæger i anvendelsen af Ambu aScope samt benytte kanalen 

til eksponering af produktets fordele og for at skabe kendskab. 

Der blev ikke sat et direkte mål på succeskriterierne for appen separat, men det blev forventet, at appen 

ville opnå 1.000 downloads i 2011. Da appen senere ramte app butikkernes top-10 lister nærmest 

eksploderede antallet af downloads. 


Selve udviklingen og indholdsproduktionen blev gennemført af den samme underleverandør, som havde 

udarbejdet onlineplatformen. Ambu forestod projektledelsen. 

Processens faser var flg.: 

1. Afdækning 

Behovsafdækning hos brugerne. Hvor meget bruger de online teknologi? Hvor mange har en smartphone? 

Dialog med målgruppen. 

2. Business case 

Opstilling af, hvordan kan appen understøtte de forretningsmæssige mål. Hvordan når vi målene? 

3. Specifikation 

Kravspecifikation og designopsætning. Hvordan skal brugergrænsefladen være? Hvordan vil vi sætte det 

op, så det ligger rigtigt i hånden? Udarbejdelse af wireframes. Design af knapper og nye ikoner. Hvordan 

skal brugeren modtage materialet? 

4. Produktionsfasen. Indhold 

Tekniske udfordringer løses og specifikationerne revurderes i en gensidig dialog, særligt hvor forventningerne 

ikke var tydeligt afstemt. 

5. Go live 

Udkommer med konceptet og får en masse erfaringer. Hvilken markedsføring virker bedst? Hvad virker 

og hvad virker ikke? Kombinerer markedsføring af appen med messer, online, bannere, QR koder og 

nyhedsbreve. Finder ud af hvor kunderne er online. Følger ugentligt, hvor brugerne kommer fra. 

6. Drift 

Appens indhold er statisk, og der gøres ikke mere ved den pt. 


20


Ambu oplevede, at især designfasen var udfordrende i udviklingsprocessen. Det at skalere en eksisterende 

platform ned til en lille skærm i både form og indhold betød prioriteringer, som krævede ekstra 

dialog og interaktioner hos leverandøren, der tog tid og betød en mindre forsinkelse. 

Der var også markedsføringsmæssige udfordringer i udviklingsprocessen. Onlineplatformen var skabt til 

at uddanne og samtidig lead generere. Ambu ønskede at stille brugerne en masse relevante spørgsmål, 

men plads og hensynet til bekvemmelighed gjorde, at flowet måtte ændres. Brugerne skulle ikke have 

en stor barriere med at besvare spørgsmål for at kunne komme i gang med appen. Også teknologien 

skabte lidt udfordringer. Herunder samspil med egne IT-systemer. Apples godkendelse af appen tog længere 

tid bl.a. fordi, det ikke måtte være påkrævet, at brugeren opgav egen email for at benytte appen. 

Efter lanceringen blev det klart, at appen rummede et meget stort potentiale. Ikke blot for at nå eksisterende 

markeder på en ny måde, men også for at nå nye markeder. 

App butikkerne er stærke markedsføringsmedier. De er effektive distributionskanaler, der allerede er 

indarbejdet i mange folks medieadfærd, og det kom bag på Ambu, at man nåede brugere i helt nye 

lande med appen. 

Udfordringen ligger i, at appen er statisk. For mens hypen om en app med sin nyhedsværdi rummer store 

muligheder, sætter et indhold, der ikke opdateres, ligeså mange begrænsninger. På Ambus webplatform 

har brugerne fx mulighed for at lægge egne videoer ind. Det har betydet, at indholdet og derved værdien 

for brugerne vokser. Det brugergenerede indhold bliver sammen med Ambus løbende udvikling af 

eget materiale brugt af læger til introduktion af aScopet. Det bruges også til at undervise studerende og 

nyuddannede. Denne effekt af cirkler, der spreder sig, går tabt i appen. Læringen er, at en videndelingsapp 

som denne skal udvikles med indhold, der kan opdateres. Det er centralt for appens levetid og ROI. 


Ambu vurderer, at særligt tre forhold gør sig gældende for medical apps: 

1. Early diagnostics. Diagnostisering kan sendes ud til patienterne vha. apps. 

2. Træning og uddannelse. Sundhedssystemet får færre og færre penge, og derfor skal de være mere 

effektive. Som producent kan man få fordele ved at påtage sig en del af uddannelsesopgaven for de 

pågældende produkter. 

3. Tone of voice. Det går ikke at markedsføre sig selv for tydeligt. Sørge for at være mere objektiv og 

ikke for kommerciel. Skriv ikke ”get a quote!”, ”buy today!”. 


1. Lav grundige wireframes og gerne med klikbar prototype. Få evt. brugerfladen testet før udviklingen 

påbegyndes. 

2. Kend din målgruppe – hvor er de, hvilke medier bruger de hvordan. Indtænk appen aktivt i den 

øvrige markedsføring. Vælg de rigtige 10 søgeord til app butikkerne 

3. Opdateringsmuligheder er afgørende for appens levetid. Tænk i et CMS, der kan styre både web og 

app ét centralt sted fra. 


21

Case 

Mobile MIM 

Navn Mobile MIM 

Udgiver MIM Software Inc. (USA) 

Platforme iPhone + iPad 

Udgivet Juni 2008/September 2011 

Målgruppe Radiologer, Lægepraksis og patienter 

Downloads til d.d. 20.000+ stk. 

Samlet budget Ikke oplyst 

Udviklingstid Ca. 8 mdr, første version: 2 uger 

Største udfordring FDA nedlagde forbud mod første version 

fordi den manglede markedsførings- 

godkendelse som medicinsk apparatur. 

Det tog 2½ år at få den godkendt af FDA, 

fordi de ikke er gearet til at godkende apps. 

Største læring At involvere læger tidligt i processen 

for at lette godkendelsesprocessen 

Bedste råd Husk at involvere IT afdelinger på 

hospitalerne for at lette den 

efterfølgende implementering. 

Nysgerrighed drev den første version 

Virksomheden Mobile MIM har sit udspring i slutningen af 1990’erne på Case Western Reserve University 

Hospital. Firmaets stifter og ejer, Dr. Dennis Nelson, manglede et redskab, der kunne kombinere MR 

og PET scanninger. I 2002 blev MIM Software officielt grundlagt og arbejdet med medincisk billedbehandling 

begyndte. 

Gennem årene har MIM software udviklet software løsninger, der gjorde arbejdet med medicinske billeder 

mere effektivt. To nysgerrige medarbejdere anskaffede sig SDK (Software Development Kit) i starten 

af 2008 og forsøgte at overføre firmaets software til Apples platform. I løbet af to uger var den første 

version klar. Resultatet var så overbevisende, at firmaet hurtigt indså, at den mobile platform ville blive 

en integreret del af firmaets portefølje. I USA er det forbudt at markedsføre medicinsk udstyr, herunder 

software, uden behørig godkendelse af FDA. MIM Software mente, at så længe appen blev tilbudt gratis 

fra App Store, kunne det ikke betegnes som markedsføring. Appen vakte så stor opmærksom, at Apple 

bad MIM Software præsentere deres app på App Developer konferencen i 2008. Opmærksomheden 

nåede dog også FDA, der kort efter nedlagde forbud mod videre markedsføring af appen førend den 

var officielt godkendt. 

Først måtte MIM Software indsende en 510(k) ansøgning, men det stillede FDA sig ikke tilfreds med. 

De udbad sig i stedet en PMA ansøgning, der er mere kompliceret i såvel tid som omkostninger. Med 

hjælp fra et par læger, der kunne dokumentere, at softwaren var sammenlignelig med andet software 

fik MIM lov til at indsende en tredje ansøgning i 510(k) format, som således blev godkendt. I foråret 

2011 blev Mobile MIM dermed relanceret efter 2½ års administrativt boldspil. 


Appen er henvendt til radiologer, der bruger appen som behandlingsgrundlag (decision-supporting 

software) som et supplement til workstation software i situationer, hvor der ikke er direkte adgang til 


22

arbejdsstationen. Den er henvendt til andre klinikere (oftest de henvisende læger), der ønsker at se de 

billeder, som deres patienter behandles på baggrund af. Samt patienter, om end de – efter FDA krav – 

har deres egen version af appen (VueMe) som ikke tillader opkobling til hospitalers PAX systemer og 

har en anden form for ansvarsfraskrivninger. 

Appen skaber merværdi til MIM Software’s kunder, der arbejder med medicinske billeder. MIMS’ kunder 

kan via appen direkte se billeder i deres database. Andre (systemer) kan uploade generiske medicinske 

billeder (SPECT, PET, CT, MRI, røntgen og ultralyd) til MIMcloud, hvorefter de respektive billeder kan 

vises på såvel iPhone som iPad. 

Aktuelt er Mobile MIMs succeskriterier, at appen nemt, hurtigt og effektivt skal kunne fremvise medicinske 

billeder. I modsætning til en workstation skal appen ikke være kompliceret at anvende, da dens 

brugssituation er defineret som ”på farten og betjening med én hånd”. 


Det er MIM Software selv, der varetager hele udviklingsprocessen, som er opdelt således: 

1. Design 

Herunder behovsafdækning, udvikling af kravspecifikation og prototype. 

2. Udvikling 

Involvering af relevante læger, der kan give fagligt feedback og hjælpe med at overbevise FDA om, at 

den ny software ligner et ”predicate device”, hvormed ansøgningsprocessen kan nøjes med en 510(k) 

i stedet for en PMA, der er påkrævet, hvis appen er helt unik. 

3. Software test 

Ny funktionalitet afprøves. 

4. Fuld test 

Alle funktionaliteter afprøves. 

5. Fejlretning 

De sidste fejl rettes. 

6. Lancering 

I App Store. 


1. Det er vigtigt at inddrage klinikere i udviklingsprocessen. Dels skal/kan de optimere resultatet af 

udviklingsarbejdet, dels er det en god idé at få dem til at udtale sig om, at brugen af appen minder 

om et andet apparats funktionalitet. Det lyder banalt, men det kan betyde en verden til forskel, når 

den amerikanske markedsføringstilladelse (510(k)) skal i hus. 

2. Den anden faldgrube er ikke at tage IT afdelingerne i hospitalerne med på råd. Kun i ganske få tilfælde 

kan man enten slippe uden om IT afdelingerne eller præsentere en app, der er så fantastisk, 

at de vil kunne lide den. Som udgangspunkt bør man indregne meget tid på at inddrage og ”nurse” 

IT afdelinger, ikke kun i udviklingsarbejdet men også i det efterfølgende salgsarbejde. 

3. Sørg for at være opdateret på lovgivningsmæssige krav fra starten af og vær bevidst om, hvad du vil 

opnå med appen (hvilken klasse skal den være; I, II eller III) 


23

4. Mobile MIM indeholder tre hovedfunktioner, mens deres workstation software indeholder 100+ 

funktioner. Software på workstation er normalt avancerede og fyldt med avancerede funktioner, fordi 

brugeren har tiden hertil foran maskinen. I en app er situationen en anden; brugeren er på farten 

og har kun et kort øjeblik til at anvende appen. Designet skal afspejle dette. I første omgang kan det 

være meget svært at skralle funktioner af. Men herefter simplificeres arbejdet sammenlignet med 

almindeligt software. Der er nemlig tilsvarende færre fejlkilder. 


I FDA regi er det specielt det regulatoriske, der spiller ind. Hvis appen ikke henvender sig til professionel 

brug er det nok at registrere den som et klasse I produkt. De andre klasser kræver dokumentation i store 

mængder. Når først en app har fået sin markedsføringstilladelse (510 (k) eller PMA), så er det vigtigt at 

holde tungen lige i munden, hvad angår opdateringerne. 

MIMS anbefaler at læse dokumentet Deciding When to Submit a 510(k) for a Change to an Existing Device 

(K97-1) grundigt igennem. I korte træk så skal man ikke ansøge FDA om en ny markedsføringstilladelse 

ved mindre ændringer eller fejlrettelser (med mindre der er tale om alvorlige fejl). Kun i det tilfælde, 

hvor der ændres på tiltænkt brug (intended use) eller indikationer (indications), er det nødvendigt at 

gå den lange vej igen. Mobile MIM har gennemgået flere softwareopdateringer uden en fornyet 510(k), 

men er pt. i gang med at tilføje røntgen-billeder til deres funktion, hvilket er en ny indikation, hvorfor 

de er i gang med en fornyet ansøgningsproces. 


1. Kill you darlings – en app er bedst, når den er simpel at betjene; så undgå alt for avancerede funktioner. 

Apps er beregnet til at blive brugt i en mobil situation; Derfor skal de være hurtige, simple 

og effektive. 

2. Involvér læger i udviklingsarbejdet; det letter den senere godkendelsesproces og skærper appens 

indholdsværdi. 

3. Opbyg et tillidsforhold til hospitalers IT afdelinger, således du nemmere kan implementere din nye 

app på hospitalerne. 


24

5. 

Før udviklingsprocessen 

- Afdækningsfasen 

De grundlæggende overvejelser 

Før man begynder på selve udviklingen af en mobil applikation, skal man i afdækningsfasen tage stilling 

til en række grundlæggende forhold, der har stor betydning for det produkt, der i sidste ende skal udarbejdes. 

Disse forhold vil afhængig af formål og kontekst for appen variere – men mange af spørgsmålene 

vil være relevante i de fleste projekter. Vi gennemgår i dette kapitel grundlæggende overvejelser og 

udfordringer og giver et bud på, hvordan du håndterer dem. 

Afdækningsfasen handler om at forstå og forholde sig til den virkelighed, appen skal fungere i. Det er 

vores opfattelse, at en app ikke altid er den eneste rigtige løsning. Gang på gang oplever man faktisk, 

hvordan der fokuseres på en bestemt løsning frem for at se på, hvad man ønsker at opnå, eller hvad 

det bagvedliggende behov er. 

Afdækningsfasen handler altså både om at finde ud af, om en app er den rigtige løsning, og fasen handler 

om at definere formålet med og konteksten for appen. I afdækningsfasen skal man således sandsynliggøre 

appens eksistens og tage stilling til de forhold, der skal sikre appens succes på kort og lang sigt. 

Resultat af afdækningsfasen er en overordnet brief. 

Vi arbejder med seks kategorier af forhold, der spiller ind. 


25

Forretning 

Den første fundamentale overvejelse lægger sig op ad forretningen. Dette vil typisk være business casen. 

Hvilken værdi skal appen skabe? Hvordan skal appen bidrage til forretningen? Hvor kommer pengene 

fra? Hvordan skal den finansieres? Hvordan skal appens værdi gøres op? Hvilken investering berettiger 

appen, og hvilket ROI kan forventes? 

De færreste vil udvikle en app uden en eller anden form for økonomisk overvejelse, der peger på, at 

det er en god idé. Altså, at appen skaber værdi, der bidrager til en forretning. En app kan bidrage til 

forretningen på flere niveauer. Fx som konkret salg, som en service, et statement (branding) eller som 

en markedsføringskanal. Business-casen vil typisk beskrive, hvordan appen indgår i forretningen og 

rumme en vurdering af rentabilitet og investeringens størrelse. Overvejer man at sælge sin app, er det 

værd at notere, at de forskellige app butikker tager sig ganske godt betalt i provision. 30% skal man således 

forvente at betale af sin omsætning på appen, både på prisen for appen, samt det salg, der måtte 

komme ind via appen. Det er naturligvis ikke altid muligt at vide på forhånd, hvilken effekt en app vil 

opnå. Ofte er det dog muligt at sige noget om, hvad den helt sikkert ikke vil opnå, og derigennem kan 

man skyde sig ind på en ikke helt urealistisk forventning. 

En strategi for appen kan på basis af formål og business-case opstilles som en plan for, hvad appen specifikt 

skal, og hvordan den skal gøre det. Strategi handler om at opnå konkrete mål. Da appen indgår i 

det samlede forretningssystem skal der være en konkret plan eller strategi for, appens rolle. Herunder 

er det interessant at se på, hvordan andre har gjort med best practice studier, samt hvad konkurrenterne 

gør gennem en konkurrentanalyse. En god måde at vurdere eksisterende apps på, er bl.a. ved at 

se på brugernes ratings og kommentarer i de forskellige distributionskanaler (App Store mv.). Vi ved, 

at appen kan spille ind på afsenders positionering, og strategien skal sikre at positioneringen er rigtig 

og bliver stærk. 

Det er samlet set vores anbefaling, at omdrejningspunktet for appstrategien er, at appen supplerer 

eksisterende kanaler mere end substituerer dem. Mobile apps kan helt andre ting og indgår i helt nye 

sammenhænge, og i praksis betyder det, at apps kan skabe værdi på nye måder. Kopiering af fx en hjemmeside 

over på en app, er efter vores mening en misforståelse af mediet. Udnyttelse af smartphonens 

indbyggede teknologiske muligheder som kompas, mikrofon, kamera, lys, display, højttalere, accelerometer, 

wifi etc. kombineret med mobilitet, bekvemmelighed og forenkling åbner mulighed for at tænke 

i nye kreative baner, hvor information og interaktion bruges til at skabe merværdi. Dette gælder ikke 

mindst medico området. 

Eksempel 

Ambu’s (se tidligere) business case var, at jo flere, der bliver uddannet i aScope, des flere køber 

produktet. Det, appen kan, er at give let tilgang, lige her og nu til produkttræning, når det passer 

lægen bedst. Strategien blev, at appen skulle supplere den eksisterende online uddannelsesportal. 

Formål 

Før et konkret projekt begyndes, er det en god idé at definere formålet med appen fx på basis af businesscasen. 

Når det først er besluttet, at en mobil applikation er den bedste løsning på et givet behov 

(jf. ovenstående), er det relativt enkelt at opstille et formål for appen. Har man derimod ikke set på, 

hvilket behov (ex en åbning i et marked, et supplement til andre kanaler mv.), appen skal dække, bliver 

formålet mere uklart. 


26

En anden væsentlig grund til at opstille formål er, at det efterfølgende kan dokumenteres, om appen 

levede op til forventningerne. Så punkt to er at kvalificere formålet gennem opstilling af konkrete mål. 

SMARTE-mål er en god guideline for opstilling af mål. Målene skal således være: 

S: Specifikke 

M: Målbare 

A: Attraktive 

R: Realistiske 

T: Tidsbegrænsede 

E: Evaluérbare. 

På basis af målene defineres de evalueringskriterier, appen efterfølgende skal vurderes på. 

Målgruppe 

Som i enhver anden kommunikationssituation, er det en forudsætning for succes, at man kender sin 

målgruppe. Målgruppen er de brugere, man forventer vil benytte appen, og deres adfærd adskiller sig 

fra andre. Det er denne specifikke adfærd, der er interessant. Formålet med at kende sin målgruppe er, 

at forstå hvordan appen kan skabe værdi for dem. 

Spørgsmålene er: Hvordan er målgruppens medievaner? Hvordan er deres dagligdag? Hvor store brugere 

er de af IT? Eller hvor vante er de med brug af IT? Er de innovatører eller late adopters? Hvilken kultur 

opererer målgruppen i? Hvor og hvordan kan vi nå vores målgruppe? 

Opstilling af persona profiler er en typisk metode i arbejdet med udvikling af kommunikations- og 

it-produkter. Personaerne beskriver brugerne og deres adfærd og giver værdifuld indsigt om motiver, 

barrierer, vaner, viden mv. 

Med andre ord er det helt centralt at undersøge og forstå målgruppens vaner. Værdiskabelsen ligger 

ofte i omsætning af indsigt i målgruppen og bør have stor påvirkning på den app, der skal udvikles. Aktiv 

forståelse og brug af viden om brugerne er guld værd i konceptudviklingsfasen og er afgørende for, om 

appen bliver en succes eller ej. 

Eksempel 

Ambu’s målgruppe er anæstesilæger globalt. Viden og undersøgelser viste, at lægerne ofte har 

ventetid. De slæber rundt på en masse opslagsværker og modtager en masse produktinformation, 

som de aldrig åbner. Indsigterne gjorde, at idéen til appen blev købt. Også den konkrete 

brugeroplevelse og indholdet på appen blev påvirket af brugerindsigt. 

Teknologi 

Når vi ved, hvad appen skal, hvordan og i hvilket samspil, er det næste at overveje det tekniske set- up. 

Da apps afvikles på brugerens individuelle mobilenhed i modsætning til websites, der afvikles på en 

central server, har det stor betydning for appens tilgængelighed og anvendelighed, hvilke platforme, 

der udvikles til. 

De forskellige platforme dækker iPhone (iOS), Android (Samsung, HTC, Sony Ericsson m.fl.), Microsoft 

Windows Mobile (Microsoft, Nokia m.fl.) og Blackberry m.fl. Fordelingen på verdensplan af de forskellige 

platforme ses her: 


27

Figur 5. Smartphone operating systems’ market share. Share of worldwide 2011 Q2 smartphone sales to end users by operating 

system, according to Gartner. Gartner report “Market Share: Mobile Communication Devices by Region and Country, 2Q11” 

Det kommer som en overraskelse for mange, at hver platform faktisk kræver særlig udvikling, og at der 

i modsætning til, hvad man skulle tro, er stort set intet at genbruge på tværs af platforme rent udviklingsmæssigt. 

Det betyder, at to platforme koster det dobbelte at udvikle til som én. Det betyder også, at 

appen skal lanceres to steder, at der ligger dobbelt så meget vedligeholdelse, og dobbelt så meget test 

i udviklingsprocessen. Android telefonernes styrke er på den ene side deres mangfoldighed, fordi der 

findes en model til ethvert behov og til enhver pengepung. På den anden side er Android telefonernes 

mangfoldighed også en svaghed med over 800 forskellige modeller, der alle fungerer på sin egen måde. 

Det er således stor set umuligt at designe eller for den sags skyld udvikle en app, der ser pæn ud og 

fungerer perfekt på alle Android telefoner. 

En fremgangsmåde, som mange benytter, er, at udvikle til én platform i første omgang og sikre et proof 

of concept. Når den første app er udviklet, testet, launchet, taget i brug, virker og er blevet en succes 

hos målgruppen, er det langt lettere og hurtigere at skabe en kopi på en ny platform. Det kan imidlertid 

give god mening af andre årsager at udvikle apps til flere platforme samtidig. Her er det vigtigt at forstå, 

at der reelt er tale om at gennemføre to udviklingsforløb samtidig, hvor ændringer hurtigt kan kræve 

væsentlige ekstra ressourcer. Et helt centralt spørgsmål er således, hvilke platforme appen skal udvikles til. 

Der findes statistikker for national udbredelse af mobilplatforme. Ligeledes findes der statistikker for 

den demografiske fordeling af platformene. I Danmark kan statistik findes her: www.itst.dk/digitalelosninger/teleguiden 

samt www.dst.dk 

En god tommelfingerregel er, at unge benytter de billigere platforme (Android), iPhone-brugere er mere 

aktive i brugen af apps, og i USA er Blackberry mere udbredt end i Europa. iPhone dækker på verdensplan 

ca. 5% af smartphone markedet. I Danmark er tallet ca 35%. I Kina udgør iPhone under 5%! Her er 

Nokia (Symbion) størst (mere end 70%). 

Vi anbefaler, at man satser på at skabe velfungerende Andriod apps på udvalgte modeller, og den bedste 

måde at finde ud af, hvilke platforme, der skal udvikles til, er altid ved at kende sin målgruppe. Indsigt i 

målgruppens medievaner og eventuelle retningslinjer i organisationen vil give svaret på, hvilke platforme, 

du skal satse på. Samt udbredelsen i det geografiske område hvor appen skal anvendes. 


28

Et andet forhold vedr. IT-system ligger i beslutningen om, hvorvidt appen skal være statisk eller dynamisk. 

Om indholdet skal være embedded eller hentes online. Forskellen er, at den statiske version er 

født med alt indhold, som downloades sammen med appen. Når appen først er lanceret, vil det være 

umuligt at ændre eller opdatere indholdet uden at involvere udviklerne. Derfor er det helt centralt at 

beslutte ud fra strategien med appen og kendskabet til målgruppen, om appen skal være indholdsmæssig 

opdaterbar eller ej. 

Fordelen ved det statiske indhold er, at brugeren ikke behøver være online for at se indholdet, hvilket 

kan være smart, hvis målgruppen fx er fra andre lande, der tit vælger at slå roaming i udlandet fra pga. 

datapriserne. En anden stor fordel ved de statiske apps, er at de er mere enkle at udvikle og derved 

billigere. Eksempler på, hvor en statisk app giver god mening er apps rettet mod turister, apps til internationale 

konferencer, apps der skal fungere på steder, hvor der ikke er internetadgang samt apps som 

typisk har en meget specifik brug og kort levetid på brugerens smartphone. 

En dynamisk app har indhold, der løbende kan ændres, hvilket kræver en backend a la et CMS, som det 

kendes fra website. Dvs. en back-end, hvor en redaktør/content manager kan tilgå appens indhold og 

ændre det uden at skulle rode med nogen form for programmering. En dynamisk app kan have sit eget 

backend system, eller den kan blive feedet af et eksisterende system, der allerede er udarbejdet til et 

website. I sidstnævnte tilfælde skal der udvikles et API mellem backendsystem og app, så de kan ”tale” 

sammen. En overvejelse i denne sammenhæng er således, hvis man beslutter sig for en dynamisk app, 

om indholdet skal opdateres fra ét fælles eller flere backend individuelle systemer til hhv. web og app, 

hvilket er lidt mere omstændeligt. Det er ofte nødvendigt at integrationen med eksisterende IT-systemer 

sker i samarbejde med de folk, der vedligeholder de eksisterende systemer i forvejen. 

Et sidste punkt i dette afsnit er samspillet med eksterne enheder, der kobles på smartphonen. I fagtermer 

og nærværende guides forståelse kaldes dette for hybrid apps, da de sammenkobler to (eller flere) 

platforme som fx en pulsmåler og appen. Ideen er, at der ved at koble appen sammen med en ekstern 

enhed opstår ny værdi, der ikke var mulig uden sammenkoblingen. 

Et eksempel er blodtryksmåleren fra Withings. En normal blodtryksmåler består af en manchet og en 

kontrolenhed, der indeholder betjeningstaster, display og pumpe. Withings har udviklet en manchet 

med indbygget pumpe, der styres via en iPhone, hvor også resultatet udlæses og logges. Denne blodtryksmåler 

giver langt større værdi, fordi iPhonen kan tilkobles internettet og resultaterne logges i en 

grafisk kurve tilgængelig fra enhver enhed med internet adgang. Derudover fylder apparatet mindre og 

har færre dele, der kan gå i stykker. Det bliver muligt for brugeren automatisk at se tendenser, historik 

mv. og således mere præcist monitorere og fortolke blodtrykket. 

Apps kan lukrere på de mange forskellige sensorer en smartphone indeholder (kompas, mikrofon, kamera, 

lys, display, højttalere, accelerometer, wifi etc.). Kombineret med, at smartphonen eller tablet’en 

er mobil, er det kun fantasien, der sætter grænsen for kreative, værdiskabende hybride apps. Der findes 

allerede tyverialarmer, der kan fjernkontrolleres af en app, og går vi ind i den medicotekniske verden, 

er det kun et spørgsmål om tid, førend patienter og deres pårørende vil kunne monitorere og agere på 

kritiske værdier målt på/af telemedicinske devices via hybride apps. 

De teknologiske forhold har naturligvis stor betydning for projektets ressourceforbrug og appens anvendelighed. 

Leverandøren vil typisk kunne rådgive om disse forhold, og de rigtige beslutninger kan 

træffes, hvis spørgsmålene adresseres indledningsvist. 


29

Ressourcer 

Det sidste punkt under de fundamentale overvejelser handler om ressourcer; Tid, penge og manpower. 

Budget 

Budgetdelen er naturligvis væsentlig for de fleste og hænger tæt sammen med den opstillede businesscase, 

hvor appens rentabilitet vurderes. Spørgsmålene er: Hvor meget kan man investere i appen, således 

at den bibringer et fornuftigt ROI? Hvordan måler vi appens værdi? Hvilke ressourcer har vi til drift? 

Hvor meget mere får vi ud af at udvikle til flere platforme? Hvad får vi ud af at investere i et backend 

system, der gør appen opdaterbar? 

En overordnet budgetramme er et nødvendigt styringsværktøj for de fleste. Herunder vurdering af, hvor 

stor en margin, der opereres med, hvis det bliver nødvendigt at tilføre flere midler undervejs i projektet. 

Det er vores erfaring, at gennemarbejdede apps koster i omegnen af 100-200.000 kr. pr. platform. Hertil 

vil komme udvikling af backend, der kan ligge på det samme niveau afhængig af, hvad der findes i forvejen. 

Parametre af betydning for prisen er: Appens funktionalitet (jo mere – jo dyrere), antal platforme 

(jo flere – jo dyrere) samt om appen har statisk eller dynamisk indhold (jo mere backend udvikling eller 

integration af eksisterende backend til styring af indholdet – jo dyrere) 

Tid 

Tidshorisonten er endnu et centralt punkt i planlægningsdelen. Spørgsmålene er: Hvilke andre aktiviteter 

kan påvirke appens lanceringsdato? Hvornår skal appen være færdig? Hvilke milepæle skal der opstilles? 

Hvad kan forsinke processen? Opstilling af en overordnet projektplan er et godt redskab, hvor der 

afsættes tid til de i det næste kapitel beskrevne faser. 

Det er i denne sammenhæng vigtigt at vide, at en godkendelse af appen til Apples App Store kan tage 

op til to uger og kan medføre, at appen ikke godkendes, hvilket betyder yderligere forsinkelse. I Android 

Market er lanceringsprocessen ca. to timer. Den langtrukne App Store proces gør, at apps og stramme 

deadlines er en risiokofyldt cocktail. 

Det er vores erfaring, at et app projekt kan tage helt op til tre-seks måneder at gennemføre fra start 

til slut. En fordeling kunne se således ud: Planlægningsfase, en til to måneder. Design og udvikling, to 

måneder. Test og godkendelse, en til to måneder. Vær derfor realistisk med tiden. Det kan ikke betale 

sig at presse projektet. Kom hellere i gang i god tid forud for en fast deadline. 

Manpower 

Herunder ligger forhold som, hvem der skal udvikle appen? Hvem skal styre processen? Og hvem der 

skal vedligeholde appen? 

De fleste får i dag udviklet apps af underleverandører og valget af underleverandør hænger ofte sammen 

med, om ens eksisterende partnere udvikler apps. I mange tilfælde vil det være fornuftigt at indhente 

tilbud fra flere leverandører, og selvom mange leverandører på papiret ser ud til at give den samme 

ydelse, kan der være stor forskel på, hvilket produkt man får som kunde. Derfor skal en opdragsgiver 

vurdere, hvad der er vigtigt i en samarbejdsrelation. For der ER forskel på leverandører, og deres kompetencer 

er forskellige. En samlet udviklingsproces består typisk af både rådgivning, idé-udvikling og 

programmering. Undersøg hvad dit behov er og spørg ind til, hvad leverancen dækker. Se referencer og 

søg garanti for at virksomheden også findes i fremtiden. 

Det er vores erfaring, at succesfuld gennemførsel af appudvikling kræver en fast ressource og opdragsgiver 

til projektstyring, dialog og evt. efterfølgende drift. Casene i denne guide har alle krævet hvad der 

svarer til en fuldtidsmedarbejder i 30-50 % af den samlede projektperiode. Hertil kommer inddragelse 

af beslutningstagere og andre interne ressourcer fra andre afdelinger. 


30

Eksempel kontaktpris 

Ambu’s tilstedeværelse på en af de store betydningsfulde medicokonferencer kan med alle 

omkostninger medtaget løbe op på anslåede 1 mio. kr. Der kommer est. 4.000 mennesker, og 

går det godt, kommer Ambu i kontakt med ca. 10% af disse gennem symposier og andet. Den 

rå kontaktpris er derved: ca. 2.500 kr. Appen kostede ca. 200.000 kr. og har pt. opnået 9.000 

downloads. Hvis 50 % af disse er kvalificerede leads betyder det en rå kontaktpris på: ca. 45 kr. 

Tallene er naturligvis ikke direkte sammenlignelige, men er et eksempel på en økonomisk betragtning 

af en apps værdi. 

ROI – Return on investment 

Hvis man anslår, at et lead er 1.000 kr. værd for AMBU, kan ROI udregnes. ROI ved at stå på messe: 

1.000/2.500=0,4. ROI på app: 1000/45=22. Dette er selvfølgelig alt andet lige betragtninger og 

uden hensyntagen til evt. forskel i udbytte af en kunde hvervet personligt på en messe og en 

kunde hvervet via appen. 

Jura 

Størstedelen af de juridiske hensyn fsva. medico apps vil læne sig op ad de regulatoriske forhold (se afsnit 

3). Selv apps, der formidles gratis, fortolkes lovgivningsmæssigt som markedsføring, dvs. en gratis app 

skal stadig godkendes regulatorisk såfremt den rent teknisk falder ind under definitionerne i afsnit 3. 

Overordnet set skal en medico app forholde sig til, om de er henvendt til privat eller professionel brug. 

Herefter skal den forholde sig til, hvilket geografisk marked den markedsføres til. Slutteligt skal udvikleren 

undersøge eventuelle rettigheder til apps indhold, herunder patenter og specielt copyright, hvis tekst, 

billeder/grafer eller lyd anvendes fra andre kilder. 

Det tilrådes at kontakte professionelle rådgivere herom fx patentrådgivere. Teknisk set er det muligt at 

hente data og andet indhold fra andre apps i en separat app, og dette stiller naturligvis krav om indhentning 

af accept fra de øvrige apps, dels om indhentning af data, dels om sammenføring med evt. 

konkurrenter. Som eksempel kan nævnes de apps, der fremviser tilbudsaviser. De bør sikre sig en aftale 

om at hente data men også om at lægge deres indhold side om side med konkurrenter. 

Slutteligt er der apps, der giver brugerne mulighed for at ytre sig. Det kan være uhensigtsmæssigt at 

kontakte fagfolk, der kan rådgive om juridiske konsekvenser, hvis en bruger går over stregen, eller hvis 

brugerne viser andre måder at benytte appen på, end den tiltænkte brug. 


31

Tjekliste 

De fundamentale forhold 

– Samles i en brief 

Forretning 

! Eksistensberettigelse (business case) 

! Samspil med andre tiltag 

! Opstilling af strategi 

Formål 

! Behovsafdækning 

! Formål med appen 

! Opstilling af konkrete mål 

! Evalueringskriterier 

Målgruppe 

! Hvem er målgruppen 

! Hvad er deres medievaner 

! Hvilken kultur spiller appen ind i 

Teknologi 

! Hvilke platforme udvikles appen til 

! Skal indholdet være dynamisk eller statisk 

! Skal appen have eget backend eller integration med eksisterende 

Ressourcer 

Økonomi 

! Udviklingsbudget 

! Buffer 

! Driftsbudget 

Tidshorisont 

! Milepæle 

! Indsendelsesdato til App Store 

! Lanceringsdato 

Manpower 

! Hvem udvikler 

! Hvem er projektleder 

! Hvem står for vedligeholdelse 

Jura 

! Er appen henvendt til privat eller professionel brug 

! Hvilket geografisk marked den markedsføres til 

! Er eventuelle rettigheder til apps indhold clearet 

! Hvad er brugerinddragelsespolitik 


32

6. 


- En fremgangsmåde i fem trin 

Når planlægningen af de fundamentale seks forhold er på plads, påbegyndes selve udviklingen. Vi har 

i dette kapitel samlet gode råd, erfaringer samt tjeklister vedr. denne del af processen, der kan sammenfattes 

i fem trin: 

Specifikation 

Specifikationsfasen ligger på en måde mellem planlægning og udvikling. For udvikling uden en forudgående 

specifikation kan mildest talt ikke anbefales. Det er i specifikationsfasen, at ideen med appen 

bliver tydeliggjort og konkret. En specifikationsproces kan ske i flg. trin: 

Idé-udvikling 

Planlægningsfasen har forhåbentlig gjort det klart, hvad appen skal overfor hvem. Og derved er idéen 

med appen overordnet set defineret. Som oftest vil idéen dog være beskrevet på et lidt højere plan 

og ikke være knyttet direkte sammen med de teknologiske og mediemæssige muligheder som en app 

rummer. Derfor er konceptudvikling første skridt i konkretisering af appen, og her kan det for de fleste 

være gunstigt at alliere sig med eksperter på området fx gennem en workshop. 


Ideen med at mødes og idéudvikle i fællesskab er at få bragt de forskellige interessenters kompetencer 

mest muligt i spil. Opdragsgiver sidder inde med viden om forretningen. Målgruppen (fx klinikere) sidder 

inde med viden om kultur, adfærd og eksisterende teknologier. Teknikkerne sidder inde med viden 

om de eksisterende IT-systemer. Og leverandøren er typisk eksperter inden for områderne som digital 

konceptudvikling, design, teknologi og medier. 

Samskabelse på idéniveau er en stor gevinst for det samlede produkt og et stærkt udgangspunkt for 

et konkret koncept, der rent faktisk vil blive en succes i praksis. En anden fordel ved at inddrage de 

forskellige interessenter tidligt er, at de får ejerskab og kan bidrage løbende i udviklingsprocessen med 

feedback, fordi de allerede er med i ”loopet”. 

Resultatet af en god idé-udviklingsproces er at stå tilbage med et klart og afstemt billede af, hvad præcis 

appen skal kunne og rumme. Appens koncept, som ud over at beskrive idéen med appen og appens 

funktionalitet, omhandler appens indhold. Og det må siges igen, at ”content is king”. Indholdet udgør 

appens værdi. Om det er et ægge-ur, der fortæller dig, hvornår dit æg er blødkogt, om det er dagens 

nyheder, der konstant er opdateret, om det er priser på benzin, vejret, et spil, aflæsning af en måleenhed, 

statistik om personlig performance, nærmeste bager, nærmeste toilet, nærmest kunstværk osv., 

så handler det altid om indhold. Indhold gjort tilgængeligt for brugeren på en måde, der skaber ny 

værdi. Og derfor er det ulejligheden værd at samle de mest kompetente mennesker på området for at 

skabe det bedste indhold, der leveres på den bedste måde for brugerne i et samlet homogent koncept. 

Prototyping 

Når appens koncept er defineret og beskrevet, kan appens anatomi visualiseres mere i dybden. Wireframing 

og prototyping er vigtige værktøjer i denne proces. Wireframes er en optegning af appens 

side/skærmvisninger, hvor både navigationselementer (som knapper, menuer mv.), indholdselementer 

(som tekst, billeder, video mv.) samt funktionalitet (som share, søg, optag, bestil mv.) er medtaget. 

Wireframes er en skitse af appen, der i første omgang skaber overblik over, hvordan appen er struktureret, 

og hvordan elementerne er placeret. Det er et meget vigtigt værktøj, fordi det er en helt konkret 

dokumentation af appen. Wireframes definerer også appen fremadrettet for designere og udviklere. I 

første omgang behøver wireframes ikke gå ud i alle detaljer. Det er en iterativ proces, hvor appen foldes 

mere og mere ud, hvilket dokumenteres gennem wireframes. 

Prototyping er et naturligt næste skridt for de fleste. Det er ikke på samme måde et must som wireframes, 

men prototyping er en god og endnu mere specifik måde at dokumentere flowet af indholdet i 

appen på. En app prototype er klikbare wireframes sat op i et program, hvor man kan navigere rundt 

i appen. Det behøver ikke være kompliceret, og vi har set flere eksempler på, at software som Power 

Point fungerer udmærket til at oprette de klikbare versioner af wireframes på. Der findes også mere 

avancerede softwareprodukter, hvor wireframes og prototype skitseres samtidigt (ex. Axure ell. Omni- 

Graffle) og slutteligt findes der software, der kan vise prototypen på den mobile enhed (ex. Prototype 

app). Prototypens styrker ift. wireframes er, at de er interaktive, at detaljeringsniveauet er højere, og at 

overblikket er endnu mere struktureret, fordi alle klikbare elementer gennemgås. Det betyder, at ”alle 

sten vendes”, vurderes og kan tilrettes, indtil appen rummer og gør det, den skal. 

Hele idéen med wireframes/prototyping er således at visualisere produktet og gennem en iterativ proces 

justere og optimere appen, indtil den kan godkendes. Den godkendte wireframe/prototype er herefter 

omdrejningspunktet for den videre udvikling og det produkt, der produceres. Ændringer efterfølgende 

på wireframes og flow betragtes af de fleste leverandører som opgaver ud over det aftalte og koster 

ekstra. Wireframes/prototype er så at sige ”point of no return”. 

Kravspecificering 

Ud over wireframes/prototyping ser vi ofte en kravspecifikation udarbejdet, som i ord beskriver, hvad 

der sker i de forskellige stadier af appen. Kravspecifikationen er god, fordi den giver mulighed for at 


34

eskrive de bagvedliggende forhold og processer, som ikke nødvendigvis kommer med i prototypen. 

Herunder tekniske forudsætninger, kommunikation med backend system, svartider, funktionalitet (søgning, 

bestilling, deling mv.) osv., samt hvor ansvaret for den givne bagvedliggende proces ligger (kunde 

eller leverandør). Kravspecifikationen kan med fordel tænkes sammen med prototypen og skrives i det 

samme dokument. 

Kravspecifikationen skal betragtes som en helt central del af specifikationsfasen og skal være afstemt 

før de næste faser påbegyndes. 

Budgetfastlæggelse 

Pointen med specifikationsfasen er at skabe et fælles og klart billede for alle interessenter af, hvordan 

appen skal opbygges og fungere. Specifikationen er det blueprint, udviklingsprocessen efterfølgende 

tager udgangspunkt i, og det er faktisk først, når specifikationsfasen er afsluttet, at produktet er klart 

defineret. 

Derfor er det også det helt rigtige tidspunkt at opstille et detaljeret budget på. En overordnet drøftelse 

af budgetrammen bør finde sted allerede ved den indledende dialog med leverandøren. Et realistisk 

budget, der harmonerer med det valgte koncept, kan dog realistisk set først udarbejdes, når specifikationsfasen 

er gennemført. 

Således er sidste del af specifikationsfasen opstilling af det endelige budget, der tager udgangspunkt 

i den udarbejde kravspecifikation med wireframes/prototype. Det er i denne fase, at funktionaliteten 

ligeledes skal nedjusteres, hvis budgettet overstiger den fastsatte ramme fra planlægningsfasen. Derved 

er budgetteringen også en iterativ proces, der hænger sammen med specifikationen af produktet. 

Når budgettet er lagt fast og appen er beskrevet i detaljer, er det tid til at reviewe projektplanen og 

opstille en endelig projektplan med milepæle. Er der ikke allerede indgået en skriftlig kontrakt med 

leverandøren, bør det ske her. 

Design 

Designfasen ligger som regel hos leverandøren, og dette er også en iterativ proces. Første trin vil være, at 

designretningslinjerne defineres fra opdragsgiveres side. Retningslinjer omfatter, om der er en corporate 

design guide, der skal følges, om der er ønske om et bestemt look’n’feel, om appen skal ligne en eksisterende 

kampagne mv. Det er de visuelle retningslinjer, som designerne skal følge i det kreative arbejde. 

På basis af den indledende designbrief, vil der typisk komme et udspil fra design og konceptudviklerne. 

Et af de steder, hvor digital design og almindeligt design adskiller sig, er i, at det digitale design rummer 

en grænseflade (interface), som brugeren interagerer med. Heraf er opstået begreberne GUI (graphical 

user interface), som man bl.a. kender fra skrivebords-mataforen på både Mac og PC, hvor grænsefladen 

mellem person og computer foregår i et metaforisk univers, som er let at forstå og bruge. NUI (natural 

user interface) er det nyeste skridt i interface designudvikling og dækker over ideen om, at brugeren får 

tilgang til enhedens funktionaliteter gennem en naturlig interaktion og progression. Ideen med NUI er, 

at interaktionen selv med komplekse applikationer bliver intuitiv og naturlig. At brugeren hurtigt opnår 

et ekspert niveau… og får succes ved at tilgå appen på en spontan og naturlig måde. 

Det er således ikke helt ligegyldigt, hvordan appen designes. Navigation, interaktion, flow og tilgængelighed 

bør indtænkes aktivt i designprocessen. Hertil kommer det faktum, at de forskellige platforme 

har forskellige skærmstørrelser og et forskelligt fysisk interface. Androids mangfoldighed med over 800 

modeller i et hav af forskellige skærmstørrelser gør det umuligt at designe til alle modeller. Samtidig er 

der forskel på Android og iPhones fyskiske knapper, der gør, at fx en ”home”-knap til iPhone skal være 

del af designet, mens den er en fysisk knap på en Android telefon. 


35

En af de helt store udfordringer i design for apps er selvfølgelig, at skærmen er lille, og at man navigerer 

rundt med sine fingre. Det betyder, at interfacet skal være både minimalt i sit informationsindhold, og 

at knapperne skal have en vis størrelse for at give fysisk mening. Ofte skal brugeroplevelsen af appen 

være baseret på en mere direkte berøring og bevægelse af elementerne. Man flytter ting på skærmen 

(lås op fx), man drejer på en knap, man forstørrer et billede med to fingre etc. Smartphonens multitouch 

teknologi har åbnet op for nye mere visuelt og fysiske måder at interagere på, og brugerfornemmelsen 

bliver ofte, at man står med et device, der fysisk ”fylder” meget mere, end man kan se, og at man 

skubber elementer, navigationsbar og knapper rundt i det lille udsnit skærmen udgør, afhængig af, hvad 

man har brug for lige nu. 

To ting har for alvor skilt appdesign ud fra andre eksisterende medier og skabt nyt formsprog; Nemlig 

ikoner og det naturlige look. Ikonerne er enkle grafiske repræsentationer, der symboliserer en funktion, 

og det kan faktisk være en udfordring at opfinde passende ikoner til helt specifikke funktioner. Det 

naturalistisk-baserede look er et andet formsprog, som mange apps benytter. Fx en guitarforstærker 

app, der ligner en fysisk guitarforstærker. En boghandler app, der ligner en bogreol. Knapper, der ligner 

metal mv. 

Virkelighedens verden og ikke mindst håndens anatomi skal tænkes med, når der designes. Placering 

af knapper efter brugerens tommelfinger har direkte konsekvens på, om brugeren oplever interfacet 

som naturligt eller ej. Det er vores anbefaling, at appens design lægges op af eksisterende formsprog 

og konnotationer, der allerede er etableret og genkendes af brugerne. Det vil understøtte brugerens 

intuitive tilgang. Heldigvis findes der et hav af grafiske redskaber, skabeloner og samlinger, der kan 

bidrage og nærmest er uundværlige i designet af en flot app. 

Skabelse af den naturlige oplevelse og brug af appen ligger i designfasen. Processen vil typisk køre frem 

og tilbage over et par omgange, der ofte er aftalt på forhånd, indtil det rigtige look’n’feel er skabt, og 

navigationen er optimeret med placering af knapper og elementer de rigtige steder. Der findes gode 

og nærmest uundværlige programmer (Ex Live View Screencaster), der kan styrke dialogen omkring 

designprocessen ved at vise designet live på en telefon, man kan stå med i hånden. 

Vi anbefaler, at man brugertester interfacet på designniveau i stedet for at vente, til det er implementeret. 

En god måde at gøre dette på, er ved at indarbejde det valgte design i prototypen, således, at man har 

fornemmelse af, hvad appen kan, og hvordan den ser ud mens brugeren klikker sig gennem den. Husk at 

brugernes respons altid er guld værd – både når det er positivt, og når det giver anledning til ændringer. 

Sidste trin i designdelen er rentegning og overlevering til udviklerne. Ligger design og udvikling hos én 

leverandør sker denne overlevering automatisk. Ligger design og udvikling hos forskellige parter, bør der 

fra start være aftalt, hvordan overlevering af designdokumenter skal ske. Herunder detaljeringsniveau 

og formater. I sådanne tilfælde kan det overvejes at bede designeren udarbejde en såkaldt style guide. 

Udvikling 

Udviklingsfasen er ofte den mest ressourcekrævende del af et app-projekt målt i mandetimer, og der er 

masser af litteratur tilgængelig på området. I denne guide har vi et praktisk fokus, hvilket betyder, at vi 

tilgår udviklingsfasen ud fra hvilke forhold, der med fordel kan overvejes rundt omkring udviklingen. Vi 

behandler ikke værktøjer til udvikling, eller hvordan man udvikler en app. Disse forhold kan en leverandør 

rådgive om. Men netop fordi selve udviklingen er så ressourcekrævende, er det naturligvis vigtigt, 

at der træffes de rigtige beslutninger omkring udviklingen, så ressourcerne bruges mest fornuftigt. Det 

er disse forhold, dette afsnit omhandler. 

Applikationstyper 

Den første overvejelse handler om valget af applikationstype. Der findes forskellige applikationstyper, 

der alle fungerer som det, man betegner som en mobile app. De afvikles på brugeres smartphone og 


36

dækker i nogen grad de samme muligheder. Imidlertid er der tale om forskellige teknologier og derfor 

rummer de forskellige typer forskellige begrænsninger og muligheder. 

Native apps 

Er den type apps, der er skræddersyet, udviklet og optimeret til den konkrete platform og styresystem, 

som appen skal afvikles på. Det er den teknologisk set mest optimerede app ift. enheden. Det betyder 

også, at native apps ikke er særlig skalerbare, når det kommer til de andre platforme, og koden kan ikke 

genbruges på tværs. Til gengæld kan appen udnytte smartphonens fulde teknologiske potentiale. Man 

taler om et app-finish, der dækker over den følelse, man som bruger oplever, når man benytter appen. 

Hvordan designet spiller sammen med navigationen, hvordan enheden responderer på interaktionen, 

hvor stabilt appen kører, hvor lækkert og gennemarbejdet detaljerne fungerer. På native apps er disse 

forhold optimerede. Native apps er det, man også kunne kalde ægte ”fuldblodsapp”. 

Fordelene er: 

! Optimal performance 

! Stærk brugeroplevelse 

! Fuld adgang til enhedens funktionaliteter og teknologi 

! Nemt at finde i diverse app butikker 

! Nemt at notificere brugere om updates 

! Push-opdateringer 

! Fungerer offline 

Ulemperne er: 

! Platformsspecifikke 

! Skal installeres 

! Skal godkendes af Apple (iOS) 

! Provision til fx Apple og Google (Android Market) - pt. 30% 

Web apps 

Kan på mange måder sammenlignes med et avanceret website, optimeret til mobile enheder og med 

udnyttelse af de nyeste teknologier, der gør, at enhedens teknologi kan benyttes (kamera, GPS, kontakter 

etc.). Web apps afvikles på en server (tynd klient) og kræver at brugeren er online. Web apps er 

fx en mailapplikation på enheden eller cloud-relaterede apps. Web apps er mere skalerbare på tværs 

af platforme, men afvikles og vises ikke 100% identiske på alle enheder. Det betyder i praksis, at web 

apps skal optimeres til de mest anvendte enheder hos målgruppen. Web-finish er ikke helt på niveau 

med native apps, men stærke teknologier som HTML 5 har gjort brugeroplevelsen langt mere app-agtig. 

Fordelene er: 

! Ingen installation 

! Virker på tværs af platforme (skalerbarhed) 

! Skal ikke godkendes i en app butik 

! Ingen provision til div. app butikker 

! Projektet er i sin helhed mindre omfattende 

! Skal ikke opdateres på brugerens enhed 

! Høj grad af statistisk overvågning 

Ulemperne er: 

! Skal være online 

! Middel brugeroplevelse (svært at opnå “app-finish”) 

! Middel performance 

! Ej fuld adgang til enhedens funktionaliteter 

! Kan være sværere at finde for en bruger 


37

Framework apps 

Den sidste type er de såkaldte framework apps. Det, der karakteriserer frameworkapps, er, at de er meget 

skalerbare på tværs af platformene. I princippet udvikles én app inden for frameworkets regi, hvorefter 

den sprøjtes ud af frameworket i de ønskede platformsversioneringer. Det er jo rigtig smart, og derfor en 

voksende industri, som også de helt store spillere (ex. Adobe) er gået ind i. Udfordringen er imidlertid, 

at frameworket som ofte har sine begrænsninger, for det siger sig selv, at kompleksiteten i at udnytte 

enhedens fulde funktionalitet som en native app gør, ikke blot lader sig kopiere til andre platforme. 

Resultatet er derfor ofte, at laveste fællesnævner sætter standarden simpelthen fordi Frameworket ikke 

understøtter mulighederne. Det gælder også styling, hvilket betyder at app-finish ikke er i top. 

Fordelene er: 

! Virker på tværs af diverse platforme 

! Mange-i-én gør processen hurtigere og billigere 

! Automatisk sikring af look på tværs af platforme 

Ulemperne er: 

! Kræver at man sætter sig ind i frameworkets udviklingsmiljø 

! Begrænset udnyttelse af enhedens funktionaliteter 

! Middel performance 

! Svært at opnå “app-finish” 

Inhouse eller outsourced 

Den næste overvejelse er, om udviklingen skal ligge i huset eller outsources til en underleverandør. Er 

der ikke tidligere erfaring med appudvikling, er det som regel ikke verdens bedste idé selv at udvikle 

appen. Vores anbefaling er, at man som opdragsgiver starter med ekstern udvikling og evt. rykker udviklingen 

in-house efterfølgende. En mulighed er at koble egne udviklere på processen hos leverandøren 

og derved bygge viden gennem processen. 

Overvejelser om valg af leverandør er beskrevet i FØR-afsnittet og skal her blot suppleres med flg. to råd: 

! Lav aftaler om, hvordan udviklingen dokumenteres i tilfælde af, at andre skal overtage den på et 

tidspunkt. 

! Lav aftaler om rettigheder til koden, at den opbevares forsvarligt og at den er tilgængelig i fremtiden. 

Projektledelse 

Ledelse af et medicoapp udviklingsprojekt adskiller sig på især to områder fra at lede andre softwareudviklingsprojekter. 

For størstedelens vedkommende er det relevant at inddrage regulatoriske godkendelsesprocedurer, 

hvilket kræver specialister og dermed ekstra tid såvel som finansielle ressourcer. Der 

kan for ikke-medico virksomheder ligge udfordringer i at gennemskue konsekvensen af at træde ind 

i medicobranchen, for selvom appen i bund og grund er ren kode, gælder der anderledes stringente 

regler og ansvarsforhold, når produktet skal forholde sig til menneskers liv og velvære. Generelt hører 

det desværre til sjældenhederne, at IT-projekter leveres fuldstændig til den aftalte tid og inden for 

budgettets rammer. Medico apps indeholder både en regulatorisk og en kvalitetsmæssig joker. Sørg for 

at undersøge myndighedskrav inden det endelige budget fastlægges og lav en aftale med styregruppen 

om frekvens for budget status. 

Det andet udfordringsområde handler om den mere generelle projektledelse og styring. App-projekter 

er specielle i det, at de på den ene side er begrænsede i deres koncept og på den anden side også meget 

komplekse, fordi det er nyt terræn, fordi bagvedliggende systemer skal integreres og fordi, der udvikles 

til klientafvikling på meget forskelligartede platforme (iPhone, Android, Blackberry mv.). 


38

Det bliver derfor essentielt at projektet scopes rigtigt fra begyndelsen både ift., hvad der er inden- og 

udenfor projektets rammer men også ift. tidsramme, samarbejdsform og afprøvning. Vi har dedikeret 

næste afsnit til test og afprøvning alene, da dette er helt centralt for projektets succes. Dette afsnit 

gennemgår projektledelse og samarbejde mere generelt. 

Styregruppe 

Det er vores erfaring, at nedsættelse af en styregruppe hos opdragsgiver fungerer godt således, at 

projektlederen er ansvarlig for den praktiske dialog og kontakt med leverandøren og løbende sikring 

af, at kravspecifikationen opfyldes, mens styregruppen er ansvarlig for godkendelsen af produktet iflg. 

de opsatte milepæle. Styregruppen bør være forankret på et beslutningsdygtigt niveau i organisationen. 

Sørg for at afstemme med styregruppen, hvad projektet IKKE vil levere. Det er bedre at tage den 

diskussion up front end til sidst. Specielt sensitivt er det med appudvikling, idet det som udgangspunkt 

tilrådes at holde appens design så simpelt som muligt (en app anvendes oftest på farten og med en 

hånd, så des færre knapper, desto bedre). Styregruppen vil hurtigt foreslå flere features, hvorfor det 

ikke er en kamp mellem features og budget snarere end en kamp mellem features og brugervenlighed, 

der skal afstemmes. 

Referencegruppe 

Sørg desuden for at have de rette kompetencer og ressourcer i projektet. Fx kan tilknyttes en ressource-/ 

reference-gruppe, der bistår projektlederen både før og under selve udviklingen. Referencegruppen kan 

bestå af brugere, fageksperter, klinikere og IT-folk, der alle sidder med vigtig viden og indsigt til gavn 

for projektet. Deres rolle er at vurdere og komme med anbefalinger undervejs i forløbet vedr. kritiske 

faktorer med konsekvenser typisk på indholds- og afviklingsniveau. 

Iterative udviklingsprocesser 

Fordi app-projekter på trods af deres begrænsning i form og indhold alligevel kan vise sig at være meget 

komplekse at udvikle, er det en god idé at benytte projektledelses- og udviklingsmetoder, der tager 

højde for, at alle krav måske ikke kan defineres fra starten, samt at der kan opstå ændringer af kravene 

undervejs, fx når man bevæger sig fra en platform til en anden. 

Et udviklingsprojekt kan enten foregå efter en vandfaldsmodel eller iterativt. I vandfaldsmodellen foregår 

udviklingen i en række faser fx; Kravspec., analyse, design, programmering og test. Herunder udvikles 

hele programmet typisk på én gang, nemlig i programmeringsfasen. I et iterativt forløb vil man som regel 

gennemføre faserne i en række kortere forløb, der ligger i forlængelse af hinanden, hvor programmet 

udvikles i form af små dele, der gradvist udbygges, til det endelige program er lavet. 

I udviklingen af medicoapps er det en fordel at arbejde med en kombination af vandfald og iteration, 

således at de indledende faser med konceptudvikling, kravspecificering og design færdiggøres efter 

vandfaldsmetoden, mens selve programmeringen gøres mere iterativ og sker i små skridt. 

Det vil i de fleste tilfælde afhængig af kompleksitet, nemlig være umuligt at lave en 100% fyldestgørende 

kravspecifikation fra starten, der besvarer og definerer alle spørgsmål. Derfor er det vores anbefaling at 

bruge moderne agile udviklingsmetoder i programmeringsfasen, der er gearet til netop dette. 

Agile Development (”adræt udvikling” på dansk) er en betegnelse for en række forskellige inkrementelle 

udviklingsmetoder. De adrætte udviklingsmetoder er kendetegnet ved udvikling i små skridt (iterationer). 

Hver iteration tilføjer ny eller forbedret funktionalitet, hvilket gør, at der løbende kan tages højde for 

ændrede forudsætninger, krav og specifikationer. 

I Adræt udvikling prioriteres opgaverne ud fra brugerens behov, og der kræves derfor en høj grad af 

involvering fra kundens/slutbrugerens side. Adræt udvikling spiller derfor godt sammen med referen- 


39

cegrupper. Blandt de mest kendte adrætte udviklingsmetoder kan nævnes Extreme Programming (XP) 

og Scrum. 

Det er vores anbefaling at samarbejdet om især udviklingsdelen gennemføres som en adræt proces 

med tæt og jævnlig kontakt projektleder og leverandør imellem, med blik på små skridt ad gangen, en 

konstant fremdrift samt med løbende dokumentation af dialog og beslutninger. Lange udviklingstræk 

uden kontakt og udokumenterede beslutninger indeholder faldgrupper og kan vise sig at få uheldige 

konsekvenser for projektet. 

Overlevering 

Projektet afsluttes, når appen lanceres, nu begynder den jo først at få et liv. Brugere giver feedback, 

fejl opdages, nye features skal tilføjes, appen skal understøttes i det daglige. Disse ting hører måske 

ikke ind i et projekt, men det er bestemt projektlederens ansvar at tænke en overlevering af appen fra 

projekt til drift. 

Test 

Testforløbet er tæt forbundet med selve udviklingsprocessen. Ofte vil opdragsgiver have et ønske om 

at følge med i udvikling og progression af appen, og omvendt vil leverandøren ofte også gerne have 

appens enkelte dele løbende godkendt. At vi har valgt at lægge testforløbet som et selvstændigt trin 

i implementeringsprocessen skyldes således ikke, at vi ser test som en isoleret del. Årsagen er, at vi 

opfatter testfasen som et utroligt centralt element i appudvikling, og især for medico apps er test og 

QA helt afgørende og kan vise sig at være ret ressourcekrævende. Medico apps skal være fejlfri, fordi 

de ofte omfatter livskritiske temaer. Og lavere fejltolerance betyder alt andet lige mere validering og 

flere test. Derfor behandler vi test som en selvstændig fase. 

Uanset om testen ligger integreret i udviklingen eller om testfasen lægges i forlængelse af implementeringen, 

er det en rigtig god ide at definere testforløbet fra starten. Både for at sikre, at det gennemføres 

som forventet, at der er sat tid af til det, og for at sikre at det tekniske set up fungerer. 

En række centrale forhold gør sig gældende, for at sikre et grundigt og professionelt testforløb. Det første 

i et testforløb er at sikre, at alle involverede parter har adgang til den tekniske løsning, dvs. appen. Det 

næste er at opstille en plan for, hvad der skal testes evt. med deadlines. Og det sidste er at skabe en 

feedback cyklus, der dokumenteres løbende og kan tilgås af alle involverede. Det er i bund og grund de 

forhold, der som minimum skal være på plads. Hvordan ovenstående organiseres og hvilke systemer, 

der benyttes er i princippet ligegyldigt, så længe de tre centrale byggesten er på plads. 

Figur 6. Figuren illustrerer de tre centrale elementer i et vellykket testforløb: 1. Adgang til appen. 2. En overordnet plan for 

testforløbet. 3. En feedbackcyklus, der dokumenteres i et fælles dokument, hvor fejlrapportering, kommentarer, feedback og 

status ajourføres. 


40

En af de store udfordringer ved apps er, at de afvikles på brugeres individuelle enhed. Det betyder, 

at appen skal installeres fysisk på en smartphone for at fungere, og for at den kan testes. Normalt får 

brugeren appen ned på sin telefon ved at downloade den fra en app store. Dette er dog forbundet med 

lidt snilde, når det gælder testversionerne. For Android Market er det faktisk muligt at lægge testversioner 

op. Her kan man aftale, at udvikleren lægger en version op i et kort begrænset tidsrum hvor den 

kan downloades af ”indviede”. Hos App Store er det dog ikke direkte muligt at lægge testversioner ud. 

Derfor skal man igennem et mere omstændigt forløb, hvor hver eneste enhed, der skal bruges til test, 

skal autentificeres, før de kan benyttes. Dvs. alle devices i opdragsgivers organisation, der tilhører folk, 

der har noget at skulle have sagt i et test- og godkendelsesforløb skal registres som del af test set-up’et. 

Herefter får de mulighed for at downloade appen til test. Dette er alt sammen forhold, som leverandøren 

kan rådgive om. Pointen er dog, at der ligger en teknisk procedure, som skal gennemføres for, at 

opdragsgiver kan få adgang til testversionen af appen, og den procedure, kan med fordel påbegyndes, 

før testforløbet skydes i gang for at undgå stilstand og forsinkelser senere i projektet. 

Vi anbefaler, at et testforløb rummer fire grundlæggende værktøjer: 

A. Den overordnede plan for, hvad der skal testes, evt. hvornår det skal gøres, og hvornår det kan betragtes 

som godkendt. Samt evt. retningslinjer for, opdatering, svartider, bekræftelser, godkendelse mv. 

B. Et fælles dokument, hvor fejl, kommentarer og status løbende ajourføres mellem opdragsgiver og 

leverandørens projektleder (PL). 

C. Et bagvedliggende ticket system el. lign. mellem PL og udviklere, som er PLs styringsværktøj ift hvad 

status er på de rapporterede fejl. 

D. Et konkret teknisk set up, hvor opdragsgiveren rent fysisk får appen i den aktuelle version ned på 

sin telefon. 

Værktøjerne kan som sagt variere. Forholdene skal dog være på plads for at sikre et struktureret, effektivt 

og dokumenteret testforløb. 

Lancering 

Lanceringsfasen har vi valgt at dele op i den konkrete publicering af appen samt de efterfølgende forhold, 

der behandles i næste kapitel. 

Lanceringen er det punkt, hvor appen er testet og godkendt af opdragsgiver. Den er klar til at gå live. 

Og for at det kan ske, skal appen uploades til de respektive app butikker, hvor den så bliver tilgængelig 

til download for brugerne verden over. For iPhones hedder app butikken ”App Store”, for Android telefoner 

hedder den ”Android Market”. For Blackburry hedder den ”App World” og for Windows Phone 

hedder det ”Marketplace”. 

Som nævnt er der forskel i både design og programmering af de forskellige platforme, og processen er 

også forskellig, når det kommer til lancering. Lanceringen foretages af enten opdragsgiver eller leverandør. 

Vi anbefaler, at leverandøren står for lanceringen, der kan være en smule krævende især første 

gang. Her skal vi kort gennemgå en række vigtige forhold vedr. lancering i App Store og Android Market, 

som tilsammen udgør mere end 65% af verdens smartphones. 

iPhone 

For at kunne lægge en app ud på App Store kræves, at personen er med i det såkaldte ”iOS Development 

Programme” og har et developer license, der koster 99 US$ pr. år. Dette er i det hele taget nødvendigt 

for, at man kan udvikle iOS apps og derfor noget, leverandøren har styr på. I selve lanceringsprocessen 

er det dog stadig vigtigt, at opdragsgiveren er med og bidrager på en række områder. Disse er: 


41

! Valg af logo til App Store og brugernes iPhone 

! Navn. Alle apps på App Store skal have et unikt navn. 

! Beskrivelse. Beskrivelsen vises i App Store og må fylde op til 4.000 tegn. Det er afgørende for, hvor 

mange apps der downloades, at beskrivelsen er god og attraktiv. Beskrivelsen laves til alle de respektive 

sprog samt engelsk. 

! Kategorier. Apps i App Store er kategoriseret og kan findes i to kategorier. Vælg disse med omtanke, 

for når appen er uploadet, kan kategoriseringen først ændres ved upload af en ny version. 

! Nøgleord (keywords). Maksimum 100 tegn. Når brugerne søger i App Store, benyttes nøgleordene af 

App Store. Nøgleord er derfor også centrale for appens udbredelse og kan kun ændres i forbindelse 

med upload af en ny version. 

! Applikation URL. Link til en webside, der beskriver appen eller til den service eller virksomhed, appen 

er relateret til. 

! Support URL. Link til et website, hvor brugere kan få support. 

! Support mailadresse. Mailadresse, hvor brugerne kan få besvaret supportspørgsmål. 

! Skærmbilleder. Fem skærmbilleder der illustrerer appens funktionalitet. Skærmbillederne vises i 

App Store og er afgørende for appens udbredelse. 

! Pris. I App Store sælges apps efter fastlagte priser og kurser. Hvis en app ikke er gratis, er mindsteprisen 

0,99 US$. Leverandøren kan rådgive videre om oprettelse af en konto hos Apple, hvor pengene 

fra salget går ind. Husk at App Store tager 30% af omsætningen på appen. 

! Lande. Skal appen kunne købes eller hentes globalt – eller skal salget begrænses til bestemte lande. 

Efter appen er indsendt til App Store følger en venteperiode, hvor Apple gennemgår og (forhåbentlig) 

godkender appen. Det tager normalt omkring en til to uger. Godkendes appen ikke er det forfra. Dvs. 

man skal gennem godkendelsesproceduren igen. Når appen er godkendt, sender Apple en e-mail om, 

at appen er klar. 

Mange af de ovennævnte detaljer kan ændres efter godkendelse uden at skulle gå gennem godkendelsesprocessen 

igen. 

Android 

Ligeledes er der for Androidplatformen en række steps, man skal igennem for at uploade appen. Den 

væsentligste forskel på App Store og Android Market er, at der ikke er en godkendelsesprocedure på 

Android Market. Fordelen ved dette er naturligvis, at selve proceduren går hurtigere. Samtidig er muligheden 

for fejl i Android apps større. 

For at kunne uploade i første omgang, skal man også her været registreret udvikler (Android Developer). 

Det koster $25. Til selve lanceringen er de centrale elementer, skal der bruges flg.: 

! Appen. Til forskel for App Store er der i Android Market en begrænsning på, hvor meget appen må 

fylde. Maksimum er 50 Mb og overskrides denne grænse, vil appen ikke være tilgængelig på en 

række håndsæt. 


42

! Skærmbilleder. To skærmbilleder der illustrerer appens funktionalitet. Skærmbillederne vises i Android 

Market og er afgørende for appens udbredelse. 

! Logo til Android Market og brugernes enhed. 

! Navn. Et unikt navn. Maks. 30 tegn. 

! Beskrivelse. Beskrivelsen må fylde op til 4.000 tegn. Det er afgørende for, hvor mange apps der 

downloades, at beskrivelsen er god og attraktiv. 

! Promo text. Android Market operer ud over selve beskrivelsen med en promoveringstekst (maks. 80 

tegn) for hver app. Den har stor betydning for appens appel og derved for, hvor mange der downloades. 

Til teksten hører også en separat grafik. 

! Kategori. Vælg appens kategori. 

! Kopibeskyttelse (copy protection). Android apps kan kopieres fra brugernes telefon med mindre de 

er kopibeskyttede. Dvs. at betalte apps skal benytte denne feature. 

! Content Rating. Handler om hvorvidt indholdet er egnet til børn. 

! Pris. Angivelse af om appen er gratis eller betalt. 

! Lokation. Angivelse af hvilke lande appen skal være tilgængelig fra. 

! Pris. På Android Market sælges apps efter fastlagte priser og kurser. Hvis en app ikke er gratis er 

mindsteprisen $0,99 (DKK: 6 DKK - 1200 DKK). Leverandøren kan rådgive videre om oprettelse af en 

konto hos Google, hvor pengene fra salget går ind. Fee på Android Market er 30% af omsætningen 

på betalings-apps. 

Når disse steps er klaret, bliver appen lanceret. 

Herefter kaster vi blikket på post-lanceringsaktiviteterne. 


43

Tjekliste 

Implementeringsfasen 

Specifikation 

! Ideudvikling 

! Prototyping 

! Kravspecificering 

Design 

! Designretningslinjerne defineret i designbrief 

! Navigation, interaktion, flow og tilgængelighed indtænkt 

! Design til forskellige platforme 

! Ikoner identificeret og udarbejdet 

! Interfacet brugertestet 

! Rentegning 

! Overlevering til udviklerne 

! Style guide 

Udvikling 

! Applikationstype besluttet 

! Inhouse eller outsourced besluttet 

! Integrationspunkter identificeret 

! IT-folk taget med på råd 

! Projektplan opdateret 

Test 

! Overordnede testplan afstemt 

! Et fælles dialogdokument sat op 

! Et bagvedliggende ticket system 

! Teknisk set-up planlagt 

Lancering 

! Logoer 

! Navn 

! Beskrivelse 

! Kategori 

! Nøgleord 

! Skærmbilleder 

! Pris 

! Promo text 


44

7. 

Efter udviklingsprocessen 

- Markedsføring og drift 

I dette afsnit ser vi på de forhold, der gør sig gældende efter selve lanceringen af appen. Det er forhold, 

der allerede er blevet drøftet og taget i betragtning i de forudgående overvejelser. På mange måder 

er post-lanceringsfasen afgørende for, om appen tjener sig hjem og bliver en succes. Bliver appen blot 

lagt ud i app butikken uden nogen form for synliggørelse eller opdatering er appens livscyklus dømt til 

at blive kortvarig allerede fra starten. Så hvor FØR-overvejelserne handler om at skabe den rigtige app 

via formål, strategi og set-up, handler EFTER-overvejelserne om at få appen til at leve bedst muligt via 

eksponering og fastholdelse. 

For at styrke appens udbredelse og levetid, er der især tre grundlæggende forhold, der skal tages hånd om: 

Figur 7. Illustrationen viser hvordan markedsføring, opdatering og videreudvikling booster downloads og forlænger appens levetid. 


Markedsføring 

App butikker udgør en selvstændig distributionskanal, der betyder, at apps når ud til nye målgrupper 

gennem deres egen globale kanal. Man skal som bruger gennem en app butik for at downloade appen, 

og derfor er det også et at de steder, brugerne kigger efter nye apps. 

App butikker er et helt system med egen promoveringsmekanismer, top-10 lister, nyeste apps, dagens 

app osv., der alt sammen er med til at eksponere appene og booste antallet af downloads. Derfor er det 

naturligvis centralt, at appen får de bedste forudsætninger for at fremstå godt i app butikkerne gennem 

flotte skærmbilleder, stærke og relevante keywords samt en retvisende og tiltrækkende beskrivelse. 

Flere af disse elementer kan løbende rettes til og optimeres ud fra, hvad der synes at fungere bedst. 

App butikkerne giver desuden mulighed for at tilgå brugbar statistik for, hvor mange der downloader appen 

samt en række andre relevante tal. Herunder hvilke modeller der er benyttet, hvilke lande brugerne 

kommer fra, hvor længe brugerne har appen liggende osv. Der er bemærkelsesværdig stor forskel på, 

hvad Apples App Store og Android Market giver af statistik, og gældende for iOS-app bør det fra starten 

besluttes, hvor meget statistik, der er behov for. Vær opmærksom på, at udvidet statistik på iPhones 

som tingene er i øjeblikket betyder ekstra udviklingsarbejde, og dette skal drøftes med leverandøren. 

Desuden eksisterer der 3. parts software (bl.a. Flurry, Localytics og GoogleAnalytics), der giver mulighed 

for yderligere interessant statistik. 

Således er en central parameter for appens synlighed, hvordan den fremstår i app butikken. Det er så 

at sige en hygiejnefaktor i markedsføring af appen. Der eksisterer hertil også deciderede mobile appsportaler 

på nettet, hvor det er godt at have sin app liggende. 

Den anden helt væsentlige del af markedsføringen er eksponering på andre kanaler. Det grundlæggende 

spørgsmål, man her bør stille er; ”Hvor er målgruppen?”. Og svaret vil fortælle, hvilke medier man skal 

benytte. En god erfaring er, at onlinemediet ofte er stærkere end offline, når det gælder om at drive folk 

til en online aktivitet som apps er. QR-koder, som er en let måde at koble off- og online sammen på og 

er derfor også et interessant element, der kan skabe trafik. I bund og grund handler markedsføringen 

om at synliggøre appen, hvor den er mest relevant og gøre den let tilgængelig. Et samspil af medier vil 

ofte give den bedste effekt. 

Figur 8. Figuren viser eksempler på markedsføringsaktiviteter, der bidrager til, at appen opnår flere downloads. 


46

Opdatering 

En anden afgørende faktor for appens udbredelse og levetid er, om indholdet opdateres eller ej. Man 

kan sige, at spørgsmålet om opdatering, som beskrevet tidligere, i høj grad handler om, hvorvidt appens 

indhold er statisk eller dynamisk. Uanset, hvordan man vender og drejer det, er der udgifter forbundet 

med opdatering. Enten indledningsvist i form af omkostninger til integration med eksisterende backend 

systemer eller udvikling af en ny backend eller efterfølgende i form af udgifter til dækning af egne og 

leverandørressourcer ved en mere manuel opdatering. Så opdatering koster. Omvendt skaber det en 

stor værdi både for brugerne og for udgiveren. 

Faktum er nemlig, at apps, der opdateres, forbliver længere på brugernes smartphones af den simple 

grund, at embeddede apps, hvor indholdet ikke ændres, hurtig mister sin værdi. Undtagelsen er selvfølgelig 

apps med meget konkrete funktioner som bestil togbillet, find vej, optag lyd osv. Disse apps har 

ofte meget specifikke funktioner. En god tommelfingerregel er således, at jo vigtigere indholdet er for 

værdiskabelsen set ift. funktioner, jo vigtigere er opdatering for appens relevans og levetid. Er indholdet 

med andre ord drivende for værdiskabelsen, er muligheden for at opdatere vigtig. 

Har man valgt at udvikle en opdatérbar app, er det hensigtsmæssigt at opstille en plan for opdateringerne 

for et halvt år ad gangen. Planen bør dække spørgsmål som, hvad skal opdateres, hvornår, med hvad 

og af hvem. En række underspørgsmål vil typisk derudaf dukke op om, hvilket indhold har vi allerede 

tilgængeligt andre steder? Hvilke ressourcer kræves? Hvad er realistisk? Hvem kan producere det? 

Content strategi er en måde at anskue indhold på, som handler om, at hvis man alligevel publicerer 

indhold, så kan man lige så godt gøre det, som en professionel udgiver. Arbejd derfor med en fast redaktion, 

faste bidragsydere, en forretningsmæssig strategisk forankring og med en plan, der er realistisk. 

Videreudvikling 

I denne guide sonderer vi mellem opdatering af appens indhold og lancering af nye versioner af appen, 

som vi karakteriserer som videreudvikling. 

Videreudvikling af en app er nødvendig af flere grunde. For det første er det nødvendigt at forbedre 

appen over tid, hvis den skal holdes i live herunder fejlretning og optimering. For det andet udvikler 

teknologierne sig, hvilket betyder, at en app simpelthen bliver forældet både i form og funktion, hvis den 

ikke opdateres. For det tredje kan appens værdi forøges væsentlig ved at udvikle den. Og for det fjerde 

kan man tale om en form for ”revitalisering” af appen hos brugerne, når der kommer nye versioner. 

En god kilde til inspiration, når det kommer til videreudvikling af appen, er at se på, hvad brugerne 

mener om appen. Både statistik om hvilke funktioner der benyttes mest, samt hvilke elementer, der 

downloades mest er interessant og giver en god indikation af, hvad der kan gøre appen endnu mere 

succesfuld. Hertil har brugerne mulighed for både at rate (Vurdere) og kommentere på appen i app butikken. 

Brugernes kommentarer er ligeledes værdifuld viden. Slutteligt er der mulighed for efter noget tid 

at afholde en fokusgruppe blandt brugerne, der kan give et nuanceret billede af punkter til forbedring 

og fremtidige udviklingsmuligheder. Hvordan bruges appen? Hvad er det bedste ved appen? Hvordan 

kan man gøre den endnu bedre? 

Brugerdialog og -involvering i idé-generering er et stærkt redskab til videreudvikling af en unik, relevant 

og succesfuld app. De fleste apps opstår ud af gode ideer, og de bedste apps formår at fastholde brugerne 

i længere tid gennem fornyelse. Derfor er brugerne en central inspirationskilde for videreudviklingen, 

og de kan med fordel involveres. 

Når der uploades nye versioner af appen, vil det være synligt direkte på brugernes enheder med en lille 

grafisk markering. Brugerne skal selv aktivt hente den nye version, hvilket på den ene side ikke garanterer, 

at alle brugere har den nyeste version liggende, omvendt skaber det top-of-mind hos brugerne 

og minder dem om appen. 


47

8. 

Efterord 

Tanken med denne guide har været at udarbejde en inspirerende og praktisk indføring i det at skabe en 

medico app. På mange måder er udviklingsprocessen for medico apps identisk med udviklingsprocessen 

for andre typer apps, og derfor er denne guide også mere bredt anvendelig. De steder, medico området 

dog især adskiller sig fra andre områder på, er inden for QA og regulatury. Derfor har dette emne fået 

en væsentlig vægtning og dybde. 

Udarbejdelsen af guiden har været en berigende rejse for Medico Innovation og forfatterne bag guiden. 

Mange ressourcestærke folk har været involveret i processen og har bidraget, hvilket undervejs har 

betydet både kvalificering af de eksisterende afsnit, såvel som tilføjelse af nye. Tilbage står vi således 

med en klar erkendelse af, at emnet på ingen måde er udtømt, og at guiden på ingen måde kan være 

fyldestgørende for evigt. 

Derfor er det vores ønske at arbejde videre med guiden og forhåbentlig i løbet af 2012 udkomme med 

en version to med flere cases, med opdatering på det regulatoriske område, og hvor mere empiri indgår. 

Det er vores håb, at vi kan få endnu flere bidragsydere til at dele deres erfaringer med udvikling 

af medico apps, at vi kan finde endnu flere eksempler på succesfulde medico apps til inspiration for 

andre, og at vi kan blive ved med at bidrage til området gennem en guide, der er opdateret og tilbyder 

aktuel og relevant viden. 

Vi opfordrer derfor også folk, der har ideer eller ønsker at bidrage med input til den næste version, til 

at henvende sig til os her: 

mail@medico-innovation.dk 


9. 

Begreber og terminologier 

Både applikations- og medicoområdet bruger termer og ord, der har specifik mening og anvendelse. 

For at skabe overblik og forståelse, har vi i dette afsnit opstillet en ordliste med forklaring af de gængse 

termer. Desuden har vi indsat en række relevante links, som der gennem guiden refereres til. 

510 (k) En af flere mulige godkendelser af de amerikanske sundhedsmyndigheder (FDA) for medicinske 

devices, 510 (k) kan anvendes, hvis et lignende apparat findes i forvejen. 

Android Et åbent styresystem udviklet af Google til Android (Droid) mobiltelefoner og tablets. 

Android Market Googles markedsplads for applikationer. 

ANSI American National Standards Institute; det amerikanske standardiseringsorgan sammenligneligt 

med DS og ISO. 

API Application Programming Interface, softwaregrænseflade, der tillader et software at interagere med 

et andet software. Et API er implementeret i applikationer (programmer), programbiblioteker og 

styresystemer. Et typisk eksempel på dette er, når en app ”taler” med en server for at hente en fil, 

hvorefter serveren på appens vegne vil indlæse filen og overføre den relevante fil til appen. 

App Forkortelse for ”applikation” eller på dansk ”program”, som installeres og afvikles lokalt på en 

mobiltelefon, tablet eller PC. I denne guide refererer app udelukkende til mobil applikation med 

mindre andet er nævnt. 

App Store Apples offentlige markedsplads for applikationer til iPod Touch, iPhone og iPad. 

App butikker I denne guide benyttes ”app butikker” generelt til at dække betydningen af online portaler/ 

markedspladser, hvorfra apps til de forskellige mobile platforme distribueres. 

App World Blackberrys app butik for applikationer til Blackberry telefoner. 

Augmented reality Brug af teknologi til at skabe en realtids tilføjelse til den virkelighed, man selv oplever, fx ved at 

holde telefonen op foran en bygning skriver den adressen, slår telefonnumre op eller angiver 

vejrudsigten for det pågældende sted. 


Bekendtgørelse om Den danske implementering af Medical Device direktivet. Se mere på www.retsinformation.dk 

medicinsk udstyr 

Bemyndiget organ Organ som har fået overdraget dele af varetagelsen af et direktiv. I Danmark findes der et 

bemyndiget organ, DGM. 

Bench testing Prototypetesting (materialer, metoder, funktionalitet) i et kontrolleret laboratorie miljø (ikke i dyr 

eller mennesker). 

CE mærke Godkendelse af bl.a. medicinsk apparatur inden for EU, kan opdeles i flere klasser afhængig af 

patient-risiko profil. 

CME Continued Medical Education; sundhedsfagligt personale i USA skal kontinuerligt indsamle CME 

point for at opretholde deres licens til at praktisere. 

CMS Content Management System, software til at organisere og lette arbejdet med at oprette 

dokumenter og anden information og hvorigennem enkeltpersoner eller grupper kan håndtere en 

mængde elektronisk indhold, for eksempel dokumenter, filer og billeder. 

Competitive audit Vurdering af interaktiv markedsføring, salg og service samt taktik for dine vigtigste konkurrenter. 

Herunder Gap analyse og identifikation af best practice løsninger. 

Corporate design guide Dokument der beskriver, hvor og hvordan logo, skrifttyper og farver ol. skal bruges, i praksis og i 

forskellig kontekst. 

CPT koder Common Procedural Termonology, koder anvendt til at klassificere medicinske procedurer ifm 

standardiseret afregning. 

CRO Contract/Clinical Research Organization, eksternt/uafhængigt forskningslaboratorium, der ofte 

anvendes til ansøgning om medicinske godkendelser. 

Definitioner Henvisning til centrale definitioner fra Medico-direktivet og som er gengivet i Bekendtgørelse om 

medicinsk udstyr. 

DGM Dansk Godkendelse af Medicinsk Udstyr. Link: http://www.dscert.dk/da-DK/DGM/Sider/DGM.aspx 

DRG Diagnosis Related Group, et sæt af 467 grupper anvendt i Danmark til afregning af medicinske 

tjenesteydelser. 

EPO European Patent Office, bureau hvor der kan ansøges om patenter i 38 europæiske lande. 

FDA Food and Drug Administration - de amerikansk sundhedsmyndigheder, der bla. udsteder 

godkendelser af medicinsk apparatur og auditerer produktionsfaciliteteter. 

“Draft Guidance For Industry and Food and Drug Administration Staff – Mobile Medical 

Applications”. Juli 2011. http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/ 

GuidanceDocuments/ucm263280.htm 

Freedom to operate Muligheden for at kommercialisere et produkt uden at krænke eksisterende patenter/IPR. 

GMP Good Manufacturing Practice, en kvalitetssikringsstandard under FDA for producenter af medicinsk 

udstyr. Erstattet af QSR. 

Harmoniserede Aktuel liste findes via Lægemiddelstyrelsens hjemmeside. 

standarder www.laegemiddelstyrelsen.dk 

HTTPS HyperText Transfer Protocole Secure; en kommunikationsprotokol til internettet til afsendelse og 

modtagelse af sikrede data. 


50

Hybrid app(likation) En hybrid app kombinerer elementer af såvel den lokale klient (native app; typisk en smartphone, 

en tablet eller i princippet også en PC) samt en web-applikation, der behandler data udtrukket fra 

en eller flere platforme, fx et medicinsk apparat. I denne guide henvises til apps, der er tilknytte 

eksternt apparatur, når termen ”hybride apps” benyttes. 

Ice Cream Sandwich Navnet på det operativsystem Android smartphones benytter også kaldet Android 4.0. 

IDE Investigational Device Exemption, en tilladelse fra FDA til en læge eller klinik til at bruge et apparat 

før det er endeligt godkendt, oftest som del af et klinisk studie. 

In Vitro Uden for kroppen, begreb der anvendes om fx diagnostisk udstyr, der anvendes uden for kroppen; fx 

pulsmåler. 

In Vivo Inden i kroppen; begreb der anvendes om fx prøver, der opsamles inden i kroppen og kan måle på 

hele organismen; fx i forbindelse med medicinsk forskning. 

IPR Intellectual Property Rights; et begreb for hvem, der har rettighederne til en given opfindelse/nyhed. 

ISO International Organisation for Standardization. ISO er ikke et akronym men en omskrivning af det 

græske ord isos med betydningen lighed. 

Klassificeringsregler Reglerne for klassifikation inden for EU og deres anvendelse er beskrevet i Medico-direktivet og 

MEDDEV 2. 4/1. 

Klinisk afprøvning Udføres om nødvendigt som en del af Klinisk evaluering skal følge Medico-direktivets bestemmelser. 

Den harmoniserede standard DS/EN ISO 14155:2011 kan følges for at opfylde direktivets krav. 

Klinisk evaluering Skal foreligge jf. Medico-direktivet . Vejledning findes i MEDDEV 2.7/1. 

Klinisk studie Et forskningsstudie, der skal afklare specifikke spørgsmål relateret til diagnose eller terapi/ 

behandling, herunder nyt apparatur og processer. Kliniske studier/test skal hjælpe med at afgøre, 

hvorvidt nye behandlingsformer er sikre og effektive. 

Lægemiddelstyrelsen Kompetent organ i Danmark. Denne hjemmeside www.medicinskudstyr.dk er en meget central 

reference til den regulatoriske ramme indenfor EU og lovgivningen i Danmark. 

LBM Location Based Marketing; anvendelsen af lokationsteknologi (fx GPS) til at målrette 

markedsføringen. 

Look’n’feel Anvendes i forbindelse med en grafisk brugergrænseflade og omfatter aspekter af dens udformning, 

herunder elementer som farver, former, layout og skrifttyper (”look”), samt opførsel af dynamiske 

elementer såsom knapper, æsker, og menuer (”feel”). 

Målefunktion Medicinsk udstyr skal opfylde Rådets direktiv 80/181/EØF - Se i øvrigt MEDDEV 2.1/5. 

MDD Medical Device Directive 93/42/EEC - en af tre regulatoriske godkendelses direktiver i EU, gældende 

for medicinsk apparatur. 

MEDDEV 2. 4/1 MEDICAL DEVICES: Guidance document Classification of medical devices. Vejledning i at anvende 

Medico-direktivets klassificeringsregler. Bemærk: EU er på vej med en vejledning af klassificering af 

standalone software, som er væsentlig i forhold til Apps. 

MEDDEV 2.1/5 MEDICAL DEVICES: Guidance document - Medical devices with a measuring function. 

Vejledning i at afgøre hvornår medicinsk udstyr har målefunktion. 

MEDDEV 2.7/1 GUIDELINES ON MEDICAL DEVICES Clinical evaluation: Guide for manufacturers and notified bodies. 

Vejledning i at opfylde Medico-direktivets klassificeringsregler. 

Medico-direktivet Rådets Direktiv 93/42/EEC om medicinsk udstyr og Rådets Direktiv 2007/47/EC. 

Kan findes på www.medicinskudstyr.dk 


51

MEDLINE Medical Literature Analysis and retrieval System Online - litteratur database af interesse for 

medicobranchen. 

Mobi Health News ”FDA Regulation of Mobile Health”, 2010, Report. http://mobihealthnews.com/wp-content/pdf/ 

FDA_Regulation_of_Mobile_Health.pdf 

NDA Non-Disclosure Agreement. En aftale mellem to eller flere parter om at den part, der modtager 

konfidentiel information fra en anden part ikke må udbrede denne information til andre inden for en 

given tidshorisont. 

NSI National Sundheds-IT (NSI) er en selvstændig styrelse under Sundhedsministeriet, der har to 

hovedopgaver: 1) At varetage den nationale styring af IT-understøttelsen af sundhedsområdet, 

herunder samarbejdet med regionerne og kommunerne. 2) At varetage drift og udvikling af 

Indenrigs- og Sundhedsministeriets IT-systemer på sundhedsområdet efter nærmere aftale med de 

enkelte styrelser mv. 

OEM Original Equipment Manufacturer - en OEM virksomhed sælger non-branded produkter til andre 

virksomheder, som herefter sælger produkterne i deres eget navn. 

OVI Store Nokias markedsplads for applikationer. 

Peer review Gennemgang af kliniske studier og artikler af ekspert på området. 

PMA Pre-market approval, den absolut mest stringente vej gennem FDA til godkendelse af medicinsk 

apparatur i USA, PMA er nødvendigt, hvis apparatet er så nyt, at der ikke findes sammenlignelige 

produkter på markedet. 

POC(T) Point Of Care (Technology) - medicinsk apparatur, der tillader anvendelse eller prøvetagning og 

analyse tæt ved patienten. 

Pull tjeneste Tjeneste, der sender information til mobile enheder, hvis brugeren selv efterspørger aktivt. 

Push tjeneste Tjeneste, der sender information til mobile enheder uden at brugeren selv efterspørger det (skal 

som udgangspunkt initielt tillades af brugeren). 

Predicate device ”Predicate Device”, begreb i FDA sammenhæng om udstyr, der går forud (allerede findes) 

og som godkendelsesprocessen kan henvise til. http://www.fda.gov/MedicalDevices/ 

DeviceRegulationandGuidance/HowtoMarketYourDevice/PremarketSubmissions/ 

PremarketNotification510k/ucm134571.htm 

QA Quality Assurance, en proces der sikrer at produktet virker som specificeret. 

QC Quality Control; procedurer designet til at opfange/identificere defekte produkter inden for 

produktionen, inden de kommer på markedet. 

QR koder Quick Response; to-dimensionelle stregkoder (firkant med sorte og hvide punkter) der kan linke 

videre til telefonnumre, sms eller websites, som herefter kan identificere telefonen og levere 

relevant feedback. 

QSR Quality System Regulation; en guide der beskriver hvorledes FDA’s auditør korps inspicerer 

producenters kvalitetssystemer. 

Reimbursement Betaling for en medicinsk ydelse af en tredje-part, oftest sygesikringen, på dansk anvendes oftest 

synonymer som refusion eller godtgørelse. 

ROI Return on investment, forholdet mellem investeringen og udbytte af en given investering 

ROI=udbytte(db)/investering(Omk). 

SDK Software Development Kit (SDK eller ”devkit”) er typisk et sæt af software-udviklingsværktøjer, 

der giver mulighed for at interagere med en bestemt softwarepakke, software rammer, hardwareplatform, 

edb-system, video, spillekonsol, styresystem, eller lignende platform, fx en API. 


52

Streaming En teknik til overførsel af data i en jævn strøm; fx til at se video eller lytte til musik uden at hele 

indeholdet først skal downloades. 

Tablet (PC) Bærbar skærm uden fysisk tastatur, fx en iPad eller Samsung Galaxy 

Top-of-mind Når folk først tænker på dig/dit mærke til at opfylde deres produkt eller service behov. 

VPN Virtual Private Network; teknologi, der anvendes til at skabe sikker (privat) forbindelse; oftest fra en 

privat internetopkobling til en virksomheds centrale server. 


53

10. 

Om folkene bag guiden 


Strategisk direktør, Umloud Untd aps 

15 års erfaring med digital strategi- og konceptudvikling. Arbejder til dagligt med at styrke virksomheder 

og organisationers brug af apps og mobile media gennem udvikling af mobile strategier og skalerbare 

mobile platforme, der skaber forretningsmæssig værdi. 


Kvalitetschef, Pallas Informatik A/S 

20 års professionel erfaring inden for software development, som udvikler og projektleder. Bred erfaring 

inden for internationale brancheløsninger - ikke mindst til høreapparatindustrien. Interesseområdet er 

p.t. telemedicinske løsninger og software som medicinsk udstyr. 

Morten Gjøl 

Konsulent, mortengjøl.dk 

Selvstændig konsulent, har i mere end 15 år arbejdet med produkt- og forretningsudvikling samt branding, 

forandringsledelse og kultur–forandringsprojekter. Ejer tillige netværksvirksomheden NetworkingCompany. 


Director for Medico Innovation 

15 års baggrund i den kommercielle del af medico branchen i Danmark, Tyskland og USA og senest et 

år i krydsfeltet mellem klinik, forskning og industri. Idémand til interessenetværket Devices n’ Apps. 


54

Læs guiden her - Medico Innovation

Create successful ePaper yourself

Delete template?

Save as template ?