Medico apps A practitioner s guide

Størrelse: px
Starte visningen fra side:

Download "Medico apps A practitioner s guide"

Transkript

1 DANSK VERSION 1.1 Medico apps A practitioner s guide Af Uri Duvald Andersen Jens Peter Andersen Martin Stenfeldt Redaktion Morten Gjøl

2 DANSK VERSION 1.1 Medico apps A practitioner s guide Af Uri Duvald Andersen Jens Peter Andersen Martin Stenfeldt Redaktion Morten Gjøl Medico apps A practitioner s guide. Dansk version 1.1, januar Udgivet af MEDICO INNOVATION. ISBN Gengivelse af denne udgivelses indhold eller dele deraf er ikke tilladt uden forudgående skriftlig aftale med MEDICO INNOVATION. Guiden kan downloades gratis på

3 1. Indledning 4 2. Formål og afgrænsning 6 3. QA og regulatory for medicoindustrien 7 Formålet afgør om det er medicinsk udstyr 8 Markedsføring og CE-mærkning af medicinsk udstyr 8 Lovgivningens formål 9 Direktiver 10 Klassificering af udstyr og krav til kvalitetsikring 10 De væsentlige krav og harmoniserede standarder 11 USA Federal Drug Administration (FDA) Cases 15 TV2 case: TV2 førstehjælp 16 AMBU case: Airway Management E-learning 19 MIM software case: Mobile MIM Før udviklingsprocessen - Afdækningsfasen 25 Forretning 26 Formål 26 Målgruppe 27 Teknologi 28 Ressourcer 30 Jura Udviklingsprocessen - En fremgangsmåde i 5 trin 33 Specifikation 33 Design 35 Udvikling 36 Test 40 Lancering Efter udviklingsprocessen Markedsføring og drift 45 Markedsføring 46 Opdatering 47 Videreudvikling Efterord Begreber og terminologier Om folkene bag guiden 54 3

4 1. Indledning Stort set alt medico teknologi gennemgår i øjeblikket en elektronisk forvandling og udvikling. Efterspørgslen efter sundheds-it/e-health/telemedicin stiger kraftigt, og udbredelsen af mobile enheder stiger ligeledes støt. Når e-health og mobile enheder bringes sammen, opstår der et kæmpe potentiale for dem, som forstår at udnytte muligheden. Figur 1. 30% af alle smartphone-brugere forventes i 2015 at benytte e-health applikationer. Der ligger i krydsfeltet mellem appudvikling og medicoteknologi mange muligheder for at udvikle en helt ny dansk niche-kompetence, som efter vores mening bør opsøges aktivt. Danmark har allerede et godt internationalt ry i medico-branchen, og det kan vi udnytte ved at tænke ud af boksen og arbejde tværdisciplinært i udviklingen af innovative og værdiskabende medico apps. Derfor har MEDICO IN- NOVATION taget initiativ til at udgive denne guide, der forhåbentlig vil være både en inspiration og et praktisk værktøj. 4

5 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 5

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

7 3. QA og regulatory for medicoindustrien I dette kapitel ser vi nærmere på kvalitetssikring (Quality Assurance; QA) og de regulatoriske krav gældende for apps, der kan betegnes som medicinsk udstyr. Det er her, vi oplever den største forskel mellem almindelig appudvikling og appudvikling til medicinsk udstyr. QA og RA er også det emne, der har haft størst interesse i DNA netværket. Målet med afsnittet er at afmystificere de forskellige lovgivningsmæssige krav og vise vej gennem denne del af processen. Software og herunder apps, der betegnes som medicinsk udstyr, skal opfylde en række lovgivningsmæssige (regulatoriske) krav. Alt efter, hvordan udstyret klassificeres, er kravene mere eller mindre omfattende. Klassifikationen tager udgangspunkt i en risikobetragtning i forhold til bruger- og patientsikkerhed. Høj risikoklasse medfører omfattende regulatoriske krav til dit udstyr. Lav risikoklasse medfører mindre omfattende krav til udstyret fra myndighedernes side. Her er det værd at bemærke, at medicinsk udstyr omfatter alt lige fra elastikbind og vatpinde over høreapparater, pulsmålere til ultralydsskannere. De enkelte lande opererer med forskellige klassificeringssystemer, som har mange lighedspunkter men desværre også væsentlige forskelligheder, og der er ingen vandtæt omsætningstabel fra det ene system til det andet. Heldigvis er det sådan, at det samme klassificeringssystem anvendes inden for hele EU. USA har sit eget system. Det samme gælder for væsentlige lande som Kina, Japan og Brasilien. Software kan være medicinsk udstyr eller indgå i det på flere måder: 1. Den kan være et tilbehør til medicinsk udstyr, som ikke er software. Fx et program som man bruger til indstille et høreapparats forstærkning af lyden, så den bliver tilpasset den aktuelle bruger. Softwaren skal i tilfælde som disse betragtes som medicinsk udstyr. 2. Den kan være medicinsk udstyr i sig selv. Fx beslutningsstøtte software til at fastlægge en diagnose. 3. Den kan være inkorporeret i det medicinske udstyr, f.eks. som indlejret software. I denne guide vil denne type af software ikke blive taget i nærmere betragtning, idet eksekveringsenheder som smartphones og tablets typisk ikke bliver leveret som medicinsk udstyr. Apps vil derfor være stand-alone software som eksekveres på en enhed, der har en mere generel specifikation end medicinsk udstyr. Det samme gælder for internettet. I det efterfølgende vil vi betragte disse komponenter som infrastruktur, som ikke skal godkendes som medicinsk udstyr. Dette fritager 7

8 dog ikke fabrikanten fra at lade infrastrukturen ude af betragtning, når appen udvikles. Det samlede system skal være effektivt og sikkert. En medicoapp adskiller sig fra medicinsk udstyr i klassisk forstand i dens afgrænsning som medicinsk udstyr ved ikke på forhånd at være fast defineret. Hvis man fx betragter to stykker medicinsk udstyr; En operationsskalpel og en app, anvendt på en tilgængelig håndholdt enhed med tilslutning til en server på internettet, så er det for skalpellens vedkommende på forhånd lettere at definere det medicinske udstyrs fysiske afgrænsning, end det er for appen. Godkendelsesmæssigt vil det da også være meget op af bakke, hvis man eksempelvis skal have internettet godkendt som en del sit medicinske udstyr! Derfor er det afgørende, at der indføres en hensigtsmæssig arkitektur og et softwaremæssigt design, så det er veldefineret, hvilke moduler og enheder, der er del af det medicinske udstyr, og hvilke der ikke er det. Formålet afgør om det er medicinsk udstyr Medicinsk udstyr skal anvendes til det, det er beregnet til. Det er fabrikantens ansvar at specificere, hvad udstyret er beregnet til. På den anden side kan fabrikanten i hovedreglen ikke stilles til ansvar, hvis udstyret anvendes på en måde, der ligger uden for denne specifikation. Et af de mest centrale begreber i forhold til lovgivningen er det medicinske udstyrs intended use (tiltænkte anvendelse). Som fabrikant af medicinsk udstyr skal man også tage hensyn til alternative anvendelser, som ikke er tiltænkte, men som er forudsigelige. Det gælder især med hensyn til hvilke skademæssige konsekvenser, den alternative anvendelse kan have for patient og bruger. Den tiltænkte anvendelse er afgørende for, om der overhovedet er tale om medicinsk udstyr. Hvis ikke, kan man spare de omkostninger, der vil medgå til myndighedsgodkendelsen af det. Definitionen af medicinsk udstyr Ethvert instrument, apparat, udstyr, software, materiale eller anden genstand anvendt alene eller i kombination, herunder software, som af fabrikanten er beregnet til specifik anvendelse til diagnostiske og/eller terapeutiske formål (se Definitioner i ordlisten), og som hører med til korrekt brug heraf, og som af fabrikanten er beregnet til anvendelse på mennesker med henblik på:! Diagnosticering, forebyggelse, overvågning, behandling eller lindring af sygdomme! Diagnosticering, overvågning, behandling, lindring af eller kompensation for skader eller handicap! Undersøgelse, udskiftning eller ændring af anatomien eller en fysiologisk proces! Svangerskabsforebyggelse og hvis forventede hovedvirkning i eller på det menneskelige legeme ikke fremkaldes ad farmakologisk, immunologisk eller metabolisk vej, men hvis virkning kan understøttes ad denne vej. Markedsføring og CE-mærkning af medicinsk udstyr Hvis den tiltænkte anvendelse ikke ligger inden for eller har en mere general karakter end beskrevet i ovennævnte definition, er der ikke tale om medicinsk udstyr. Tag fx et videokamera, der sat op på en operationsstue med det formål, at en ekstern læge kan fjerneovervåge operationer. Formålet med kameraet vil da sandsynligvis have noget med behandling og overvågning at gøre. Men det gør ikke videokameraet til medicinsk udstyr, idet det jo er et videokamera markedsført til generelle billedoptagelses formål. Det bliver først medicinsk udstyr i det øjeblik fabrikanten specificerer det som sådan, 8

9 altså når det ligger inden for ovenstående definition. Her er det afgørende, hvad der påstås fra fabrikantens side i forbindelse med markedsføringen. Hvis det fx påstås, at udstyret er specielt velegnet til fjernovervågning under en operation, så kan bordet fange og fabrikanten er forpligtet til at CE-mærke udstyret som medicinsk udstyr (se senere). Det er ikke svært at overføre ovenstående eksempel til en app på en mobil-enhed med et kamera. Hvis appen har den egenskab, at den kan sende et billede taget med kameraet til lægen, så er der ikke tale om medicinsk udstyr. Men hvis den også kan analysere billedet og generere en diagnose på f.eks. en hudsygdom, så er der tale om medicinsk udstyr. Markedsføring er et centralt og skelsættende begreb i lovgivningen vedr. medicinsk udstyr. Markedsføring finder sted i det øjeblik fabrikanten stiller sit udstyr til rådighed for andre. Eksempelvis ved distribution af en app. Det er dog lovligt, at stille sin app til rådighed til demonstrationsformål m.m., men det skal tydelig fremgå, at den ikke må anvendes som medicinsk udstyr. Hvis man har CE-mærket sin app efter forudgående myndighedsgodkendelse, må man markedsføre den over hele EU. De enkelte lande kan dog stille krav om oversættelse. Fx ledetekster i skærmbilleder og andet tekstmateriale, der er nødvendigt for, at man kan anvende appen, som medicinsk udstyr på den tiltænkte måde. Danmark er et af de lande, som kræver oversættelse. Derfor er det værd at overveje en sprogvalgs option i appen, hvis den skal distribueres inden for EU s område. CE-mærkning giver kun lov til at markedsføre inden for EU. Man har altså ikke lov til, at stille appen til rådighed inden for fx USAs grænser medmindre man har fået grønt lys fra FDA, som forvalter USAs lovgivning indenfor området. EU har truffet forholdsregler mht. markedsovervågning således, at medicinalpersoner og hospitaler har pligt til indberetning, hvis udstyret svigter, således at det forårsager død eller alvorlig forværring af patientens eller brugerens helbredstilstand. Tilbagetrækning af appen fra markedet kan være konsekvensen af dette. Den person, der er ansvarlig for markedsføringen skal registreres hos den kompetente myndighed. Det vil i Danmark sige Lægemiddelstyrelsen. Bemærk at lovgivningen gælder fabrikanter af medicinsk udstyr. Hvis man fx laver softwareudvikling for ét hospital markedsfører man ikke nødvendigvis medicinsk udstyr. Lovgivningens formål Den centrale sigte med lovgivningen, uanset hvilket land det drejer sig om, er at få dokumenteret:! Sikkerhed for udstyrets ydeevne! Beskyttelse af bruger og patient mod skader, som kan forvoldes af udstyret. Myndighederne forlanger dokumentation for udstyrets ydeevne, som matcher state-of-the-art, samt at den resterende risiko, der måtte være forbundet med at anvende udstyret, skal være minimeret mest mulig og ligge inden for et acceptabelt niveau i forhold til udstyrets tiltænkte anvendelse. Hvert land har sin egen lovgivning inden for området, som har store ligheder og måske også store forskelligheder. I denne guide vil lovgivningen indenfor EU blive brugt som det gennemgående og med referencer til lovgivningen i USA, hvor denne afviger i forhold hertil. 9

10 Direktiver Indenfor EU defineres den lovgivningsmæssige ramme for det medicinske udstyr, man er ved at udvikle, af det direktiv, som udstyret henhører under. Det kan være et af følgende:! Medico-direktivet: Rådets Direktiv 93/42/EEC om medicinsk udstyr og Rådets Direktiv 2007/47/EC.! Rådets Direktiv 90/385/EEC om aktivt, implantabelt medicinsk udstyr og Rådets Direktiv 2007/47/ EC.! Rådets Direktiv 98/79/EØF af 27. oktober 1998 om medicinsk udstyr til in vitro-diagnostik. Noget at det første, man skal gøre sig klart er, hvilket direktiv udstyret hører under. Direktiverne er alle implementeret i de nationale lovgivninger i EU. Direktivet vedr. aktivt, implantabelt udstyr kan være relevant i forhold til software, hvis den er tilbehør til fx en pacemaker. Selv om software er aktivt udstyr kan det næppe være medicinsk udstyr i sig selv. En app kan næppe implanteres direkte i den menneskelige krop. Software kan være inkorporeret i det aktive implantat. Bemærk, at det, der gør et implantat aktivt, er, at det har sin egen iboende energikilde, som ikke hidrører fra kroppen. In vitro-diagnostik direktivet kan appen være omfattet af, som tilbehør til medicinsk udstyr, der anvendes på prøvemateriale, som er udtaget af det menneskelige legeme. In vitro diagnostisk udstyr anvendes aldrig direkte på mennesker. CE-mærket på udstyret angiver, at udstyret ikke blot overholder et af de ovennævnte direktiver men alle relevante direktiver. Fx direktivet om beskyttelse af persondata og radio teleterminal direktivet. Myndighederne i de enkelte EU-medlemslande er forpligtet til at samarbejde, så direktiverne anvendes på ensartet måde. Det vil i reglen være Medico-direktivet, der skal bringes i anvendelse. Derfor handler resten af guiden om dette. Klassificering af udstyr og krav til kvalitetsikring I EU opdeles medicinsk udstyr i en af følgende produktklasser:! Klasse I er den produktklasse, hvor der er mindst risiko for patient og bruger forbundet med anvendelsen af det medicinske udstyr. For denne klasses vedkommende skal fabrikanten indsende en overensstemmelseserklæring til det kompetente organ i det land (i Danmark Lægemiddelstyrelsen), hvor produktet skal CE-mærkes, hvorefter mærkning er tilladt. Det er ikke nødvendigt med et bemyndiget organs medvirken for CE-mærke produkter i denne klasse medmindre, der tale om udstyr med målefunktion eller udstyr som bliver markedsført i steril tilstand. Apps med målefunktion er en realistisk mulighed man som udvikler skal have i mente: Er der tale om målefunktion eller tendensindikation. Der er omkostninger vedr. godkendelsesforløbet til forskel.! Klasse IIa omfatter fx aktivt terapeutisk udstyr som høreapparater og diagnostisk udstyr til rutine overvågning og selvmonitorering vitale fysiologiske processer blodtryk og hjerterytme. En blodstryksmåler til hjemmebrug er et godt eksempel. Apps kan tilhøre denne klasse, hvis de kan stille en diagnose. Denne produktklasse kræver et Bemyndiget organs medvirken for, at man må markedsføre og CE-mærke udstyret.! Klasse IIb. Denne produktklasse kræver, at et Bemyndiget organ fører tilsyn med konstruktion og fremstilling. Denne produktklasse omfatter fx diagnostisk udstyr til ikke-rutinemæssig overvågning. Udstyr i denne klasse skal CE-mærkes.! Klasse III omfatter de mest risikoforbundne udstyrstyper som fx implantater. Et Bemyndiget organs medvirken kæves selvsagt også her. Udstyr i denne klasse skal CE-mærkes. EU har defineret et sæt af vejledninger, som er nyttige. Software er defineret som aktivt udstyr og skal derfor klassificeres efter de tilhørende regler. For alle typer af udstyr skal der laves en overensstemmelseserklæring som beskrevet i Medico-direktivet. Udstyrsklassen fastlægges ved en forhandling mellem 10

11 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 EN ISO 13485:2003 DS/EN ISO 14971:2009 DS/EN 62304:2006 EN 62366:2008 EN 980:2008 EN 1041:2009 DS/EN ISO 14155:2011 Titel Medical devices - Quality management systems - Requirements for regulatory purposes Medical devices - Application of risk management to medical devices Medical device software - Software life-cycle processes Medical devices - Application of usability engineering to medical devices Symbols for use in the labeling of medical devices Information supplied by the manufacturer of medical devices Clinical investigation of medical devices for human subjects - Good clinical practice Udstyret skal konstrueres og fremstilles med sikkerhed for øje - princippet om sikkerhedsintegration - i videst mulig omfang. Alarmer skal integreres i udstyret i det omfang, at konstruktionen ikke kan gøres 100% sikker. 11

12 Ovenstående kræver en effektiv risk management proces i udviklingsforløbet. Dette gælder også for det endelige udstyrs betjeningsegenskaber, hvor risikoen for betjeningsfejl, der kan forvolde personskade, skal minimeres mest muligt. I denne forbindelse skal der tages hensyn til brugernes teknologiske viden. Det er således et krav, at en app har et sikkert betjeningskoncept, hvor der er taget hensyn til brugernes forudsætninger: Det skal være klart angivet på anordningerne, hvorledes betjeningspaneler og indikatorer virker. On-going risk management er motoren, der driver dette. Den anførte ydeevne skal også dokumenteres. Hvis appen fx bruger det indbyggede kamera i den håndholdte enhed til at tage et billede af fx et modermærke eller øjet og derudfra giver et bud på en diagnose, så skal det dokumenteres med hvilken statistisk sikkerhed, dette sker. Der skal gennemføres klinisk evaluering gennem hele produktets livscyklus, hvilket betyder, at kliniske data skal underbygge, at udstyret har den ydeevne, som er specificeret af fabrikanten. I den forbindelse skal der:! Gennemføres et litteratur-studium, som dokumenteres i den kliniske evalueringsrapport. Litteraturstudiet baseres på tidligere offentliggjorte og/eller egne undersøgelser.! Om nødvendigt gennemføres en klinisk afprøvning, hvis datagrundlaget ikke er tilstrækkeligt. Det er vigtigt at få klarlagt i starten af produktudviklingsprojektet, idet klinisk afprøvning kræver forholdsvis store ressourcer til planlægning og afvikling.! Løbende indsamles kliniske data om udstyrets anvendelse over hele dets livscyklus. Det kliniske evaluering spiller sammen med risk management processen: Risici evalueres som en del af den kliniske evaluering og på den måde identificeres risici i den kliniske evaluering. Det skal sikres, at appen ikke ændrer egenskaber undervejs i processen fra download til installation på det håndholdte device og videre frem. En app er i sin natur som medicinsk udstyr, som skal anvendes sammen med andet udstyr. Her er kravet systemet betragtet som en enhed skal være sikkert. Hvis fx den håndholdte enhed og appen markedsføres samlet, er der tale om en systempakke og kravene for sådanne skal være opfyldt. Udstyr med målefunktion skal overholde særlige krav mht. stabilitet, nøjagtighed og tolerancer samt ergonomiske principper. Kravene til sidstnævnte er defineret i EN 62366:2008. Den udviklede app skal have en kvalitet, der matcher formålet. Der betyder bl.a., at softwaren skal håndtere fejlsituationer på en måde, så de hermed forbundne risici begrænses mest muligt. En medico app skal: valideres i overensstemmelse med det aktuelle tekniske niveau, idet der tages hensyn til principperne for udviklingslivscyklus, risikostyring, validering og verificering. For at matche det krav anbefales det, at man opfylder kravene i EN 62366:2008, som er den mest software specifikke af de harmoniserede standarder. Den har veldefinerede krav til udviklingscyklus og risk management samt verifikation og validering. Udstyr, der overvåger en eller flere kliniske parametre, skal være forsynet med passende alarm systemer. En app, der kører på udstyr, der er afhængig af en energikilde, det være:! Intern i form af et batteri. Hvis det er tilfældet skal der være en batteriindikator! Ekstern i form at net-tilslutning. Hvis sådant udstyr er afgørende for patientens sikkerhed, skal der være indbygget alarmsystem. 12

13 Det medicinske udstyr skal leveres med de oplysninger, der skal til for at det kan anvendes sikkert og korrekt. Det skal også være muligt at spore udstyret tilbage til dig som fabrikant. Der skal også følge en brugsanvisning med udstyret, hvilket der dog kan ses bort fra, hvis udstyret er i klasse I eller IIa og det kan betjenes sikkert uden anvisninger. Hvis man udvikler en medico app kan følgende være påkrævet:! Batchkode, hvilket svarer til den installerede apps buildnummer. Angives med symbolet LOT.! Hvis appen er bestemt til klinisk afprøvning (se Definitioner) skal det fremgå.! Advarsler og forholdsregler.! Fremstillingsår. Angives med symbolet for fremstillingsår.! Oplysning om hvilke enheder appen kan afvikles sikkert på. De er nok, at angive deres karakteristika. Formålet er at opnå en sikker kombination.! Oplysninger om hvordan brugeren sikrer sig, at appen er installeret korrekt samt vedligeholdelses og evt. kalibreringsforskrifter. De harmoniserede standarder EN 1041:2009 og EN 980:2008 definerer forventningen til ovennævnte type af information og anvendelsen af symboler. USA Federal Drug Administration (FDA) Som nævnt har USA sit eget system til godkendelse af medical devices inkl. apps som er inden for området. Da FDA (sundhedsmyndighederne i USA, der godkender udstyr og medicin) kun har publiceret draft guidelines (det vageste første udspil til en bekendtgørelse på det specifikke område omhandlende apps; se reference nedenfor), er der en del spekulationer om, hvordan FDA vil behandle specifikke eksempler. Indtil der er lagt en juridisk (regulatorisk) standard, må man gå ud fra de (få) cases, der allerede er behandlet samt anvende beskrivelsen ovenfor (fra EU) som benchmark. Nedenfor følger en del figurer, der forklarer behandlingen af apps i USA. Figur 2. Alt efter hvor stor en risikoen for skader en bruger af appen (patienten) udsætter sig selv og andre for (inkl. ved selv-forskyldt fejlbrug af appen), bliver appen (+evt. device) klassificeret, og skal udvise grader af validerende studier (ref. MobiHealthNews.com). 13

14 Figur 3. Den (potentielle) risiko ligger på et kontinuum, og bestemmes bedst ved samarbejde med rådgivere på området og evt. ved diskussion med FDA sent i udviklingsprocessen (ref. MobiHealthNews.com). Figur 4. ISO er en del af kvalitetskontrollen, men FDA går ud over disse krav ved at kræve dokumentation for validering (fx er den hævdede effekt dokumenteret?, er der et system til at tage hånd om Adverse Events? (AE, bivirkninger), etc) (ref. MobiHealthNews.com) 14

15 4. Cases Da et af formålene med denne guide er at dele erfaringerne fra nogle af dem, der allerede har udgivet medico-app, følger her tre cases på apps udgivet inden for det seneste. 15

16 Case TV2 Førstehjælp Navn TV2 Førstehjælp Udgiver TV2 Platforme iphone + Android Udgivet Oktober, 2011 Målgruppe Den brede befolkning. B-t-C Downloads til d.d stk. Samlet budget Omk kr. Udviklingstid Ca. 4 mdr. Største udfordring Kvalitetssikring af de sidste 2%, der gør appen fuldstændig fejlfri, hvilket er nødvendigt for apps, der handler om liv og død. Største læring Medical apps kræver mere QA. Derfor er tydelig definition af kvalitetskrav fra starten og et struktureret test set-up vigtigt. Bedste råd Hellere én funktionalitet, der sidder i skabet, end en masse, der virker halvt. Skabt for at redde liv TV2 er Danmarks største kommercielle public service tv-station med fem kanaler. Stationen har udgivet flere forskellige mobile applikationer fra events til nyheder, vejr mv. som en del af TV2s strategi om at være repræsenteret stærkt også på de digitale medier. I september 2011 blev den gribende dokumentarserie Tak fordi du reddede mit liv lanceret. I serien møder man almindelige mennesker, der er trådt i karakter, når uheld har ramt tilfældige personer, de ikke kender. Mennesker med mod og hjerte på rette sted til at rede andre folks liv. I forbindelse med serien opstod med hjælp fra Tryg Fonden mulighed for at skabe en mobil applikation, der lagde sig op ad seriens tema om at redde liv. Grundidéen til den app, der senere skulle gå hen og blive appen for førstehjælp i Danmark, blev født. Appens idé er, at hjælpen skal være ét tryk væk, og allerede fra begyndelsen stod det klart, at ambitionen var at skabe en app, der kunne mere end de eksisterende førstehjælps apps på markedet. Som tv-station tænker man naturligt i billeder, og derfor blev video medtænkt fra starten. Det stod også klart, at siden appen drejede sig om liv og død, måtte det faglige indhold være i absolut top, baseret på den nyeste viden, og det måtte komme fra en ekspert på området. Derfor teamede TV2 op med overlæge og formand for Dansk Råd for Genoplivning Torsten Lauritsen med speciale i førstehjælp. Stationen vidste, at når de havde Danmarks førende læge på området med på holdet, ville appen blive bedre og opnå større troværdighed. Formål og succeskriterier Formålet med TV2 Førstehjælp var enkelt, selvom målgruppen var bred. Mange har på et eller andet tidspunkt modtaget undervisning i førstehjælp - og glemt det igen. Og endnu flere har måske aldrig lært det... 16

17 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 gange. Udviklingsprocessen Selve udviklingen og indholdsproduktionen blev gennemført af underleverandører, mens TV2 forestod projektledelsen. Underleverandørerne blev valgt efter sondering og ud fra deres kendskab til den tekniske løsning. Processens faser var flg.: 1. Idékatalog Herunder: Idéudvikling, indsamling af viden og markedsresearch, kondensering af det væsentlige i ideerne, formulering af grundidé. 2. Specifikation Herunder: Beskrivelse af appen og opstilling af præspecifikationer, indhentning af tilbud fra leverandører, tilpasning og organisering af funktionaliteter, opstilling af flowchart samt prototype og udarbejdelse af detaljeret kravspecifikation. Prototypen blev opbygget i Powerpoint. 3. Artwork og design Herunder: Fastlæggelse af designmæssige retningslinjer (ej fancy), designoplæg, tilretning og godkendelse. 4. Udvikling Herunder: Iterationer med feedback og tilretning, fejlbeskrivelser, udarbejdet på to platforme samtidig. 5. Testforløb Herunder: Struktureret test set-up med afprøvning på egne testtelefoner. 6. Lancering Herunder: On air promotion, PR-kit sendt ud til diverse medier. 7. Drift Appens indhold er statisk, og der gøres ikke mere ved den pt. Udfordringer og læring TV2 største udfordring i produktionen var de mange iterationer, der var nødvendige for at sikre appens kvalitet og fejlfrihed. Projektet blev mere omfattende for alle interessenter, fordi kvalitetskravene ikke havde været klart defineret fra starten. Nul-tolerancen for fejl kostede ekstra ressourcer, og projektet blev forsinket ca en måned, hvilket fordyrede opgaven i både interne timer og eksterne omkostninger. Derfor var den største læring også, at medical apps kræver mere kvalitetssikring, end TV2 var vant til fra deres tidligere apps. Og mere kvalitetssikring kræver en mere struktureret styring af test set up. Herudover oplevede TV2, at Android platformen voldte særlige udfordringer pga de mange forskellige enheder, der er på markedet. Det faktum, at en applikation afvikles på en enkelt smartphone eller tablet giver ikke sikkerhed for at sikre, at appen virker på alle telefoner. 17

18 Særlige forhold for medical apps TV2 vurderer, at særligt tre forhold gør sig gældende for medical apps: 1. Der er ingen plads til fejl. 2. Kvalitetsstyring er mere krævende. 3. Appen skal være opdateret. Tre lavpraktiske råd 1. Medico apps kan rumme mange fagudtryk. Tænk derfor i at formidling og terminologi skal matche målgruppen. 2. Medico apps er meget følsomme for fejl. Sæt tid af til at teste. Det tager tid og kan være meget omstændeligt. 3. Hellere én funktion, der sidder i skabet, end en masse, der virker halvt. 18

19 Case Airway Management E-learning Navn Airway Management elearning. Udgiver Ambu A/S. Platforme iphone + ipad + Android. Udgivet Maj, Målgruppe Anæstesilæger, globalt. B-t-B. Downloads til d.d stk. Samlet budget Omk kr. Udviklingstid Ca. 5 mdr. Største udfordring Konvertering og nedskalering af større onlineplatform til et begrænset brugerinterface, der fungerer godt og intuitivt på en lille håndholdt enhed. Største læring Mobile applikationer er sit eget medie med eget forretningsmæssige formål, sin egen distribution og egen målgruppe. Tænkt og brugt rigtigt kan en app udgøre stor markedsføringsmæssig værdi og nå helt nye markeder og målgrupper. Bedste råd Opdateringsmuligheder er afgørende for appens levetid. Skabt for at uddanne læger Virksomheden Ambu blev stiftet i 1937, har hovedkvarter i Danmark, og er en global spiller med salg i ca. 80 lande. Ambus firmafilosofi har altid været at gøre livet lettere for læger og udvikle innovative produkter, der redder liv. Ambu A/S udvikler, producerer og markedsfører således diagnosticerings- og livredningsprodukter til hospitaler og redningstjenester. Ambu ascope er et innovativt produkt fra Ambu til placering af luftveje ifm. operationer for anæstesilæger. 3% af alle patienter har nemlig det, der hedder svære luftveje, hvor lægerne traditionelt må bruge et langt og meget dyrt skop som hjælpemiddel. Problemet med de traditionelle skoper er, at de er dyre, der er få af dem på hospitalet, de skal repareres og rengøres, og at de skal transporteres rundt mellem operationerne. Det kan i yderste konsekvens betyde, at skoperne ikke er tilgængelige, og derfor udviklede Ambu et billigere engangs-scope. Fordi Ambu ascopet bruges på de sværeste 3% af patienter, er det et spørgsmål om liv og død, at apparaturet benyttes korrekt. Og derfor er træning af høj interesse hos lægerne. Tidligere blev uddannelsesopgaven løftet af Ambus sælgere, hvor udfordringen dog var, at lægerne ikke altid har mulighed for at være til stede eller har tid til at deltage i en trænings-session. Ambu vidste om anæstesilægerne, at de typisk har en del tid under operationerne til at videreuddanne sig. Samtidig ville Ambu gerne eksponere mere af deres kliniske dokumentation og økonomiske beregninger overfor lægerne. Desuden var formålet også at være medvirkende til, at flere anæstesilæger blev mere rutineret i håndteringen af vanskelige luftvejs-situationer, da de i praksis ikke forekommer særlig ofte. Ambu besluttede sig derfor for at udvikle en online trænings-platform på nettet, der var mere fleksibel end den personafhængige uddannelse samt en mobil app, der kunne imødekomme lægernes timeslots. Tanken var, at jo flere der er trænet, jo flere vil købe produktet. 19

20 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å downloads i 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. 20

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

22 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 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æring At involvere læger tidligt i processen for at lette godkendelsesprocessen Bedste råd Husk at involvere IT afdelinger på hospitalerne for at lette den efterfølgende implementering. Nysgerrighed drev den første version Virksomheden Mobile MIM har sit udspring i slutningen af 1990 erne på Case Western Reserve University Hospital. Firmaets stifter og ejer, Dr. Dennis Nelson, manglede et redskab, der kunne kombinere MR og PET scanninger. I 2002 blev MIM Software officielt grundlagt og arbejdet med medincisk billedbehandling begyndte. Gennem årene har MIM software udviklet software løsninger, der gjorde arbejdet med medicinske billeder mere effektivt. To nysgerrige medarbejdere anskaffede sig SDK (Software Development Kit) i starten af 2008 og forsøgte at overføre firmaets software til Apples platform. I løbet af to uger var den første version klar. Resultatet var så overbevisende, at firmaet hurtigt indså, at den mobile platform ville blive en integreret del af firmaets portefølje. I USA er det forbudt at markedsføre medicinsk udstyr, herunder software, uden behørig godkendelse af FDA. MIM Software mente, at så længe appen blev tilbudt gratis fra App Store, kunne det ikke betegnes som markedsføring. Appen vakte så stor opmærksom, at Apple bad MIM Software præsentere deres app på App Developer konferencen i 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 22

23 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) 23

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

25 5. Før udviklingsprocessen - Afdækningsfasen De grundlæggende overvejelser Før man begynder på selve udviklingen af en mobil applikation, skal man i afdækningsfasen tage stilling til en række grundlæggende forhold, der har stor betydning for det produkt, der i sidste ende skal udarbejdes. Disse forhold vil afhængig af formål og kontekst for appen variere men mange af spørgsmålene vil være relevante i de fleste projekter. Vi gennemgår i dette kapitel grundlæggende overvejelser og udfordringer og giver et bud på, hvordan du håndterer dem. Afdækningsfasen handler om at forstå og forholde sig til den virkelighed, appen skal fungere i. Det er vores opfattelse, at en app ikke altid er den eneste rigtige løsning. Gang på gang oplever man faktisk, hvordan der fokuseres på en bestemt løsning frem for at se på, hvad man ønsker at opnå, eller hvad det bagvedliggende behov er. Afdækningsfasen handler altså både om at finde ud af, om en app er den rigtige løsning, og fasen handler om at definere formålet med og konteksten for appen. I afdækningsfasen skal man således sandsynliggøre appens eksistens og tage stilling til de forhold, der skal sikre appens succes på kort og lang sigt. Resultat af afdækningsfasen er en overordnet brief. Vi arbejder med seks kategorier af forhold, der spiller ind. 25

26 Forretning Den første fundamentale overvejelse lægger sig op ad forretningen. Dette vil typisk være business casen. Hvilken værdi skal appen skabe? Hvordan skal appen bidrage til forretningen? Hvor kommer pengene fra? Hvordan skal den finansieres? Hvordan skal appens værdi gøres op? Hvilken investering berettiger appen, og hvilket ROI kan forventes? De færreste vil udvikle en app uden en eller anden form for økonomisk overvejelse, der peger på, at det er en god idé. Altså, at appen skaber værdi, der bidrager til en forretning. En app kan bidrage til forretningen på flere niveauer. Fx som konkret salg, som en service, et statement (branding) eller som en markedsføringskanal. Business-casen vil typisk beskrive, hvordan appen indgår i forretningen og rumme en vurdering af rentabilitet og investeringens størrelse. Overvejer man at sælge sin app, er det værd at notere, at de forskellige app butikker tager sig ganske godt betalt i provision. 30% skal man således forvente at betale af sin omsætning på appen, både på prisen for appen, samt det salg, der måtte komme ind via appen. Det er naturligvis ikke altid muligt at vide på forhånd, hvilken effekt en app vil opnå. Ofte er det dog muligt at sige noget om, hvad den helt sikkert ikke vil opnå, og derigennem kan man skyde sig ind på en ikke helt urealistisk forventning. En strategi for appen kan på basis af formål og business-case opstilles som en plan for, hvad appen specifikt skal, og hvordan den skal gøre det. Strategi handler om at opnå konkrete mål. Da appen indgår i det samlede forretningssystem skal der være en konkret plan eller strategi for, appens rolle. Herunder er det interessant at se på, hvordan andre har gjort med best practice studier, samt hvad konkurrenterne gør gennem en konkurrentanalyse. En god måde at vurdere eksisterende apps på, er bl.a. ved at se på brugernes ratings og kommentarer i de forskellige distributionskanaler (App Store mv.). Vi ved, at appen kan spille ind på afsenders positionering, og strategien skal sikre at positioneringen er rigtig og bliver stærk. Det er samlet set vores anbefaling, at omdrejningspunktet for appstrategien er, at appen supplerer eksisterende kanaler mere end substituerer dem. Mobile apps kan helt andre ting og indgår i helt nye sammenhænge, og i praksis betyder det, at apps kan skabe værdi på nye måder. Kopiering af fx en hjemmeside over på en app, er efter vores mening en misforståelse af mediet. Udnyttelse af smartphonens indbyggede teknologiske muligheder som kompas, mikrofon, kamera, lys, display, højttalere, accelerometer, wifi etc. kombineret med mobilitet, bekvemmelighed og forenkling åbner mulighed for at tænke i nye kreative baner, hvor information og interaktion bruges til at skabe merværdi. Dette gælder ikke mindst medico området. Eksempel Ambu s (se tidligere) business case var, at jo flere, der bliver uddannet i ascope, des flere køber produktet. Det, appen kan, er at give let tilgang, lige her og nu til produkttræning, når det passer lægen bedst. Strategien blev, at appen skulle supplere den eksisterende online uddannelsesportal. Formål Før et konkret projekt begyndes, er det en god idé at definere formålet med appen fx på basis af businesscasen. Når det først er besluttet, at en mobil applikation er den bedste løsning på et givet behov (jf. ovenstående), er det relativt enkelt at opstille et formål for appen. Har man derimod ikke set på, hvilket behov (ex en åbning i et marked, et supplement til andre kanaler mv.), appen skal dække, bliver formålet mere uklart. 26

27 En anden væsentlig grund til at opstille formål er, at det efterfølgende kan dokumenteres, om appen levede op til forventningerne. Så punkt to er at kvalificere formålet gennem opstilling af konkrete mål. SMARTE-mål er en god guideline for opstilling af mål. Målene skal således være: S: Specifikke M: Målbare A: Attraktive R: Realistiske T: Tidsbegrænsede E: Evaluérbare. På basis af målene defineres de evalueringskriterier, appen efterfølgende skal vurderes på. Målgruppe Som i enhver anden kommunikationssituation, er det en forudsætning for succes, at man kender sin målgruppe. Målgruppen er de brugere, man forventer vil benytte appen, og deres adfærd adskiller sig fra andre. Det er denne specifikke adfærd, der er interessant. Formålet med at kende sin målgruppe er, at forstå hvordan appen kan skabe værdi for dem. Spørgsmålene er: Hvordan er målgruppens medievaner? Hvordan er deres dagligdag? Hvor store brugere er de af IT? Eller hvor vante er de med brug af IT? Er de innovatører eller late adopters? Hvilken kultur opererer målgruppen i? Hvor og hvordan kan vi nå vores målgruppe? Opstilling af persona profiler er en typisk metode i arbejdet med udvikling af kommunikations- og it-produkter. Personaerne beskriver brugerne og deres adfærd og giver værdifuld indsigt om motiver, barrierer, vaner, viden mv. Med andre ord er det helt centralt at undersøge og forstå målgruppens vaner. Værdiskabelsen ligger ofte i omsætning af indsigt i målgruppen og bør have stor påvirkning på den app, der skal udvikles. Aktiv forståelse og brug af viden om brugerne er guld værd i konceptudviklingsfasen og er afgørende for, om appen bliver en succes eller ej. Eksempel Ambu s målgruppe er anæstesilæger globalt. Viden og undersøgelser viste, at lægerne ofte har ventetid. De slæber rundt på en masse opslagsværker og modtager en masse produktinformation, som de aldrig åbner. Indsigterne gjorde, at idéen til appen blev købt. Også den konkrete brugeroplevelse og indholdet på appen blev påvirket af brugerindsigt. Teknologi Når vi ved, hvad appen skal, hvordan og i hvilket samspil, er det næste at overveje det tekniske set- up. Da apps afvikles på brugerens individuelle mobilenhed i modsætning til websites, der afvikles på en central server, har det stor betydning for appens tilgængelighed og anvendelighed, hvilke platforme, der udvikles til. De forskellige platforme dækker iphone (ios), Android (Samsung, HTC, Sony Ericsson m.fl.), Microsoft Windows Mobile (Microsoft, Nokia m.fl.) og Blackberry m.fl. Fordelingen på verdensplan af de forskellige platforme ses her: 27

28 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: samt En god tommelfingerregel er, at unge benytter de billigere platforme (Android), iphone-brugere er mere aktive i brugen af apps, og i USA er Blackberry mere udbredt end i Europa. iphone dækker på verdensplan ca. 5% af smartphone markedet. I Danmark er tallet ca 35%. I Kina udgør iphone under 5%! Her er Nokia (Symbion) størst (mere end 70%). Vi anbefaler, at man satser på at skabe velfungerende Andriod apps på udvalgte modeller, og den bedste måde at finde ud af, hvilke platforme, der skal udvikles til, er altid ved at kende sin målgruppe. Indsigt i målgruppens medievaner og eventuelle retningslinjer i organisationen vil give svaret på, hvilke platforme, du skal satse på. Samt udbredelsen i det geografiske område hvor appen skal anvendes. 28

29 Et andet forhold vedr. IT-system ligger i beslutningen om, hvorvidt appen skal være statisk eller dynamisk. Om indholdet skal være embedded eller hentes online. Forskellen er, at den statiske version er født med alt indhold, som downloades sammen med appen. Når appen først er lanceret, vil det være umuligt at ændre eller opdatere indholdet uden at involvere udviklerne. Derfor er det helt centralt at beslutte ud fra strategien med appen og kendskabet til målgruppen, om appen skal være indholdsmæssig opdaterbar eller ej. Fordelen ved det statiske indhold er, at brugeren ikke behøver være online for at se indholdet, hvilket kan være smart, hvis målgruppen fx er fra andre lande, der tit vælger at slå roaming i udlandet fra pga. datapriserne. En anden stor fordel ved de statiske apps, er at de er mere enkle at udvikle og derved billigere. Eksempler på, hvor en statisk app giver god mening er apps rettet mod turister, apps til internationale konferencer, apps der skal fungere på steder, hvor der ikke er internetadgang samt apps som typisk har en meget specifik brug og kort levetid på brugerens smartphone. En dynamisk app har indhold, der løbende kan ændres, hvilket kræver en backend a la et CMS, som det kendes fra website. Dvs. en back-end, hvor en redaktør/content manager kan tilgå appens indhold og ændre det uden at skulle rode med nogen form for programmering. En dynamisk app kan have sit eget backend system, eller den kan blive feedet af et eksisterende system, der allerede er udarbejdet til et website. I sidstnævnte tilfælde skal der udvikles et API mellem backendsystem og app, så de kan tale sammen. En overvejelse i denne sammenhæng er således, hvis man beslutter sig for en dynamisk app, om indholdet skal opdateres fra ét fælles eller flere backend individuelle systemer til hhv. web og app, hvilket er lidt mere omstændeligt. Det er ofte nødvendigt at integrationen med eksisterende IT-systemer sker i samarbejde med de folk, der vedligeholder de eksisterende systemer i forvejen. Et sidste punkt i dette afsnit er samspillet med eksterne enheder, der kobles på smartphonen. I fagtermer og nærværende guides forståelse kaldes dette for hybrid apps, da de sammenkobler to (eller flere) platforme som fx en pulsmåler og appen. Ideen er, at der ved at koble appen sammen med en ekstern enhed opstår ny værdi, der ikke var mulig uden sammenkoblingen. Et eksempel er blodtryksmåleren fra Withings. En normal blodtryksmåler består af en manchet og en kontrolenhed, der indeholder betjeningstaster, display og pumpe. Withings har udviklet en manchet med indbygget pumpe, der styres via en iphone, hvor også resultatet udlæses og logges. Denne blodtryksmåler giver langt større værdi, fordi iphonen kan tilkobles internettet og resultaterne logges i en grafisk kurve tilgængelig fra enhver enhed med internet adgang. Derudover fylder apparatet mindre og har færre dele, der kan gå i stykker. Det bliver muligt for brugeren automatisk at se tendenser, historik mv. og således mere præcist monitorere og fortolke blodtrykket. Apps kan lukrere på de mange forskellige sensorer en smartphone indeholder (kompas, mikrofon, kamera, lys, display, højttalere, accelerometer, wifi etc.). Kombineret med, at smartphonen eller tablet en er mobil, er det kun fantasien, der sætter grænsen for kreative, værdiskabende hybride apps. Der findes allerede tyverialarmer, der kan fjernkontrolleres af en app, og går vi ind i den medicotekniske verden, er det kun et spørgsmål om tid, førend patienter og deres pårørende vil kunne monitorere og agere på kritiske værdier målt på/af telemedicinske devices via hybride apps. De teknologiske forhold har naturligvis stor betydning for projektets ressourceforbrug og appens anvendelighed. Leverandøren vil typisk kunne rådgive om disse forhold, og de rigtige beslutninger kan træffes, hvis spørgsmålene adresseres indledningsvist. 29

30 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 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 % af den samlede projektperiode. Hertil kommer inddragelse af beslutningstagere og andre interne ressourcer fra andre afdelinger. 30

31 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 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 kr. Appen kostede ca kr. og har pt. opnået 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 kr. værd for AMBU, kan ROI udregnes. ROI ved at stå på messe: 1.000/2.500=0,4. ROI på app: 1000/45=22. Dette er selvfølgelig alt andet lige betragtninger og uden hensyntagen til evt. forskel i udbytte af en kunde hvervet personligt på en messe og en kunde hvervet via appen. Jura Størstedelen af de juridiske hensyn fsva. medico apps vil læne sig op ad de regulatoriske forhold (se afsnit 3). Selv apps, der formidles gratis, fortolkes lovgivningsmæssigt som markedsføring, dvs. en gratis app skal stadig godkendes regulatorisk såfremt den rent teknisk falder ind under definitionerne i afsnit 3. Overordnet set skal en medico app forholde sig til, om de er henvendt til privat eller professionel brug. Herefter skal den forholde sig til, hvilket geografisk marked den markedsføres til. Slutteligt skal udvikleren undersøge eventuelle rettigheder til apps indhold, herunder patenter og specielt copyright, hvis tekst, billeder/grafer eller lyd anvendes fra andre kilder. Det tilrådes at kontakte professionelle rådgivere herom fx patentrådgivere. Teknisk set er det muligt at hente data og andet indhold fra andre apps i en separat app, og dette stiller naturligvis krav om indhentning af accept fra de øvrige apps, dels om indhentning af data, dels om sammenføring med evt. konkurrenter. Som eksempel kan nævnes de apps, der fremviser tilbudsaviser. De bør sikre sig en aftale om at hente data men også om at lægge deres indhold side om side med konkurrenter. Slutteligt er der apps, der giver brugerne mulighed for at ytre sig. Det kan være uhensigtsmæssigt at kontakte fagfolk, der kan rådgive om juridiske konsekvenser, hvis en bruger går over stregen, eller hvis brugerne viser andre måder at benytte appen på, end den tiltænkte brug. 31

32 Tjekliste De fundamentale forhold Samles i en brief Forretning Eksistensberettigelse (business case)! Samspil med andre tiltag Opstilling af strategi! Formål Behovsafdækning Formål med appen Opstilling af konkrete mål! Evalueringskriterier Målgruppe Hvem er målgruppen! Hvad er deres medievaner Hvilken kultur spiller appen ind i! Teknologi Hvilke platforme udvikles appen til! Skal indholdet være dynamisk eller statisk Skal appen have eget backend eller integration med eksisterende! Ressourcer Økonomi! Udviklingsbudget! Buffer! Driftsbudget Tidshorisont Milepæle Indsendelsesdato til App Store! Lanceringsdato Manpower Hvem udvikler! Hvem er projektleder Hvem står for vedligeholdelse! Jura Er appen henvendt til privat eller professionel brug Hvilket geografisk marked den markedsføres til! Er eventuelle rettigheder til apps indhold clearet Hvad er brugerinddragelsespolitik! 32

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

34 Ideen med at mødes og idéudvikle i fællesskab er at få bragt de forskellige interessenters kompetencer mest muligt i spil. Opdragsgiver sidder inde med viden om forretningen. Målgruppen (fx klinikere) sidder inde med viden om kultur, adfærd og eksisterende teknologier. Teknikkerne sidder inde med viden om de eksisterende IT-systemer. Og leverandøren er typisk eksperter inden for områderne som digital konceptudvikling, design, teknologi og medier. Samskabelse på idéniveau er en stor gevinst for det samlede produkt og et stærkt udgangspunkt for et konkret koncept, der rent faktisk vil blive en succes i praksis. En anden fordel ved at inddrage de forskellige interessenter tidligt er, at de får ejerskab og kan bidrage løbende i udviklingsprocessen med feedback, fordi de allerede er med i loopet. Resultatet af en god idé-udviklingsproces er at stå tilbage med et klart og afstemt billede af, hvad præcis appen skal kunne og rumme. Appens koncept, som ud over at beskrive idéen med appen og appens funktionalitet, omhandler appens indhold. Og det må siges igen, at content is king. Indholdet udgør appens værdi. Om det er et ægge-ur, der fortæller dig, hvornår dit æg er blødkogt, om det er dagens nyheder, der konstant er opdateret, om det er priser på benzin, vejret, et spil, aflæsning af en måleenhed, statistik om personlig performance, nærmeste bager, nærmeste toilet, nærmest kunstværk osv., så handler det altid om indhold. Indhold gjort tilgængeligt for brugeren på en måde, der skaber ny værdi. Og derfor er det ulejligheden værd at samle de mest kompetente mennesker på området for at skabe det bedste indhold, der leveres på den bedste måde for brugerne i et samlet homogent koncept. Prototyping Når appens koncept er defineret og beskrevet, kan appens anatomi visualiseres mere i dybden. Wireframing og prototyping er vigtige værktøjer i denne proces. Wireframes er en optegning af appens side/skærmvisninger, hvor både navigationselementer (som knapper, menuer mv.), indholdselementer (som tekst, billeder, video mv.) samt funktionalitet (som share, søg, optag, bestil mv.) er medtaget. Wireframes er en skitse af appen, der i første omgang skaber overblik over, hvordan appen er struktureret, og hvordan elementerne er placeret. Det er et meget vigtigt værktøj, fordi det er en helt konkret dokumentation af appen. Wireframes definerer også appen fremadrettet for designere og udviklere. I første omgang behøver wireframes ikke gå ud i alle detaljer. Det er en iterativ proces, hvor appen foldes mere og mere ud, hvilket dokumenteres gennem wireframes. Prototyping er et naturligt næste skridt for de fleste. Det er ikke på samme måde et must som wireframes, men prototyping er en god og endnu mere specifik måde at dokumentere flowet af indholdet i appen på. En app prototype er klikbare wireframes sat op i et program, hvor man kan navigere rundt i appen. Det behøver ikke være kompliceret, og vi har set flere eksempler på, at software som Power Point fungerer udmærket til at oprette de klikbare versioner af wireframes på. Der findes også mere avancerede softwareprodukter, hvor wireframes og prototype skitseres samtidigt (ex. Axure ell. Omni- Graffle) og slutteligt findes der software, der kan vise prototypen på den mobile enhed (ex. Prototype app). Prototypens styrker ift. wireframes er, at de er interaktive, at detaljeringsniveauet er højere, og at overblikket er endnu mere struktureret, fordi alle klikbare elementer gennemgås. Det betyder, at alle sten vendes, vurderes og kan tilrettes, indtil appen rummer og gør det, den skal. Hele idéen med wireframes/prototyping er således at visualisere produktet og gennem en iterativ proces justere og optimere appen, indtil den kan godkendes. Den godkendte wireframe/prototype er herefter omdrejningspunktet for den videre udvikling og det produkt, der produceres. Ændringer efterfølgende på wireframes og flow betragtes af de fleste leverandører som opgaver ud over det aftalte og koster ekstra. Wireframes/prototype er så at sige point of no return. Kravspecificering Ud over wireframes/prototyping ser vi ofte en kravspecifikation udarbejdet, som i ord beskriver, hvad der sker i de forskellige stadier af appen. Kravspecifikationen er god, fordi den giver mulighed for at 34

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

36 En af de helt store udfordringer i design for apps er selvfølgelig, at skærmen er lille, og at man navigerer rundt med sine fingre. Det betyder, at interfacet skal være både minimalt i sit informationsindhold, og at knapperne skal have en vis størrelse for at give fysisk mening. Ofte skal brugeroplevelsen af appen være baseret på en mere direkte berøring og bevægelse af elementerne. Man flytter ting på skærmen (lås op fx), man drejer på en knap, man forstørrer et billede med to fingre etc. Smartphonens multitouch teknologi har åbnet op for nye mere visuelt og fysiske måder at interagere på, og brugerfornemmelsen bliver ofte, at man står med et device, der fysisk fylder meget mere, end man kan se, og at man skubber elementer, navigationsbar og knapper rundt i det lille udsnit skærmen udgør, afhængig af, hvad man har brug for lige nu. To ting har for alvor skilt appdesign ud fra andre eksisterende medier og skabt nyt formsprog; Nemlig ikoner og det naturlige look. Ikonerne er enkle grafiske repræsentationer, der symboliserer en funktion, og det kan faktisk være en udfordring at opfinde passende ikoner til helt specifikke funktioner. Det naturalistisk-baserede look er et andet formsprog, som mange apps benytter. Fx en guitarforstærker app, der ligner en fysisk guitarforstærker. En boghandler app, der ligner en bogreol. Knapper, der ligner metal mv. Virkelighedens verden og ikke mindst håndens anatomi skal tænkes med, når der designes. Placering af knapper efter brugerens tommelfinger har direkte konsekvens på, om brugeren oplever interfacet som naturligt eller ej. Det er vores anbefaling, at appens design lægges op af eksisterende formsprog og konnotationer, der allerede er etableret og genkendes af brugerne. Det vil understøtte brugerens intuitive tilgang. Heldigvis findes der et hav af grafiske redskaber, skabeloner og samlinger, der kan bidrage og nærmest er uundværlige i designet af en flot app. Skabelse af den naturlige oplevelse og brug af appen ligger i designfasen. Processen vil typisk køre frem og tilbage over et par omgange, der ofte er aftalt på forhånd, indtil det rigtige look n feel er skabt, og navigationen er optimeret med placering af knapper og elementer de rigtige steder. Der findes gode og nærmest uundværlige programmer (Ex Live View Screencaster), der kan styrke dialogen omkring designprocessen ved at vise designet live på en telefon, man kan stå med i hånden. Vi anbefaler, at man brugertester interfacet på designniveau i stedet for at vente, til det er implementeret. En god måde at gøre dette på, er ved at indarbejde det valgte design i prototypen, således, at man har fornemmelse af, hvad appen kan, og hvordan den ser ud mens brugeren klikker sig gennem den. Husk at brugernes respons altid er guld værd både når det er positivt, og når det giver anledning til ændringer. Sidste trin i designdelen er rentegning og overlevering til udviklerne. Ligger design og udvikling hos én leverandør sker denne overlevering automatisk. Ligger design og udvikling hos forskellige parter, bør der fra start være aftalt, hvordan overlevering af designdokumenter skal ske. Herunder detaljeringsniveau og formater. I sådanne tilfælde kan det overvejes at bede designeren udarbejde en såkaldt style guide. Udvikling Udviklingsfasen er ofte den mest ressourcekrævende del af et app-projekt målt i mandetimer, og der er masser af litteratur tilgængelig på området. I denne guide har vi et praktisk fokus, hvilket betyder, at vi tilgår udviklingsfasen ud fra hvilke forhold, der med fordel kan overvejes rundt omkring udviklingen. Vi behandler ikke værktøjer til udvikling, eller hvordan man udvikler en app. Disse forhold kan en leverandør rådgive om. Men netop fordi selve udviklingen er så ressourcekrævende, er det naturligvis vigtigt, at der træffes de rigtige beslutninger omkring udviklingen, så ressourcerne bruges mest fornuftigt. Det er disse forhold, dette afsnit omhandler. Applikationstyper Den første overvejelse handler om valget af applikationstype. Der findes forskellige applikationstyper, der alle fungerer som det, man betegner som en mobile app. De afvikles på brugeres smartphone og 36

37 dækker i nogen grad de samme muligheder. Imidlertid er der tale om forskellige teknologier og derfor rummer de forskellige typer forskellige begrænsninger og muligheder. Native apps Er den type apps, der er skræddersyet, udviklet og optimeret til den konkrete platform og styresystem, som appen skal afvikles på. Det er den teknologisk set mest optimerede app ift. enheden. Det betyder også, at native apps ikke er særlig skalerbare, når det kommer til de andre platforme, og koden kan ikke genbruges på tværs. Til gengæld kan appen udnytte smartphonens fulde teknologiske potentiale. Man taler om et app-finish, der dækker over den følelse, man som bruger oplever, når man benytter appen. Hvordan designet spiller sammen med navigationen, hvordan enheden responderer på interaktionen, hvor stabilt appen kører, hvor lækkert og gennemarbejdet detaljerne fungerer. På native apps er disse forhold optimerede. Native apps er det, man også kunne kalde ægte fuldblodsapp. Fordelene er:! Optimal performance! Stærk brugeroplevelse! Fuld adgang til enhedens funktionaliteter og teknologi! Nemt at finde i diverse app butikker! Nemt at notificere brugere om updates! Push-opdateringer! Fungerer offline Ulemperne er:! Platformsspecifikke! Skal installeres! Skal godkendes af Apple (ios)! Provision til fx Apple og Google (Android Market) - pt. 30% Web apps Kan på mange måder sammenlignes med et avanceret website, optimeret til mobile enheder og med udnyttelse af de nyeste teknologier, der gør, at enhedens teknologi kan benyttes (kamera, GPS, kontakter etc.). Web apps afvikles på en server (tynd klient) og kræver at brugeren er online. Web apps er fx en mailapplikation på enheden eller cloud-relaterede apps. Web apps er mere skalerbare på tværs af platforme, men afvikles og vises ikke 100% identiske på alle enheder. Det betyder i praksis, at web apps skal optimeres til de mest anvendte enheder hos målgruppen. Web-finish er ikke helt på niveau med native apps, men stærke teknologier som HTML 5 har gjort brugeroplevelsen langt mere app-agtig. Fordelene er:! Ingen installation! Virker på tværs af platforme (skalerbarhed)! Skal ikke godkendes i en app butik! Ingen provision til div. app butikker! Projektet er i sin helhed mindre omfattende! Skal ikke opdateres på brugerens enhed! Høj grad af statistisk overvågning Ulemperne er:! Skal være online! Middel brugeroplevelse (svært at opnå app-finish )! Middel performance! Ej fuld adgang til enhedens funktionaliteter! Kan være sværere at finde for en bruger 37

38 Framework apps Den sidste type er de såkaldte framework apps. Det, der karakteriserer frameworkapps, er, at de er meget skalerbare på tværs af platformene. I princippet udvikles én app inden for frameworkets regi, hvorefter den sprøjtes ud af frameworket i de ønskede platformsversioneringer. Det er jo rigtig smart, og derfor en voksende industri, som også de helt store spillere (ex. Adobe) er gået ind i. Udfordringen er imidlertid, at frameworket som ofte har sine begrænsninger, for det siger sig selv, at kompleksiteten i at udnytte enhedens fulde funktionalitet som en native app gør, ikke blot lader sig kopiere til andre platforme. Resultatet er derfor ofte, at laveste fællesnævner sætter standarden simpelthen fordi Frameworket ikke understøtter mulighederne. Det gælder også styling, hvilket betyder at app-finish ikke er i top. Fordelene er:! Virker på tværs af diverse platforme! Mange-i-én gør processen hurtigere og billigere! Automatisk sikring af look på tværs af platforme Ulemperne er:! Kræver at man sætter sig ind i frameworkets udviklingsmiljø! Begrænset udnyttelse af enhedens funktionaliteter! Middel performance! Svært at opnå app-finish Inhouse eller outsourced Den næste overvejelse er, om udviklingen skal ligge i huset eller outsources til en underleverandør. Er der ikke tidligere erfaring med appudvikling, er det som regel ikke verdens bedste idé selv at udvikle appen. Vores anbefaling er, at man som opdragsgiver starter med ekstern udvikling og evt. rykker udviklingen in-house efterfølgende. En mulighed er at koble egne udviklere på processen hos leverandøren og derved bygge viden gennem processen. Overvejelser om valg af leverandør er beskrevet i FØR-afsnittet og skal her blot suppleres med flg. to råd:! Lav aftaler om, hvordan udviklingen dokumenteres i tilfælde af, at andre skal overtage den på et tidspunkt.! Lav aftaler om rettigheder til koden, at den opbevares forsvarligt og at den er tilgængelig i fremtiden. Projektledelse Ledelse af et medicoapp udviklingsprojekt adskiller sig på især to områder fra at lede andre softwareudviklingsprojekter. For størstedelens vedkommende er det relevant at inddrage regulatoriske godkendelsesprocedurer, hvilket kræver specialister og dermed ekstra tid såvel som finansielle ressourcer. Der kan for ikke-medico virksomheder ligge udfordringer i at gennemskue konsekvensen af at træde ind i medicobranchen, for selvom appen i bund og grund er ren kode, gælder der anderledes stringente regler og ansvarsforhold, når produktet skal forholde sig til menneskers liv og velvære. Generelt hører det desværre til sjældenhederne, at IT-projekter leveres fuldstændig til den aftalte tid og inden for budgettets rammer. Medico apps indeholder både en regulatorisk og en kvalitetsmæssig joker. Sørg for at undersøge myndighedskrav inden det endelige budget fastlægges og lav en aftale med styregruppen om frekvens for budget status. Det andet udfordringsområde handler om den mere generelle projektledelse og styring. App-projekter er specielle i det, at de på den ene side er begrænsede i deres koncept og på den anden side også meget komplekse, fordi det er nyt terræn, fordi bagvedliggende systemer skal integreres og fordi, der udvikles til klientafvikling på meget forskelligartede platforme (iphone, Android, Blackberry mv.). 38

39 Det bliver derfor essentielt at projektet scopes rigtigt fra begyndelsen både ift., hvad der er inden- og udenfor projektets rammer men også ift. tidsramme, samarbejdsform og afprøvning. Vi har dedikeret næste afsnit til test og afprøvning alene, da dette er helt centralt for projektets succes. Dette afsnit gennemgår projektledelse og samarbejde mere generelt. Styregruppe Det er vores erfaring, at nedsættelse af en styregruppe hos opdragsgiver fungerer godt således, at projektlederen er ansvarlig for den praktiske dialog og kontakt med leverandøren og løbende sikring af, at kravspecifikationen opfyldes, mens styregruppen er ansvarlig for godkendelsen af produktet iflg. de opsatte milepæle. Styregruppen bør være forankret på et beslutningsdygtigt niveau i organisationen. Sørg for at afstemme med styregruppen, hvad projektet IKKE vil levere. Det er bedre at tage den diskussion up front end til sidst. Specielt sensitivt er det med appudvikling, idet det som udgangspunkt tilrådes at holde appens design så simpelt som muligt (en app anvendes oftest på farten og med en hånd, så des færre knapper, desto bedre). Styregruppen vil hurtigt foreslå flere features, hvorfor det ikke er en kamp mellem features og budget snarere end en kamp mellem features og brugervenlighed, der skal afstemmes. Referencegruppe Sørg desuden for at have de rette kompetencer og ressourcer i projektet. Fx kan tilknyttes en ressource-/ reference-gruppe, der bistår projektlederen både før og under selve udviklingen. Referencegruppen kan bestå af brugere, fageksperter, klinikere og IT-folk, der alle sidder med vigtig viden og indsigt til gavn for projektet. Deres rolle er at vurdere og komme med anbefalinger undervejs i forløbet vedr. kritiske faktorer med konsekvenser typisk på indholds- og afviklingsniveau. Iterative udviklingsprocesser Fordi app-projekter på trods af deres begrænsning i form og indhold alligevel kan vise sig at være meget komplekse at udvikle, er det en god idé at benytte projektledelses- og udviklingsmetoder, der tager højde for, at alle krav måske ikke kan defineres fra starten, samt at der kan opstå ændringer af kravene undervejs, fx når man bevæger sig fra en platform til en anden. Et udviklingsprojekt kan enten foregå efter en vandfaldsmodel eller iterativt. I vandfaldsmodellen foregår udviklingen i en række faser fx; Kravspec., analyse, design, programmering og test. Herunder udvikles hele programmet typisk på én gang, nemlig i programmeringsfasen. I et iterativt forløb vil man som regel gennemføre faserne i en række kortere forløb, der ligger i forlængelse af hinanden, hvor programmet udvikles i form af små dele, der gradvist udbygges, til det endelige program er lavet. I udviklingen af medicoapps er det en fordel at arbejde med en kombination af vandfald og iteration, således at de indledende faser med konceptudvikling, kravspecificering og design færdiggøres efter vandfaldsmetoden, mens selve programmeringen gøres mere iterativ og sker i små skridt. Det vil i de fleste tilfælde afhængig af kompleksitet, nemlig være umuligt at lave en 100% fyldestgørende kravspecifikation fra starten, der besvarer og definerer alle spørgsmål. Derfor er det vores anbefaling at bruge moderne agile udviklingsmetoder i programmeringsfasen, der er gearet til netop dette. Agile Development ( adræt udvikling på dansk) er en betegnelse for en række forskellige inkrementelle udviklingsmetoder. De adrætte udviklingsmetoder er kendetegnet ved udvikling i små skridt (iterationer). Hver iteration tilføjer ny eller forbedret funktionalitet, hvilket gør, at der løbende kan tages højde for ændrede forudsætninger, krav og specifikationer. I Adræt udvikling prioriteres opgaverne ud fra brugerens behov, og der kræves derfor en høj grad af involvering fra kundens/slutbrugerens side. Adræt udvikling spiller derfor godt sammen med referen- 39

40 cegrupper. Blandt de mest kendte adrætte udviklingsmetoder kan nævnes Extreme Programming (XP) og Scrum. Det er vores anbefaling at samarbejdet om især udviklingsdelen gennemføres som en adræt proces med tæt og jævnlig kontakt projektleder og leverandør imellem, med blik på små skridt ad gangen, en konstant fremdrift samt med løbende dokumentation af dialog og beslutninger. Lange udviklingstræk uden kontakt og udokumenterede beslutninger indeholder faldgrupper og kan vise sig at få uheldige konsekvenser for projektet. Overlevering Projektet afsluttes, når appen lanceres, nu begynder den jo først at få et liv. Brugere giver feedback, fejl opdages, nye features skal tilføjes, appen skal understøttes i det daglige. Disse ting hører måske ikke ind i et projekt, men det er bestemt projektlederens ansvar at tænke en overlevering af appen fra projekt til drift. Test Testforløbet er tæt forbundet med selve udviklingsprocessen. Ofte vil opdragsgiver have et ønske om at følge med i udvikling og progression af appen, og omvendt vil leverandøren ofte også gerne have appens enkelte dele løbende godkendt. At vi har valgt at lægge testforløbet som et selvstændigt trin i implementeringsprocessen skyldes således ikke, at vi ser test som en isoleret del. Årsagen er, at vi opfatter testfasen som et utroligt centralt element i appudvikling, og især for medico apps er test og QA helt afgørende og kan vise sig at være ret ressourcekrævende. Medico apps skal være fejlfri, fordi de ofte omfatter livskritiske temaer. Og lavere fejltolerance betyder alt andet lige mere validering og flere test. Derfor behandler vi test som en selvstændig fase. Uanset om testen ligger integreret i udviklingen eller om testfasen lægges i forlængelse af implementeringen, er det en rigtig god ide at definere testforløbet fra starten. Både for at sikre, at det gennemføres som forventet, at der er sat tid af til det, og for at sikre at det tekniske set up fungerer. En række centrale forhold gør sig gældende, for at sikre et grundigt og professionelt testforløb. Det første i et testforløb er at sikre, at alle involverede parter har adgang til den tekniske løsning, dvs. appen. Det næste er at opstille en plan for, hvad der skal testes evt. med deadlines. Og det sidste er at skabe en feedback cyklus, der dokumenteres løbende og kan tilgås af alle involverede. Det er i bund og grund de forhold, der som minimum skal være på plads. Hvordan ovenstående organiseres og hvilke systemer, der benyttes er i princippet ligegyldigt, så længe de tre centrale byggesten er på plads. Figur 6. Figuren illustrerer de tre centrale elementer i et vellykket testforløb: 1. Adgang til appen. 2. En overordnet plan for testforløbet. 3. En feedbackcyklus, der dokumenteres i et fælles dokument, hvor fejlrapportering, kommentarer, feedback og status ajourføres. 40

Sundhedsapps. Christian Vinding Thomsen, Partner, Advokat

Sundhedsapps. Christian Vinding Thomsen, Partner, Advokat Sundhedsapps Christian Vinding Thomsen, Partner, Advokat Sundhedsapps Den retlige regulering et overblik : Reklame for lægemidler Markedsføring af sundhedsydelser Medicinsk udstyr (CE-mærkning og reklame)

Læs mere

Det forudsættes, at hovedvirkningen ikke opnås ad farmakologisk, metabolisk eller immunologisk vej (lægemiddelvirkninger).

Det forudsættes, at hovedvirkningen ikke opnås ad farmakologisk, metabolisk eller immunologisk vej (lægemiddelvirkninger). Medicoteknisk udstyr Medicoteknisk udstyr er en undergruppe af medicinsk udstyr og dets tilbehør. Medicoteknisk udstyr omfatter alene aktivt medicinsk udstyr og dets tilbehør. Medicoteknisk udstyr omfatter

Læs mere

El sikkerhed. Lkaa 2012

El sikkerhed. Lkaa 2012 El sikkerhed Lkaa 2012 Sikkerhed, uheld og risiko Det ideelle sygehusvæsen!! Høj sikkerhed Ingen uheld Lav risiko Lasse Kaae Mail: Lkaa@mercantec.dk 2 Definitioner! Uheld Et uheld er en uventet og pludselig

Læs mere

Ni vigtige overvejelser før du udvikler en app et uddrag fra Medico Apps. A practitioner s guide. Uri Duvald Andersen Morten Gjøl

Ni vigtige overvejelser før du udvikler en app et uddrag fra Medico Apps. A practitioner s guide. Uri Duvald Andersen Morten Gjøl Ni vigtige overvejelser før du udvikler en app et uddrag fra Medico Apps. A practitioner s guide Uri Duvald Andersen Morten Gjøl 1 Introduktion Uri og Morten er initiativtagere til og har udviklet bogen

Læs mere

LÆGEFORENINGEN. Sikker behandling med medicinsk udstyr. Patienter og læger har krav på sikkert og effektivt medicinsk udstyr

LÆGEFORENINGEN. Sikker behandling med medicinsk udstyr. Patienter og læger har krav på sikkert og effektivt medicinsk udstyr LÆGEFORENINGEN Sikker behandling med medicinsk udstyr Patienter og læger har krav på sikkert og effektivt medicinsk udstyr Udkast til politikpapir kort version. Lægemøde 2015 Plastre, hofteproteser, høreapparater,

Læs mere

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke:

Hos Lasse Ahm Consult vurderer vi at følgende supplerende krav i de enkelte kravelementer er væsentlige at bemærke: ISO 9001:2015 (Draft) Side 1 af 9 Så ligger udkastet klar til den kommende version af ISO 9001. Der er sket en række strukturelle ændringer i form af standardens opbygning ligesom kravene er blevet yderligere

Læs mere

BESLUTNINGSBARRIEREN ER HØJERE

BESLUTNINGSBARRIEREN ER HØJERE At lave innovation og tænke nye forretningsområder kræver et velfunderet grundlag, der sikre kendskab til målgruppens behov og forretningens strategiske mål. Det er vigtigt at være sin position bevidst

Læs mere

Hvilke regulatoriske krav er der til kliniske forsøg, når børn udgør patientgruppen?

Hvilke regulatoriske krav er der til kliniske forsøg, når børn udgør patientgruppen? Hvilke regulatoriske krav er der til kliniske forsøg, når børn udgør patientgruppen? Lone Ekstrøm Ragn, RA/QA Konsulent Tirsdag den 17. juni 2014, 17.10 17.30 Ragn Regulatory Consulting Børn som forsøgsdeltagere

Læs mere

Projektevaluering. Caretech Innovation. Projekt Mobiladgang for læger og andet sundhedspersonale (C-47)

Projektevaluering. Caretech Innovation. Projekt Mobiladgang for læger og andet sundhedspersonale (C-47) 1 Projektevaluering Caretech Innovation Projekt Mobiladgang for læger og andet sundhedspersonale (C-47) Deltagere/partnere: Systematic A/S Regionshospitalet Randers og Grenå Caretech Innovation Dato: 8.

Læs mere

Ikke bare endnu en e-bog... CoMPreNDo. Sådan kommer du i gang med din egen app. Og hvad skal virksomheden overhovedet bruge en app til?

Ikke bare endnu en e-bog... CoMPreNDo. Sådan kommer du i gang med din egen app. Og hvad skal virksomheden overhovedet bruge en app til? Ikke bare endnu en e-bog... CoMPreNDo. Sådan kommer du i gang med din egen app Og hvad skal virksomheden overhovedet bruge en app til? Titel: Sådan kommer du i gang med din egen applikation 1. udgave -

Læs mere

Innovationens Syv Cirkler

Innovationens Syv Cirkler Innovationens Syv Cirkler Med denne gennemgang får du en kort introduktion af Innovationens Syv Cirkler, en model for innovationsledelse. Dette er en beskrivelse af hvilke elementer der er betydende for

Læs mere

INFLUENCERS. Nemt igang på internettet. Kom hurtigt igang med det du er god til. Klar, start! w w w. i n f l u e n c e r s. d k

INFLUENCERS. Nemt igang på internettet. Kom hurtigt igang med det du er god til. Klar, start! w w w. i n f l u e n c e r s. d k INFLUENCERS Nemt igang på internettet Kom hurtigt igang med det du er god til Klar, start! w w w. i n f l u e n c e r s. d k STOR effekt - billig løsning Hej, jeg hedder Anders Søndergaard, og jeg er selvstændig

Læs mere

Projektevaluering. Caretech Innovation. Optimized Brain reading (C-63)

Projektevaluering. Caretech Innovation. Optimized Brain reading (C-63) 1 Projektevaluering Caretech Innovation Optimized Brain reading (C-63) Deltagere/partnere: Brainreader Institut for datalogi, Aarhus Universitet Caretech Innovation Dato: 3. oktober 2012 Version: c-63

Læs mere

FORRETNINGSSTRATEGI SUNDHED.DK

FORRETNINGSSTRATEGI SUNDHED.DK FORRETNINGSSTRATEGI SUNDHED.DK INDHOLD 01 Om dokumentet 3 02 Sundhed.dk s forretning 4 02.1 Mission og vision 4 02.2 Sundhed.dk s position og marked 4 02.3 Sundhed.dk s fundament og leverancer 5 02.4 Målgrupper

Læs mere

Maj 2012. Ontasknaturally.com Case Studie. Hvordan E-Intelligence Sikrede Mere end 100% Tilbagebetaling På Investeringen til Ontasknaturally.

Maj 2012. Ontasknaturally.com Case Studie. Hvordan E-Intelligence Sikrede Mere end 100% Tilbagebetaling På Investeringen til Ontasknaturally. Hvordan E-Intelligence Sikrede Mere end 100% Tilbagebetaling På Investeringen til Ontasknaturally.com Maj 2012 Ontasknaturally.com Case Studie Ophavsret eintelligenceweb.com 2013 Kontakt os: eintelligenceweb.com

Læs mere

Opstramning af lovgivningen om medicinsk Udstyr. hvad bliver ændret? Henrik G. Jensen

Opstramning af lovgivningen om medicinsk Udstyr. hvad bliver ændret? Henrik G. Jensen Opstramning af lovgivningen om medicinsk Udstyr hvad bliver ændret? Henrik G. Jensen 31.05.2013 Indhold Principperne bag reglerne for medicinsk udstyr Styrker/Svagheder i gældende lovgivning Forslag til

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Specialister i softwareudvikling. Mobil apps Online løsninger IT-konsulenter Ændring af eksisterende løsninger

Specialister i softwareudvikling. Mobil apps Online løsninger IT-konsulenter Ændring af eksisterende løsninger Specialister i softwareudvikling Mobil apps Online løsninger IT-konsulenter Ændring af eksisterende løsninger Projekter med Centic 1) Udgangspunktet er jeres virksomhed Den it-løsning vi leverer til jeres

Læs mere

Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV

Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV Leverings- og vedligeholdelsesvilkår for Moderniseringsstyrelsen lokale datavarehus LDV Indhold 1. DEFINITIONER... 2 2. BAGGRUND OG FORMÅL... 2 3. MODERNISERINGSSTYRELSENS YDELSER... 3 4. INSTITUTIONENS

Læs mere

Lovforslag om ændring af lov om markedsføring af sundhedsydelser.

Lovforslag om ændring af lov om markedsføring af sundhedsydelser. Sundheds- og Forebyggelsesudvalget 2012-13 L 93 endeligt svar på spørgsmål 13 Offentligt Dato 8. februar 2013 Sagsnr. 2012081031 mdn mdn@dkma.dk Lovforslag om ændring af lov om markedsføring af sundhedsydelser.

Læs mere

HVORDAN SKAL JEG BRUGE SOCIALE MEDIER? GODE RÅD

HVORDAN SKAL JEG BRUGE SOCIALE MEDIER? GODE RÅD 1 Denne vejledning viser, hvordan du kan udnytte de mange muligheder, de sociale medier giver, og være opmærksom på de faldgruber, der kan skade dig selv, dine pårørende og kolleger eller din myndighed.

Læs mere

Foranalyse for edagsordensprojekt og devices

Foranalyse for edagsordensprojekt og devices Foranalyse for edagsordensprojekt og devices Udarbejdet af Jesper Rønnov og Morten Hougaard Sidst revideret d. 13/01/11 Sammenfatning af foranalysen... 2 Mulige veje frem for projektet... 2 A. Fujitsu

Læs mere

Infrarød Screening. med Total Vision anatomi software

Infrarød Screening. med Total Vision anatomi software Infrarød Screening med Total Vision anatomi software Infrarød Screening med Total Vision anatomi software Der er ubegrænsede muligheder med vores høje kvalitetsinfrarød screeningssystem. Energetic Health

Læs mere

Guide til IT projekter i den fællesoffentlige projektmodel

Guide til IT projekter i den fællesoffentlige projektmodel DEN FÆLLESOFFENTLIGE PROJEKTMODEL Guide til IT projekter i den fællesoffentlige projektmodel Dato: 22.06.2015 Version: 1.0 1 Projektledelse af it-projekter Denne guide tager udgangspunkt i særlige forhold

Læs mere

Teknologi markedsføring -> et produkt som er på vej fx et it-system

Teknologi markedsføring -> et produkt som er på vej fx et it-system 1 Traditionel markedsføring-> et produkt du har på hylden Teknologi markedsføring -> et produkt som er på vej fx et it-system Strategiske alliancer og partnerskaber er ofte nødvendige pga. kompleksiteten

Læs mere

Drupal. Hvad er Drupal?

Drupal. Hvad er Drupal? Drupal Verdens bedste Content Management System Drupal er to år i træk blevet kåret som det bedste Open Source CMS i den såkaldte CMS Award, som årligt afholdes af det anerkendte IT-bogforlag Packt Publishing.

Læs mere

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011

Spil Rapport. Spil lavet i GameMaker. Kevin, Mads og Thor 03-02-2011 Spil Rapport Spil lavet i GameMaker Kevin, Mads og Thor 03-02-2011 Indholdsfortegnelse Indledning... 2 HCI... 2 Planlægning / Elementær systemudvikling... 2 Kravspecifikationer... 4 Spil beskrivelse...

Læs mere

Alarmen er frakoblet. Easy Series Alarmcentral Gør sikkerhed enkel med wlsn* * wireless Local SecurityNetwork (trådløst lokalt sikkerhedsnetværk)

Alarmen er frakoblet. Easy Series Alarmcentral Gør sikkerhed enkel med wlsn* * wireless Local SecurityNetwork (trådløst lokalt sikkerhedsnetværk) Alarmen er frakoblet Easy Series Alarmcentral Gør sikkerhed enkel med wlsn* * wireless Local SecurityNetwork (trådløst lokalt sikkerhedsnetværk) 2 Sikkerhed i første række Selvfølgelig vil du sørge for

Læs mere

Hvor og hvordan kan man være tilstede på nettet?

Hvor og hvordan kan man være tilstede på nettet? Hvor og hvordan kan man være tilstede på nettet? 1) Den klassiske tilstedeværelse Visitkort hele pakken blogs Fora Netbutik Distribueret indhold 2) De sociale medier Facebook LinkedIn Twitter Faglige blogs

Læs mere

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune

App-strategi for Randers Kommune December 2012. Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Bilag 2: Procesvejledning for app-udvikling i Randers Kommune Procesvejledningen har til formål, at skabe overblik over app-udviklingsprocessen, og skal sikre kvalitet og genkendelighed blandt apps ene

Læs mere

Strategi for Væksthus for Ledelse mod 2011

Strategi for Væksthus for Ledelse mod 2011 Strategi for Væksthus for Ledelse mod 2011 Formålet med Væksthus for Ledelse - at systematisere og målrette dialogen om ledelse i kommuner og regioner, herunder at udvikle og fokusere ledelse som disciplin,

Læs mere

XMO Det handler om IT, der skaber værdi helt enkelt

XMO Det handler om IT, der skaber værdi helt enkelt XMO Det handler om IT, der skaber værdi helt enkelt OPLEV XMO Har du set videoen? På xmo.dk kan du se en kort video om XMO. Hvis du vil se mere, kommer vi gerne og viser systemet i din klinik. Se den på

Læs mere

Én IT løsning, mange fordele AX TRAVEL. - fremtidens rejsebureauløsning

Én IT løsning, mange fordele AX TRAVEL. - fremtidens rejsebureauløsning Én IT løsning, mange fordele - fremtidens rejsebureauløsning Privatejet virksomhed Etableret i 1987 100 % danskejet Hovedkontor i Allerød og kontor i Århus +80 medarbejdere Solid og positiv økonomi gennem

Læs mere

XProtect-klienter Tilgå din overvågning

XProtect-klienter Tilgå din overvågning XProtect-klienter Tilgå din overvågning Tre måder at se videoovervågning på For at skabe nem adgang til videoovervågning tilbyder Milestone tre fleksible brugergrænseflader: XProtect Smart Client, XProtect

Læs mere

Fremtidsseminar 2013. Andelen af folk der laver frivillig arbejde fordelt på alder. Definition af frivilligt arbejde

Fremtidsseminar 2013. Andelen af folk der laver frivillig arbejde fordelt på alder. Definition af frivilligt arbejde Fremtidsseminar 2013 Definition af frivilligt arbejde Et stykke arbejde, der er kendetegnet ved: - Ikke lønnet, dog med mulighed for kompensation - Er frivilligt, dvs. at det udføres uden fysisk, retsligt

Læs mere

Projektledelse. Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.

Projektledelse. Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Projektledelse Uddrag af artikel trykt i Projektledelse. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste

Læs mere

Medicinsk udstyr. Udvikling med agile metoder. We help ideas meet the real world / madebydelta.com

Medicinsk udstyr. Udvikling med agile metoder. We help ideas meet the real world / madebydelta.com delta /Health & Care Medicinsk udstyr Udvikling med agile metoder We help ideas meet the real world / madebydelta.com 01 At udvikle og markedsføre medicinsk udstyr er et spørgsmål om tillid Agil tankegang

Læs mere

MASKINDIREKTIVET - din sikkerhed

MASKINDIREKTIVET - din sikkerhed MASKINDIREKTIVET - din sikkerhed Hvad er maskindirektivet? Maskindirektivet fastlægger de væsentlige sikkerheds- og sundhedskrav til indretningen af maskiner. Direktivet er bl.a. indført for at nedbringe

Læs mere

Bilag 3A.7 Brugergrænseflader

Bilag 3A.7 Brugergrænseflader Bilag 3A.7 Brugergrænseflader Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 3 2 INDLEDNING... 4 3 USER EXPERIENCE GUIDELINES (UX-GUIDELINES)... 5 3.1 GENERELLE UX-GUIDELINES... 5 3.1.1

Læs mere

MEE is all about YOU

MEE is all about YOU MEE is all about YOU Om MEE TM Sådan fungerer systemet MEE TM er et betalingssystem, der gør det muligt at betale med mobiltelefonen (smartphones) på en enkel, hurtig, fleksibel, sikker og billig måde

Læs mere

RAMMEAFTALEBILAG A - KRAVSPECIFIKATION

RAMMEAFTALEBILAG A - KRAVSPECIFIKATION RAMMEAFTALEBILAG A - KRAVSPECIFIKATION Niels Juels Gade 13 1022 København vd@vd.dk EAN 5798000893450 Postboks 9018 Telefon 7244 3333 vejdirektoratet.dk SE 60729018 2 af 6 KRAVSPECIFIKATION Mindstekrav

Læs mere

Kom godt i gang med din webs. Dato: 14. marts 2013 Jan Overgaard, Sektionsleder i IBIZ-Center, ved Teknologisk Institut

Kom godt i gang med din webs. Dato: 14. marts 2013 Jan Overgaard, Sektionsleder i IBIZ-Center, ved Teknologisk Institut Kom godt i gang med din webs Dato: 14. marts 2013 Jan Overgaard, Sektionsleder i IBIZ-Center, ved Teknologisk Institut Program Kl. 14.00-14.10 Velkommen v/dansk Erhverv Kl. 14.10-14.30 Rammer og tendenser

Læs mere

Mobility-strategi Hvordan kommer du i gang?

Mobility-strategi Hvordan kommer du i gang? Mobility-strategi Hvordan kommer du i gang? Kenneth Rosenkrantz 13. marts 2013 kro@dubex.dk Agenda Kort opsummering Hvad bør en Mobility Strategi indeholde? Virksomhedens modenhed Hvordan kommer du i gang?

Læs mere

Arbejdsformer i datalogiske forundersøgelser

Arbejdsformer i datalogiske forundersøgelser Arbejdsformer i datalogiske forundersøgelser Keld Bødker, Finn Kensing og Jesper Simonsen, RUC/datalogi Projektet foregår i et samarbejde mellem Danmarks Radio, H:S Informatik, WMdata Consulting A/S og

Læs mere

Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens:

Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens: DS/ISO 31000 Risikoledelse ISO 31000 - Risikoledelse Virksomheden bør udvikle, implementere og konstant forbedre de rammer, der sikrer integration af processen til at håndtere risici i virksomhedens: overordnede

Læs mere

læring og it Digitale medier i undervisningen Nye muligheder i en web 2.0 verden

læring og it Digitale medier i undervisningen Nye muligheder i en web 2.0 verden Digitale medier i undervisningen Nye muligheder i en web 2.0 verden Hvem er jeg? Bjørg Torning Andersen Gymnasielærer Grundfagslærer Pædagogisk it vejleder Projektleder Agenda Web 2.0 Elevtyper Didaktik

Læs mere

Proceduren Proceduren for en given vare eller varetype fastlægges ud fra:

Proceduren Proceduren for en given vare eller varetype fastlægges ud fra: Forudsætning for CE-mærkning En fabrikant kan først CE-mærke sit produkt og dermed få ret til frit at sælge byggevaren i alle EU-medlemsstater, når fabrikanten har dokumenteret, at varens egenskaber stemmer

Læs mere

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING

2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING 2. SEMESTER PROJEKT 3 INTERAKTIONSUDVIKLING Baggrund Udgangspunktet er projekt 2, dvs. en blog om cupcakes, hvor målgruppe, afsender og modtager allerede er defineret. Du bliver nu bedt om at udvikle et

Læs mere

Kort sagt: vil du lave den fede Rejseplanen, skal du være med i vores konkurrence!

Kort sagt: vil du lave den fede Rejseplanen, skal du være med i vores konkurrence! Rejseplanen A/S afholder konkurrencen: Ideudvikling af Rejseplanen 1. Beskrivelse af opgaven Den overordnede opgave er at komme med bud på ideudvikling af Rejseplanen. Har du den fede ide til at nyskabe

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

SPT. The Association of Danish Cosmetics and Detergent Industries. Ny Kosmetikforordning

SPT. The Association of Danish Cosmetics and Detergent Industries. Ny Kosmetikforordning Information til foreningens medlemmer Ny Kosmetikforordning Kgs. Lyngby den 4. januar 2010 Den nye Kosmetikforordning blev offentliggjort i EU s Lovtidende den 22. december 2009. Forordningen (der er dateret

Læs mere

Ondisplay - Digitalt informationssystem

Ondisplay - Digitalt informationssystem Ondisplay - Digitalt informationssystem Instore TV, Infoskærme eller digital skitning Instore TV blev fra den spæde begyndelse i USA introduceret som en ny mediekanal primært i detailforretninger. Et faktum

Læs mere

Velfærd gennem digitalisering

Velfærd gennem digitalisering Velfærd gennem digitalisering Sorø Kommunes Strategi for velfærdsteknologi og digitalisering 2011 2016 1. Indledning Strategi for velfærdsteknologi og digitalisering er udarbejdet i 2011 over en periode

Læs mere

CIVILSAMFUND I UDVIKLING - fælles om global retfærdighed

CIVILSAMFUND I UDVIKLING - fælles om global retfærdighed CIVILSAMFUND I UDVIKLING - fælles om global retfærdighed CISUs STRATEGI 2014-2017 CISUs STRATEGI 2014 2017 Civilsamfund i udvikling fælles om global retfærdighed Vedtaget af CISUs generalforsamling 26.

Læs mere

Kort introduktion til grøn innovation

Kort introduktion til grøn innovation Kort introduktion til grøn innovation Hvad kan der søges om, hvem kan søge, og hvordan søger man? Ansøgningsrunde juni 2011 vedr. innovation af serviceydelser, produkter og systemløsninger på det grønne

Læs mere

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT

PROJEKTBESKRIVELSE INFORMATIONER FOR AFLEVERING TIL DRIFT PROJEKTBESKRIVELSE cuneco en del af bips INFORMATIONER FOR AFLEVERING TIL DRIFT Dato 20. marts 2014 Projektnr. 13 031 Sign. SSP 1 Indledning Dette projekt vil have fokus på at specificere de informationer,

Læs mere

Mobilitet har fået nyt navn: CrossPad. Comwell Kolding den 9. april 2013

Mobilitet har fået nyt navn: CrossPad. Comwell Kolding den 9. april 2013 Mobilitet har fået nyt navn: CrossPad Comwell Kolding den 9. april 2013 it s a mobile first world I går Find hen til computeren I dag Der er en App til det Lokation Er ikke relevant Tid Er på min side

Læs mere

Forretningsmodeller for mobile applikationer

Forretningsmodeller for mobile applikationer Forretningsmodeller for mobile applikationer Indsigt og strategi Søren Kottal Eskildsen Alexandra Instituttet A/S Skabelon til forretningsmodel for mobile Click to edit Master title style applikationer

Læs mere

Online tilstedeværelse

Online tilstedeværelse Online tilstedeværelse Modul 1: Online tilstedeværelse -Hvordan bygger jeg en hjemmeside og hvad skal den gøre for mig? Modul 2: Få flere kunder -Hvordan får jeg mine besøgende konverteret til nye kunder

Læs mere

Application Management Service

Application Management Service Application Management Service I dette Whitepaper vil vi beskrive nogle af vores erfaringer med Application Management. De fleste virksomheder har på et tidspunkt lavet, eller fået lavet, en mindre applikation,

Læs mere

Find vej til offentlige penge og tilbud til fornyelse, forskning og finansiering

Find vej til offentlige penge og tilbud til fornyelse, forskning og finansiering Find vej til offentlige penge og tilbud til fornyelse, forskning og finansiering Børsen 16. juni 2011 Susanne Duus, ABT-fonden (fremover Fonden for Velfærdsteknologi) 1 Baggrund for ABT-fonden >Demografisk

Læs mere

I har ikke brug for endnu et nyt website!

I har ikke brug for endnu et nyt website! I har ikke brug for endnu et nyt website! Tusindvis af websites svæver formålsløst rundt i cyberspace. Mange af vores nye kunder har siddet med følelsen af, at de ikke fik nok ud af deres website. Og mange

Læs mere

E-læring og samarbejde over nettet

E-læring og samarbejde over nettet E-læring og samarbejde over nettet Vi var ikke i tvivl, da vi for nogle år tilbage valgte at satse på e-læring og udvikling af nye lærings- og samarbejdsformer. Vi havde brug for en seriøs og kompetent

Læs mere

Apps og smartphones HMI. mobil devices og produktions-it. Anders Rolann, evikali A/S

Apps og smartphones HMI. mobil devices og produktions-it. Anders Rolann, evikali A/S Apps og smartphones HMI mobil devices og produktions-it Anders Rolann, evikali A/S Agenda Kort om evikali A/S Mobil Teknologi Smartdevices Fordele og ulemper ved smart devices Vision Brug af Apps i automation

Læs mere

Talegenkendelse. Indhold. Teknologien

Talegenkendelse. Indhold. Teknologien Indhold Teknologien... 1 Vurdering af talegenkendelse på forskellige platforme... 2 Talegenkendelse som potentiale for skriftlig deltagelse... 3 Målgruppen... 4 Talegenkendelse Teknologien Talegenkendelse

Læs mere

GENERELLE BRUGERBETINGELSER FOR

GENERELLE BRUGERBETINGELSER FOR GENERELLE BRUGERBETINGELSER FOR mypku Disse generelle brugerbetingelser ( Betingelser ) fastsætter de betingelser, der gælder mellem dig som bruger ( Brugeren ) og Nutricia A/S, CVR.: 73128110 ( Nutricia

Læs mere

Vejledning til kvalitetsstyringssystemer i Fyrværkerivirksomheder. Sikkerhedsstyrelsen 4. maj 2006

Vejledning til kvalitetsstyringssystemer i Fyrværkerivirksomheder. Sikkerhedsstyrelsen 4. maj 2006 Vejledning til kvalitetsstyringssystemer i Fyrværkerivirksomheder Sikkerhedsstyrelsen 4. maj 2006 INDHOLDSFORTEGNELSE Indholdsfortegnelse...1 Indledning...2 Krav til kvalitetsstyringssystemet...2 Etablering

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2

UC Effektiviseringsprogrammet. Projektgrundlag. Business Intelligence. version 1.2 UC Effektiviseringsprogrammet Projektgrundlag Business Intelligence version 1.2 9. september 2014 1 Stamdata Stamdata Projektnavn (forventet): Projektejer: Projekttype: Business Intelligence It-chef Hans-Henrik

Læs mere

Mobility-strategi Hvordan kommer du i gang? Kenneth Rosenkrantz Søborg, 7. november 2013

Mobility-strategi Hvordan kommer du i gang? Kenneth Rosenkrantz Søborg, 7. november 2013 Mobility-strategi Hvordan kommer du i gang? Kenneth Rosenkrantz Søborg, 7. november 2013 DUBEX SECURITY & RISK MANAGEMENT SUMMIT 2013 Agenda Mobility Politik og procedure Virksomhedens modenhed Hvad bør

Læs mere

ANSØGNINGSSKEMA FÆLLES PULJE

ANSØGNINGSSKEMA FÆLLES PULJE ANSØGNINGSSKEMA FÆLLES PULJE INITIATIVETS TITEL: Gratis tryghed til borgerne 1. ANSØGERE OG SAMARBEJDSPARTNERE Ansøger (projektansvarlig): Velfærdsteknologisk Enhed Navn: Ivan Kjær Lauridsen E-mail: ijk@aarhus.dk

Læs mere

PLAN OG UDVIKLING GIS-STRATEGI 2012-2016

PLAN OG UDVIKLING GIS-STRATEGI 2012-2016 PLAN OG UDVIKLING GIS-STRATEGI 2012-2016 Indhold 1 INDLEDNING 3 2 STRATEGIGRUNDLAGET OG HANDLINGSPLAN 5 3 VISION 6 4 PEJLEMÆRKER OG PRINCIPPER 8 4.1 TEKNOLOGI 8 4.1.1 Principper 8 4.2 KOMMUNIKATION 9 4.2.1

Læs mere

Produktion III. Del af en integreret virksomhedsløsning. Produktion III til Microsoft Navision Axapta. forøger effektiviteten i produktionscyklussen.

Produktion III. Del af en integreret virksomhedsløsning. Produktion III til Microsoft Navision Axapta. forøger effektiviteten i produktionscyklussen. Produktion III til Microsoft Navision Axapta forøger effektiviteten i produktionscyklussen. Produktion III Produktionsserien til Microsoft Navision Axapta gør det muligt for producenter at styre hele Fordele

Læs mere

Det psykologiske. Betina Rangstrup, Cand.psych., Human Factors Specialist bra@force.dk

Det psykologiske. Betina Rangstrup, Cand.psych., Human Factors Specialist bra@force.dk Det psykologiske Patientsikkerhed og brugervenlighed med Human Factors Betina Rangstrup, Cand.psych., Human Factors Specialist bra@force.dk Helle Boelsmand Bak R.N., Master of Education & HRD, Human Factors

Læs mere

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer INDLÆG 13 : DYNAMICS AX Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer Tonny Bybæk, Lau Bøgelund Larsen Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Læs mere

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO...

INDHOLDSFORTEGNELSE. INDLEDNING... 7 Kristian Langborg-Hansen. KAPITEL ET... 9 I gang med App Inventor. KAPITEL TO... INDHOLDSFORTEGNELSE INDLEDNING... 7 Kristian Langborg-Hansen KAPITEL ET... 9 I gang med App Inventor Installation af App Inventor... 10 Trådløs installation... 11 Installation af emulator (Windows)...

Læs mere

KOMMUNIKATIONSSTRATEGI. Analyse af organisationers udvikling og anvendelse af kommunikationstrategier

KOMMUNIKATIONSSTRATEGI. Analyse af organisationers udvikling og anvendelse af kommunikationstrategier KOMMUNIKATIONSSTRATEGI Analyse af organisationers udvikling og anvendelse af kommunikationstrategier Februar 2014 INDHOLD KONKLUSION............................................ 3 OM ANALYSEN...........................................

Læs mere

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet...

1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet... Indhold 1 Ordliste 2 2 Indledning 3 2.1 Problemstillinger.................................. 3 2.2 Problemformulering................................ 4 2.3 Problemafgrænsning................................

Læs mere

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014

UC Effektiviseringsprogrammet. Projektgrundlag. Fælles UC Videoplatform 08-05-2014 UC Effektiviseringsprogrammet Projektgrundlag Fælles UC Videoplatform 08-05-2014 Den fællesstatslige it-projektmodel, Digitaliseringsstyrelsen Produkt: Projektgrundlag, ver. 27/8-2013 1 Stamdata Stamdata

Læs mere

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England.

Løsningen garanterer at finde alle de cookies, som et nationalt tilsyn kan finde. Løsningen er valideret af Audit Bureau of Circulation i England. Cookievejledningens Tekniske Guide Den tekniske guide beskriver fem skridt til overholdelse af cookiereglerne: 1. Fastlæggelse af webejendom 2. Undersøgelse af om der sættes cookies på hjemmesiden 3. Afgivelse

Læs mere

Afrapportering af projektet BApps - Biblioteks Apps

Afrapportering af projektet BApps - Biblioteks Apps 14. november 2014 Side 1 af 8 Afrapportering af projektet BApps - Biblioteks Apps KULTUR OG BORGERSER- VICE Borgerservice og Biblioteker Aarhus Kommune ITK Møllegade 1 8000 Aarhus C Telefon: 89 40 94 00

Læs mere

Alle vil have apps. En løsning til alle

Alle vil have apps. En løsning til alle Alle vil have apps Der er flere mobiltelefoner end indbyggere i Danmark 86 % af alle nye telefoner er en smartphone 20 % af alle søgninger på nettet er via mobiltelefon Over 80 % af alle køb indledes på

Læs mere

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER

PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER PRINCE2 PRACTITIONER EKSAMEN VEJLEDNING TIL EKSAMINANDER 1 INTRODUKTION 1.1 Formålet med Practitioner-eksamen er at give eksaminanden mulighed for at demonstrere forståelse af PRINCE2. Samtidig skal eksaminanden

Læs mere

Ledelse i TDC. Casebeskrivelse Conmoto A/S Human Business Development. DMR Konsulentprisen 2006 TDC A/S

Ledelse i TDC. Casebeskrivelse Conmoto A/S Human Business Development. DMR Konsulentprisen 2006 TDC A/S Ledelse i TDC Casebeskrivelse Conmoto A/S Human Business Development DMR Konsulentprisen 2006 TDC A/S November 2005 Indledning Nedenstående case er en beskrivelse af samarbejdet mellem TDC Koncern HR og

Læs mere

CareerMediator MANAGING CONSULTANT TIL KILDEDAL MØRKHØJVEJ 4 DK-3660 STENLØSE TELEFON +45 70275665 INFO@CAREERMEDIATOR.DK WWW.CAREERMEDIATOR.

CareerMediator MANAGING CONSULTANT TIL KILDEDAL MØRKHØJVEJ 4 DK-3660 STENLØSE TELEFON +45 70275665 INFO@CAREERMEDIATOR.DK WWW.CAREERMEDIATOR. MANAGING CONSULTANT TIL CAREERMEDIATOR KILDEDAL MØRKHØJVEJ 4 DK-3660 STENLØSE TELEFON +45 70275665 INFO@CAREERMEDIATOR.DK WWW.CAREERMEDIATOR.DK Jobfact: Virksomhed: Stillingsbetegnelse: Markedssegment:

Læs mere

Fra ad hoc-tilgang til en struktureret CSR-indsats

Fra ad hoc-tilgang til en struktureret CSR-indsats Tryksag 541-643 Gode råd Her er nogle gode råd til, hvordan I griber CSR-processen an. Kom godt i gang med standarder > > Sæt et realistisk ambitionsniveau > > Sørg for, at CSR er en integreret del af

Læs mere

Mobil adgang til logistikdata

Mobil adgang til logistikdata 2012 Samarbejde Partnere Capgemini Systematic A/S Regionshospitalet Randers Caretech Innovation, Alexandra Instituttet Budget 1.100.000 kr. Projektperiode 1. januar 2012 til 31. august 2012 Projektet er

Læs mere

Kravsspecifikation til Nationalpark App

Kravsspecifikation til Nationalpark App Kravsspecifikation til Nationalpark App Kravsspecifikation til Nationalpark App...1 1. Introduktion og platform...1 2. Ikke funktionelle specifikationer...2 3. Brugeroplevelse...2 4. Indholdsleverandører...2

Læs mere

Læredygtige møder Skru op for det, der gør jer bedre

Læredygtige møder Skru op for det, der gør jer bedre Læredygtige møder Skru op for det, der gør jer bedre Holder I mange møder? Handler de om andet, end daglig drift og administration? Kunne møderne også bruges til at skabe udvikling og læring? Organisatorisk

Læs mere

17 METODER TIL SUCCESFULD ONLINE OG OFFLINE MARKEDFØRING MED GAVEARTIKLER

17 METODER TIL SUCCESFULD ONLINE OG OFFLINE MARKEDFØRING MED GAVEARTIKLER 17 METODER TIL SUCCESFULD ONLINE OG OFFLINE MARKEDFØRING MED GAVEARTIKLER Indholdsfortegnelse INTRODUKTION...3 ONLINE MARKEDSFØRING MED GAVEARTIKLER...4 Promovér din virksomheds hjemmeside...4 Konkurrencer...4

Læs mere

Facts om det danske mobilmarked II

Facts om det danske mobilmarked II Facts om det danske mobilmarked II Udviklingen på annoncemarkedet Konsulent Johan Winbladh, Danske Medier johanwinbladh@gmail.com - Tel: 21915612 74% af danskerne har en smartphone Smartphones står for

Læs mere

Professionel Udvælgelse i byggeriet Skabeloner

Professionel Udvælgelse i byggeriet Skabeloner Professionel Udvælgelse i byggeriet Skabeloner Vejledning i anvendelsen af skabeloner til brug for udvælgelse, herunder prækvalifikation i byggeriet Marts 2013 Byggeriets Evaluerings Center SOLIDARISK

Læs mere

DEN KOMPLETTE VÆRDIKÆDE MOBILITET SKABER VÆRDI FOR MOBILE MEDARBEJDERE

DEN KOMPLETTE VÆRDIKÆDE MOBILITET SKABER VÆRDI FOR MOBILE MEDARBEJDERE DEN KOMPLETTE VÆRDIKÆDE MOBILITET SKABER VÆRDI FOR MOBILE MEDARBEJDERE Læs mere på www.locus.dk LOCUS VÆRDI FOR MOBILE MEDARBEJDERE Locus makes mobility easy! Det er vores vision og leveregel. Vi leverer

Læs mere

TRIN TIL ØGET OMSÆTNING.

TRIN TIL ØGET OMSÆTNING. 3 TRIN TIL ØGET OMSÆTNING. Tlf. 70 268 264 info@relationwise.dk København - London - Stockholm Introduktion Loyalitets-guruen Frederick Reichheld beskriver, at loyale kunder er en fantastisk profit-generator,

Læs mere

strategi drejer sig om at udvælge de midler, processer og de handlinger, der gør det muligt at nå det kommunikationsmæssige mål. 2

strategi drejer sig om at udvælge de midler, processer og de handlinger, der gør det muligt at nå det kommunikationsmæssige mål. 2 KOMMUNIKATIONSSTRATEGIENS TEORETISKE FUNDAMENT I den litteratur, jeg har haft adgang til under tilblivelsen af denne publikation, har jeg ikke fundet nogen entydig definition på, hvad en kommunikationsstrategi

Læs mere

RAPPORT FRA KOMMISSIONEN TIL EUROPA-PARLAMENTET OG RÅDET

RAPPORT FRA KOMMISSIONEN TIL EUROPA-PARLAMENTET OG RÅDET EUROPA- KOMMISSIONEN Bruxelles, den 30.3.2015 COM(2015) 138 final RAPPORT FRA KOMMISSIONEN TIL EUROPA-PARLAMENTET OG RÅDET om udøvelse af de delegerede beføjelser, der tillægges Kommissionen i henhold

Læs mere

VEJLEDNING TIL ANSØGNINGSSKEMA ET NYT LIV MED TYPE 2 DIABETES. Ansøgningsfrist d. 7. oktober 2014 kl.12:00

VEJLEDNING TIL ANSØGNINGSSKEMA ET NYT LIV MED TYPE 2 DIABETES. Ansøgningsfrist d. 7. oktober 2014 kl.12:00 VEJLEDNING TIL ANSØGNINGSSKEMA ET NYT LIV MED TYPE 2 DIABETES Ansøgningsfrist d. 7. oktober 2014 kl.12:00 Indhold Introduktion... 3 Processen... 3 Betingelser... 3 OPI-projektets titel... 5 Varighed og

Læs mere

Industriel 3D måleteknik og digitalisering

Industriel 3D måleteknik og digitalisering Industriel 3D måleteknik og digitalisering Enestående service, professionelle teknikere og det bedste udstyr i verden gør Zebicon banebrydende indenfor industriel 3D scanning, 3D måling og digitalisering.

Læs mere

RÅDETS DIREKTIV 93/33/EØF af 14. juni 1993 om tyverisikring på to- og trehjulede motordrevne køretøjer. (EFT L 188 af 29.7.1993, s.

RÅDETS DIREKTIV 93/33/EØF af 14. juni 1993 om tyverisikring på to- og trehjulede motordrevne køretøjer. (EFT L 188 af 29.7.1993, s. 1993L0033 DA 11.05.1999 001.001 1 Dette dokument er et dokumentationsredskab, og institutionerne påtager sig intet ansvar herfor B RÅDETS DIREKTIV 93/33/EØF af 14. juni 1993 om tyverisikring på to- og

Læs mere

FULL SCREEN: CTR+L LUK FULL SCREEN: ESC

FULL SCREEN: CTR+L LUK FULL SCREEN: ESC Afstem forventningerne Vi ved det, og det er så simpelt. Lyt til din kunde og afstem forventningerne - og alligevel går det galt - kunden klager og er ikke tilfreds med den forventede kvalitet. Sådan kan

Læs mere

POLAR s3+ STRIDE SENSOR. Brugervejledning

POLAR s3+ STRIDE SENSOR. Brugervejledning POLAR s3+ STRIDE SENSOR Brugervejledning 1. 2. 3. 4. 5. DANSK Tillykke! Polar s3+ stride sensor TM W.I.N.D. er det bedste valg til at forbedre din løbeteknik og effektivitet. Brug af følsomme interti-sensorer

Læs mere