medico apps a practitioner's guide

Medico appsA practitioner’s guide

AfUri Duvald AndersenJens Peter AndersenMartin Stenfeldt

RedaktionMorten Gjøl

www.medico-innovation.dk

DANSKVERSION 1.1

Medico appsA practitioner’s guide

AfUri Duvald AndersenJens Peter AndersenMartin Stenfeldt

RedaktionMorten Gjøl

www.medico-innovation.dk

DANSKVERSION 1.1

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

3MEDICO APPS - A PRACTITIONER’S GUIDE

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

4

Stort set alt medico teknologi gennemgår i øjeblikket en elektronisk forvandling og udvikling. Efter-spø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.

1.Indledning

MEDICO APPS - A PRACTITIONER’S GUIDE


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 in-novationspartnerskaber, 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

Martin StenfeldtDirector, MEDICO INNOVATION

MEDICO APPS - A PRACTITIONER’S GUIDE 6

Formål & målgruppeDenne 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ærdiska-belsen 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. Udviklingsproces-sen 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ænsningDet 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 ud-vikling 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.

2.Formål og afgrænsning


I dette kapitel ser vi nærmere på kvalitetssikring (Quality Assurance; QA) og de regulatoriske krav gæl-dende 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æs-sige 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 ud-styr 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 spe-cifikation 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

3.QA og regulatory for medicoindustrien


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 udstyrMedicinsk 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 omkost-ninger, der vil medgå til myndighedsgodkendelsen af det.

Definitionen af medicinsk udstyrEthvert instrument, apparat, udstyr, software, materiale eller anden genstand anvendt alene el-ler 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 kor-rekt 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 farma-kologisk, immunologisk eller metabolisk vej, men hvis virkning kan understøttes ad denne vej.

Markedsføring og CE-mærkning af medicinsk udstyrHvis 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 billedop-tagelses formål. Det bliver først medicinsk udstyr i det øjeblik fabrikanten specificerer det som sådan,


altså når det ligger inden for ovenstående definition. Her er det afgørende, hvad der påstås fra fabri-kantens 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 kon-sekvensen 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ålDen 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.


DirektiverIndenfor 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 menneske-lige 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 kvalitetsikringI 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 an-vendelsen 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 be-myndiget 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 tendens-indikation. 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 blods-tryksmå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 overensstemmel-seserklæring som beskrevet i Medico-direktivet. Udstyrsklassen fastlægges ved en forhandling mellem


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 appsVed 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 medi-cinsk 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 standarderEU 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 myndighe-dernes 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.


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. Litteratur-studiet 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 soft-ware 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 syste-mer. 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.


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 al-lerede 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).


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)


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.

4.Cases



CaseTV2 Førstehjælp

Skabt for at redde livTV2 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 ambi-tionen 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 succeskriterierFormå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...

Navn TV2 FørstehjælpUdgiver TV2Platforme iPhone + AndroidUdgivet Oktober, 2011Målgruppe Den brede befolkning. B-t-CDownloads 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ød-vendigt 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.



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.

UdviklingsprocessenSelve 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 tek-niske løsning.

Processens faser var flg.:

1. IdékatalogHerunder: 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 designHerunder: Fastlæggelse af designmæssige retningslinjer (ej fancy), designoplæg, tilretning og godkendelse.

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

5. TestforløbHerunder: Struktureret test set-up med afprøvning på egne testtelefoner.

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

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

Udfordringer og læringTV2 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.



Særlige forhold for medical appsTV2 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åd1. 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.



CaseAirway 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 bruger-interface, der fungerer godt og intui-tivt 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ægerVirksomheden 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æstesi-læ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 ap-paraturet benyttes korrekt. Og derfor er træning af høj interesse hos lægerne. Tidligere blev uddan-nelsesopgaven 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 eks-ponere 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.



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.

Formål og succeskriterierAppen er henvendt til anæstesilæger globalt. Onlineplatformen rummer mere interaktion og infor-mationsdybde, 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 ap-pen ville opnå 1.000 downloads i 2011. Da appen senere ramte app butikkernes top-10 lister nærmest eksploderede antallet af downloads.

UdviklingsprocessenSelve udviklingen og indholdsproduktionen blev gennemført af den samme underleverandør, som havde udarbejdet onlineplatformen. Ambu forestod projektledelsen.

Processens faser var flg.:

1. AfdækningBehovsafdækning hos brugerne. Hvor meget bruger de online teknologi? Hvor mange har en smartphone? Dialog med målgruppen.

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

3. SpecifikationKravspecifikation 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. IndholdTekniske udfordringer løses og specifikationerne revurderes i en gensidig dialog, særligt hvor forvent-ningerne 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. DriftAppens indhold er statisk, og der gøres ikke mere ved den pt.



Udfordringer og læringAmbu oplevede, at især designfasen var udfordrende i udviklingsprocessen. Det at skalere en eksiste-rende 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æn-gere 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å eksi-sterende 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ær-dien 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 videndelings-app som denne skal udvikles med indhold, der kan opdateres. Det er centralt for appens levetid og ROI.

Særlige forhold for medical appsAmbu 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!”.

Tre lavpraktiske råd1. 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 butikkerne3. Opdateringsmuligheder er afgørende for appens levetid. Tænk i et CMS, der kan styre både web og

app ét centralt sted fra.



CaseMobile MIM

Navn Mobile MIMUdgiver MIM Software Inc. (USA)Platforme iPhone + iPadUdgivet Juni 2008/September 2011Målgruppe Radiologer, Lægepraksis og patienter Downloads til d.d. 20.000+ stk.Samlet budget Ikke oplystUdviklingstid Ca. 8 mdr, første version: 2 ugerStø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 versionVirksomheden 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 billedbe-handling begyndte.

Gennem årene har MIM software udviklet software løsninger, der gjorde arbejdet med medicinske bil-leder 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.

Formål og succeskriterierAppen 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



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 medi-cinske 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”.

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

1. DesignHerunder behovsafdækning, udvikling af kravspecifikation og prototype.

2. UdviklingInvolvering 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 testNy funktionalitet afprøves.

4. Fuld test Alle funktionaliteter afprøves.

5. FejlretningDe sidste fejl rettes.

6. LanceringI App Store.

Udfordringer og læring1. 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å til-fæ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)



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.

Særlige forhold for medical appsI 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.

Tre lavpraktiske råd1. Kill you darlings – en app er bedst, når den er simpel at betjene; så undgå alt for avancerede funk-

tioner. 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.



De grundlæggende overvejelserFø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 udar-bejdes. 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 sandsynlig-gø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.

5.Før udviklingsprocessen- Afdækningsfasen


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 spe-cifikt 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 konkurren-terne 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 hjem-meside 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, accelero-meter, 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.

EksempelAmbu’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ålFør et konkret projekt begyndes, er det en god idé at definere formålet med appen fx på basis af busi-nesscasen. 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.


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: SpecifikkeM: MålbareA: AttraktiveR: RealistiskeT: TidsbegrænsedeE: Evaluérbare.

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

MålgruppeSom 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.

EksempelAmbu’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 produktinforma-tion, 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.

TeknologiNå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 forskel-lige platforme ses her:


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 udvik-lingsmæ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/digitale-losninger/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å verdens-plan 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.


Et andet forhold vedr. IT-system ligger i beslutningen om, hvorvidt appen skal være statisk eller dyna-misk. 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æs-sig 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 inter-nationale 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 fagter-mer 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 blod-tryksmå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, ka-mera, 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 an-vendelighed. Leverandøren vil typisk kunne rådgive om disse forhold, og de rigtige beslutninger kan træffes, hvis spørgsmålene adresseres indledningsvist.


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

BudgetBudgetdelen er naturligvis væsentlig for de fleste og hænger tæt sammen med den opstillede business-case, 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 forve-jen. 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)

TidTidshorisonten 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 opstil-les? 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 kom-petencer 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 opdrags-giver 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.


Eksempel kontaktprisAmbu’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 be-tragtning af en apps værdi.

ROI – Return on investmentHvis 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.

JuraStø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 ind-hentning 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.


TjeklisteDe 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



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 sam-menfattes i fem trin:

SpecifikationSpecifikationsfasen ligger på en måde mellem planlægning og udvikling. For udvikling uden en forud-gå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é-udviklingPlanlæ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.

6.Udviklingsprocessen- En fremgangsmåde i fem trin


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) sid-der 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åleen-hed, 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.

PrototypingNår appens koncept er defineret og beskrevet, kan appens anatomi visualiseres mere i dybden. Wi-reframing 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 struktu-reret, 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 wirefra-mes, 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”.

KravspecificeringUd 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


beskrive de bagvedliggende forhold og processer, som ikke nødvendigvis kommer med i prototypen. Herunder tekniske forudsætninger, kommunikation med backend system, svartider, funktionalitet (søg-ning, 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æggelsePointen 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 specifika-tionsfasen 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. Der-ved 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.

DesignDesignfasen 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 eksiste-rende 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ænge-lighed 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.


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 brugerfornemmel-sen 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.

UdviklingUdviklingsfasen 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 leveran-dø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.

ApplikationstyperDen 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


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 appsEr 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 appsKan 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, kon-takter 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


Framework appsDen 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 outsourcedDen 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 udvik-lingen 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.

ProjektledelseLedelse af et medicoapp udviklingsprojekt adskiller sig på især to områder fra at lede andre software-udviklingsprojekter. For størstedelens vedkommende er det relevant at inddrage regulatoriske godken-delsesprocedurer, 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.).


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.

StyregruppeDet 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 organisatio-nen. 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.

ReferencegruppeSø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 udviklingsprocesserFordi 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-


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.

TestTestforlø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 implemente-ringen, 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.


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 testver-sioner 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 leveran-dø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 betrag-tes 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, ef-fektivt og dokumenteret testforløb.

LanceringLanceringsfasen har vi valgt at dele op i den konkrete publicering af appen samt de efterfølgende for-hold, 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 te-lefoner 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 leve-randø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.

iPhoneFor 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:


! 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 re-spektive 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, ap-pen 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 mindstepri-sen 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 godkendel-sesprocessen igen.

AndroidLigeledes 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 mu-ligheden 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.


! Skærmbilleder. To skærmbilleder der illustrerer appens funktionalitet. Skærmbillederne vises i An-droid 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 down-loades. 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.


Tjekliste ImplementeringsfasenSpecifikation! 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



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.

7.Efter udviklingsprocessen- Markedsføring og drift


MarkedsføringApp 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 ap-pen 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 apps-portaler 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.


OpdateringEn 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 selv-fø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 re-daktion, faste bidragsydere, en forretningsmæssig strategisk forankring og med en plan, der er realistisk.

VidereudviklingI 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 butik-ken. 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 garan-terer, at alle brugere har den nyeste version liggende, omvendt skaber det top-of-mind hos brugerne og minder dem om appen.


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 ind-gå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:

[email protected]

8.Efterord


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.

9.Begreber og terminologier

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.dkmedicinsk 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.


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


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, hardware-platform, edb-system, video, spillekonsol, styresystem, eller lignende platform, fx en API.


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.


Uri Duvald Andersen Strategisk direktør, Umloud Untd aps15 å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. Jens Peter AndersenKvalitetschef, Pallas Informatik A/S20 å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.dkSelvstændig konsulent, har i mere end 15 år arbejdet med produkt- og forretningsudvikling samt branding, forandringsledelse og kultur–forandringsprojekter. Ejer tillige netværksvirksomheden NetworkingCompany. Martin StenfeldtDirector 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.

10.Om folkene bag guiden