1. No category

DANSK
VERSION 1.1
Medico apps
A practitioner’s guide
Af
Uri Duvald Andersen
Jens Peter Andersen
Martin Stenfeldt
Redaktion
Morten Gjøl
www.medico-innovation.dk
DANSK
VERSION 1.1
Medico apps
A practitioner’s guide
Af
Uri Duvald Andersen
Jens Peter Andersen
Martin Stenfeldt
Redaktion
Morten Gjøl
www.medico-innovation.dk
Medico apps – A practitioner’s guide.
Dansk version 1.1, januar 2012.
Udgivet af MEDICO INNOVATION.
ISBN 978-87-995083-0-3
Gengivelse af denne udgivelses indhold eller dele deraf er ikke tilladt uden forudgående skriftlig aftale med MEDICO INNOVATION.
Guiden kan downloades gratis på www.medico-innovation.dk
1. Indledning
4
2. Formål og afgrænsning
6
3. QA og regulatory for medicoindustrien
7
Formålet afgør om det er medicinsk udstyr
Markedsføring og CE-mærkning af medicinsk udstyr
Lovgivningens formål
Direktiver
Klassificering af udstyr og krav til kvalitetsikring
De væsentlige krav og harmoniserede standarder
USA – Federal Drug Administration (FDA)
8
8
9
10
10
11
13
4. Cases
15
5. Før udviklingsprocessen - Afdækningsfasen
25
6. Udviklingsprocessen - En fremgangsmåde i 5 trin
33
7. Efter udviklingsprocessen Markedsføring og drift
45
8. Efterord
48
9. Begreber og terminologier
49
10.Om folkene bag guiden
54
TV2 case: TV2 førstehjælp
AMBU case: Airway Management E-learning
MIM software case: Mobile MIM
16
19
22
Forretning
Formål
Målgruppe
Teknologi
Ressourcer
Jura
26
26
27
28
30
31
Specifikation
Design
Udvikling
Test
Lancering
33
35
36
40
41
Markedsføring
Opdatering
Videreudvikling
46
47
47
MEDICO APPS - A PRACTITIONER’S GUIDE
3
1.
Indledning
Stort set alt medico teknologi gennemgår i øjeblikket en elektronisk forvandling og udvikling. Efterspørgslen efter sundheds-IT/e-health/telemedicin stiger kraftigt, og udbredelsen af mobile enheder
stiger ligeledes støt. Når e-health og mobile enheder bringes sammen, opstår der et kæmpe potentiale
for dem, som forstår at udnytte muligheden.
Figur 1. 30% af alle smartphone-brugere forventes i 2015 at benytte e-health applikationer.
Der ligger i krydsfeltet mellem appudvikling og medicoteknologi mange muligheder for at udvikle en
helt ny dansk niche-kompetence, som efter vores mening bør opsøges aktivt. Danmark har allerede et
godt internationalt ry i medico-branchen, og det kan vi udnytte ved at tænke ud af boksen og arbejde
tværdisciplinært i udviklingen af innovative og værdiskabende medico apps. Derfor har MEDICO INNOVATION taget initiativ til at udgive denne guide, der forhåbentlig vil være både en inspiration og et
praktisk værktøj.
MEDICO APPS - A PRACTITIONER’S GUIDE
4
MEDICO INNOVATION er et offentligt-privat initiativ, der arbejder på at styrke rammerne for innovation
i den medico-tekniske branche i Danmark. Dette sker gennem igangsættelsen af offentligt-private innovationspartnerskaber, kompetenceudvikling og dannelsen af faglige netværk. Således har Medico
Innovation taget initiativ til at etablere interesse-netværket ”Devices n’ Apps” (DNA), som har til formål
at dele viden om udvikling af medico-tekniske apps mellem virksomheder, forskere, sundhedsfagligt og
teknisk personale samt IT folk med interesse for emnet. I dette forum opstod tanken om at skrive en
praktisk anlagt guide om udviklingen af medico apps.
DNA netværket har i skrivende stund besluttet at fortsætte i 2012 og arbejde på at samle kompetencer
i hele landet på tværs af discipliner. I MEDICO INNOVATION støtter vi op om dette initiativ og hjælper
gerne alle, der går med en god idé til en banebrydende ny medico app, videre med relevante kontakter
inden for industrien, sundhedsvæsenet eller de tekniske videnskabers verden.
MEDICO INNOVATION takker forfatterne for deres kompetente bidrag og følgende personer for deres
aktive indsats med at pudse guiden af: Jacob Schlundt for dine drilske spørgsmål, konstruktive feedback
og altid gode humør. Karsten Dyresberg for dit bidrag med praktiske erfaringer. Thomas Tscherning for
konstruktiv korrekturlæsning og gode bidrag. Rikke Arendt Christiansen for kyndig og konstruktiv bistand
i korrekturlæsning af det regulatoriske afsnit, samt ikke mindst AMBU, TV2 og MIM Software for at stille
op til interviews om jeres praktiske erfaringer med medico app udvikling.
Vi har lært meget på denne rejse og håber, det vil komme vores læsere til gode på en konstruktiv måde.
God fornøjelse
Martin Stenfeldt
Director, MEDICO INNOVATION
MEDICO APPS - A PRACTITIONER’S GUIDE
5
2.
Formål og afgrænsning
Formål & målgruppe
Denne guide er henvendt til medicinalbranchen. Den er primært skrevet til medico virksomheder,
sundhedsfagligt og -teknisk personale, forskere, IT folk og app-udviklere, der ønsker at øge forståelsen
for udviklingen af mobile applikationer (apps) inden for medico-området.
Ønsket med guiden er at inspirere og motivere udviklingen af medico apps ved at synliggøre værdiskabelsen i apps og lette arbejdet ved at dele erfaringer fra andre, der allerede har gjort det.
Målet har været at opstille en praktisk guide. Den har fra starten haft en praktisk vinkel og beskæftiger
sig med proces og retningslinjer for udvikling af apps, som brugeren interagerer med. Udviklingsprocessen har vi opdelt i et før-under-efter forløb, hvor faserne i guiden gennemgås med centrale overvejelser,
tips og tjeklister.
Herudover omhandler guiden områder særlig relevant for medicobranchen. Herunder det regulatoriske
område (RA), kvalitetssikring (QA), konkrete medico cases samt immaterielle og materielle rettigheder
(IPR).
Afgrænsning
Det har været fristende at inkludere business-cases, innovationsteori, tendenser og statistik mv. i guiden.
Samtidig har det også været et bevidst valg at udgive guiden inden for en givet tidsramme og fokusere
på, hvordan man kommer godt i gang med app-udvikling. Det betyder, at guiden koncentreres om udvikling af medico apps og derfor ikke beskæftiger sig med:
!Idéudvikling / -kvalificering
!Teknologi i relation til konkret udvikling. Vi behandler ikke værktøjer til udvikling, eller hvordan man
udvikler en app.
!Specifikke tekniske udfordringer i relation til apps. Dette er ikke en manual.
!Apps, der rummer spil, håndbøger, brugsanvisninger, opslagsværker el. simple handlingsanvisninger.
!Mobile websites, responsive webdesign og andre teknologier til håndholdte enheder.
MEDICO APPS - A PRACTITIONER’S GUIDE
6
3.
QA og regulatory for medicoindustrien
I dette kapitel ser vi nærmere på kvalitetssikring (Quality Assurance; QA) og de regulatoriske krav gældende for apps, der kan betegnes som medicinsk udstyr. Det er her, vi oplever den største forskel mellem
”almindelig” appudvikling og appudvikling til medicinsk udstyr. QA og RA er også det emne, der har haft
størst interesse i DNA netværket. Målet med afsnittet er at afmystificere de forskellige lovgivningsmæssige krav og vise vej gennem denne del af processen.
Software og herunder apps, der betegnes som medicinsk udstyr, skal opfylde en række lovgivningsmæssige
(regulatoriske) krav. Alt efter, hvordan udstyret klassificeres, er kravene mere eller mindre omfattende.
Klassifikationen tager udgangspunkt i en risikobetragtning i forhold til bruger- og patientsikkerhed.
Høj risikoklasse medfører omfattende regulatoriske krav til dit udstyr. Lav risikoklasse medfører mindre
omfattende krav til udstyret fra myndighedernes side. Her er det værd at bemærke, at medicinsk udstyr omfatter alt lige fra elastikbind og vatpinde over høreapparater, pulsmålere til ultralydsskannere.
De enkelte lande opererer med forskellige klassificeringssystemer, som har mange lighedspunkter men
desværre også væsentlige forskelligheder, og der er ingen vandtæt omsætningstabel fra det ene system
til det andet. Heldigvis er det sådan, at det samme klassificeringssystem anvendes inden for hele EU.
USA har sit eget system. Det samme gælder for væsentlige lande som Kina, Japan og Brasilien. Software
kan være medicinsk udstyr eller indgå i det på flere måder:
1.Den kan være et tilbehør til medicinsk udstyr, som ikke er software. Fx et program som man bruger til
indstille et høreapparats forstærkning af lyden, så den bliver tilpasset den aktuelle bruger. Softwaren
skal i tilfælde som disse betragtes som medicinsk udstyr.
2. Den kan være medicinsk udstyr i sig selv. Fx beslutningsstøtte software til at fastlægge en diagnose.
3.Den kan være inkorporeret i det medicinske udstyr, f.eks. som indlejret software. I denne guide
vil denne type af software ikke blive taget i nærmere betragtning, idet eksekveringsenheder som
smartphones og tablets typisk ikke bliver leveret som medicinsk udstyr.
Apps vil derfor være stand-alone software som eksekveres på en enhed, der har en mere generel specifikation end medicinsk udstyr. Det samme gælder for internettet. I det efterfølgende vil vi betragte
disse komponenter som infrastruktur, som ikke skal godkendes som medicinsk udstyr. Dette fritager
MEDICO APPS - A PRACTITIONER’S GUIDE
7
dog ikke fabrikanten fra at lade infrastrukturen ude af betragtning, når appen udvikles. Det samlede
system skal være effektivt og sikkert.
En medicoapp adskiller sig fra medicinsk udstyr i klassisk forstand i dens afgrænsning som medicinsk
udstyr ved ikke på forhånd at være fast defineret. Hvis man fx betragter to stykker medicinsk udstyr; En
operationsskalpel og en app, anvendt på en tilgængelig håndholdt enhed med tilslutning til en server
på internettet, så er det for skalpellens vedkommende på forhånd lettere at definere det medicinske
udstyrs fysiske afgrænsning, end det er for appen.
Godkendelsesmæssigt vil det da også være meget op af bakke, hvis man eksempelvis skal have internettet
godkendt som en del sit medicinske udstyr! Derfor er det afgørende, at der indføres en hensigtsmæssig
arkitektur og et softwaremæssigt design, så det er veldefineret, hvilke moduler og enheder, der er del
af det medicinske udstyr, og hvilke der ikke er det.
Formålet afgør om det er medicinsk udstyr
Medicinsk udstyr skal anvendes til det, det er beregnet til. Det er fabrikantens ansvar at specificere,
hvad udstyret er beregnet til. På den anden side kan fabrikanten i hovedreglen ikke stilles til ansvar, hvis
udstyret anvendes på en måde, der ligger uden for denne specifikation.
Et af de mest centrale begreber i forhold til lovgivningen er det medicinske udstyrs intended use (tiltænkte
anvendelse). Som fabrikant af medicinsk udstyr skal man også tage hensyn til alternative anvendelser,
som ikke er tiltænkte, men som er forudsigelige. Det gælder især med hensyn til hvilke skademæssige
konsekvenser, den alternative anvendelse kan have for patient og bruger. Den tiltænkte anvendelse er
afgørende for, om der overhovedet er tale om medicinsk udstyr. Hvis ikke, kan man spare de omkostninger, der vil medgå til myndighedsgodkendelsen af det.
Definitionen af medicinsk udstyr
Ethvert instrument, apparat, udstyr, software, materiale eller anden genstand anvendt alene eller i kombination, herunder software, som af fabrikanten er beregnet til specifik anvendelse til
diagnostiske og/eller terapeutiske formål (se Definitioner i ordlisten), og som hører med til korrekt brug heraf, og som af fabrikanten er beregnet til anvendelse på mennesker med henblik på:
!
!
!
!
Diagnosticering, forebyggelse, overvågning, behandling eller lindring af sygdomme
iagnosticering, overvågning, behandling, lindring af eller kompensation for skader eller handicap
D
Undersøgelse, udskiftning eller ændring af anatomien eller en fysiologisk proces
Svangerskabsforebyggelse
og hvis forventede hovedvirkning i eller på det menneskelige legeme ikke fremkaldes ad farmakologisk, immunologisk eller metabolisk vej, men hvis virkning kan understøttes ad denne vej.
Markedsføring og CE-mærkning af medicinsk udstyr
Hvis den tiltænkte anvendelse ikke ligger inden for eller har en mere general karakter end beskrevet
i ovennævnte definition, er der ikke tale om medicinsk udstyr. Tag fx et videokamera, der sat op på
en operationsstue med det formål, at en ekstern læge kan fjerneovervåge operationer. Formålet med
kameraet vil da sandsynligvis have noget med behandling og overvågning at gøre. Men det gør ikke
videokameraet til medicinsk udstyr, idet det jo er et videokamera markedsført til generelle billedoptagelses formål. Det bliver først medicinsk udstyr i det øjeblik fabrikanten specificerer det som sådan,
MEDICO APPS - A PRACTITIONER’S GUIDE
8
altså når det ligger inden for ovenstående definition. Her er det afgørende, hvad der påstås fra fabrikantens side i forbindelse med markedsføringen. Hvis det fx påstås, at udstyret er specielt velegnet til
fjernovervågning under en operation, så kan bordet fange og fabrikanten er forpligtet til at CE-mærke
udstyret som medicinsk udstyr (se senere).
Det er ikke svært at overføre ovenstående eksempel til en app på en mobil-enhed med et kamera. Hvis
appen har den egenskab, at den kan sende et billede taget med kameraet til lægen, så er der ikke tale
om medicinsk udstyr. Men hvis den også kan analysere billedet og generere en diagnose på f.eks. en
hudsygdom, så er der tale om medicinsk udstyr.
Markedsføring er et centralt og skelsættende begreb i lovgivningen vedr. medicinsk udstyr. Markedsføring
finder sted i det øjeblik fabrikanten stiller sit udstyr til rådighed for andre. Eksempelvis ved distribution
af en app. Det er dog lovligt, at stille sin app til rådighed til demonstrationsformål m.m., men det skal
tydelig fremgå, at den ikke må anvendes som medicinsk udstyr.
Hvis man har CE-mærket sin app efter forudgående myndighedsgodkendelse, må man markedsføre den
over hele EU. De enkelte lande kan dog stille krav om oversættelse. Fx ledetekster i skærmbilleder og
andet tekstmateriale, der er nødvendigt for, at man kan anvende appen, som medicinsk udstyr på den
tiltænkte måde. Danmark er et af de lande, som kræver oversættelse. Derfor er det værd at overveje
en sprogvalgs option i appen, hvis den skal distribueres inden for EU’s område.
CE-mærkning giver kun lov til at markedsføre inden for EU. Man har altså ikke lov til, at stille appen
til rådighed inden for fx USAs grænser medmindre man har fået grønt lys fra FDA, som forvalter USAs
lovgivning indenfor området.
EU har truffet forholdsregler mht. markedsovervågning således, at medicinalpersoner og hospitaler
har pligt til indberetning, hvis udstyret svigter, således at det forårsager død eller alvorlig forværring
af patientens eller brugerens helbredstilstand. Tilbagetrækning af appen fra markedet kan være konsekvensen af dette.
Den person, der er ansvarlig for markedsføringen skal registreres hos den kompetente myndighed. Det
vil i Danmark sige Lægemiddelstyrelsen.
Bemærk at lovgivningen gælder fabrikanter af medicinsk udstyr. Hvis man fx laver softwareudvikling for
ét hospital markedsfører man ikke nødvendigvis medicinsk udstyr.
Lovgivningens formål
Den centrale sigte med lovgivningen, uanset hvilket land det drejer sig om, er at få dokumenteret:
!Sikkerhed for udstyrets ydeevne
!Beskyttelse af bruger og patient mod skader, som kan forvoldes af udstyret.
Myndighederne forlanger dokumentation for udstyrets ydeevne, som matcher state-of-the-art, samt at
den resterende risiko, der måtte være forbundet med at anvende udstyret, skal være minimeret mest
mulig og ligge inden for et acceptabelt niveau i forhold til udstyrets tiltænkte anvendelse.
Hvert land har sin egen lovgivning inden for området, som har store ligheder og måske også store
forskelligheder. I denne guide vil lovgivningen indenfor EU blive brugt som det gennemgående og med
referencer til lovgivningen i USA, hvor denne afviger i forhold hertil.
MEDICO APPS - A PRACTITIONER’S GUIDE
9
Direktiver
Indenfor EU defineres den lovgivningsmæssige ramme for det medicinske udstyr, man er ved at udvikle,
af det direktiv, som udstyret henhører under. Det kan være et af følgende:
!Medico-direktivet: Rådets Direktiv 93/42/EEC om medicinsk udstyr og Rådets Direktiv 2007/47/EC.
!Rådets Direktiv 90/385/EEC om aktivt, implantabelt medicinsk udstyr og Rådets Direktiv 2007/47/
EC.
!Rådets Direktiv 98/79/EØF af 27. oktober 1998 om medicinsk udstyr til in vitro-diagnostik.
Noget at det første, man skal gøre sig klart er, hvilket direktiv udstyret hører under. Direktiverne er alle
implementeret i de nationale lovgivninger i EU. Direktivet vedr. aktivt, implantabelt udstyr kan være
relevant i forhold til software, hvis den er tilbehør til fx en pacemaker. Selv om software er aktivt udstyr
kan det næppe være medicinsk udstyr i sig selv. En app kan næppe implanteres direkte i den menneskelige krop. Software kan være inkorporeret i det aktive implantat. Bemærk, at det, der gør et implantat
aktivt, er, at det har sin egen iboende energikilde, som ikke hidrører fra kroppen.
In vitro-diagnostik direktivet kan appen være omfattet af, som tilbehør til medicinsk udstyr, der anvendes
på prøvemateriale, som er udtaget af det menneskelige legeme. In vitro diagnostisk udstyr anvendes
aldrig direkte på mennesker.
CE-mærket på udstyret angiver, at udstyret ikke blot overholder et af de ovennævnte direktiver men
alle relevante direktiver. Fx direktivet om beskyttelse af persondata og radio teleterminal direktivet.
Myndighederne i de enkelte EU-medlemslande er forpligtet til at samarbejde, så direktiverne anvendes
på ensartet måde. Det vil i reglen være Medico-direktivet, der skal bringes i anvendelse. Derfor handler
resten af guiden om dette.
Klassificering af udstyr og krav til kvalitetsikring
I EU opdeles medicinsk udstyr i en af følgende produktklasser:
!Klasse I er den produktklasse, hvor der er mindst risiko for patient og bruger forbundet med anvendelsen af det medicinske udstyr. For denne klasses vedkommende skal fabrikanten indsende en
overensstemmelseserklæring til det kompetente organ i det land (i Danmark Lægemiddelstyrelsen),
hvor produktet skal CE-mærkes, hvorefter mærkning er tilladt. Det er ikke nødvendigt med et bemyndiget organs medvirken for CE-mærke produkter i denne klasse medmindre, der tale om udstyr
med målefunktion eller udstyr som bliver markedsført i steril tilstand. Apps med målefunktion er en
realistisk mulighed man som udvikler skal have i mente: Er der tale om målefunktion eller tendensindikation. Der er omkostninger vedr. godkendelsesforløbet til forskel.
!Klasse IIa omfatter fx aktivt terapeutisk udstyr som høreapparater og diagnostisk udstyr til rutine
overvågning og selvmonitorering vitale fysiologiske processer blodtryk og hjerterytme. En blodstryksmåler til hjemmebrug er et godt eksempel. Apps kan tilhøre denne klasse, hvis de kan stille en
diagnose. Denne produktklasse kræver et Bemyndiget organs medvirken for, at man må markedsføre
og CE-mærke udstyret.
!Klasse IIb. Denne produktklasse kræver, at et Bemyndiget organ fører tilsyn med konstruktion og
fremstilling. Denne produktklasse omfatter fx diagnostisk udstyr til ikke-rutinemæssig overvågning.
Udstyr i denne klasse skal CE-mærkes.
!Klasse III omfatter de mest risikoforbundne udstyrstyper som fx implantater. Et Bemyndiget organs
medvirken kæves selvsagt også her. Udstyr i denne klasse skal CE-mærkes.
EU har defineret et sæt af vejledninger, som er nyttige. Software er defineret som aktivt udstyr og skal
derfor klassificeres efter de tilhørende regler. For alle typer af udstyr skal der laves en overensstemmelseserklæring som beskrevet i Medico-direktivet. Udstyrsklassen fastlægges ved en forhandling mellem
MEDICO APPS - A PRACTITIONER’S GUIDE
10
fabrikanten og et Bemyndiget organ – fx Dansk Godkendelse af Medicinsk Udstyr (DGM). Ved tvister er
det det kompetente organ, der afgør sagen. Undtagelsen er klasse I udstyr, som før nævnt.
Klassificering af medico apps
Ved klassificering af appen skal man være meget opmærksom på følgende (jf. Medico-direktivet):
Edb-programmel, som styrer en anordning eller påvirker anvendelsen af en anordning, klassificeres
automatisk i samme klasse som den pågældende anordning.
Bemærk at der er to scenarier:
!Appen styrer noget medicinsk udstyr. Det kunne være en app, der tilpasser et høreapparat. Appen
bliver da medicinsk udstyr af samme klasse - i dette tilfælde IIa.
Appen
påvirker anvendelsen af noget medicinsk udstyr. Dette er måske den situation, der kræver
!
mest omtanke. Det kunne være en arbejdsgang, der bliver omlagt pga appen, der gør den til medicinsk udstyr og dermed påvirker anvendelsen af noget medicinsk udstyr…
I skrivende stund er EU undervejs med en klassificeringsguide for stand-alone software. Det er bl.a. lagt
op til, at software kan klassificeres på modul niveau. Guiden kommer også til at indeholde regler for,
hvornår software skal betragtes som medicinsk udstyr, selvom det er integreret med anden software,
der er medicinsk udstyr.
Nedbrydningen i moduler bør i så fald udføres på softwareniveau, idet nogle moduler da sikkert kan lades
ude af betragtning som medicinsk udstyr. De resterende vil opdeles i risikoklasser på software niveau
jf. den harmoniserede standard DS/EN 62304:2006. Hvis ikke man får lavet denne opdeling risikerer
godkendelsesprocessen at blive unødig omstændelig, derfor: Design for safety - design for approval!
De væsentlige krav og harmoniserede standarder
EU har opstillet en række såkaldte væsentlige krav (essential requirements) som al medicinsk udstyr
skal opfylde. Disse er en del af Medico-direktivet. Kravene er for manges vedkommende formuleret på
et forholdsvis overordnet niveau. Men det er netop disse krav udstyret skal opfylde set fra myndighedernes side.
Når man udvikler software er der et sæt af standarder som typisk kommer i spil:
Standard
Titel
EN ISO 13485:2003
Medical devices - Quality management systems - Requirements for regulatory purposes
DS/EN ISO 14971:2009
Medical devices - Application of risk management to medical devices
DS/EN 62304:2006
Medical device software - Software life-cycle processes
EN 62366:2008
Medical devices - Application of usability engineering to medical devices
EN 980:2008
Symbols for use in the labeling of medical devices
EN 1041:2009
Information supplied by the manufacturer of medical devices
DS/EN ISO 14155:2011
Clinical investigation of medical devices for human subjects - Good clinical practice
Udstyret skal konstrueres og fremstilles med sikkerhed for øje - princippet om sikkerhedsintegration - i
videst mulig omfang. Alarmer skal integreres i udstyret i det omfang, at konstruktionen ikke kan gøres
100% sikker.
MEDICO APPS - A PRACTITIONER’S GUIDE
11
Ovenstående kræver en effektiv risk management proces i udviklingsforløbet. Dette gælder også for det
endelige udstyrs betjeningsegenskaber, hvor risikoen for betjeningsfejl, der kan forvolde personskade,
skal minimeres mest muligt. I denne forbindelse skal der tages hensyn til brugernes teknologiske viden.
Det er således et krav, at en app har et sikkert betjeningskoncept, hvor der er taget hensyn til brugernes
forudsætninger:
Det skal være klart angivet på anordningerne, hvorledes betjeningspaneler og indikatorer virker.
On-going risk management er motoren, der driver dette.
Den anførte ydeevne skal også dokumenteres. Hvis appen fx bruger det indbyggede kamera i den
håndholdte enhed til at tage et billede af fx et modermærke eller øjet og derudfra giver et bud på en
diagnose, så skal det dokumenteres med hvilken statistisk sikkerhed, dette sker.
Der skal gennemføres klinisk evaluering gennem hele produktets livscyklus, hvilket betyder, at kliniske
data skal underbygge, at udstyret har den ydeevne, som er specificeret af fabrikanten. I den forbindelse
skal der:
!Gennemføres et litteratur-studium, som dokumenteres i den kliniske evalueringsrapport. Litteraturstudiet baseres på tidligere offentliggjorte og/eller egne undersøgelser.
! Om nødvendigt gennemføres en klinisk afprøvning, hvis datagrundlaget ikke er tilstrækkeligt. Det er
vigtigt at få klarlagt i starten af produktudviklingsprojektet, idet klinisk afprøvning kræver forholdsvis
store ressourcer til planlægning og afvikling.
!Løbende indsamles kliniske data om udstyrets anvendelse over hele dets livscyklus.
Det kliniske evaluering spiller sammen med risk management processen: Risici evalueres som en del af
den kliniske evaluering og på den måde identificeres risici i den kliniske evaluering.
Det skal sikres, at appen ikke ændrer egenskaber undervejs i processen fra download til installation på
det håndholdte device og videre frem. En app er i sin natur som medicinsk udstyr, som skal anvendes
sammen med andet udstyr. Her er kravet systemet betragtet som en enhed skal være sikkert. Hvis fx
den håndholdte enhed og appen markedsføres samlet, er der tale om en systempakke og kravene for
sådanne skal være opfyldt.
Udstyr med målefunktion skal overholde særlige krav mht. stabilitet, nøjagtighed og tolerancer samt
ergonomiske principper. Kravene til sidstnævnte er defineret i EN 62366:2008. Den udviklede app skal
have en kvalitet, der matcher formålet. Der betyder bl.a., at softwaren skal håndtere fejlsituationer på
en måde, så de hermed forbundne risici begrænses mest muligt. En medico app skal:
valideres i overensstemmelse med det aktuelle tekniske niveau, idet der tages hensyn til principperne
for udviklingslivscyklus, risikostyring, validering og verificering.
For at matche det krav anbefales det, at man opfylder kravene i EN 62366:2008, som er den mest software specifikke af de harmoniserede standarder. Den har veldefinerede krav til udviklingscyklus og risk
management samt verifikation og validering.
Udstyr, der overvåger en eller flere kliniske parametre, skal være forsynet med ’passende’ alarm systemer. En app, der kører på udstyr, der er afhængig af en energikilde, det være:
!Intern i form af et batteri. Hvis det er tilfældet skal der være en batteriindikator
!Ekstern i form at net-tilslutning. Hvis sådant udstyr er afgørende for patientens sikkerhed, skal der
være indbygget alarmsystem.
MEDICO APPS - A PRACTITIONER’S GUIDE
12
Det medicinske udstyr skal leveres med de oplysninger, der skal til for at det kan anvendes sikkert og
korrekt. Det skal også være muligt at spore udstyret tilbage til dig som fabrikant. Der skal også følge en
brugsanvisning med udstyret, hvilket der dog kan ses bort fra, hvis udstyret er i klasse I eller IIa og det
kan betjenes sikkert uden anvisninger. Hvis man udvikler en medico app kan følgende være påkrævet:
!Batchkode, hvilket svarer til den installerede apps buildnummer. Angives med symbolet LOT.
!Hvis appen er bestemt til klinisk afprøvning (se Definitioner) skal det fremgå.
!Advarsler og forholdsregler.
!Fremstillingsår. Angives med symbolet for fremstillingsår.
!Oplysning om hvilke enheder appen kan afvikles sikkert på. De er nok, at angive deres karakteristika.
Formålet er at opnå en sikker kombination.
!Oplysninger om hvordan brugeren sikrer sig, at appen er installeret korrekt samt vedligeholdelses
og evt. kalibreringsforskrifter.
De harmoniserede standarder EN 1041:2009 og EN 980:2008 definerer forventningen til ovennævnte
type af information og anvendelsen af symboler.
USA – Federal Drug Administration (FDA)
Som nævnt har USA sit eget system til godkendelse af medical devices – inkl. apps som er inden for
området. Da FDA (sundhedsmyndighederne i USA, der godkender udstyr og medicin) kun har publiceret
draft guidelines (det vageste første udspil til en bekendtgørelse på det specifikke område omhandlende
apps; se reference nedenfor), er der en del spekulationer om, hvordan FDA vil behandle specifikke
eksempler. Indtil der er lagt en juridisk (regulatorisk) standard, må man gå ud fra de (få) cases, der allerede er behandlet samt anvende beskrivelsen ovenfor (fra EU) som benchmark. Nedenfor følger en
del figurer, der forklarer behandlingen af apps i USA.
Figur 2. Alt efter hvor stor en risikoen for skader en bruger af appen (patienten) udsætter sig selv og andre for (inkl. ved selv-forskyldt
fejlbrug af appen), bliver appen (+evt. device) klassificeret, og skal udvise grader af validerende studier (ref. MobiHealthNews.com).
MEDICO APPS - A PRACTITIONER’S GUIDE
13
Figur 3. Den (potentielle) risiko ligger på et kontinuum, og bestemmes bedst ved samarbejde med rådgivere på området – og evt.
ved diskussion med FDA sent i udviklingsprocessen (ref. MobiHealthNews.com).
Figur 4. ISO er en del af kvalitetskontrollen, men FDA går ud over disse krav ved at kræve dokumentation for validering
(fx er den hævdede effekt dokumenteret?, er der et system til at tage hånd om Adverse Events? (AE, bivirkninger), etc)
(ref. MobiHealthNews.com)
MEDICO APPS - A PRACTITIONER’S GUIDE
14
4.
Cases
Da et af formålene med denne guide er at dele erfaringerne fra
nogle af dem, der allerede har udgivet medico-app, følger her tre
cases på apps udgivet inden for det seneste.
MEDICO APPS - A PRACTITIONER’S GUIDE
15
Case
TV2 Førstehjælp
Navn
TV2 Førstehjælp
UdgiverTV2
Platforme
iPhone + Android
Udgivet Oktober, 2011
Målgruppe
Den brede befolkning. B-t-C
Downloads til d.d. 20.000 stk.
Samlet budget
Omk. 300.000 kr.
Udviklingstid
Ca. 4 mdr.
Største udfordring Kvalitetssikring af de sidste 2%, der gør
appen fuldstændig fejlfri, hvilket er nødvendigt for apps, der handler om liv og død.
Største læringMedical apps kræver mere QA. Derfor er
tydelig definition af kvalitetskrav fra starten
og et struktureret test set-up vigtigt.
Bedste rådHellere én funktionalitet, der sidder i
skabet, end en masse, der virker halvt.
Skabt for at redde liv
TV2 er Danmarks største kommercielle public service tv-station med fem kanaler. Stationen har udgivet
flere forskellige mobile applikationer fra events til nyheder, vejr mv. som en del af TV2s strategi om at
være repræsenteret stærkt også på de digitale medier.
I september 2011 blev den gribende dokumentarserie ”Tak fordi du reddede mit liv” lanceret. I serien
møder man almindelige mennesker, der er trådt i karakter, når uheld har ramt tilfældige personer, de
ikke kender. Mennesker med mod og hjerte på rette sted til at rede andre folks liv.
I forbindelse med serien opstod med hjælp fra Tryg Fonden mulighed for at skabe en mobil applikation,
der lagde sig op ad seriens tema om at redde liv. Grundidéen til den app, der senere skulle gå hen og
blive appen for førstehjælp i Danmark, blev født.
Appens idé er, at hjælpen skal være ét tryk væk, og allerede fra begyndelsen stod det klart, at ambitionen var at skabe en app, der kunne mere end de eksisterende førstehjælps apps på markedet. Som
tv-station tænker man naturligt i billeder, og derfor blev video medtænkt fra starten. Det stod også klart,
at siden appen drejede sig om liv og død, måtte det faglige indhold være i absolut top, baseret på den
nyeste viden, og det måtte komme fra en ekspert på området. Derfor teamede TV2 op med overlæge
og formand for Dansk Råd for Genoplivning Torsten Lauritsen med speciale i førstehjælp. Stationen
vidste, at når de havde Danmarks førende læge på området med på holdet, ville appen blive bedre og
opnå større troværdighed.
Formål og succeskriterier
Formålet med TV2 Førstehjælp var enkelt, selvom målgruppen var bred. Mange har på et eller andet
tidspunkt modtaget undervisning i førstehjælp - og glemt det igen. Og endnu flere har måske aldrig
lært det...
MEDICO APPS - A PRACTITIONER’S GUIDE
16
Appen skulle gøre to ting:
1) Være en her og nu guide i førstehjælp til folk, der stod i en ulykkessituation.
2) Opkvalificere interesserede i førstehjælp, når de har tid, gennem instruktionsvideoer.
Der blev ikke sat direkte succeskriterier op for appen, da den ikke havde et kommercielt sigte. På trods
af dette var appen tre måneder senere downloadet 20.000 gange.
Udviklingsprocessen
Selve udviklingen og indholdsproduktionen blev gennemført af underleverandører, mens TV2 forestod
projektledelsen. Underleverandørerne blev valgt efter sondering og ud fra deres kendskab til den tekniske løsning.
Processens faser var flg.:
1. Idékatalog
Herunder: Idéudvikling, indsamling af viden og markedsresearch, kondensering af det væsentlige i
ideerne, formulering af grundidé.
2. Specifikation
Herunder: Beskrivelse af appen og opstilling af præspecifikationer, indhentning af tilbud fra leverandører,
tilpasning og organisering af funktionaliteter, opstilling af flowchart samt prototype og udarbejdelse af
detaljeret kravspecifikation. Prototypen blev opbygget i Powerpoint.
3. Artwork og design
Herunder: Fastlæggelse af designmæssige retningslinjer (ej fancy), designoplæg, tilretning og godkendelse.
4. Udvikling
Herunder: Iterationer med feedback og tilretning, fejlbeskrivelser, udarbejdet på to platforme samtidig.
5. Testforløb
Herunder: Struktureret test set-up med afprøvning på egne testtelefoner.
6. Lancering
Herunder: On air promotion, PR-kit sendt ud til diverse medier.
7. Drift
Appens indhold er statisk, og der gøres ikke mere ved den pt.
Udfordringer og læring
TV2 største udfordring i produktionen var de mange iterationer, der var nødvendige for at sikre appens
kvalitet og fejlfrihed. Projektet blev mere omfattende for alle interessenter, fordi kvalitetskravene ikke
havde været klart defineret fra starten. Nul-tolerancen for fejl kostede ekstra ressourcer, og projektet
blev forsinket ca en måned, hvilket fordyrede opgaven i både interne timer og eksterne omkostninger.
Derfor var den største læring også, at medical apps kræver mere kvalitetssikring, end TV2 var vant til
fra deres tidligere apps. Og mere kvalitetssikring kræver en mere struktureret styring af test set up.
Herudover oplevede TV2, at Android platformen voldte særlige udfordringer pga de mange forskellige
enheder, der er på markedet. Det faktum, at en applikation afvikles på en enkelt smartphone eller tablet
giver ikke sikkerhed for at sikre, at appen virker på alle telefoner.
MEDICO APPS - A PRACTITIONER’S GUIDE
17
Særlige forhold for medical apps
TV2 vurderer, at særligt tre forhold gør sig gældende for medical apps:
1. Der er ingen plads til fejl.
2. Kvalitetsstyring er mere krævende.
3. Appen skal være opdateret.
Tre lavpraktiske råd
1.Medico apps kan rumme mange fagudtryk. Tænk derfor i at formidling og terminologi skal matche
målgruppen.
2.Medico apps er meget følsomme for fejl. Sæt tid af til at teste. Det tager tid og kan være meget
omstændeligt.
3. Hellere én funktion, der sidder i skabet, end en masse, der virker halvt.
MEDICO APPS - A PRACTITIONER’S GUIDE
18
Case
Airway Management E-learning
Navn
Airway Management eLearning.
Udgiver
Ambu A/S.
Platforme iPhone + iPad + Android.
Udgivet
Maj, 2011.
Målgruppe
Anæstesilæger, globalt. B-t-B.
Downloads til d.d. 9.000 stk.
Samlet budget
Omk. 200.000 kr.
Udviklingstid
Ca. 5 mdr.
Største udfordringKonvertering og nedskalering af større
onlineplatform til et begrænset brugerinterface, der fungerer godt og intuitivt på en lille håndholdt enhed.
Største læringMobile 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ådOpdateringsmuligheder er
afgørende for appens levetid.
Skabt for at uddanne læger
Virksomheden Ambu blev stiftet i 1937, har hovedkvarter i Danmark, og er en global spiller med salg
i ca. 80 lande. Ambus firmafilosofi har altid været at gøre livet lettere for læger og udvikle innovative
produkter, der redder liv. Ambu A/S udvikler, producerer og markedsfører således diagnosticerings- og
livredningsprodukter til hospitaler og redningstjenester.
Ambu aScope er et innovativt produkt fra Ambu til placering af luftveje ifm. operationer for anæstesilæger. 3% af alle patienter har nemlig det, der hedder svære luftveje, hvor lægerne traditionelt må
bruge et langt og meget dyrt skop som hjælpemiddel. Problemet med de traditionelle skoper er, at de
er dyre, der er få af dem på hospitalet, de skal repareres og rengøres, og at de skal transporteres rundt
mellem operationerne. Det kan i yderste konsekvens betyde, at skoperne ikke er tilgængelige, og derfor
udviklede Ambu et billigere engangs-scope.
Fordi Ambu aScopet bruges på de sværeste 3% af patienter, er det et spørgsmål om liv og død, at apparaturet benyttes korrekt. Og derfor er træning af høj interesse hos lægerne. Tidligere blev uddannelsesopgaven løftet af Ambus sælgere, hvor udfordringen dog var, at lægerne ikke altid har mulighed
for at være til stede eller har tid til at deltage i en trænings-session. Ambu vidste om anæstesilægerne,
at de typisk har en del tid under operationerne til at videreuddanne sig. Samtidig ville Ambu gerne eksponere mere af deres kliniske dokumentation og økonomiske beregninger overfor lægerne. Desuden
var formålet også at være medvirkende til, at flere anæstesilæger blev mere rutineret i håndteringen
af vanskelige luftvejs-situationer, da de i praksis ikke forekommer særlig ofte.
Ambu besluttede sig derfor for at udvikle en online trænings-platform på nettet, der var mere fleksibel
end den personafhængige uddannelse samt en mobil app, der kunne imødekomme lægernes timeslots.
Tanken var, at jo flere der er trænet, jo flere vil købe produktet.
MEDICO APPS - A PRACTITIONER’S GUIDE
19
I maj 2011 lancerede Ambu deres Airway Management eLearning app til iPhone, iPad og Android som
supplement til den eksisterende onlineplatform. Og det viste sig at være en ret god idé. Responsen på
de håndholdte enheder blev nemlig ni gange så stor som på onlineplatformen.
Formål og succeskriterier
Appen er henvendt til anæstesilæger globalt. Onlineplatformen rummer mere interaktion og informationsdybde, mens appen, der er tilpasset i både form og indhold, handler om bekvemmelighed og
primært rummer video upload. Appen giver let tilgang, lige her og nu til produkttræning, når det passer
lægen bedst.
Formålet var:
At skabe en mobil kanal til træning af anæstesilæger i anvendelsen af Ambu aScope samt benytte kanalen
til eksponering af produktets fordele og for at skabe kendskab.
Der blev ikke sat et direkte mål på succeskriterierne for appen separat, men det blev forventet, at appen ville opnå 1.000 downloads i 2011. Da appen senere ramte app butikkernes top-10 lister nærmest
eksploderede antallet af downloads.
Udviklingsprocessen
Selve udviklingen og indholdsproduktionen blev gennemført af den samme underleverandør, som havde
udarbejdet onlineplatformen. Ambu forestod projektledelsen.
Processens faser var flg.:
1. Afdækning
Behovsafdækning hos brugerne. Hvor meget bruger de online teknologi? Hvor mange har en smartphone?
Dialog med målgruppen.
2. Business case
Opstilling af, hvordan kan appen understøtte de forretningsmæssige mål. Hvordan når vi målene?
3. Specifikation
Kravspecifikation og designopsætning. Hvordan skal brugergrænsefladen være? Hvordan vil vi sætte det
op, så det ligger rigtigt i hånden? Udarbejdelse af wireframes. Design af knapper og nye ikoner. Hvordan
skal brugeren modtage materialet?
4. Produktionsfasen. Indhold
Tekniske udfordringer løses og specifikationerne revurderes i en gensidig dialog, særligt hvor forventningerne ikke var tydeligt afstemt.
5. Go live
Udkommer med konceptet og får en masse erfaringer. Hvilken markedsføring virker bedst? Hvad virker
og hvad virker ikke? Kombinerer markedsføring af appen med messer, online, bannere, QR koder og
nyhedsbreve. Finder ud af hvor kunderne er online. Følger ugentligt, hvor brugerne kommer fra.
6. Drift
Appens indhold er statisk, og der gøres ikke mere ved den pt.
MEDICO APPS - A PRACTITIONER’S GUIDE
20
Udfordringer og læring
Ambu oplevede, at især designfasen var udfordrende i udviklingsprocessen. Det at skalere en eksisterende platform ned til en lille skærm i både form og indhold betød prioriteringer, som krævede ekstra
dialog og interaktioner hos leverandøren, der tog tid og betød en mindre forsinkelse.
Der var også markedsføringsmæssige udfordringer i udviklingsprocessen. Onlineplatformen var skabt til
at uddanne og samtidig lead generere. Ambu ønskede at stille brugerne en masse relevante spørgsmål,
men plads og hensynet til bekvemmelighed gjorde, at flowet måtte ændres. Brugerne skulle ikke have
en stor barriere med at besvare spørgsmål for at kunne komme i gang med appen. Også teknologien
skabte lidt udfordringer. Herunder samspil med egne IT-systemer. Apples godkendelse af appen tog længere tid bl.a. fordi, det ikke måtte være påkrævet, at brugeren opgav egen email for at benytte appen.
Efter lanceringen blev det klart, at appen rummede et meget stort potentiale. Ikke blot for at nå eksisterende markeder på en ny måde, men også for at nå nye markeder.
App butikkerne er stærke markedsføringsmedier. De er effektive distributionskanaler, der allerede er
indarbejdet i mange folks medieadfærd, og det kom bag på Ambu, at man nåede brugere i helt nye
lande med appen.
Udfordringen ligger i, at appen er statisk. For mens hypen om en app med sin nyhedsværdi rummer store
muligheder, sætter et indhold, der ikke opdateres, ligeså mange begrænsninger. På Ambus webplatform
har brugerne fx mulighed for at lægge egne videoer ind. Det har betydet, at indholdet og derved værdien for brugerne vokser. Det brugergenerede indhold bliver sammen med Ambus løbende udvikling af
eget materiale brugt af læger til introduktion af aScopet. Det bruges også til at undervise studerende og
nyuddannede. Denne effekt af cirkler, der spreder sig, går tabt i appen. Læringen er, at en videndelingsapp som denne skal udvikles med indhold, der kan opdateres. Det er centralt for appens levetid og ROI.
Særlige forhold for medical apps
Ambu vurderer, at særligt tre forhold gør sig gældende for medical apps:
1. Early diagnostics. Diagnostisering kan sendes ud til patienterne vha. apps.
2.Træning og uddannelse. Sundhedssystemet får færre og færre penge, og derfor skal de være mere
effektive. Som producent kan man få fordele ved at påtage sig en del af uddannelsesopgaven for de
pågældende produkter.
3.Tone of voice. Det går ikke at markedsføre sig selv for tydeligt. Sørge for at være mere objektiv og
ikke for kommerciel. Skriv ikke ”get a quote!”, ”buy today!”.
Tre lavpraktiske råd
1.Lav grundige wireframes og gerne med klikbar prototype. Få evt. brugerfladen testet før udviklingen
påbegyndes.
2.Kend din målgruppe – hvor er de, hvilke medier bruger de hvordan. Indtænk appen aktivt i den
øvrige markedsføring. Vælg de rigtige 10 søgeord til app butikkerne
3.Opdateringsmuligheder er afgørende for appens levetid. Tænk i et CMS, der kan styre både web og
app ét centralt sted fra.
MEDICO APPS - A PRACTITIONER’S GUIDE
21
Case
Mobile MIM
Navn
Mobile MIM
Udgiver
MIM Software Inc. (USA)
Platforme iPhone + iPad
Udgivet
Juni 2008/September 2011
Målgruppe
Radiologer, Lægepraksis og patienter
Downloads til d.d. 20.000+ stk.
Samlet budget
Ikke oplyst
Udviklingstid
Ca. 8 mdr, første version: 2 uger
Største udfordring FDA nedlagde forbud mod første version
fordi den manglede markedsføringsgodkendelse 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æringAt involvere læger tidligt i processen
for at lette godkendelsesprocessen
Bedste rådHusk at involvere IT afdelinger på
hospitalerne for at lette den
efterfølgende implementering.
Nysgerrighed drev den første version
Virksomheden Mobile MIM har sit udspring i slutningen af 1990’erne på Case Western Reserve University
Hospital. Firmaets stifter og ejer, Dr. Dennis Nelson, manglede et redskab, der kunne kombinere MR
og PET scanninger. I 2002 blev MIM Software officielt grundlagt og arbejdet med medincisk billedbehandling begyndte.
Gennem årene har MIM software udviklet software løsninger, der gjorde arbejdet med medicinske billeder mere effektivt. To nysgerrige medarbejdere anskaffede sig SDK (Software Development Kit) i starten
af 2008 og forsøgte at overføre firmaets software til Apples platform. I løbet af to uger var den første
version klar. Resultatet var så overbevisende, at firmaet hurtigt indså, at den mobile platform ville blive
en integreret del af firmaets portefølje. I USA er det forbudt at markedsføre medicinsk udstyr, herunder
software, uden behørig godkendelse af FDA. MIM Software mente, at så længe appen blev tilbudt gratis
fra App Store, kunne det ikke betegnes som markedsføring. Appen vakte så stor opmærksom, at Apple
bad MIM Software præsentere deres app på App Developer konferencen i 2008. Opmærksomheden
nåede dog også FDA, der kort efter nedlagde forbud mod videre markedsføring af appen førend den
var officielt godkendt.
Først måtte MIM Software indsende en 510(k) ansøgning, men det stillede FDA sig ikke tilfreds med.
De udbad sig i stedet en PMA ansøgning, der er mere kompliceret i såvel tid som omkostninger. Med
hjælp fra et par læger, der kunne dokumentere, at softwaren var sammenlignelig med andet software
fik MIM lov til at indsende en tredje ansøgning i 510(k) format, som således blev godkendt. I foråret
2011 blev Mobile MIM dermed relanceret efter 2½ års administrativt boldspil.
Formål og succeskriterier
Appen er henvendt til radiologer, der bruger appen som behandlingsgrundlag (decision-supporting
software) som et supplement til workstation software i situationer, hvor der ikke er direkte adgang til
MEDICO APPS - A PRACTITIONER’S GUIDE
22
arbejdsstationen. Den er henvendt til andre klinikere (oftest de henvisende læger), der ønsker at se de
billeder, som deres patienter behandles på baggrund af. Samt patienter, om end de – efter FDA krav –
har deres egen version af appen (VueMe) som ikke tillader opkobling til hospitalers PAX systemer og
har en anden form for ansvarsfraskrivninger.
Appen skaber merværdi til MIM Software’s kunder, der arbejder med medicinske billeder. MIMS’ kunder
kan via appen direkte se billeder i deres database. Andre (systemer) kan uploade generiske medicinske
billeder (SPECT, PET, CT, MRI, røntgen og ultralyd) til MIMcloud, hvorefter de respektive billeder kan
vises på såvel iPhone som iPad.
Aktuelt er Mobile MIMs succeskriterier, at appen nemt, hurtigt og effektivt skal kunne fremvise medicinske billeder. I modsætning til en workstation skal appen ikke være kompliceret at anvende, da dens
brugssituation er defineret som ”på farten og betjening med én hånd”.
Udviklingsprocessen
Det er MIM Software selv, der varetager hele udviklingsprocessen, som er opdelt således:
1. Design
Herunder behovsafdækning, udvikling af kravspecifikation og prototype.
2. Udvikling
Involvering af relevante læger, der kan give fagligt feedback og hjælpe med at overbevise FDA om, at
den ny software ligner et ”predicate device”, hvormed ansøgningsprocessen kan nøjes med en 510(k)
i stedet for en PMA, der er påkrævet, hvis appen er helt unik.
3. Software test
Ny funktionalitet afprøves.
4. Fuld test
Alle funktionaliteter afprøves.
5. Fejlretning
De sidste fejl rettes.
6. Lancering
I App Store.
Udfordringer og læring
1.Det er vigtigt at inddrage klinikere i udviklingsprocessen. Dels skal/kan de optimere resultatet af
udviklingsarbejdet, dels er det en god idé at få dem til at udtale sig om, at brugen af appen minder
om et andet apparats funktionalitet. Det lyder banalt, men det kan betyde en verden til forskel, når
den amerikanske markedsføringstilladelse (510(k)) skal i hus.
2.Den anden faldgrube er ikke at tage IT afdelingerne i hospitalerne med på råd. Kun i ganske få tilfælde kan man enten slippe uden om IT afdelingerne eller præsentere en app, der er så fantastisk,
at de vil kunne lide den. Som udgangspunkt bør man indregne meget tid på at inddrage og ”nurse”
IT afdelinger, ikke kun i udviklingsarbejdet men også i det efterfølgende salgsarbejde.
3.Sørg for at være opdateret på lovgivningsmæssige krav fra starten af og vær bevidst om, hvad du vil
opnå med appen (hvilken klasse skal den være; I, II eller III)
MEDICO APPS - A PRACTITIONER’S GUIDE
23
4.Mobile MIM indeholder tre hovedfunktioner, mens deres workstation software indeholder 100+
funktioner. Software på workstation er normalt avancerede og fyldt med avancerede funktioner, fordi
brugeren har tiden hertil foran maskinen. I en app er situationen en anden; brugeren er på farten
og har kun et kort øjeblik til at anvende appen. Designet skal afspejle dette. I første omgang kan det
være meget svært at skralle funktioner af. Men herefter simplificeres arbejdet sammenlignet med
almindeligt software. Der er nemlig tilsvarende færre fejlkilder.
Særlige forhold for medical apps
I FDA regi er det specielt det regulatoriske, der spiller ind. Hvis appen ikke henvender sig til professionel
brug er det nok at registrere den som et klasse I produkt. De andre klasser kræver dokumentation i store
mængder. Når først en app har fået sin markedsføringstilladelse (510 (k) eller PMA), så er det vigtigt at
holde tungen lige i munden, hvad angår opdateringerne.
MIMS anbefaler at læse dokumentet Deciding When to Submit a 510(k) for a Change to an Existing Device
(K97-1) grundigt igennem. I korte træk så skal man ikke ansøge FDA om en ny markedsføringstilladelse
ved mindre ændringer eller fejlrettelser (med mindre der er tale om alvorlige fejl). Kun i det tilfælde,
hvor der ændres på tiltænkt brug (intended use) eller indikationer (indications), er det nødvendigt at
gå den lange vej igen. Mobile MIM har gennemgået flere softwareopdateringer uden en fornyet 510(k),
men er pt. i gang med at tilføje røntgen-billeder til deres funktion, hvilket er en ny indikation, hvorfor
de er i gang med en fornyet ansøgningsproces.
Tre lavpraktiske råd
1.Kill you darlings – en app er bedst, når den er simpel at betjene; så undgå alt for avancerede funktioner. Apps er beregnet til at blive brugt i en mobil situation; Derfor skal de være hurtige, simple
og effektive.
2.Involvér læger i udviklingsarbejdet; det letter den senere godkendelsesproces og skærper appens
indholdsværdi.
3.Opbyg et tillidsforhold til hospitalers IT afdelinger, således du nemmere kan implementere din nye
app på hospitalerne.
MEDICO APPS - A PRACTITIONER’S GUIDE
24
5.
Før udviklingsprocessen
- Afdækningsfasen
De grundlæggende overvejelser
Før man begynder på selve udviklingen af en mobil applikation, skal man i afdækningsfasen tage stilling
til en række grundlæggende forhold, der har stor betydning for det produkt, der i sidste ende skal udarbejdes. Disse forhold vil afhængig af formål og kontekst for appen variere – men mange af spørgsmålene
vil være relevante i de fleste projekter. Vi gennemgår i dette kapitel grundlæggende overvejelser og
udfordringer og giver et bud på, hvordan du håndterer dem.
Afdækningsfasen handler om at forstå og forholde sig til den virkelighed, appen skal fungere i. Det er
vores opfattelse, at en app ikke altid er den eneste rigtige løsning. Gang på gang oplever man faktisk,
hvordan der fokuseres på en bestemt løsning frem for at se på, hvad man ønsker at opnå, eller hvad
det bagvedliggende behov er.
Afdækningsfasen handler altså både om at finde ud af, om en app er den rigtige løsning, og fasen handler
om at definere formålet med og konteksten for appen. I afdækningsfasen skal man således sandsynliggøre appens eksistens og tage stilling til de forhold, der skal sikre appens succes på kort og lang sigt.
Resultat af afdækningsfasen er en overordnet brief.
Vi arbejder med seks kategorier af forhold, der spiller ind.
MEDICO APPS - A PRACTITIONER’S GUIDE
25
Forretning
Den første fundamentale overvejelse lægger sig op ad forretningen. Dette vil typisk være business casen.
Hvilken værdi skal appen skabe? Hvordan skal appen bidrage til forretningen? Hvor kommer pengene
fra? Hvordan skal den finansieres? Hvordan skal appens værdi gøres op? Hvilken investering berettiger
appen, og hvilket ROI kan forventes?
De færreste vil udvikle en app uden en eller anden form for økonomisk overvejelse, der peger på, at
det er en god idé. Altså, at appen skaber værdi, der bidrager til en forretning. En app kan bidrage til
forretningen på flere niveauer. Fx som konkret salg, som en service, et statement (branding) eller som
en markedsføringskanal. Business-casen vil typisk beskrive, hvordan appen indgår i forretningen og
rumme en vurdering af rentabilitet og investeringens størrelse. Overvejer man at sælge sin app, er det
værd at notere, at de forskellige app butikker tager sig ganske godt betalt i provision. 30% skal man således forvente at betale af sin omsætning på appen, både på prisen for appen, samt det salg, der måtte
komme ind via appen. Det er naturligvis ikke altid muligt at vide på forhånd, hvilken effekt en app vil
opnå. Ofte er det dog muligt at sige noget om, hvad den helt sikkert ikke vil opnå, og derigennem kan
man skyde sig ind på en ikke helt urealistisk forventning.
En strategi for appen kan på basis af formål og business-case opstilles som en plan for, hvad appen specifikt skal, og hvordan den skal gøre det. Strategi handler om at opnå konkrete mål. Da appen indgår i
det samlede forretningssystem skal der være en konkret plan eller strategi for, appens rolle. Herunder
er det interessant at se på, hvordan andre har gjort med best practice studier, samt hvad konkurrenterne gør gennem en konkurrentanalyse. En god måde at vurdere eksisterende apps på, er bl.a. ved at
se på brugernes ratings og kommentarer i de forskellige distributionskanaler (App Store mv.). Vi ved,
at appen kan spille ind på afsenders positionering, og strategien skal sikre at positioneringen er rigtig
og bliver stærk.
Det er samlet set vores anbefaling, at omdrejningspunktet for appstrategien er, at appen supplerer
eksisterende kanaler mere end substituerer dem. Mobile apps kan helt andre ting og indgår i helt nye
sammenhænge, og i praksis betyder det, at apps kan skabe værdi på nye måder. Kopiering af fx en hjemmeside over på en app, er efter vores mening en misforståelse af mediet. Udnyttelse af smartphonens
indbyggede teknologiske muligheder som kompas, mikrofon, kamera, lys, display, højttalere, accelerometer, wifi etc. kombineret med mobilitet, bekvemmelighed og forenkling åbner mulighed for at tænke
i nye kreative baner, hvor information og interaktion bruges til at skabe merværdi. Dette gælder ikke
mindst medico området.
Eksempel
Ambu’s (se tidligere) business case var, at jo flere, der bliver uddannet i aScope, des flere køber
produktet. Det, appen kan, er at give let tilgang, lige her og nu til produkttræning, når det passer
lægen bedst. Strategien blev, at appen skulle supplere den eksisterende online uddannelsesportal.
Formål
Før et konkret projekt begyndes, er det en god idé at definere formålet med appen fx på basis af businesscasen. Når det først er besluttet, at en mobil applikation er den bedste løsning på et givet behov
(jf. ovenstående), er det relativt enkelt at opstille et formål for appen. Har man derimod ikke set på,
hvilket behov (ex en åbning i et marked, et supplement til andre kanaler mv.), appen skal dække, bliver
formålet mere uklart.
MEDICO APPS - A PRACTITIONER’S GUIDE
26
En anden væsentlig grund til at opstille formål er, at det efterfølgende kan dokumenteres, om appen
levede op til forventningerne. Så punkt to er at kvalificere formålet gennem opstilling af konkrete mål.
SMARTE-mål er en god guideline for opstilling af mål. Målene skal således være:
S: Specifikke
M:Målbare
A: Attraktive
R: Realistiske
T: Tidsbegrænsede
E: Evaluérbare.
På basis af målene defineres de evalueringskriterier, appen efterfølgende skal vurderes på.
Målgruppe
Som i enhver anden kommunikationssituation, er det en forudsætning for succes, at man kender sin
målgruppe. Målgruppen er de brugere, man forventer vil benytte appen, og deres adfærd adskiller sig
fra andre. Det er denne specifikke adfærd, der er interessant. Formålet med at kende sin målgruppe er,
at forstå hvordan appen kan skabe værdi for dem.
Spørgsmålene er: Hvordan er målgruppens medievaner? Hvordan er deres dagligdag? Hvor store brugere
er de af IT? Eller hvor vante er de med brug af IT? Er de innovatører eller late adopters? Hvilken kultur
opererer målgruppen i? Hvor og hvordan kan vi nå vores målgruppe?
Opstilling af persona profiler er en typisk metode i arbejdet med udvikling af kommunikations- og
it-produkter. Personaerne beskriver brugerne og deres adfærd og giver værdifuld indsigt om motiver,
barrierer, vaner, viden mv.
Med andre ord er det helt centralt at undersøge og forstå målgruppens vaner. Værdiskabelsen ligger
ofte i omsætning af indsigt i målgruppen og bør have stor påvirkning på den app, der skal udvikles. Aktiv
forståelse og brug af viden om brugerne er guld værd i konceptudviklingsfasen og er afgørende for, om
appen bliver en succes eller ej.
Eksempel
Ambu’s målgruppe er anæstesilæger globalt. Viden og undersøgelser viste, at lægerne ofte har
ventetid. De slæber rundt på en masse opslagsværker og modtager en masse produktinformation, som de aldrig åbner. Indsigterne gjorde, at idéen til appen blev købt. Også den konkrete
brugeroplevelse og indholdet på appen blev påvirket af brugerindsigt.
Teknologi
Når vi ved, hvad appen skal, hvordan og i hvilket samspil, er det næste at overveje det tekniske set- up.
Da apps afvikles på brugerens individuelle mobilenhed i modsætning til websites, der afvikles på en
central server, har det stor betydning for appens tilgængelighed og anvendelighed, hvilke platforme,
der udvikles til.
De forskellige platforme dækker iPhone (iOS), Android (Samsung, HTC, Sony Ericsson m.fl.), Microsoft
Windows Mobile (Microsoft, Nokia m.fl.) og Blackberry m.fl. Fordelingen på verdensplan af de forskellige platforme ses her:
MEDICO APPS - A PRACTITIONER’S GUIDE
27
Figur 5. Smartphone operating systems’ market share. Share of worldwide 2011 Q2 smartphone sales to end users by operating
system, according to Gartner. Gartner report “Market Share: Mobile Communication Devices by Region and Country, 2Q11”
Det kommer som en overraskelse for mange, at hver platform faktisk kræver særlig udvikling, og at der
i modsætning til, hvad man skulle tro, er stort set intet at genbruge på tværs af platforme rent udviklingsmæssigt. Det betyder, at to platforme koster det dobbelte at udvikle til som én. Det betyder også, at
appen skal lanceres to steder, at der ligger dobbelt så meget vedligeholdelse, og dobbelt så meget test
i udviklingsprocessen. Android telefonernes styrke er på den ene side deres mangfoldighed, fordi der
findes en model til ethvert behov og til enhver pengepung. På den anden side er Android telefonernes
mangfoldighed også en svaghed med over 800 forskellige modeller, der alle fungerer på sin egen måde.
Det er således stor set umuligt at designe eller for den sags skyld udvikle en app, der ser pæn ud og
fungerer perfekt på alle Android telefoner.
En fremgangsmåde, som mange benytter, er, at udvikle til én platform i første omgang og sikre et proof
of concept. Når den første app er udviklet, testet, launchet, taget i brug, virker og er blevet en succes
hos målgruppen, er det langt lettere og hurtigere at skabe en kopi på en ny platform. Det kan imidlertid
give god mening af andre årsager at udvikle apps til flere platforme samtidig. Her er det vigtigt at forstå,
at der reelt er tale om at gennemføre to udviklingsforløb samtidig, hvor ændringer hurtigt kan kræve
væsentlige ekstra ressourcer. Et helt centralt spørgsmål er således, hvilke platforme appen skal udvikles til.
Der findes statistikker for national udbredelse af mobilplatforme. Ligeledes findes der statistikker for
den demografiske fordeling af platformene. I Danmark kan statistik findes her: www.itst.dk/digitalelosninger/teleguiden samt www.dst.dk
En god tommelfingerregel er, at unge benytter de billigere platforme (Android), iPhone-brugere er mere
aktive i brugen af apps, og i USA er Blackberry mere udbredt end i Europa. iPhone dækker på verdensplan ca. 5% af smartphone markedet. I Danmark er tallet ca 35%. I Kina udgør iPhone under 5%! Her er
Nokia (Symbion) størst (mere end 70%).
Vi anbefaler, at man satser på at skabe velfungerende Andriod apps på udvalgte modeller, og den bedste
måde at finde ud af, hvilke platforme, der skal udvikles til, er altid ved at kende sin målgruppe. Indsigt i
målgruppens medievaner og eventuelle retningslinjer i organisationen vil give svaret på, hvilke platforme,
du skal satse på. Samt udbredelsen i det geografiske område hvor appen skal anvendes.
MEDICO APPS - A PRACTITIONER’S GUIDE
28
Et andet forhold vedr. IT-system ligger i beslutningen om, hvorvidt appen skal være statisk eller dynamisk. Om indholdet skal være embedded eller hentes online. Forskellen er, at den statiske version er
født med alt indhold, som downloades sammen med appen. Når appen først er lanceret, vil det være
umuligt at ændre eller opdatere indholdet uden at involvere udviklerne. Derfor er det helt centralt at
beslutte ud fra strategien med appen og kendskabet til målgruppen, om appen skal være indholdsmæssig opdaterbar eller ej.
Fordelen ved det statiske indhold er, at brugeren ikke behøver være online for at se indholdet, hvilket
kan være smart, hvis målgruppen fx er fra andre lande, der tit vælger at slå roaming i udlandet fra pga.
datapriserne. En anden stor fordel ved de statiske apps, er at de er mere enkle at udvikle og derved
billigere. Eksempler på, hvor en statisk app giver god mening er apps rettet mod turister, apps til internationale konferencer, apps der skal fungere på steder, hvor der ikke er internetadgang samt apps som
typisk har en meget specifik brug og kort levetid på brugerens smartphone.
En dynamisk app har indhold, der løbende kan ændres, hvilket kræver en backend a la et CMS, som det
kendes fra website. Dvs. en back-end, hvor en redaktør/content manager kan tilgå appens indhold og
ændre det uden at skulle rode med nogen form for programmering. En dynamisk app kan have sit eget
backend system, eller den kan blive feedet af et eksisterende system, der allerede er udarbejdet til et
website. I sidstnævnte tilfælde skal der udvikles et API mellem backendsystem og app, så de kan ”tale”
sammen. En overvejelse i denne sammenhæng er således, hvis man beslutter sig for en dynamisk app,
om indholdet skal opdateres fra ét fælles eller flere backend individuelle systemer til hhv. web og app,
hvilket er lidt mere omstændeligt. Det er ofte nødvendigt at integrationen med eksisterende IT-systemer
sker i samarbejde med de folk, der vedligeholder de eksisterende systemer i forvejen.
Et sidste punkt i dette afsnit er samspillet med eksterne enheder, der kobles på smartphonen. I fagtermer og nærværende guides forståelse kaldes dette for hybrid apps, da de sammenkobler to (eller flere)
platforme som fx en pulsmåler og appen. Ideen er, at der ved at koble appen sammen med en ekstern
enhed opstår ny værdi, der ikke var mulig uden sammenkoblingen.
Et eksempel er blodtryksmåleren fra Withings. En normal blodtryksmåler består af en manchet og en
kontrolenhed, der indeholder betjeningstaster, display og pumpe. Withings har udviklet en manchet
med indbygget pumpe, der styres via en iPhone, hvor også resultatet udlæses og logges. Denne blodtryksmåler giver langt større værdi, fordi iPhonen kan tilkobles internettet og resultaterne logges i en
grafisk kurve tilgængelig fra enhver enhed med internet adgang. Derudover fylder apparatet mindre og
har færre dele, der kan gå i stykker. Det bliver muligt for brugeren automatisk at se tendenser, historik
mv. og således mere præcist monitorere og fortolke blodtrykket.
Apps kan lukrere på de mange forskellige sensorer en smartphone indeholder (kompas, mikrofon, kamera, lys, display, højttalere, accelerometer, wifi etc.). Kombineret med, at smartphonen eller tablet’en
er mobil, er det kun fantasien, der sætter grænsen for kreative, værdiskabende hybride apps. Der findes
allerede tyverialarmer, der kan fjernkontrolleres af en app, og går vi ind i den medicotekniske verden,
er det kun et spørgsmål om tid, førend patienter og deres pårørende vil kunne monitorere og agere på
kritiske værdier målt på/af telemedicinske devices via hybride apps.
De teknologiske forhold har naturligvis stor betydning for projektets ressourceforbrug og appens anvendelighed. Leverandøren vil typisk kunne rådgive om disse forhold, og de rigtige beslutninger kan
træffes, hvis spørgsmålene adresseres indledningsvist.
MEDICO APPS - A PRACTITIONER’S GUIDE
29
Ressourcer
Det sidste punkt under de fundamentale overvejelser handler om ressourcer; Tid, penge og manpower.
Budget
Budgetdelen er naturligvis væsentlig for de fleste og hænger tæt sammen med den opstillede businesscase, hvor appens rentabilitet vurderes. Spørgsmålene er: Hvor meget kan man investere i appen, således
at den bibringer et fornuftigt ROI? Hvordan måler vi appens værdi? Hvilke ressourcer har vi til drift?
Hvor meget mere får vi ud af at udvikle til flere platforme? Hvad får vi ud af at investere i et backend
system, der gør appen opdaterbar?
En overordnet budgetramme er et nødvendigt styringsværktøj for de fleste. Herunder vurdering af, hvor
stor en margin, der opereres med, hvis det bliver nødvendigt at tilføre flere midler undervejs i projektet.
Det er vores erfaring, at gennemarbejdede apps koster i omegnen af 100-200.000 kr. pr. platform. Hertil
vil komme udvikling af backend, der kan ligge på det samme niveau afhængig af, hvad der findes i forvejen. Parametre af betydning for prisen er: Appens funktionalitet (jo mere – jo dyrere), antal platforme
(jo flere – jo dyrere) samt om appen har statisk eller dynamisk indhold (jo mere backend udvikling eller
integration af eksisterende backend til styring af indholdet – jo dyrere)
Tid
Tidshorisonten er endnu et centralt punkt i planlægningsdelen. Spørgsmålene er: Hvilke andre aktiviteter
kan påvirke appens lanceringsdato? Hvornår skal appen være færdig? Hvilke milepæle skal der opstilles? Hvad kan forsinke processen? Opstilling af en overordnet projektplan er et godt redskab, hvor der
afsættes tid til de i det næste kapitel beskrevne faser.
Det er i denne sammenhæng vigtigt at vide, at en godkendelse af appen til Apples App Store kan tage
op til to uger og kan medføre, at appen ikke godkendes, hvilket betyder yderligere forsinkelse. I Android
Market er lanceringsprocessen ca. to timer. Den langtrukne App Store proces gør, at apps og stramme
deadlines er en risiokofyldt cocktail.
Det er vores erfaring, at et app projekt kan tage helt op til tre-seks måneder at gennemføre fra start
til slut. En fordeling kunne se således ud: Planlægningsfase, en til to måneder. Design og udvikling, to
måneder. Test og godkendelse, en til to måneder. Vær derfor realistisk med tiden. Det kan ikke betale
sig at presse projektet. Kom hellere i gang i god tid forud for en fast deadline.
Manpower
Herunder ligger forhold som, hvem der skal udvikle appen? Hvem skal styre processen? Og hvem der
skal vedligeholde appen?
De fleste får i dag udviklet apps af underleverandører og valget af underleverandør hænger ofte sammen
med, om ens eksisterende partnere udvikler apps. I mange tilfælde vil det være fornuftigt at indhente
tilbud fra flere leverandører, og selvom mange leverandører på papiret ser ud til at give den samme
ydelse, kan der være stor forskel på, hvilket produkt man får som kunde. Derfor skal en opdragsgiver
vurdere, hvad der er vigtigt i en samarbejdsrelation. For der ER forskel på leverandører, og deres kompetencer er forskellige. En samlet udviklingsproces består typisk af både rådgivning, idé-udvikling og
programmering. Undersøg hvad dit behov er og spørg ind til, hvad leverancen dækker. Se referencer og
søg garanti for at virksomheden også findes i fremtiden.
Det er vores erfaring, at succesfuld gennemførsel af appudvikling kræver en fast ressource og opdragsgiver til projektstyring, dialog og evt. efterfølgende drift. Casene i denne guide har alle krævet hvad der
svarer til en fuldtidsmedarbejder i 30-50 % af den samlede projektperiode. Hertil kommer inddragelse
af beslutningstagere og andre interne ressourcer fra andre afdelinger.
MEDICO APPS - A PRACTITIONER’S GUIDE
30
Eksempel kontaktpris
Ambu’s tilstedeværelse på en af de store betydningsfulde medicokonferencer kan med alle
omkostninger medtaget løbe op på anslåede 1 mio. kr. Der kommer est. 4.000 mennesker, og
går det godt, kommer Ambu i kontakt med ca. 10% af disse gennem symposier og andet. Den
rå kontaktpris er derved: ca. 2.500 kr. Appen kostede ca. 200.000 kr. og har pt. opnået 9.000
downloads. Hvis 50 % af disse er kvalificerede leads betyder det en rå kontaktpris på: ca. 45 kr.
Tallene er naturligvis ikke direkte sammenlignelige, men er et eksempel på en økonomisk betragtning af en apps værdi.
ROI – Return on investment
Hvis man anslår, at et lead er 1.000 kr. værd for AMBU, kan ROI udregnes. ROI ved at stå på messe:
1.000/2.500=0,4. ROI på app: 1000/45=22. Dette er selvfølgelig alt andet lige betragtninger og
uden hensyntagen til evt. forskel i udbytte af en kunde hvervet personligt på en messe og en
kunde hvervet via appen.
Jura
Størstedelen af de juridiske hensyn fsva. medico apps vil læne sig op ad de regulatoriske forhold (se afsnit
3). Selv apps, der formidles gratis, fortolkes lovgivningsmæssigt som markedsføring, dvs. en gratis app
skal stadig godkendes regulatorisk såfremt den rent teknisk falder ind under definitionerne i afsnit 3.
Overordnet set skal en medico app forholde sig til, om de er henvendt til privat eller professionel brug.
Herefter skal den forholde sig til, hvilket geografisk marked den markedsføres til. Slutteligt skal udvikleren
undersøge eventuelle rettigheder til apps indhold, herunder patenter og specielt copyright, hvis tekst,
billeder/grafer eller lyd anvendes fra andre kilder.
Det tilrådes at kontakte professionelle rådgivere herom fx patentrådgivere. Teknisk set er det muligt at
hente data og andet indhold fra andre apps i en separat app, og dette stiller naturligvis krav om indhentning af accept fra de øvrige apps, dels om indhentning af data, dels om sammenføring med evt.
konkurrenter. Som eksempel kan nævnes de apps, der fremviser tilbudsaviser. De bør sikre sig en aftale
om at hente data men også om at lægge deres indhold side om side med konkurrenter.
Slutteligt er der apps, der giver brugerne mulighed for at ytre sig. Det kan være uhensigtsmæssigt at
kontakte fagfolk, der kan rådgive om juridiske konsekvenser, hvis en bruger går over stregen, eller hvis
brugerne viser andre måder at benytte appen på, end den tiltænkte brug.
MEDICO APPS - A PRACTITIONER’S GUIDE
31
Tjekliste
De fundamentale forhold
– Samles i en brief
Forretning
(business case)
! Eksistensberettigelse
Samspil
med
andre
tiltag
! Opstilling af strategi
!
Formål
!Behovsafdækning
med appen
!Formål
Opstilling
af konkrete mål
!Evalueringskriterier
!
Målgruppe
er målgruppen
!Hvem
Hvad
er
deres medievaner
!Hvilken kultur
spiller appen ind i
!
Teknologi
platforme udvikles appen til
!Hvilke
Skal
indholdet
dynamisk eller statisk
!Skal appen havevære
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
appen henvendt til privat eller professionel brug
!ErHvilket
geografisk marked den markedsføres til
!Er eventuelle
rettigheder til apps indhold clearet
!Hvad er brugerinddragelsespolitik
!
MEDICO APPS - A PRACTITIONER’S GUIDE
32
6.
Udviklingsprocessen
- En fremgangsmåde i fem trin
Når planlægningen af de fundamentale seks forhold er på plads, påbegyndes selve udviklingen. Vi har
i dette kapitel samlet gode råd, erfaringer samt tjeklister vedr. denne del af processen, der kan sammenfattes i fem trin:
Specifikation
Specifikationsfasen ligger på en måde mellem planlægning og udvikling. For udvikling uden en forudgående specifikation kan mildest talt ikke anbefales. Det er i specifikationsfasen, at ideen med appen
bliver tydeliggjort og konkret. En specifikationsproces kan ske i flg. trin:
Idé-udvikling
Planlægningsfasen har forhåbentlig gjort det klart, hvad appen skal overfor hvem. Og derved er idéen
med appen overordnet set defineret. Som oftest vil idéen dog være beskrevet på et lidt højere plan
og ikke være knyttet direkte sammen med de teknologiske og mediemæssige muligheder som en app
rummer. Derfor er konceptudvikling første skridt i konkretisering af appen, og her kan det for de fleste
være gunstigt at alliere sig med eksperter på området fx gennem en workshop.
MEDICO APPS - A PRACTITIONER’S GUIDE
33
Ideen med at mødes og idéudvikle i fællesskab er at få bragt de forskellige interessenters kompetencer
mest muligt i spil. Opdragsgiver sidder inde med viden om forretningen. Målgruppen (fx klinikere) sidder inde med viden om kultur, adfærd og eksisterende teknologier. Teknikkerne sidder inde med viden
om de eksisterende IT-systemer. Og leverandøren er typisk eksperter inden for områderne som digital
konceptudvikling, design, teknologi og medier.
Samskabelse på idéniveau er en stor gevinst for det samlede produkt og et stærkt udgangspunkt for
et konkret koncept, der rent faktisk vil blive en succes i praksis. En anden fordel ved at inddrage de
forskellige interessenter tidligt er, at de får ejerskab og kan bidrage løbende i udviklingsprocessen med
feedback, fordi de allerede er med i ”loopet”.
Resultatet af en god idé-udviklingsproces er at stå tilbage med et klart og afstemt billede af, hvad præcis
appen skal kunne og rumme. Appens koncept, som ud over at beskrive idéen med appen og appens
funktionalitet, omhandler appens indhold. Og det må siges igen, at ”content is king”. Indholdet udgør
appens værdi. Om det er et ægge-ur, der fortæller dig, hvornår dit æg er blødkogt, om det er dagens
nyheder, der konstant er opdateret, om det er priser på benzin, vejret, et spil, aflæsning af en måleenhed, statistik om personlig performance, nærmeste bager, nærmeste toilet, nærmest kunstværk osv.,
så handler det altid om indhold. Indhold gjort tilgængeligt for brugeren på en måde, der skaber ny
værdi. Og derfor er det ulejligheden værd at samle de mest kompetente mennesker på området for at
skabe det bedste indhold, der leveres på den bedste måde for brugerne i et samlet homogent koncept.
Prototyping
Når appens koncept er defineret og beskrevet, kan appens anatomi visualiseres mere i dybden. Wireframing og prototyping er vigtige værktøjer i denne proces. Wireframes er en optegning af appens
side/skærmvisninger, hvor både navigationselementer (som knapper, menuer mv.), indholdselementer
(som tekst, billeder, video mv.) samt funktionalitet (som share, søg, optag, bestil mv.) er medtaget.
Wireframes er en skitse af appen, der i første omgang skaber overblik over, hvordan appen er struktureret, og hvordan elementerne er placeret. Det er et meget vigtigt værktøj, fordi det er en helt konkret
dokumentation af appen. Wireframes definerer også appen fremadrettet for designere og udviklere. I
første omgang behøver wireframes ikke gå ud i alle detaljer. Det er en iterativ proces, hvor appen foldes
mere og mere ud, hvilket dokumenteres gennem wireframes.
Prototyping er et naturligt næste skridt for de fleste. Det er ikke på samme måde et must som wireframes, men prototyping er en god og endnu mere specifik måde at dokumentere flowet af indholdet i
appen på. En app prototype er klikbare wireframes sat op i et program, hvor man kan navigere rundt
i appen. Det behøver ikke være kompliceret, og vi har set flere eksempler på, at software som Power
Point fungerer udmærket til at oprette de klikbare versioner af wireframes på. Der findes også mere
avancerede softwareprodukter, hvor wireframes og prototype skitseres samtidigt (ex. Axure ell. OmniGraffle) og slutteligt findes der software, der kan vise prototypen på den mobile enhed (ex. Prototype
app). Prototypens styrker ift. wireframes er, at de er interaktive, at detaljeringsniveauet er højere, og at
overblikket er endnu mere struktureret, fordi alle klikbare elementer gennemgås. Det betyder, at ”alle
sten vendes”, vurderes og kan tilrettes, indtil appen rummer og gør det, den skal.
Hele idéen med wireframes/prototyping er således at visualisere produktet og gennem en iterativ proces
justere og optimere appen, indtil den kan godkendes. Den godkendte wireframe/prototype er herefter
omdrejningspunktet for den videre udvikling og det produkt, der produceres. Ændringer efterfølgende
på wireframes og flow betragtes af de fleste leverandører som opgaver ud over det aftalte og koster
ekstra. Wireframes/prototype er så at sige ”point of no return”.
Kravspecificering
Ud over wireframes/prototyping ser vi ofte en kravspecifikation udarbejdet, som i ord beskriver, hvad
der sker i de forskellige stadier af appen. Kravspecifikationen er god, fordi den giver mulighed for at
MEDICO APPS - A PRACTITIONER’S GUIDE
34
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øgning, bestilling, deling mv.) osv., samt hvor ansvaret for den givne bagvedliggende proces ligger (kunde
eller leverandør). Kravspecifikationen kan med fordel tænkes sammen med prototypen og skrives i det
samme dokument.
Kravspecifikationen skal betragtes som en helt central del af specifikationsfasen og skal være afstemt
før de næste faser påbegyndes.
Budgetfastlæggelse
Pointen med specifikationsfasen er at skabe et fælles og klart billede for alle interessenter af, hvordan
appen skal opbygges og fungere. Specifikationen er det blueprint, udviklingsprocessen efterfølgende
tager udgangspunkt i, og det er faktisk først, når specifikationsfasen er afsluttet, at produktet er klart
defineret.
Derfor er det også det helt rigtige tidspunkt at opstille et detaljeret budget på. En overordnet drøftelse
af budgetrammen bør finde sted allerede ved den indledende dialog med leverandøren. Et realistisk
budget, der harmonerer med det valgte koncept, kan dog realistisk set først udarbejdes, når specifikationsfasen er gennemført.
Således er sidste del af specifikationsfasen opstilling af det endelige budget, der tager udgangspunkt
i den udarbejde kravspecifikation med wireframes/prototype. Det er i denne fase, at funktionaliteten
ligeledes skal nedjusteres, hvis budgettet overstiger den fastsatte ramme fra planlægningsfasen. Derved er budgetteringen også en iterativ proces, der hænger sammen med specifikationen af produktet.
Når budgettet er lagt fast og appen er beskrevet i detaljer, er det tid til at reviewe projektplanen og
opstille en endelig projektplan med milepæle. Er der ikke allerede indgået en skriftlig kontrakt med
leverandøren, bør det ske her.
Design
Designfasen ligger som regel hos leverandøren, og dette er også en iterativ proces. Første trin vil være, at
designretningslinjerne defineres fra opdragsgiveres side. Retningslinjer omfatter, om der er en corporate
design guide, der skal følges, om der er ønske om et bestemt look’n’feel, om appen skal ligne en eksisterende kampagne mv. Det er de visuelle retningslinjer, som designerne skal følge i det kreative arbejde.
På basis af den indledende designbrief, vil der typisk komme et udspil fra design og konceptudviklerne.
Et af de steder, hvor digital design og almindeligt design adskiller sig, er i, at det digitale design rummer
en grænseflade (interface), som brugeren interagerer med. Heraf er opstået begreberne GUI (graphical
user interface), som man bl.a. kender fra skrivebords-mataforen på både Mac og PC, hvor grænsefladen
mellem person og computer foregår i et metaforisk univers, som er let at forstå og bruge. NUI (natural
user interface) er det nyeste skridt i interface designudvikling og dækker over ideen om, at brugeren får
tilgang til enhedens funktionaliteter gennem en naturlig interaktion og progression. Ideen med NUI er,
at interaktionen selv med komplekse applikationer bliver intuitiv og naturlig. At brugeren hurtigt opnår
et ekspert niveau… og får succes ved at tilgå appen på en spontan og naturlig måde.
Det er således ikke helt ligegyldigt, hvordan appen designes. Navigation, interaktion, flow og tilgængelighed bør indtænkes aktivt i designprocessen. Hertil kommer det faktum, at de forskellige platforme
har forskellige skærmstørrelser og et forskelligt fysisk interface. Androids mangfoldighed med over 800
modeller i et hav af forskellige skærmstørrelser gør det umuligt at designe til alle modeller. Samtidig er
der forskel på Android og iPhones fyskiske knapper, der gør, at fx en ”home”-knap til iPhone skal være
del af designet, mens den er en fysisk knap på en Android telefon.
MEDICO APPS - A PRACTITIONER’S GUIDE
35
En af de helt store udfordringer i design for apps er selvfølgelig, at skærmen er lille, og at man navigerer
rundt med sine fingre. Det betyder, at interfacet skal være både minimalt i sit informationsindhold, og
at knapperne skal have en vis størrelse for at give fysisk mening. Ofte skal brugeroplevelsen af appen
være baseret på en mere direkte berøring og bevægelse af elementerne. Man flytter ting på skærmen
(lås op fx), man drejer på en knap, man forstørrer et billede med to fingre etc. Smartphonens multitouch
teknologi har åbnet op for nye mere visuelt og fysiske måder at interagere på, og brugerfornemmelsen bliver ofte, at man står med et device, der fysisk ”fylder” meget mere, end man kan se, og at man
skubber elementer, navigationsbar og knapper rundt i det lille udsnit skærmen udgør, afhængig af, hvad
man har brug for lige nu.
To ting har for alvor skilt appdesign ud fra andre eksisterende medier og skabt nyt formsprog; Nemlig
ikoner og det naturlige look. Ikonerne er enkle grafiske repræsentationer, der symboliserer en funktion,
og det kan faktisk være en udfordring at opfinde passende ikoner til helt specifikke funktioner. Det
naturalistisk-baserede look er et andet formsprog, som mange apps benytter. Fx en guitarforstærker
app, der ligner en fysisk guitarforstærker. En boghandler app, der ligner en bogreol. Knapper, der ligner
metal mv.
Virkelighedens verden og ikke mindst håndens anatomi skal tænkes med, når der designes. Placering
af knapper efter brugerens tommelfinger har direkte konsekvens på, om brugeren oplever interfacet
som naturligt eller ej. Det er vores anbefaling, at appens design lægges op af eksisterende formsprog
og konnotationer, der allerede er etableret og genkendes af brugerne. Det vil understøtte brugerens
intuitive tilgang. Heldigvis findes der et hav af grafiske redskaber, skabeloner og samlinger, der kan
bidrage og nærmest er uundværlige i designet af en flot app.
Skabelse af den naturlige oplevelse og brug af appen ligger i designfasen. Processen vil typisk køre frem
og tilbage over et par omgange, der ofte er aftalt på forhånd, indtil det rigtige look’n’feel er skabt, og
navigationen er optimeret med placering af knapper og elementer de rigtige steder. Der findes gode
og nærmest uundværlige programmer (Ex Live View Screencaster), der kan styrke dialogen omkring
designprocessen ved at vise designet live på en telefon, man kan stå med i hånden.
Vi anbefaler, at man brugertester interfacet på designniveau i stedet for at vente, til det er implementeret.
En god måde at gøre dette på, er ved at indarbejde det valgte design i prototypen, således, at man har
fornemmelse af, hvad appen kan, og hvordan den ser ud mens brugeren klikker sig gennem den. Husk at
brugernes respons altid er guld værd – både når det er positivt, og når det giver anledning til ændringer.
Sidste trin i designdelen er rentegning og overlevering til udviklerne. Ligger design og udvikling hos én
leverandør sker denne overlevering automatisk. Ligger design og udvikling hos forskellige parter, bør der
fra start være aftalt, hvordan overlevering af designdokumenter skal ske. Herunder detaljeringsniveau
og formater. I sådanne tilfælde kan det overvejes at bede designeren udarbejde en såkaldt style guide.
Udvikling
Udviklingsfasen er ofte den mest ressourcekrævende del af et app-projekt målt i mandetimer, og der er
masser af litteratur tilgængelig på området. I denne guide har vi et praktisk fokus, hvilket betyder, at vi
tilgår udviklingsfasen ud fra hvilke forhold, der med fordel kan overvejes rundt omkring udviklingen. Vi
behandler ikke værktøjer til udvikling, eller hvordan man udvikler en app. Disse forhold kan en leverandør rådgive om. Men netop fordi selve udviklingen er så ressourcekrævende, er det naturligvis vigtigt,
at der træffes de rigtige beslutninger omkring udviklingen, så ressourcerne bruges mest fornuftigt. Det
er disse forhold, dette afsnit omhandler.
Applikationstyper
Den første overvejelse handler om valget af applikationstype. Der findes forskellige applikationstyper,
der alle fungerer som det, man betegner som en mobile app. De afvikles på brugeres smartphone og
MEDICO APPS - A PRACTITIONER’S GUIDE
36
dækker i nogen grad de samme muligheder. Imidlertid er der tale om forskellige teknologier og derfor
rummer de forskellige typer forskellige begrænsninger og muligheder.
Native apps
Er den type apps, der er skræddersyet, udviklet og optimeret til den konkrete platform og styresystem,
som appen skal afvikles på. Det er den teknologisk set mest optimerede app ift. enheden. Det betyder
også, at native apps ikke er særlig skalerbare, når det kommer til de andre platforme, og koden kan ikke
genbruges på tværs. Til gengæld kan appen udnytte smartphonens fulde teknologiske potentiale. Man
taler om et app-finish, der dækker over den følelse, man som bruger oplever, når man benytter appen.
Hvordan designet spiller sammen med navigationen, hvordan enheden responderer på interaktionen,
hvor stabilt appen kører, hvor lækkert og gennemarbejdet detaljerne fungerer. På native apps er disse
forhold optimerede. Native apps er det, man også kunne kalde ægte ”fuldblodsapp”.
Fordelene er:
!Optimal performance
!Stærk brugeroplevelse
!Fuld adgang til enhedens funktionaliteter og teknologi
!Nemt at finde i diverse app butikker
!Nemt at notificere brugere om updates
!Push-opdateringer
!Fungerer offline
Ulemperne er:
!Platformsspecifikke
!Skal installeres
!Skal godkendes af Apple (iOS)
!Provision til fx Apple og Google (Android Market) - pt. 30%
Web apps
Kan på mange måder sammenlignes med et avanceret website, optimeret til mobile enheder og med
udnyttelse af de nyeste teknologier, der gør, at enhedens teknologi kan benyttes (kamera, GPS, kontakter etc.). Web apps afvikles på en server (tynd klient) og kræver at brugeren er online. Web apps er
fx en mailapplikation på enheden eller cloud-relaterede apps. Web apps er mere skalerbare på tværs
af platforme, men afvikles og vises ikke 100% identiske på alle enheder. Det betyder i praksis, at web
apps skal optimeres til de mest anvendte enheder hos målgruppen. Web-finish er ikke helt på niveau
med native apps, men stærke teknologier som HTML 5 har gjort brugeroplevelsen langt mere app-agtig.
Fordelene er:
!Ingen installation
!Virker på tværs af platforme (skalerbarhed)
!Skal ikke godkendes i en app butik
!Ingen provision til div. app butikker
!Projektet er i sin helhed mindre omfattende
!Skal ikke opdateres på brugerens enhed
!Høj grad af statistisk overvågning
Ulemperne er:
!Skal være online
!Middel brugeroplevelse (svært at opnå “app-finish”)
!Middel performance
!Ej fuld adgang til enhedens funktionaliteter
!Kan være sværere at finde for en bruger
MEDICO APPS - A PRACTITIONER’S GUIDE
37
Framework apps
Den sidste type er de såkaldte framework apps. Det, der karakteriserer frameworkapps, er, at de er meget
skalerbare på tværs af platformene. I princippet udvikles én app inden for frameworkets regi, hvorefter
den sprøjtes ud af frameworket i de ønskede platformsversioneringer. Det er jo rigtig smart, og derfor en
voksende industri, som også de helt store spillere (ex. Adobe) er gået ind i. Udfordringen er imidlertid,
at frameworket som ofte har sine begrænsninger, for det siger sig selv, at kompleksiteten i at udnytte
enhedens fulde funktionalitet som en native app gør, ikke blot lader sig kopiere til andre platforme.
Resultatet er derfor ofte, at laveste fællesnævner sætter standarden simpelthen fordi Frameworket ikke
understøtter mulighederne. Det gælder også styling, hvilket betyder at app-finish ikke er i top.
Fordelene er:
!Virker på tværs af diverse platforme
!Mange-i-én gør processen hurtigere og billigere
!Automatisk sikring af look på tværs af platforme
Ulemperne er:
!Kræver at man sætter sig ind i frameworkets udviklingsmiljø
!Begrænset udnyttelse af enhedens funktionaliteter
!Middel performance
!Svært at opnå “app-finish”
Inhouse eller outsourced
Den næste overvejelse er, om udviklingen skal ligge i huset eller outsources til en underleverandør. Er
der ikke tidligere erfaring med appudvikling, er det som regel ikke verdens bedste idé selv at udvikle
appen. Vores anbefaling er, at man som opdragsgiver starter med ekstern udvikling og evt. rykker udviklingen in-house efterfølgende. En mulighed er at koble egne udviklere på processen hos leverandøren
og derved bygge viden gennem processen.
Overvejelser om valg af leverandør er beskrevet i FØR-afsnittet og skal her blot suppleres med flg. to råd:
!Lav aftaler om, hvordan udviklingen dokumenteres i tilfælde af, at andre skal overtage den på et
tidspunkt.
Lav
aftaler om rettigheder til koden, at den opbevares forsvarligt og at den er tilgængelig i fremtiden.
!
Projektledelse
Ledelse af et medicoapp udviklingsprojekt adskiller sig på især to områder fra at lede andre softwareudviklingsprojekter. For størstedelens vedkommende er det relevant at inddrage regulatoriske godkendelsesprocedurer, hvilket kræver specialister og dermed ekstra tid såvel som finansielle ressourcer. Der
kan for ikke-medico virksomheder ligge udfordringer i at gennemskue konsekvensen af at træde ind
i medicobranchen, for selvom appen i bund og grund er ren kode, gælder der anderledes stringente
regler og ansvarsforhold, når produktet skal forholde sig til menneskers liv og velvære. Generelt hører
det desværre til sjældenhederne, at IT-projekter leveres fuldstændig til den aftalte tid og inden for
budgettets rammer. Medico apps indeholder både en regulatorisk og en kvalitetsmæssig joker. Sørg for
at undersøge myndighedskrav inden det endelige budget fastlægges og lav en aftale med styregruppen
om frekvens for budget status.
Det andet udfordringsområde handler om den mere generelle projektledelse og styring. App-projekter
er specielle i det, at de på den ene side er begrænsede i deres koncept og på den anden side også meget
komplekse, fordi det er nyt terræn, fordi bagvedliggende systemer skal integreres og fordi, der udvikles
til klientafvikling på meget forskelligartede platforme (iPhone, Android, Blackberry mv.).
MEDICO APPS - A PRACTITIONER’S GUIDE
38
Det bliver derfor essentielt at projektet scopes rigtigt fra begyndelsen både ift., hvad der er inden- og
udenfor projektets rammer men også ift. tidsramme, samarbejdsform og afprøvning. Vi har dedikeret
næste afsnit til test og afprøvning alene, da dette er helt centralt for projektets succes. Dette afsnit
gennemgår projektledelse og samarbejde mere generelt.
Styregruppe
Det er vores erfaring, at nedsættelse af en styregruppe hos opdragsgiver fungerer godt således, at
projektlederen er ansvarlig for den praktiske dialog og kontakt med leverandøren og løbende sikring
af, at kravspecifikationen opfyldes, mens styregruppen er ansvarlig for godkendelsen af produktet iflg.
de opsatte milepæle. Styregruppen bør være forankret på et beslutningsdygtigt niveau i organisationen. Sørg for at afstemme med styregruppen, hvad projektet IKKE vil levere. Det er bedre at tage den
diskussion up front end til sidst. Specielt sensitivt er det med appudvikling, idet det som udgangspunkt
tilrådes at holde appens design så simpelt som muligt (en app anvendes oftest på farten og med en
hånd, så des færre knapper, desto bedre). Styregruppen vil hurtigt foreslå flere features, hvorfor det
ikke er en kamp mellem features og budget snarere end en kamp mellem features og brugervenlighed,
der skal afstemmes.
Referencegruppe
Sørg desuden for at have de rette kompetencer og ressourcer i projektet. Fx kan tilknyttes en ressource-/
reference-gruppe, der bistår projektlederen både før og under selve udviklingen. Referencegruppen kan
bestå af brugere, fageksperter, klinikere og IT-folk, der alle sidder med vigtig viden og indsigt til gavn
for projektet. Deres rolle er at vurdere og komme med anbefalinger undervejs i forløbet vedr. kritiske
faktorer med konsekvenser typisk på indholds- og afviklingsniveau.
Iterative udviklingsprocesser
Fordi app-projekter på trods af deres begrænsning i form og indhold alligevel kan vise sig at være meget
komplekse at udvikle, er det en god idé at benytte projektledelses- og udviklingsmetoder, der tager
højde for, at alle krav måske ikke kan defineres fra starten, samt at der kan opstå ændringer af kravene
undervejs, fx når man bevæger sig fra en platform til en anden.
Et udviklingsprojekt kan enten foregå efter en vandfaldsmodel eller iterativt. I vandfaldsmodellen foregår
udviklingen i en række faser fx; Kravspec., analyse, design, programmering og test. Herunder udvikles
hele programmet typisk på én gang, nemlig i programmeringsfasen. I et iterativt forløb vil man som regel
gennemføre faserne i en række kortere forløb, der ligger i forlængelse af hinanden, hvor programmet
udvikles i form af små dele, der gradvist udbygges, til det endelige program er lavet.
I udviklingen af medicoapps er det en fordel at arbejde med en kombination af vandfald og iteration,
således at de indledende faser med konceptudvikling, kravspecificering og design færdiggøres efter
vandfaldsmetoden, mens selve programmeringen gøres mere iterativ og sker i små skridt.
Det vil i de fleste tilfælde afhængig af kompleksitet, nemlig være umuligt at lave en 100% fyldestgørende
kravspecifikation fra starten, der besvarer og definerer alle spørgsmål. Derfor er det vores anbefaling at
bruge moderne agile udviklingsmetoder i programmeringsfasen, der er gearet til netop dette.
Agile Development (”adræt udvikling” på dansk) er en betegnelse for en række forskellige inkrementelle
udviklingsmetoder. De adrætte udviklingsmetoder er kendetegnet ved udvikling i små skridt (iterationer).
Hver iteration tilføjer ny eller forbedret funktionalitet, hvilket gør, at der løbende kan tages højde for
ændrede forudsætninger, krav og specifikationer.
I Adræt udvikling prioriteres opgaverne ud fra brugerens behov, og der kræves derfor en høj grad af
involvering fra kundens/slutbrugerens side. Adræt udvikling spiller derfor godt sammen med referen-
MEDICO APPS - A PRACTITIONER’S GUIDE
39
cegrupper. Blandt de mest kendte adrætte udviklingsmetoder kan nævnes Extreme Programming (XP)
og Scrum.
Det er vores anbefaling at samarbejdet om især udviklingsdelen gennemføres som en adræt proces
med tæt og jævnlig kontakt projektleder og leverandør imellem, med blik på små skridt ad gangen, en
konstant fremdrift samt med løbende dokumentation af dialog og beslutninger. Lange udviklingstræk
uden kontakt og udokumenterede beslutninger indeholder faldgrupper og kan vise sig at få uheldige
konsekvenser for projektet.
Overlevering
Projektet afsluttes, når appen lanceres, nu begynder den jo først at få et liv. Brugere giver feedback,
fejl opdages, nye features skal tilføjes, appen skal understøttes i det daglige. Disse ting hører måske
ikke ind i et projekt, men det er bestemt projektlederens ansvar at tænke en overlevering af appen fra
projekt til drift.
Test
Testforløbet er tæt forbundet med selve udviklingsprocessen. Ofte vil opdragsgiver have et ønske om
at følge med i udvikling og progression af appen, og omvendt vil leverandøren ofte også gerne have
appens enkelte dele løbende godkendt. At vi har valgt at lægge testforløbet som et selvstændigt trin
i implementeringsprocessen skyldes således ikke, at vi ser test som en isoleret del. Årsagen er, at vi
opfatter testfasen som et utroligt centralt element i appudvikling, og især for medico apps er test og
QA helt afgørende og kan vise sig at være ret ressourcekrævende. Medico apps skal være fejlfri, fordi
de ofte omfatter livskritiske temaer. Og lavere fejltolerance betyder alt andet lige mere validering og
flere test. Derfor behandler vi test som en selvstændig fase.
Uanset om testen ligger integreret i udviklingen eller om testfasen lægges i forlængelse af implementeringen, er det en rigtig god ide at definere testforløbet fra starten. Både for at sikre, at det gennemføres
som forventet, at der er sat tid af til det, og for at sikre at det tekniske set up fungerer.
En række centrale forhold gør sig gældende, for at sikre et grundigt og professionelt testforløb. Det første
i et testforløb er at sikre, at alle involverede parter har adgang til den tekniske løsning, dvs. appen. Det
næste er at opstille en plan for, hvad der skal testes evt. med deadlines. Og det sidste er at skabe en
feedback cyklus, der dokumenteres løbende og kan tilgås af alle involverede. Det er i bund og grund de
forhold, der som minimum skal være på plads. Hvordan ovenstående organiseres og hvilke systemer,
der benyttes er i princippet ligegyldigt, så længe de tre centrale byggesten er på plads.
Figur 6. Figuren illustrerer de tre centrale elementer i et vellykket testforløb: 1. Adgang til appen. 2. En overordnet plan for
testforløbet. 3. En feedbackcyklus, der dokumenteres i et fælles dokument, hvor fejlrapportering, kommentarer, feedback og
status ajourføres.
MEDICO APPS - A PRACTITIONER’S GUIDE
40
En af de store udfordringer ved apps er, at de afvikles på brugeres individuelle enhed. Det betyder,
at appen skal installeres fysisk på en smartphone for at fungere, og for at den kan testes. Normalt får
brugeren appen ned på sin telefon ved at downloade den fra en app store. Dette er dog forbundet med
lidt snilde, når det gælder testversionerne. For Android Market er det faktisk muligt at lægge testversioner op. Her kan man aftale, at udvikleren lægger en version op i et kort begrænset tidsrum hvor den
kan downloades af ”indviede”. Hos App Store er det dog ikke direkte muligt at lægge testversioner ud.
Derfor skal man igennem et mere omstændigt forløb, hvor hver eneste enhed, der skal bruges til test,
skal autentificeres, før de kan benyttes. Dvs. alle devices i opdragsgivers organisation, der tilhører folk,
der har noget at skulle have sagt i et test- og godkendelsesforløb skal registres som del af test set-up’et.
Herefter får de mulighed for at downloade appen til test. Dette er alt sammen forhold, som leverandøren kan rådgive om. Pointen er dog, at der ligger en teknisk procedure, som skal gennemføres for, at
opdragsgiver kan få adgang til testversionen af appen, og den procedure, kan med fordel påbegyndes,
før testforløbet skydes i gang for at undgå stilstand og forsinkelser senere i projektet.
Vi anbefaler, at et testforløb rummer fire grundlæggende værktøjer:
A. Den overordnede plan for, hvad der skal testes, evt. hvornår det skal gøres, og hvornår det kan betragtes som godkendt. Samt evt. retningslinjer for, opdatering, svartider, bekræftelser, godkendelse mv.
B. Et fælles dokument, hvor fejl, kommentarer og status løbende ajourføres mellem opdragsgiver og
leverandørens projektleder (PL).
C. Et bagvedliggende ticket system el. lign. mellem PL og udviklere, som er PLs styringsværktøj ift hvad
status er på de rapporterede fejl.
D. E t konkret teknisk set up, hvor opdragsgiveren rent fysisk får appen i den aktuelle version ned på
sin telefon.
Værktøjerne kan som sagt variere. Forholdene skal dog være på plads for at sikre et struktureret, effektivt og dokumenteret testforløb.
Lancering
Lanceringsfasen har vi valgt at dele op i den konkrete publicering af appen samt de efterfølgende forhold, der behandles i næste kapitel.
Lanceringen er det punkt, hvor appen er testet og godkendt af opdragsgiver. Den er klar til at gå live.
Og for at det kan ske, skal appen uploades til de respektive app butikker, hvor den så bliver tilgængelig
til download for brugerne verden over. For iPhones hedder app butikken ”App Store”, for Android telefoner hedder den ”Android Market”. For Blackburry hedder den ”App World” og for Windows Phone
hedder det ”Marketplace”.
Som nævnt er der forskel i både design og programmering af de forskellige platforme, og processen er
også forskellig, når det kommer til lancering. Lanceringen foretages af enten opdragsgiver eller leverandør. Vi anbefaler, at leverandøren står for lanceringen, der kan være en smule krævende især første
gang. Her skal vi kort gennemgå en række vigtige forhold vedr. lancering i App Store og Android Market,
som tilsammen udgør mere end 65% af verdens smartphones.
iPhone
For at kunne lægge en app ud på App Store kræves, at personen er med i det såkaldte ”iOS Development
Programme” og har et developer license, der koster 99 US$ pr. år. Dette er i det hele taget nødvendigt
for, at man kan udvikle iOS apps og derfor noget, leverandøren har styr på. I selve lanceringsprocessen
er det dog stadig vigtigt, at opdragsgiveren er med og bidrager på en række områder. Disse er:
MEDICO APPS - A PRACTITIONER’S GUIDE
41
!Valg af logo til App Store og brugernes iPhone
!Navn. Alle apps på App Store skal have et unikt navn.
!Beskrivelse. Beskrivelsen vises i App Store og må fylde op til 4.000 tegn. Det er afgørende for, hvor
mange apps der downloades, at beskrivelsen er god og attraktiv. Beskrivelsen laves til alle de respektive sprog samt engelsk.
!Kategorier. Apps i App Store er kategoriseret og kan findes i to kategorier. Vælg disse med omtanke,
for når appen er uploadet, kan kategoriseringen først ændres ved upload af en ny version.
!Nøgleord (keywords). Maksimum 100 tegn. Når brugerne søger i App Store, benyttes nøgleordene af
App Store. Nøgleord er derfor også centrale for appens udbredelse og kan kun ændres i forbindelse
med upload af en ny version.
!Applikation URL. Link til en webside, der beskriver appen eller til den service eller virksomhed, appen er relateret til.
!Support URL. Link til et website, hvor brugere kan få support.
!Support mailadresse. Mailadresse, hvor brugerne kan få besvaret supportspørgsmål.
!Skærmbilleder. Fem skærmbilleder der illustrerer appens funktionalitet. Skærmbillederne vises i
App Store og er afgørende for appens udbredelse.
!Pris. I App Store sælges apps efter fastlagte priser og kurser. Hvis en app ikke er gratis, er mindsteprisen 0,99 US$. Leverandøren kan rådgive videre om oprettelse af en konto hos Apple, hvor pengene
fra salget går ind. Husk at App Store tager 30% af omsætningen på appen.
!Lande. Skal appen kunne købes eller hentes globalt – eller skal salget begrænses til bestemte lande.
Efter appen er indsendt til App Store følger en venteperiode, hvor Apple gennemgår og (forhåbentlig)
godkender appen. Det tager normalt omkring en til to uger. Godkendes appen ikke er det forfra. Dvs.
man skal gennem godkendelsesproceduren igen. Når appen er godkendt, sender Apple en e-mail om,
at appen er klar.
Mange af de ovennævnte detaljer kan ændres efter godkendelse uden at skulle gå gennem godkendelsesprocessen igen.
Android
Ligeledes er der for Androidplatformen en række steps, man skal igennem for at uploade appen. Den
væsentligste forskel på App Store og Android Market er, at der ikke er en godkendelsesprocedure på
Android Market. Fordelen ved dette er naturligvis, at selve proceduren går hurtigere. Samtidig er muligheden for fejl i Android apps større.
For at kunne uploade i første omgang, skal man også her været registreret udvikler (Android Developer).
Det koster $25. Til selve lanceringen er de centrale elementer, skal der bruges flg.:
!Appen. Til forskel for App Store er der i Android Market en begrænsning på, hvor meget appen må
fylde. Maksimum er 50 Mb og overskrides denne grænse, vil appen ikke være tilgængelig på en
række håndsæt.
MEDICO APPS - A PRACTITIONER’S GUIDE
42
!Skærmbilleder. To skærmbilleder der illustrerer appens funktionalitet. Skærmbillederne vises i Android Market og er afgørende for appens udbredelse.
!Logo til Android Market og brugernes enhed.
!Navn. Et unikt navn. Maks. 30 tegn.
!Beskrivelse. Beskrivelsen må fylde op til 4.000 tegn. Det er afgørende for, hvor mange apps der
downloades, at beskrivelsen er god og attraktiv.
!Promo text. Android Market operer ud over selve beskrivelsen med en promoveringstekst (maks. 80
tegn) for hver app. Den har stor betydning for appens appel og derved for, hvor mange der downloades. Til teksten hører også en separat grafik.
!Kategori. Vælg appens kategori.
!Kopibeskyttelse (copy protection). Android apps kan kopieres fra brugernes telefon med mindre de
er kopibeskyttede. Dvs. at betalte apps skal benytte denne feature.
!Content Rating. Handler om hvorvidt indholdet er egnet til børn.
!Pris. Angivelse af om appen er gratis eller betalt.
!Lokation. Angivelse af hvilke lande appen skal være tilgængelig fra.
!Pris. På Android Market sælges apps efter fastlagte priser og kurser. Hvis en app ikke er gratis er
mindsteprisen $0,99 (DKK: 6 DKK - 1200 DKK). Leverandøren kan rådgive videre om oprettelse af en
konto hos Google, hvor pengene fra salget går ind. Fee på Android Market er 30% af omsætningen
på betalings-apps.
Når disse steps er klaret, bliver appen lanceret.
Herefter kaster vi blikket på post-lanceringsaktiviteterne.
MEDICO APPS - A PRACTITIONER’S GUIDE
43
Tjekliste
Implementeringsfasen
Specifikation
!Ideudvikling
!Prototyping
! Kravspecificering
Design
defineret i designbrief
!Designretningslinjerne
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
besluttet
!Applikationstype
eller outsourced besluttet
!Inhouse
Integrationspunkter
identificeret
!IT-folk taget med på råd
!Projektplan opdateret
!
Test
testplan afstemt
!Overordnede
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
!
MEDICO APPS - A PRACTITIONER’S GUIDE
44
7.
Efter udviklingsprocessen
- Markedsføring og drift
I dette afsnit ser vi på de forhold, der gør sig gældende efter selve lanceringen af appen. Det er forhold,
der allerede er blevet drøftet og taget i betragtning i de forudgående overvejelser. På mange måder
er post-lanceringsfasen afgørende for, om appen tjener sig hjem og bliver en succes. Bliver appen blot
lagt ud i app butikken uden nogen form for synliggørelse eller opdatering er appens livscyklus dømt til
at blive kortvarig allerede fra starten. Så hvor FØR-overvejelserne handler om at skabe den rigtige app
via formål, strategi og set-up, handler EFTER-overvejelserne om at få appen til at leve bedst muligt via
eksponering og fastholdelse.
For at styrke appens udbredelse og levetid, er der især tre grundlæggende forhold, der skal tages hånd om:
Figur 7. Illustrationen viser hvordan markedsføring, opdatering og videreudvikling booster downloads og forlænger appens levetid.
MEDICO APPS - A PRACTITIONER’S GUIDE
45
Markedsføring
App butikker udgør en selvstændig distributionskanal, der betyder, at apps når ud til nye målgrupper
gennem deres egen globale kanal. Man skal som bruger gennem en app butik for at downloade appen,
og derfor er det også et at de steder, brugerne kigger efter nye apps.
App butikker er et helt system med egen promoveringsmekanismer, top-10 lister, nyeste apps, dagens
app osv., der alt sammen er med til at eksponere appene og booste antallet af downloads. Derfor er det
naturligvis centralt, at appen får de bedste forudsætninger for at fremstå godt i app butikkerne gennem
flotte skærmbilleder, stærke og relevante keywords samt en retvisende og tiltrækkende beskrivelse.
Flere af disse elementer kan løbende rettes til og optimeres ud fra, hvad der synes at fungere bedst.
App butikkerne giver desuden mulighed for at tilgå brugbar statistik for, hvor mange der downloader appen samt en række andre relevante tal. Herunder hvilke modeller der er benyttet, hvilke lande brugerne
kommer fra, hvor længe brugerne har appen liggende osv. Der er bemærkelsesværdig stor forskel på,
hvad Apples App Store og Android Market giver af statistik, og gældende for iOS-app bør det fra starten
besluttes, hvor meget statistik, der er behov for. Vær opmærksom på, at udvidet statistik på iPhones
som tingene er i øjeblikket betyder ekstra udviklingsarbejde, og dette skal drøftes med leverandøren.
Desuden eksisterer der 3. parts software (bl.a. Flurry, Localytics og GoogleAnalytics), der giver mulighed
for yderligere interessant statistik.
Således er en central parameter for appens synlighed, hvordan den fremstår i app butikken. Det er så
at sige en hygiejnefaktor i markedsføring af appen. Der eksisterer hertil også deciderede mobile appsportaler på nettet, hvor det er godt at have sin app liggende.
Den anden helt væsentlige del af markedsføringen er eksponering på andre kanaler. Det grundlæggende
spørgsmål, man her bør stille er; ”Hvor er målgruppen?”. Og svaret vil fortælle, hvilke medier man skal
benytte. En god erfaring er, at onlinemediet ofte er stærkere end offline, når det gælder om at drive folk
til en online aktivitet som apps er. QR-koder, som er en let måde at koble off- og online sammen på og
er derfor også et interessant element, der kan skabe trafik. I bund og grund handler markedsføringen
om at synliggøre appen, hvor den er mest relevant og gøre den let tilgængelig. Et samspil af medier vil
ofte give den bedste effekt.
Figur 8. Figuren viser eksempler på markedsføringsaktiviteter, der bidrager til, at appen opnår flere downloads.
MEDICO APPS - A PRACTITIONER’S GUIDE
46
Opdatering
En anden afgørende faktor for appens udbredelse og levetid er, om indholdet opdateres eller ej. Man
kan sige, at spørgsmålet om opdatering, som beskrevet tidligere, i høj grad handler om, hvorvidt appens
indhold er statisk eller dynamisk. Uanset, hvordan man vender og drejer det, er der udgifter forbundet
med opdatering. Enten indledningsvist i form af omkostninger til integration med eksisterende backend
systemer eller udvikling af en ny backend eller efterfølgende i form af udgifter til dækning af egne og
leverandørressourcer ved en mere manuel opdatering. Så opdatering koster. Omvendt skaber det en
stor værdi både for brugerne og for udgiveren.
Faktum er nemlig, at apps, der opdateres, forbliver længere på brugernes smartphones af den simple
grund, at embeddede apps, hvor indholdet ikke ændres, hurtig mister sin værdi. Undtagelsen er selvfølgelig apps med meget konkrete funktioner som bestil togbillet, find vej, optag lyd osv. Disse apps har
ofte meget specifikke funktioner. En god tommelfingerregel er således, at jo vigtigere indholdet er for
værdiskabelsen set ift. funktioner, jo vigtigere er opdatering for appens relevans og levetid. Er indholdet
med andre ord drivende for værdiskabelsen, er muligheden for at opdatere vigtig.
Har man valgt at udvikle en opdatérbar app, er det hensigtsmæssigt at opstille en plan for opdateringerne
for et halvt år ad gangen. Planen bør dække spørgsmål som, hvad skal opdateres, hvornår, med hvad
og af hvem. En række underspørgsmål vil typisk derudaf dukke op om, hvilket indhold har vi allerede
tilgængeligt andre steder? Hvilke ressourcer kræves? Hvad er realistisk? Hvem kan producere det?
Content strategi er en måde at anskue indhold på, som handler om, at hvis man alligevel publicerer
indhold, så kan man lige så godt gøre det, som en professionel udgiver. Arbejd derfor med en fast redaktion, faste bidragsydere, en forretningsmæssig strategisk forankring og med en plan, der er realistisk.
Videreudvikling
I denne guide sonderer vi mellem opdatering af appens indhold og lancering af nye versioner af appen,
som vi karakteriserer som videreudvikling.
Videreudvikling af en app er nødvendig af flere grunde. For det første er det nødvendigt at forbedre
appen over tid, hvis den skal holdes i live herunder fejlretning og optimering. For det andet udvikler
teknologierne sig, hvilket betyder, at en app simpelthen bliver forældet både i form og funktion, hvis den
ikke opdateres. For det tredje kan appens værdi forøges væsentlig ved at udvikle den. Og for det fjerde
kan man tale om en form for ”revitalisering” af appen hos brugerne, når der kommer nye versioner.
En god kilde til inspiration, når det kommer til videreudvikling af appen, er at se på, hvad brugerne
mener om appen. Både statistik om hvilke funktioner der benyttes mest, samt hvilke elementer, der
downloades mest er interessant og giver en god indikation af, hvad der kan gøre appen endnu mere
succesfuld. Hertil har brugerne mulighed for både at rate (Vurdere) og kommentere på appen i app butikken. Brugernes kommentarer er ligeledes værdifuld viden. Slutteligt er der mulighed for efter noget tid
at afholde en fokusgruppe blandt brugerne, der kan give et nuanceret billede af punkter til forbedring
og fremtidige udviklingsmuligheder. Hvordan bruges appen? Hvad er det bedste ved appen? Hvordan
kan man gøre den endnu bedre?
Brugerdialog og -involvering i idé-generering er et stærkt redskab til videreudvikling af en unik, relevant
og succesfuld app. De fleste apps opstår ud af gode ideer, og de bedste apps formår at fastholde brugerne
i længere tid gennem fornyelse. Derfor er brugerne en central inspirationskilde for videreudviklingen,
og de kan med fordel involveres.
Når der uploades nye versioner af appen, vil det være synligt direkte på brugernes enheder med en lille
grafisk markering. Brugerne skal selv aktivt hente den nye version, hvilket på den ene side ikke garanterer, at alle brugere har den nyeste version liggende, omvendt skaber det top-of-mind hos brugerne
og minder dem om appen.
MEDICO APPS - A PRACTITIONER’S GUIDE
47
8.
Efterord
Tanken med denne guide har været at udarbejde en inspirerende og praktisk indføring i det at skabe en
medico app. På mange måder er udviklingsprocessen for medico apps identisk med udviklingsprocessen
for andre typer apps, og derfor er denne guide også mere bredt anvendelig. De steder, medico området
dog især adskiller sig fra andre områder på, er inden for QA og regulatury. Derfor har dette emne fået
en væsentlig vægtning og dybde.
Udarbejdelsen af guiden har været en berigende rejse for Medico Innovation og forfatterne bag guiden.
Mange ressourcestærke folk har været involveret i processen og har bidraget, hvilket undervejs har
betydet både kvalificering af de eksisterende afsnit, såvel som tilføjelse af nye. Tilbage står vi således
med en klar erkendelse af, at emnet på ingen måde er udtømt, og at guiden på ingen måde kan være
fyldestgørende for evigt.
Derfor er det vores ønske at arbejde videre med guiden og forhåbentlig i løbet af 2012 udkomme med
en version to med flere cases, med opdatering på det regulatoriske område, og hvor mere empiri indgår. Det er vores håb, at vi kan få endnu flere bidragsydere til at dele deres erfaringer med udvikling
af medico apps, at vi kan finde endnu flere eksempler på succesfulde medico apps til inspiration for
andre, og at vi kan blive ved med at bidrage til området gennem en guide, der er opdateret og tilbyder
aktuel og relevant viden.
Vi opfordrer derfor også folk, der har ideer eller ønsker at bidrage med input til den næste version, til
at henvende sig til os her:
[email protected]
MEDICO APPS - A PRACTITIONER’S GUIDE
48
9.
Begreber og terminologier
Både applikations- og medicoområdet bruger termer og ord, der har specifik mening og anvendelse.
For at skabe overblik og forståelse, har vi i dette afsnit opstillet en ordliste med forklaring af de gængse
termer. Desuden har vi indsat en række relevante links, som der gennem guiden refereres til.
510 (k)En af flere mulige godkendelser af de amerikanske sundhedsmyndigheder (FDA) for medicinske
devices, 510 (k) kan anvendes, hvis et lignende apparat findes i forvejen.
AndroidEt åbent styresystem udviklet af Google til Android (Droid) mobiltelefoner og tablets.
Android MarketGoogles markedsplads for applikationer.
ANSIAmerican National Standards Institute; det amerikanske standardiseringsorgan sammenligneligt
med DS og ISO.
APIApplication 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.
AppForkortelse 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 StoreApples offentlige markedsplads for applikationer til iPod Touch, iPhone og iPad.
App butikkerI 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 realityBrug 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.
MEDICO APPS - A PRACTITIONER’S GUIDE
49
Bekendtgørelse om medicinsk udstyr
Den danske implementering af Medical Device direktivet. Se mere på www.retsinformation.dk
Bemyndiget organOrgan som har fået overdraget dele af varetagelsen af et direktiv. I Danmark findes der et
bemyndiget organ, DGM.
Bench testingPrototypetesting (materialer, metoder, funktionalitet) i et kontrolleret laboratorie miljø (ikke i dyr
eller mennesker).
CE mærkeGodkendelse af bl.a. medicinsk apparatur inden for EU, kan opdeles i flere klasser afhængig af
patient-risiko profil.
CMEContinued Medical Education; sundhedsfagligt personale i USA skal kontinuerligt indsamle CME
point for at opretholde deres licens til at praktisere.
CMSContent 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 auditVurdering 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 guideDokument der beskriver, hvor og hvordan logo, skrifttyper og farver ol. skal bruges, i praksis og i
forskellig kontekst.
CPT koderCommon Procedural Termonology, koder anvendt til at klassificere medicinske procedurer ifm
standardiseret afregning.
CROContract/Clinical Research Organization, eksternt/uafhængigt forskningslaboratorium, der ofte
anvendes til ansøgning om medicinske godkendelser.
DefinitionerHenvisning til centrale definitioner fra Medico-direktivet og som er gengivet i Bekendtgørelse om
medicinsk udstyr.
DGMDansk Godkendelse af Medicinsk Udstyr. Link: http://www.dscert.dk/da-DK/DGM/Sider/DGM.aspx
DRGDiagnosis Related Group, et sæt af 467 grupper anvendt i Danmark til afregning af medicinske
tjenesteydelser.
EPOEuropean Patent Office, bureau hvor der kan ansøges om patenter i 38 europæiske lande.
FDAFood 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 operateMuligheden for at kommercialisere et produkt uden at krænke eksisterende patenter/IPR.
GMPGood Manufacturing Practice, en kvalitetssikringsstandard under FDA for producenter af medicinsk
udstyr. Erstattet af QSR.
HarmoniseredeAktuel liste findes via Lægemiddelstyrelsens hjemmeside.
standarder
www.laegemiddelstyrelsen.dk
HTTPSHyperText Transfer Protocole Secure; en kommunikationsprotokol til internettet til afsendelse og
modtagelse af sikrede data.
MEDICO APPS - A PRACTITIONER’S GUIDE
50
Hybrid app(likation)En hybrid app kombinerer elementer af såvel den lokale klient (native app; typisk en smartphone,
en tablet eller i princippet også en PC) samt en web-applikation, der behandler data udtrukket fra
en eller flere platforme, fx et medicinsk apparat. I denne guide henvises til apps, der er tilknytte
eksternt apparatur, når termen ”hybride apps” benyttes.
Ice Cream SandwichNavnet på det operativsystem Android smartphones benytter også kaldet Android 4.0.
IDEInvestigational 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 VitroUden for kroppen, begreb der anvendes om fx diagnostisk udstyr, der anvendes uden for kroppen; fx
pulsmåler.
In VivoInden 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.
IPRIntellectual Property Rights; et begreb for hvem, der har rettighederne til en given opfindelse/nyhed.
ISOInternational Organisation for Standardization. ISO er ikke et akronym men en omskrivning af det
græske ord isos med betydningen lighed.
KlassificeringsreglerReglerne for klassifikation inden for EU og deres anvendelse er beskrevet i Medico-direktivet og
MEDDEV 2. 4/1.
Klinisk afprøvningUdfø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 evalueringSkal foreligge jf. Medico-direktivet . Vejledning findes i MEDDEV 2.7/1.
Klinisk studieEt 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ægemiddelstyrelsenKompetent organ i Danmark. Denne hjemmeside www.medicinskudstyr.dk er en meget central
reference til den regulatoriske ramme indenfor EU og lovgivningen i Danmark.
LBMLocation Based Marketing; anvendelsen af lokationsteknologi (fx GPS) til at målrette
markedsføringen.
Look’n’feelAnvendes 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ålefunktionMedicinsk udstyr skal opfylde Rådets direktiv 80/181/EØF - Se i øvrigt MEDDEV 2.1/5.
MDDMedical Device Directive 93/42/EEC - en af tre regulatoriske godkendelses direktiver i EU, gældende
for medicinsk apparatur.
MEDDEV 2. 4/1MEDICAL 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/5MEDICAL DEVICES: Guidance document - Medical devices with a measuring function.
Vejledning i at afgøre hvornår medicinsk udstyr har målefunktion.
MEDDEV 2.7/1GUIDELINES ON MEDICAL DEVICES Clinical evaluation: Guide for manufacturers and notified bodies.
Vejledning i at opfylde Medico-direktivets klassificeringsregler.
Medico-direktivetRådets Direktiv 93/42/EEC om medicinsk udstyr og Rådets Direktiv 2007/47/EC.
Kan findes på www.medicinskudstyr.dk
MEDICO APPS - A PRACTITIONER’S GUIDE
51
MEDLINEMedical 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
NDANon-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.
NSINational 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.
OEMOriginal Equipment Manufacturer - en OEM virksomhed sælger non-branded produkter til andre
virksomheder, som herefter sælger produkterne i deres eget navn.
OVI StoreNokias markedsplads for applikationer.
Peer reviewGennemgang af kliniske studier og artikler af ekspert på området.
PMAPre-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 tjenesteTjeneste, der sender information til mobile enheder, hvis brugeren selv efterspørger aktivt.
Push tjenesteTjeneste, 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
QAQuality Assurance, en proces der sikrer at produktet virker som specificeret.
QCQuality Control; procedurer designet til at opfange/identificere defekte produkter inden for
produktionen, inden de kommer på markedet.
QR koderQuick 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.
QSRQuality System Regulation; en guide der beskriver hvorledes FDA’s auditør korps inspicerer
producenters kvalitetssystemer.
ReimbursementBetaling for en medicinsk ydelse af en tredje-part, oftest sygesikringen, på dansk anvendes oftest
synonymer som refusion eller godtgørelse.
ROIReturn on investment, forholdet mellem investeringen og udbytte af en given investering
ROI=udbytte(db)/investering(Omk).
SDKSoftware Development Kit (SDK eller ”devkit”) er typisk et sæt af software-udviklingsværktøjer,
der giver mulighed for at interagere med en bestemt softwarepakke, software rammer, hardwareplatform, edb-system, video, spillekonsol, styresystem, eller lignende platform, fx en API.
MEDICO APPS - A PRACTITIONER’S GUIDE
52
StreamingEn 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-mindNår folk først tænker på dig/dit mærke til at opfylde deres produkt eller service behov.
VPNVirtual Private Network; teknologi, der anvendes til at skabe sikker (privat) forbindelse; oftest fra en
privat internetopkobling til en virksomheds centrale server.
MEDICO APPS - A PRACTITIONER’S GUIDE
53
10.
Om folkene bag guiden
Uri Duvald Andersen
Strategisk direktør, Umloud Untd aps
15 års erfaring med digital strategi- og konceptudvikling. Arbejder til dagligt med at styrke virksomheder
og organisationers brug af apps og mobile media gennem udvikling af mobile strategier og skalerbare
mobile platforme, der skaber forretningsmæssig værdi.
Jens Peter Andersen
Kvalitetschef, Pallas Informatik A/S
20 års professionel erfaring inden for software development, som udvikler og projektleder. Bred erfaring
inden for internationale brancheløsninger - ikke mindst til høreapparatindustrien. Interesseområdet er
p.t. telemedicinske løsninger og software som medicinsk udstyr.
Morten Gjøl
Konsulent, mortengjøl.dk
Selvstændig konsulent, har i mere end 15 år arbejdet med produkt- og forretningsudvikling samt branding,
forandringsledelse og kultur–forandringsprojekter. Ejer tillige netværksvirksomheden NetworkingCompany.
Martin Stenfeldt
Director for Medico Innovation
15 års baggrund i den kommercielle del af medico branchen i Danmark, Tyskland og USA og senest et
år i krydsfeltet mellem klinik, forskning og industri. Idémand til interessenetværket Devices n’ Apps.
MEDICO APPS - A PRACTITIONER’S GUIDE
54