HAS Objets Connectes

valuation et amlioration
des pratiques
Rfrentiel de bonnes pratiques

sur les applications et
les objets connects en sant
(Mobile Health ou mHealth)
Octobre 2016
Ce document et les ressources complmentaires

sont tlchargeables sur : www.has-sante.fr
Haute Autorit de Sant
Service communication information
5, avenue du Stade de France F 93218 Saint-Denis La Plaine Cedex
Tl. : +33 (0)1 55 93 70 00 Fax : +33 (0)1 55 93 74 00
Ce document a t valid par le Collge de la Haute Autorit de sant en octobre 2016.

Haute Autorit de sant 2016.
Sommaire
Sommaire......................................................................................................................................3
Abrviations et acronymes........................................................................................................4
Prambule.....................................................................................................................................5
1. Contexte..................................................................................................................................7
1.1 Dfinitions et concepts : Applications, objets connects............................................................ 8
1.2 Classifications retrouves dans la littrature................................................................................. 8
1.3 valuation de la sant mobile dans diffrents pays...................................................................... 9
1.4 Mesure dimpact et/ou defficacit.................................................................................................. 11
1.5 Aspects juridiques de lvaluation des applications et objets connects en sant............... 11
2. Le rfrentiel de bonnes pratiques....................................................................................14

2.1 Les domaines valuer....................................................................................................................... 14
2.2 Modulation du primtre de lvaluation....................................................................................... 14
2.3 Domaine : informations utilisateurs................................................................................................ 16
2.4 Domaine : contenu de sant.............................................................................................................. 19
2.5 Domaine : contenant technique....................................................................................................... 26
2.6 Domaine : scurit/fiabilit................................................................................................................28
2.7 Domaine : utilisation/usage............................................................................................................... 37
3. Mise en uvre du rfrentiel de bonnes pratiques...................................................... 43

Annexe 1. Le Mobile App Rating Scale (MARS) (98, 99)..............................................................................................................................44
Annexe 2. Lvaluation par les pairs du Journal of Medical Internet Research JMIR -.....................................................................46
Annexe 3. Recherche documentaire ................................................................................................................................................................. 47
Annexe 4. Liste des tableaux..............................................................................................................................................................................50
Annexe 5. Glossaire .............................................................................................................................................................................................. 51
Annexe 6. Mthode de travail............................................................................................................................................................................53
Annexe 7. Participants..........................................................................................................................................................................................54
Rfrences...............................................................................................................................................................................................................56
Abrviations et acronymes
AFCDP
Association franaise de normalisation
AFNOR
Association franaise des correspondants la protection des donnes caractre personnel
ANSM
Agence nationale de scurit du mdicament et des produits de sant
ANSSI
Agence nationale de la scurit des systmes dinformations
Apps/OC
Applications mobiles/objet connect
ASIP-Sant
Agence des systmes dinformation partags de sant
CE
Marquage CE (conforme aux exigences)
CERT
Computer Emergency Response Team - galement appel CSIRT (Computer security incident response
team)
CERT-FR
Computer Emergency Response Team pour la France
CGU
Conditions gnrales dutilisation
CNIL
Commission nationale de linformatique et des liberts
CSRF
Cross-Site Request Forgery
DCP
Donnes caractre personnelles
DM
Dispositif mdical
EBIOS
Expression des besoins et identification des objectifs de scurit
ECR
Essai contrl randomis
ENISA
European Union Agency for Network and Information Security
EU
European Union
FAQ
Foire aux questions
GDPR
General Data Protection Regulation
HAS
Haute Autorit de Sant
HDS
Hbergeur de donnes de sant
HON
Health On the Net foundation
IMC
Indice de masse corporelle
IHM
Interface homme machine
ISO
International Organization for Standardization
kg
Kilogramme
mHealth
Mobile health (sant mobile)
OS
Operating System
OWASP
Open Web Application Security Project
PAS
Publically Available Specification
PDA
Personal Digital Assistant
RGI
Rfrentiel gnral dinteroprabilit
RGAA
Rfrentiel gnral daccessibilit pour les administrations
RGS
Rfrentiel gnral de scurit
SMS
Short Message Service
TIC
Technologies de linformation et de la communication pour lducation
TLS
Transport Layer Security
XSS
Cross-Site Scripting (parfois not CSS)
W3C
World Wide Web Consortium
4 | valuation et amlioration des pratiques Rfrentiel de bonnes pratiques sur les applications et les objets connects en sant
Prambule
Cette contribution de la HAS vise guider, promouvoir lusage et renforcer la confiance dans les applications
et les objets connects en sant en diffusant pour cela un rfrentiel de bonnes pratiques pour les industriels et
pour des valuateurs (structures dvaluation, associations de consommateurs ou socits savantes mdicales) qui
pourraient le mettre en uvre pour conduire leurs propres valuations.
Ce rfrentiel porte sur les applications et les objets connects nayant pas de finalit mdicale dclare. Il
concerne donc tout particulirement la zone dite grise des applications ou des objets connects ayant un effet
potientiel sur la sant sans tre un dispositif mdical. Les dispositifs mdicaux, au sens de la directive europenne
93/42/CEE qui entraine le marquage CE, en sont donc exclus.
Ce rfrentiel ne se substitue pas la loi ou la rglementation concernant les dispositifs mdicaux (au sens de la
directive europenne 93/42/CEE qui entraine le marquage CE), la protection des donnes personnelles et la protection
des consommateurs. Lapplication des bonnes pratiques dfinies dans le prsent rfrentiel sentend sans prjudice de
la rglementation en vigueur.
Ce rfrentiel de bonnes pratiques de la HAS ne constitue pas un outil dvaluation en vue de ladmission au
remboursement, ni une recommandation professionnelle.
La sant mobile offre de nouvelles possibilits pour amliorer la surveillance des maladies chroniques et permettre au patient
dtre plus acteur de sa prise en charge. Elle pourrait galement contribuer au dveloppement de la dimension prventive de
notre systme de sant. La recherche acadmique autour du big data en sant pourrait galement contribuer aux progrs de
la mdecine.
Dans ce contexte, la HAS a labor un rfrentiel de bonnes pratiques portant sur les applications et les objets connects
(Apps/OC) en sant.
Lvaluation des Apps de sant mobile et des objets connects fait intervenir de nombreux domaines de bonnes pratiques. La
Haute Autorit de Sant (HAS) est lgitime pour laborer un rfrentiel sur des champs correspondants ses missions, cest
dire :
lamlioration de la qualit des soins (intrt thrapeutique, organisation) ;
la qualit de linformation mdicale (exhaustivit, neutralit, exactitude et fracheur de linformation mdicale) ;
la scurit du patient (grad en niveau et types de risques en fonction de la destination dusage et du principal utilisateur
cible de lApps/OC considr) ;
lvaluation en sant (impact sur la sant publique) ;
la coordination des soins et linteroprabilit qui en dcoule (structuration de linformation) ;
le rapport cot efficacit (efficience conomique).
En outre, deux champs complmentaires ne correspondant pas aux enjeux stratgiques de la HAS, mais intrinsquement
lis la thmatique, ont t tudis ; il sagit de la protection de la vie prive et de la cyberscurit. Ils sont en partie intgrs
dans ce rfrentiel grce aux contributions de lAgence nationale de la scurit des systmes d'information (ANSSI) et de la
Commission nationale de l'informatique et des liberts1 (CNIL).
Dautres domaines dvaluations plus techniques concernent galement la sant mobile, et ne sont pas traits par ce guide,
par exemple :
la tlcommunication2 sous langle technique et scurit de linformation3, de sa transmission ou du processus complet
li laccs, au stockage et la transmission de donnes de sant ;
lhbergement4 des donnes collectes (loi 4 mars 2004) ;
la scurit/fiabilit des donnes5 sous langle de traitement des donnes ou du signal et de la mtrologie ;
la fiabilit des algorithmes et des formules de calcul ;
etc.
Ce rfrentiel constitue une premire tape dans le processus dvaluation et de conception des Apps/OC dans le monde de
la sant mobile. Il est sujet voluer en fonction des volutions du secteur.
Ce rfrentiel sera complt de supports destination des utilisateurs (professionnels de sant et usagers) paratre
ultrieurement.
1. www.cnil.fr/linstitution/actualite/article/article/quantified-self-m-sante-le-corps-est-il-un-nouvel-objet-connecte/
2. www.wi6labs.com/blog/fr/2013/12/13/quelle-technologie-radio-pour-les-objets-connectes-premiere-partie/
3. esante.gouv.fr/sites/default/files/Guide_Pratique_Dispositif_Connecte.pdf
4. esante.gouv.fr/services/referentiels/securite/hebergement-faq
5. internetactu.blog.lemonde.fr/2015/03/07/les-applications-de-sante-en-questions/
valuation et amlioration des pratiques Rfrentiel de bonnes pratiques sur les applications et les objets connects en sant| 5
noter quau niveau europen, un guide de bonnes pratiques (propos par un livre vert publi en 20146) est attendu pour
20177, il viendra complter le code de conduite8 et les processus dinteroprabilit et de standardisation en cours9 du plan
dactions europen 2012-2020 pour la e-sant.
6. ec.europa.eu/digital-single-market/news/green-paper-mobile-health-mhealth
7. ec.europa.eu/digital-single-market/en/news/new-eu-working-group-aims-draft-guidelines-improve-mhealth-apps-data-quality
8. ec.europa.eu/digital-single-market/en/privacy-code-conduct-mobile-health-apps
9. ec.europa.eu/digital-single-market/en/interoperability-standardisation-connecting-ehealth-services
1. Contexte
Il existe une volution des rflexions sur lvaluation des technologies de linformation et de la communication (TIC) dans le
monde de la sant. Nous entrons dans une priode de mutation en passant dun modle dvaluation de logiciel gnraux
qui pouvaient accomplir plusieurs actions un modle dApplis (Apps) qui sont des petits programmes rpondant des
besoins spcifiques ou des besoins de niches volutifs trs rapidement (1).
Ce changement de paradigme de lvaluation ou de la rgulation/certification de programmes gnraux la notation de
petits programmes spcialiss pose la difficult doutils dvaluations adapts, spcifiques et flexibles dans le temps.
Ces petits programmes rpondent mieux aux besoins de terrain et cherchent tre plus pertinents. Ils offrent galement de
nouvelles perspectives en termes dactions de promotion/rgulation cibles sur des domaines forts enjeux de sant publique
et/ou mdico-conomique. Cest une diffrence notable compare la certification des sites Internet dont les enseignements
ne sont finalement que trs partiellement transposables la problmatique des Apps/OC en sant.
La convergence de diffrents concepts (TIC, big data, etc.) est lie lvolution rapide (2) des technologies utilises
(miniaturisation, smartphone, flux de donnes). Les premires utilisations efficaces en sant mobile auprs du patient sont
lenvoi de SMS pour aider les patients respecter leur prise mdicamenteuse [revue systmatique de Park (3)]. En 2014, le
dveloppement dApps volues pour remplir la mme fonction possde un agenda, un historique, un serveur de donnes,
etc. [revue systmatique de Bailey sur les Apps dans le cadre de prise en charge mdicamenteuse (4)].
Les questions de fiabilit et de scurit des Apps/OC se posent avec les dveloppements actuels :
Apps de fiche mdicale durgence (avec groupe sanguin, allergies, dons dorgane, etc.) accessible sur le smartphone de
lutilisateur en ouverture directe ;
conseil/avis donns lutilisateur par des Apps ou des objets connects au smartphone (de manire automatise par
algorithme ou auprs dun professionnel de sant) ;
utilisation des fonctions de golocalisation des smartphones pour orienter lutilisateur ;
collecte de donnes pour raliser des profils de pratique pour les professionnels de sant ;
etc.
Dans toutes ces situations, lutilisateur doit pouvoir bnficier de produits qui ne nuisent pas sa sant et qui lui apportent
un bnfice au moins quivalent par rapport ce qui existait auparavant.
Lvaluation de la qualit des Apps/OC en sant apparat ncessaire devant lhtrognit de ce qui est disponible sur un
march en plein essor.
Au niveau utilisateurs, les besoins dvaluation peuvent se formuler simplement :
pour le patient ou lutilisateur bien portant, est-ce que cet Apps/OC peut mtre utile pour ma sant et sur quels points par
rapport ce qui existait auparavant ?
pour le professionnel de sant, comment rpondre aux questions poses par le patient sur les Apps/OC quil utilise ? Quels
Apps/OC utiliser pour son exercice et recommander/prescrire ses patients ?
pour les associations de patients et les organismes professionnels, que faut-il slectionner/dvelopper/promouvoir pour sa
communaut ?
Au niveau des industriels en charge de la conception et du dveloppement, des questions plus spcifiques se posent :
comment garantir que les besoins des utilisateurs ont t pris en compte ?
est-ce que lApps/OC a t dvelopp en respectant la transparence, la qualit, la confidentialit et la scurit des
informations?
est-ce que les risques ou menaces ont t identifis, traits et surveills ?
De 2002 2012, lvaluation de la qualit des Apps/OC en sant mobile a volu dune valuation technologique vers une
valuation de limpact en Sant Publique. Les pathologies et problmes de sant les plus tudis sont : le diabte, lobsit,
la sant mentale, lusage du tabac, les maladies chroniques, etc. (5).
Mme si ladoption par les patients et les professionnels de sant est variable et des barrires ou des facteurs favorisants ont
t identifis (6), la notion de mdecine personnalise et de mesure de soi (quantified-self) est en train de se dvelopper. De
la Vega aborde la notion dvolution de prescription dApps/OC pour un patient spcifique ayant un problme spcifique (1).
Pour la Canadian Advanced Technology Alliance (7) 5 thmatiques sont dvelopper dans ce secteur :
sensibilisation et ducation ;
accs aux informations de sant personnelle ;
modles de remboursements pour les cliniciens ;
certification pour les Apps mobiles en sant ;
grer lcart entre innovation et adoption.
1.1 Dfinitions et concepts : Applications, objets connects

LOrganisation mondiale de la sant (8) dfinit les termes Mobile Health (mHealth) par : pratiques mdicales et de sant
publique supportes par des appareils mobiles, tels que les tlphones mobiles, les dispositifs de surveillance des patients,
les PDA et autres appareils sans fil.
Concernant les objets connects (9), aucune dfinition na t identifie spcifiquement. Ils sont dfinis dans ce document
comme des dispositifs connects lInternet pouvant collecter, stocker, traiter et diffuser des donnes ou pouvant accomplir
des actions spcifiques en fonction des informations reues.
Aungst (10) dfinie la typologie des Apps selon 4 types :
Application mobile : logiciel informatique qui fonctionne sur un appareil mobile et qui remplit une/des fonction(s) particulire(s).
Application mobile native : logiciel informatique qui est prinstall sur un appareil mobile (exemple : logiciel grant
lutilisation de la camra de lappareil mobile).
Application mobile tlchargeable : logiciel informatique qui nest pas prinstall sur un appareil mobile et requiert dtre
tlcharg au travers dune source externe (en gnral un magasin dApps mobiles).
Application web (Web-Based) : logiciel informatique qui se connecte un portail web sur Internet et qui adresse le flux sur
un appareil mobile. Ncessite une connexion Internet.
Lutilisation du terme App est recommande pour les publications scientifiques en langue anglaise (11). Une check-list
spcifique (mERA) pour valuer les articles du secteur est propos par Agarwal (12).
La sant mobile (mHealth) est comprise dans le domaine de la e-sant et se partage en partie avec les domaines de la
tlmdecine et du quantified-self (13).
1.2 Classifications retrouves dans la littrature

Diffrentes classifications sont dcrites dans la littrature. Nous en reprenons quelques-unes pour illustrer les orientations de
ce secteur.
Classification de Aungst (10)
Aungst propose une classification avec 4 domaines et 4 sous-domaines pour chacun deux :
Centr patient : promotion de la sant, communication auprs du patient, suivi de paramtres de sant, rappel de prise
mdicamenteuse ;
Centr praticien : dossier patient informatis et prescription lectronique, productivit, communication, calcul mdical ;
Rfrence : rfrence sur la maladie, rfrence clinique, rfrence mdicament, littrature mdicale ;
ducation : enseignement mdical gnral, enseignement mdical spcialis, enseignement mdical continu, enseignement
du patient.
Classification de Mosa (14)
Mosa structure les Apps par rapport lexercice mdical :
7 catgories pour les professionnels de sant : diagnostic de maladie, rfrences mdicamenteuses, calcul de paramtres
mdicaux, recherche de littrature scientifique, communication clinique, connexion avec le dossier patient, formation
mdicale. Une catgorie gnrale pour les autres ;
Apps de formations pour les tudiants ;
Apps patients : gestion de pathologies chroniques.
Classification de Yasini (15)
Yasini sappuie sur une enqute de terrain pour dlimiter 31 catgories (values sur 567 Apps sant en langue franaise
dont 218 pour les professionnels de sant et 352 pour le grand public).
Les catgories sont les suivantes : recommandation clinique, diffusion scientifique grand public, synthse de donnes mdicales,
informations mdicales, recherche dans une base de donnes (mdicament, image, nutrition, etc.), livres, communication
publique gnrale, communication entre professions de sant et institutions, communication entre public et professionnels
de sant, communication entre professions de sant, calculer ou interprter des donnes, vrification de donnes du dossier
du patient, systme daide la dcision, grer distance ou collecter des donnes, utiliser lobjet connect comme un outil
diagnostic ou de mesure, calculer les honoraires, soutien comptabilit, gestion dagenda, recherche demplois, soutien la
cotation/codage des actes, grer le stock de mdicaments, localiser un service de sant, interaction avec un tablissement de
sant/pharmacie/assurance, chercher des informations sur des professionnels de sant/tablissement, cas cliniques, serious
game, question denseignement.
Classification de Mobile World Capital & Agncia de Qualitat i Avaluaci Sanitries de Catalunya AquAS (16) :
Mobile World Capital (MWC) et lagence pour la qualit et lvaluation sanitaire de Catalogne (Agncia de Qualitat i Avaluaci
Sanitries de Catalunya AquAS) propose un cadre dvaluation avec une stratification de 5 niveaux de risque dans une
matrice de risque qui catgorise les interventions risques (de rfrences/guides suivre/monitoring/alerter ) et les
risques spcifiques lis aux personnes et malades.
Autres classifications :
Labrique (17) structure les Apps par rapport 12 types de fonctions qui peuvent tre gres par smartphone ;
Dans le cadre dApps dans un domaine spcifique (cancer), Bender (18) dcrit 8 catgories dApps dfinies (sensibilisation,
information sur la maladie et le traitement, leve de fond, dtection prcoce, promotion dune organisation, prise en charge
de la maladie, prvention, soutien entre pairs) ;
Yetisen (19) dfinit 3 catgories majeures afin daider la rgulation (mdecine prventive, et promotion de la sant ;
instruments portables de diagnostic et de monitoring ; gestion de donnes, formation mdicale, paiement mobile) ;
Hussain (20) recense les types dApps en sant et leurs valuations et proposent des pistes pour les patients, dveloppeurs,
agences, etc. ;
Cook (21) est un exemple de publication de synthse sur les Apps censes amliorer le diagnostic de mlanome. Peu de
critres sont discriminants, mais il propose de classifier les Apps en fonction des utilisateurs possibles (tous les patients,
patients haut-risque, tudiants).
1.3 valuation de la sant mobile dans diffrents pays

Diffrents organismes ont propos ou proposent des services de compilation, de lablisation ou de registre des Apps/OC en
sant. Une liste non exhaustive est prsente titre informatif (tableau 1).
Tableau 1. Compilation non exhaustive des sites valuant les Apps/OC en sant au niveau de diffrents pays (prsent
par ordre alphabtique)
Pays
Nom
Organisation/Prestataire
Allemagne
AppCheck10
ZTG Zentrum fr Telematik und Telemedizin GmbH
Allemagne
HealthOn
Sanawork
Espagne (Andalousie)
AppSaludable : Catlogo de aplicaciones

mviles de salud12
Agency of Healthcare Quality of Andalusia
tats-Unis
Zur Institute13
Zur Institute
tats-Unis
Eat right
Academy of Nutrition and Dietetics
tats-Unis
Happtique15
Greater New York Hospital Association

NB : Service suspendu
tats-Unis
iMedicalApps16
iprescribeapps.com17
iMedicalApps
tats-Unis
UF Diabetes Institute18
UF Diabetes Institute
France
AppScript
IMS health's
France
DMD sant20
DMD sant
France
GPM e-sant21
Groupe Pasteur Mutualit
France
Medappcare
Medappcare
France
Sanofidiabete
SANOFI & DMD sant
Pays-Bas
Royal Dutch Medical Association (KNMG)24
Medical App Checker
Royaume-Uni
UKs National Health Service (NHS) Apps

Library25
NHS
NB : Service suspendu
Royaume-Uni
myhealthapps.net26
Patient View
11
14
19
22
23
10. www.appcheck.de - 11. www.healthon.de -12. www.calidadappsalud.com/distintivo/catalogo/13. www.zurinstitute.com/mentalhealthapps_resources.html - 14. www.eatright.org/appreviews - 15. www.happtique.com/home - 16. www.imedicalapps.com/about - 17. iprescribeapps.com - 18. diabetes.ufl.edu/my-diabetes/diabetes-resources/
diabetes-apps - 19. www.imshealth.com - 20. www.dmd-sante.com - 21. www.gpm.fr/toutes-les-news.html?id=10093 - 22. www.medappcare.com/conseil-scientifique - 23.
www.sanofi-diabete.fr/Accueil/Menu/Guide-des-applications-diabete - 24. www.knmg.nl/over-knmg/contact/about-knmg.htm - 25. apps.nhs.uk/review-process/# - 26. myhealthapps.net/about
La plupart des plateformes dvaluation des Apps/OC utilisent une grille danalyse recoupant diffrents domaines et sappuient
sur une expertise de professionnels de sant, dutilisateurs et danalyse technique du risque ciblant la cyberscurit, la
protection des donnes personnelles, le respect juridique, etc. Les dispositifs mdicaux (DM) ne sont pas du ressort de ces
valuations. Ces systmes essayent dvaluer la zone grise des Apps/OC nayant pas de finalit mdicale dclare.
1.3.1 Systme dvaluation mis en place un niveau rgional ou national

LOrganisation mondiale de la sant (OMS) a rdig les rsultats dune enqute sur la e-sant en Europe. Concernant la sant
mobile, 22 % (10 pays) disent mettre en place un systme pour valuer la qualit, la scurit et la fiabilit de la sant mobile (22).
Avec AppSaludable, lagence pour la qualit sanitaire dAndalousie propose depuis 2013 un catalogue dApps qui suivent les
31 recommandations tablies par lagence. En 2015, prs de 17 % de la population rgionale utilise au moins une de ces Apps.
Dun autre ct, Happtique ou NHS Choice ont soit cess soit suspendu leur activit de registre aprs des problmes de
scurit concernant des Apps rfrences sur leurs sites (23).
Au niveau international, il na pas t retrouv dapproches consensuelles sur la manire dvaluer les Apps mobiles ou les
objets connects qui ne sont pas dclars comme des dispositifs mdicaux (24-29).
Pourtant selon Canada Health Infoway, il existe plusieurs situations qui peuvent ncessiter une rgulation (2) notamment tout
ce qui peut influencer la dcision de lutilisateur ou du professionnel de sant dans le champ de la sant et du bien-tre (27,
30-35).
Le hub australien recensant les diffrentes approches dans diffrents pays en voie de dveloppement propose des exemples
pragmatiques dintgration dApps27 pour les pays en voie de dveloppement.
Au niveau europen, un groupe de travail de la commission europenne rdige un guide de bonnes pratiques pour garantir
la fiabilit et la scurit des Apps mobiles et des objets connects. Ce document est attendu pour dbut 201728. La HAS a
particip au groupe de travail et a apport les lments prsents dans ce guide.
1.3.2 chelles et scores dvaluation

Au niveau individuel, le score dvaluation retrouv le plus souvent dans la littrature est le score australien intitul score de
MARS (Mobile App Rating Scale). Ce score est utilis pour les publications valuant des Apps de sant. Une traduction non
valide est publie en annexe 1 pour information. Une liste non exhaustive des chelles et scores est prsente titre informatif
ci-dessous :
ABACUS29 (36) ;
Gonnermann (37) propose 3 niveaux : valuation globale (10 critres), contenu (6 critres), niveau tudi (lvaluation dpend
de la mthodologie et suit les recommandations de publication) ;
McMillan (38) propose 62 questions ;
Albrecht (39) propose une checklist de reporting ;
Salber (40) propose un guide pour les cliniciens avec 6 critres pragmatiques :
valuer si vos patients ont dj utilis des Apps mdicales, des dispositifs mdicaux sans fils, ou tout autres outils de
sant numriques,
connatre les types dinformations que vos patients obtiennent de leurs technologies de sant numriques et ce quils
en font,
comprendre si lApp ou lobjet ou le programme est sre et sil fournit des informations prcises ;
essayer lApps/OC vous-mme,
valuer si vous et votre patient voyez que lApp ou lobjet connect sont des moyens damliorer la communication et la
relation mdecin/patient ou pas,
dterminer si lApp entre dans votre flux de travail ;
Murfin (41) propose le modle KYA (Know Your Apps) : aller la source, sponsors, rfrences, valuation du protocole,
mises jour ;
Chan (42) propose une valuation dans le domaine de la sant mentale :
dimension utilit (4 critres),
dimension utilisation (5 critres),
dimension intgration/infrastructure (5 critres),
et catgories ;
Huckvale (43) propose une valuation pour les Apps concernant lasthme. Cest une adaptation des recommandations et
des 8 principes de HON ;
Safavi (44) propose une liste de 10 principes et 9 checklists pour permettre aux dveloppeurs de protger la confidentialit
des donnes.
27. www.uq.edu.au/hishub/wp25
28. ec.europa.eu/digital-single-market/en/news/new-eu-working-group-aims-draft-guidelines-improve-mhealth-apps-data-quality
29. libguides.library.arizona.edu/c.php?g=122854&p=802639
Pour le grand public ou les patients, lAmerican Health Information Management Association (AHIMA) propose un outil grand
public : just think APP 30. Lacronyme signifie A pour avis et PP pour les donnes personnelles et prives. Le document
value et liste des questions se poser ou des conseils raliser.
1.4 Mesure dimpact et/ou defficacit

Le dveloppement des Apps/OC en sant date de moins dune dizaine dannes ce qui explique que les publications de
mesure dimpact ou de mesure de taille deffet thrapeutique soient encore limites.
1.4.1 Revue systmatique sur la sant mobile

Payne (45) a ralis une valuation des principaux domaines o se dploient des Apps dans une revue systmatique. Les
Apps visant un changement de comportement (alimentaire, addictions, etc.), la promotion de lactivit physique ou le suivi des
problmes dpressifs sont le plus frquemment tudis. Au niveau mthodologique, les effectifs sont le plus souvent infrieurs
100. Des effets sont retrouvs dans tous les domaines tudis. Des tudes de plus grande puissance sont attendues.
Free (46) a ralis une mta-analyse sur lamlioration des soins avec un mme niveau de rsultats modestes. Hamine (47) a
montr une adhrence leve pour les maladies chroniques.
La recherche documentaire na pas cherch localiser les tudes de cots spcifiquement, car ce ntait pas lobjet du travail
demand. Il existe des publications sur le sujet qui montre une tendance une rduction des cots de sant (48-50). Une
analyse plus complte serait mener spcifiquement sur le thme du bnfice cot/efficacit.
1.4.2 Quelques rsultats sur des problmes de sant

Une slection non exhaustive de publications ciblant lefficacit des Apps/OC en sant dans le cadre de diffrents problmes
de sant est expose afin de donner un aperu du type de publications actuelles sur des sujets cibls. Le type dApps/OC
figurant dans ces tudes est htrogne (certaines sont des dispositifs mdicaux, dautres pas).
XX
Diabtes
Russell-Minda (51) a ralis une revue systmatique sur le diabte et les objets connects pour mesurer la glycmie et lactivit
physique. Les rsultats montrent une meilleure gestion de la glycmie et une amlioration de la prise en charge.
Des rsultats positifs sont aussi retrouvs dans une mta-analyse chinoise de Liang (meilleur contrle de la glycmie) (52) et
dans une revue systmatique de Holtz (53).
Gray (54) dans une revue systmatique recommande lvaluation et la validation externe des risques. Il insiste sur leffort de
pdagogie et dducation la sant spcifique raliser dans ce domaine.
XX
Activits physiques et obsit
Liu (55) a ralis une mta-analyse sur limpact des Apps sur lactivit physique et la rduction de poids. LIMC et le poids
(1,44 kg avec un IC95 % : 2,12 0,76) sont amliors.
Dautres tudes (56, 57) mettent en avant lintrt des Apps dans ce domaine ou dans le cadre de recommandation dans le
champ de lobsit pdiatrique (58).
Bort-Roig (59) dans une revue systmatique met en avant les Apps/OC qui ont le meilleur impact : dfinir des profils dactivits
physiques, mise en place dobjectifs, feedback en temps rel, rseau de soutien, consultation dexperts en ligne. Ce travail
complte une tude antrieure de Fanning (60) sur les critres de qualit des Apps/OC efficaces dans ce domaine.
XX
Asthme
Une revue systmatique de la Cochrane de 2013 sur lasthme (61) na pas permis de conclure sur lintrt des Apps/OC dans
ce domaine car les tudes sont peu nombreuses et htrognes.
Huckvale en 2015 (62) montre une volution de la qualit des applis dans lasthme en comparant 2011 2013, ce qui tend
dmontrer que le secteur volue sur des cycles courts.
1.5 Aspects juridiques de lvaluation des applications et objets connects en sant

La conception et lexploitation des objets connects dans le monde de la sant mobile doit se conformer aux cadres juridiques
(national et europen) existants notamment en matire de dispositifs mdicaux, d'change d'informations et de traitement des
donnes de sant caractre personnel.
30. myphr.com/HealthLiteracy/MX7644_myPHRbrochure.final7-3-13.pdf
1.5.1 Respect des dispositions lgales et rglementaires relatives aux dispositifs mdicaux
Certaines Apps/OC en sant sont susceptibles dtre qualifis de dispositif mdical (DM).
Le DM est dfini larticle L. 5211-1 du code de la sant publique comme tout instrument, appareil, quipement, matire,
produit, l'exception des produits d'origine humaine, ou autre article utilis seul ou en association, y compris les accessoires
et logiciels ncessaires au bon fonctionnement de celui-ci, destin par le fabricant tre utilis chez l'homme des fins
mdicales et dont l'action principale voulue n'est pas obtenue par des moyens pharmacologiques ou immunologiques ni par
mtabolisme, mais dont la fonction peut tre assiste par de tels moyens. Constitue galement un dispositif mdical le logiciel
destin par le fabricant tre utilis spcifiquement des fins diagnostiques ou thrapeutiques .
Lagence nationale de scurit du mdicament et des produits de sant (ANSM), autorit comptente en matire de DM
notamment pour la surveillance du march et la vigilance de ces produits, propose sur son site Internet31 des lments
dapprciation aidant dterminer si une App en sant relve du statut du DM ou non au regard de sa finalit.
Elle indique notamment les consquences ainsi que la marche suivre pour commercialiser les Apps qualifies de DM
(marquage CE, ralisation dune analyse de risque et constitution de documentation technique, etc.)32.
1.5.2 Respect des dispositions lgales et rglementaires relatives au partage dinformations et aux
traitements de donnes caractre personnel
Les dispositions relatives la collecte et au traitement de donnes sappliquent ds lors que les donnes traites par lApps/
OC sont relatives une personne physique identifie ou qui peut tre identifie, directement ou indirectement33.
Les principes suivants doivent notamment tre respects en cas de traitements de donnes caractre personnel :
le principe de finalit : avant toute collecte et utilisation de donnes personnelles, le responsable de traitement doit
prcisment annoncer aux personnes concernes ce quoi elles vont lui servir ;
le principe de la pertinence des donnes : seules les donnes strictement ncessaires la ralisation de lobjectif peuvent
tre collectes. Cest le principe de minimisation de la collecte. Le responsable de traitement ne doit donc pas collecter plus
de donnes que ce dont il a vraiment besoin. Il doit galement faire attention au caractre sensible de certaines donnes ;
le principe dune dure limite de conservation des informations : galement appel droit loubli : une fois que lobjectif
poursuivi par la collecte des donnes est atteint, il ny a plus lieu de les conserver et elles doivent tre supprimes. Cette
dure de conservation doit tre dfinie au pralable par le responsable du traitement, en tenant compte des ventuelles
obligations conserver certaines donnes ;
le principe de scurit et de confidentialit des donnes : le responsable de traitement doit prendre toutes les mesures
ncessaires pour garantir la scurit des donnes quil a collectes mais aussi leur confidentialit, c'est--dire sassurer que
seules les personnes autorises y accdent. Ces mesures pourront tre dtermines en fonction des risques pesant sur ce
fichier (sensibilit des donnes, objectif du traitement, etc.) ;
le principe du respect des droits des personnes : des donnes concernant des personnes peuvent tre collectes la
condition essentielle quelles aient t informes de cette opration. Ces personnes disposent galement de certains droits
quelles peuvent exercer auprs de lorganisme qui dtient ces donnes la concernant : un droit daccder ces donnes,
un droit de les rectifier, un droit de sopposer leur utilisation ; un droit loubli (effacement des donnes personnelles), un
droit la portabilit des donnes qui permet la personne concerne de transmettre facilement ses donnes un autre
responsable de traitement, le droit dtre inform en cas de piratage de ses donnes ;
les donnes de sant34, particulirement sensibles font lobjet dun encadrement renforc.
Par ailleurs, les Apps/OC prvoyant lchange ou le partage dinformations doivent garantir la scurit des donnes.
En outre, le partage ou change de donnes de sant dune personne implique son consentement exprs recueilli pralablement
sa mise en uvre. Ce consentement doit pouvoir tre modifi ou retir tout moment.
La CNIL, autorit charge de veiller la protection des donnes personnelles, accompagne les professionnels dans leur mise
en conformit avec la loi et propose de nombreux guides quant la collecte et lutilisation des donnes caractre personnel
notamment par les professionnels de sant35.
31. ansm.sante.fr/Produits-de-sante/Dispositifs-medicaux
32. ansm.sante.fr/Activites/Mise-sur-le-marche-des-dispositifs-medicaux-et-dispositifs-medicaux-de-diagnostic-in-vitro-DM-DMIA-DMDIV/Logiciels-et-applications-mobiles-en-sante/%28offset%29/1
33. Loi n 78-17 du 6 janvier 1978 relative l'informatique, aux fichiers et aux liberts ; - Rglement (UE) 2016/679 du Parlement europen du 27 avril 2016 relatif la protection
des personnes physiques l'gard du traitement des donnes caractre personnel et la libre circulation de ces donnes, et abrogeant la directive 95/46/CE (ce rglement
sappliquera tous les tats membres de lUnion europenne compter du 25 mai 2018 sans quil soit ncessaire de le transposer).
34. Les donnes concernant la sant sont dfinies par le rglement europen du 27 avril 2016 comme les donnes caractre personnel relatives la sant physique ou mentale
dune personne physique, y compris la prestation de services de soins de sant, qui rvlent des informations sur ltat de sant de cette personne .
35. www.cnil.fr
1.5.3 Respect des dispositions relatives lhbergement de donnes de sant caractre personnel
Les Apps/OC qui ncessitent lhbergement de donnes de sant caractre personnel pour le compte de personnes
physiques ou morales l'origine de la production ou du recueil desdites donnes ou pour le compte du patient lui-mme,
doivent respecter larticle L. 1111-8 du Code de la sant publique.
LAgence des systmes dinformation partags de sant (ASIP) qui a notamment pour mission de dvelopper une offre de
produits et de services qui permettent de structurer la e-sant, publie des guides et informations sur ces questions sur son
site Internet36.
36. esante.gouv.fr
2. Le rfrentiel de bonnes pratiques

Le rfrentiel de bonnes pratiques sur les Apps/OC en Sant a t construit en plusieurs tapes : analyse de la littrature,
groupe de travail indpendant, groupe de lecture et sollicitation de parties prenantes. Une note de cadrage explicite lorigine
et les modalits de ralisation de ce document.
2.1 Les domaines valuer

Une revue de littrature importante a t ralise par Riezebos (63) en 2014. Il cite diffrents auteurs ayant cherchs valuer
les Apps/OC en sant. Un systme dvaluation par ses pairs produit par un journal en ligne (annexe 2) a t construit partir
de cette analyse de la littrature37. Son tableau de synthse des diffrents auteurs a t utilis pour recenser lensemble des
critres dcrits dans la littrature pour valuer la sant mobile.
partir de ce document, le groupe de travail a retenu les critres pertinents et les a structurs par domaines et sousdomaines. Un total de 5 domaines et 14 sous-domaines a t retenu pour le rfrentiel de bonnes pratiques de ce document.
Liste des 5 domaines et 14 sous-domaines dvaluation du rfrentiel de bonnes pratiques :
Informations utilisateurs
Description
Consentement
Contenu de sant
Conception de contenu initial
Standardisation
Contenu gnr
Contenu interprt
Contenant technique
Conception technique
Flux des donnes
Scurit/Fiabilit
Cyberscurit
Fiabilit
Confidentialit
Utilisation/usage
Utilisation/design
Acceptabilit
Intgration/import
Pour chacun de ces domaines et sous-domaines des critres dvaluation ont t assembls partir de ceux proposs
par Riezebos (63) et ceux suggrs par le groupe de travail ou les experts externes. Ils sont dcrits, justifis et encadrs
dexemples concrets.
2.2 Modulation du primtre de lvaluation

Les niveaux de risque des Apps/OC sont diffrents. Lewis (64) dfinit diffrents types de risques pour mieux les valuer. Cette
approche entrane diffrents scnarios dvaluation.
Ce constat implique quil ne parat pas envisageable de produire un seul rfrentiel qui pourrait rpondre la varit des Apps/
OC et leurs diffrents niveaux de risque.
Une solution propose est de mettre en place une pondration qui permettrait de sadapter au niveau dexigence escompt
pour lApps/OC valuer.
Une matrice de risque (Tableau 2) a t construite pour permettre de moduler la liste des critres du rfrentiel. La pondration
est fonction du principal utilisateur et de la principale destination dusage dclare de lApps/OC.
Le niveau dexigence vert correspond au niveau dexigence le plus bas et le niveau rouge correspond au niveau le plus
lev. Le niveau jaune tant intermdiaire.
37. tinyurl.com/appsform
PRINCIPAL
UTILISATEUR CIBLE
Tableau 2. Modulation du rfrentiel par une matrice de risque

Professionnels de sant dans sa
relation avec ses pairs (travail en
quipe, en rseau, etc.)
Professionnels de sant dans sa
relation directe avec les patients
Patient, aidants, entourage,
associations de patients, etc.
Grand public
Information,
recommandations
gnrales
Prvention primaire,
promotion de la sant,
saisie manuelle et
acquisition de donnes
sans analyse
Prvention secondaire
et tertiaire,
accompagnement
personnalis, soins de
support.
Analyse de donnes/
valuation mdicale
contribuant au : bilan,
diagnostic, suivi tout au
long du parcours patients.
ducation
thrapeutique
du patient (ETP)
Impact sur la
thrapeutique
PRINCIPALE DESTINATION DUSAGE

Niveau de criticit faible
Niveau de criticit modr
Niveau de criticit lev
Un produit ayant un impact sur la thrapeutique doit systmatiquement tre scuris quelle que soit sa cible. Par ailleurs et
mme si la matrice ne linterdit pas, ce type de produit ne devrait a priori pas sadresser au grand public.
2.2.1 Description des lignes et colonnes de la matrice de risque

Laxe principal utilisateur est divis en 4 catgories : le grand public, les patients et aidants, le professionnel de sant en
relation directe avec le patient et les professionnels de sant entre pairs.
Sur cet axe, le niveau dexigence le plus lev cible les professionnels de sant car les dcisions sont susceptibles de
sadresser un grand nombre de patients. Les produits doivent tre davantage scuriss.
Laxe principale destination dusage est divis en 4 catgories : informations/recommandations, prvention primaire,
prvention secondaire et ducation thrapeutique du patient, enfin, analyse de donnes et impact sur la thrapeutique.
Sur cet axe, le niveau dexigence le plus lev cible lanalyse des donnes ayant un impact sur le bilan et le diagnostic de
lutilisateur et limpact sur la thrapeutique par rapport une information gnrale.
La pondration ainsi propose na pas pour but de dgrader la qualit de lvaluation. Elle permet daider slectionner les
critres dvaluations et le niveau de suret adapts lutilisation du produit.
XX
Exemple arbitraire A : Appli monpillulier
Une App de gestion de prise de mdicaments par le patient aurait un niveau dexigence considr comme lev. Tous les
critres (sauf ceux qui ne sont pas adapts) seront utiliser pour lvaluation.
XX
Exemple arbitraire B : Appli monasthme
Une App dinformation aurait un niveau dexigence considr comme plus faible. Une slection restreinte de critres sera
effectue.
noter que, quel que soit le niveau de pondration, certains critres sont incontournables pour prserver la qualit du produit.
Cela concerne tout particulirement les critres dits obligatoires , fonds sur la rglementation.
2.2.2 Niveaux des critres

Ce rfrentiel est un guide de bonnes pratiques. Il est construit dans le but damliorer la qualit des Apps/OC disponibles
sur le march. Mis part, les critres sappuyant sur les dispositions lgales et rglementaires qui sont obligatoires, les
critres retenus dans le rfrentiel sont considrs comme souhaits ou recommands en fonction de la pondration
prcdente. Ainsi, selon le niveau dexigence attendu, un mme critre dvaluation, sil nest pas obligatoire, pourra tre soit
souhait soit recommand ce qui permet au rfrentiel de sadapter en fonction du type dApps/OC valuer.
Des exemples concrets permettent dillustrer les critres de lensemble du rfrentiel.
2.2.3 Mode de slection et de pondration des critres du rfrentiel

En pratique, la slection des critres dvaluation du rfrentiel suivrait les tapes suivantes :
dtermination de lutilisateur cible principal (normalement dfini par le concepteur ou le fabricant) ;
dtermination de lusage principal de lApps/OC (normalement dfini par le concepteur ou le fabricant) ;
position sur la matrice de risque pour slectionner le niveau dexigence en fonction des 2 rponses prcdentes
(exemple: site dinformations gnrales destination des patients correspond au niveau vert) ;
slection des critres de chaque domaine et sous-domaine en fonction du niveau dexigence/de criticit (utilisation du
tableur fournit avec ce document ou du tableau rcapitulatif de chaque domaine du chapitre suivant) ;
exclusion des critres qui ne sont pas adapts car ne correspondant pas aux spcificits de lApps/OC (exemple : les
critres correspondants la fiabilit de la collecte de mesure ne sont pas utilisables pour valuer une App dinformation en
sant) ;
valuation des critres obligatoires des 5 domaines dvaluations. En cas de non-respect rglementaire ou lgal,
lvaluation est arrte ce stade. Il est rappel que ce rfrentiel ne se substitue pas la rglementation relative aux
dispositifs mdicaux et la conformit juridique attendue ;
valuation des critres recommands et souhaits . Certains critres ncessitent la mise en place dune analyse de
risque qui ne pourra pas tre conduite sans un soutien de personnes comptentes ;
compilation des rsultats de lvaluation des critres et synthse (ventuellement prconisation spcifique damlioration).
Il est rappel une nouvelle fois que ce rfrentiel ne se substitue pas au cadre juridique relatif aux dispositifs mdicaux et
la conformit juridique attendue. Ce rfrentiel na, par ailleurs, pas vocation lister de manire exhaustive lensemble des
dispositions lgales et rglementaires applicables aux applications et objets connects en sant.
La liste des critres est dcrite dans les chapitres suivants.
2.3 Domaine : informations utilisateurs

Le domaine de linformation utilisateur (tableau 3) est le premier domaine valuer avant de poursuivre lvaluation.
Tableau 3. Liste des critres se rapportant aux informations utilisateurs
SOUS-DOMAINES
Faible
Modre
leve
Dnomination du produit
Dfinition du produit
(version et environnement)
Prix et facturation ventuelle dabonnement

ou de services intra-App
Sources de financement
valuation
Crdits auteurs
Contacts (diteur)
Description
Recommand
NIVEAU DEXIGENCE
POUR LES APPS/OC DE CRITICIT
INTITULS
Obligatoire
SOUS-DOMAINES
INTITULS
Faible
Modre
leve
Formalits juridiques
Obligation dinformation
Consentement dutilisation des donnes

obligatoirement recueilli (indpendant
des conditions gnrales dutilisation)
Consentement rvisable et
accessible tout moment
Rectification et suppression tout moment
Consentement
Recommand
NIVEAU DEXIGENCE
Obligatoire
2.3.1 Sous-domaine : description

XX
Dnomination du produit
La dnomination exacte du produit38 est-elle dcrite prcisment sur les supports de promotion et les magasins en ligne ?
Justification : la dnomination doit permettre dviter toute confusion avec des noms similaires. Des fausses Apps existent
dans diffrents secteurs et tentent dimiter une rfrence connue (recherche demplois, faux anti-virus, etc.). Lutilisateur doit
prter attention des tentatives de phishing par design ou par noms similaires ralises dans un but malveillant.
Exemple : la slection dans le magasin en ligne seffectue sans ambigut et lutilisateur peut re-couper les informations
concordantes.
XX
Dfinition du produit (version et environnement)
La version du produit (indices de version et de rvision, date de la version), la liste des modifications majeures (volutions et
corrections) prises en compte dans la version et lenvironnement dutilisation (OS, navigateurs Internet, plateforme, etc.) est-elle
accessible ?
Justification : les fonctionnalits des diffrentes versions peuvent diffrer. Lutilisateur doit pouvoir identifier la/les version(s) qui
correspond(ent) ses besoins. Il peut galement sagir de correction de scurit ou autre amlioration qui informent lutilisateur
que certaines anciennes versions ne doivent plus tre utilises pour diffrentes raisons (conflit inter-Apps, erreur de mesure,
etc.). De mme, lenvironnement dutilisation doit tre adapt au matriel de lutilisateur.
Exemple : lutilisateur est inform que des versions antrieures du produit ont pos des problmes ou des erreurs dans leur
fonctionnement afin dutiliser la version adapte et fiable correspondant ses besoins et au matriel sa disposition.
XX
Prix et facturation ventuelle dabonnement ou de services intra-App
Le prix, labonnement ou les achats ventuels de produits supplmentaires ou intgrs (achat intra-App) sont-ils affichs de
manire transparente et explicite pour lutilisateur ?
Justification : certains produits ncessitent un abonnement pour pouvoir tre utilis. Le modle conomique de certaines
Apps sappuie sur des achats intgrs dans lApp. La ou les fonction(s) de facturation/paiement intgrs sont transparentes,
explicites et consultables par tous.
Exemple : lutilisateur peut se retrouver li des contrats de longue dure (aprs un premier mois gratuit ) ou des cots
de fonctionnement non spcifi (accs au rseau mobile payant). Le prix rel dutilisation est explicite. Lutilisateur doit tre
inform de services supplmentaires disponibles dans lApp en surcot.
38. Dans la suite du document, le terme produit est utilis pour dsigner une application de sant mobile seule ou un objet connect interfac avec une application.
XX
Sources de financement
Les sources de financement et la provenance des fonds sont-elles documentes39 et consultables ?
Justification : la provenance du financement peut influer sur la prise des dcisions ou impacter la diffusion de contenu biais
pour maintenir ou promouvoir son activit au dpend de la fiabilit et de limpartialit exige par le produit. Les sources de
financement ne doivent pas influer sur la neutralit ou crdibilit du produit.
Exemple : une App proposant dinformer/dduquer le patient pour une maladie chronique peut orienter les options
thrapeutiques dans un sens conomiquement favorable au financeur. Les sources de financement doivent tre exposes.
XX
valuation
Le(s) type(s) et la nature dvaluation dj ralis(s) et jour est-il/sont-ils document(s) ?
Justification : les diffrents types et nature dvaluations (valuation externe, notation en ligne, audit de qualit, marquage CE,
etc.) sont disponibles et transparentes.
Exemple : le propritaire du produit pourrait manipuler les valuations ralises de manire promouvoir celui-ci de manire
abusive. Pour prvenir cela, le propritaire met disposition lensemble des valuations ralises en cours de validit de la
version jour de son produit.
XX
Crdits auteurs
Le nom et le rle des diffrents contributeurs et ventuellement les droits de copie utiliss (copyrights) sont-ils documents et
consultables par tous ?
Justification : les sources des informations doivent tre explicites pour connatre la part de chaque contributeur. Les droits de
copie40 (image, vidos, autres sources) doivent tre publis car un concepteur pourrait reprendre son compte une partie des
informations dun concurrent ou une iconographie ne lui appartenant pas.
Exemple : lorigine du contenu de lApp est prcise et permet de connatre les auteurs ayant contribus la conception du
produit ainsi que les crdits iconographiques.
XX
Contacts (diteur)
Les modalits de contacts incluant les dlais de rponses entre le demandeur et lditeur sont-elles documentes et
consultables ?
Justification : lutilisateur doit pouvoir se rfrer un responsable en cas de question(s) lie(s) lutilisation du produit en cas
dabsence de hotline. Une adresse physique et des modalits de contacts tlphonique ou numrique (e-mail, formulaire, etc.)
sont rendre disponible pour tous.
Exemple : une fonctionnalit de lApp nest pas active et lutilisateur a adress un e-mail au support depuis plusieurs jours
sans rponse malgr le fait que le dlai de rponse affich est de moins de 48h. Lditeur du produit met en place une
procdure damlioration du suivi des requtes techniques ou administratives des utilisateurs.
2.3.2 Sous-domaine : consentement

XX
Formalits juridiques
La finalit de traitement est-elle dtermine, explicite et lgitime ?
Les formalits ont-elles t ralises concernant le traitement de donnes personnelles et lhbergement de donnes de
sant?
Justification : les formalits pralables sont des obligations lgales.
Exemple : lApp a t dclare la CNIL et son hbergeur est agr hbergeurs agrs donnes de sant (HDS/HADS) ; une
tude des risques sur la vie prive a t ralise.
XX
Obligation dinformation
Lobligation dinformation suit-elle les principes de bonnes pratiques suivants ?
Pour les dveloppeurs :
politique de confidentialit explicite et facilement accessible ;
avant utilisation, consentement clair sur laccs des informations sensibles (exemple : golocalisation, liste de
contacts, calendrier, photos, vidos, etc.) tant que les plateformes et les systmes dexploitations nassurent pas cela
systmatiquement;
39. On entend par documenter la prsence dune trace formelle qui peut tre consulte sur demande.
40. www.legifrance.gouv.fr/affichCode.do?cidTexte=LEGITEXT000006069414
amliorer la communication et la coordination avec les socits publicitaires (comme les socits danalyses) ventuellement
utilises par les dveloppeurs, pour harmoniser les informations concernant la collecte de donnes ;
se rapprocher des standards qui peuvent tre mis en place par diffrentes organisations.
Cette obligation dinformation est-elle mise en uvre galement en cas de modification(s) des conditions gnrales dutilisation
(CGU) ?
Justification : certains produits peuvent avoir accs au contenu suivant du smartphone : e-mails, messagerie instantane,
liste dappels tlphoniques, carnet dadresses, enregistrement des ca-lendriers, rseaux sociaux, historiques de navigations,
photographies/films stocks, prfrences du systme, golocalisation, accs au microphone, aux camras, fichiers divers,
etc. Pour les dveloppeurs, le principe de Privacy by design est critique pour lensemble des donnes personnelles de
lutilisateur ; son non-respect peut mettre en cause la loyaut de lApp.
Le concepteur doit informer sur ces lments de manire explicite.
Exemple : une App demande laccs la golocalisation de lutilisateur sans prciser les dlais daccs ou lutilisation
simultane des appareils photographiques. Le concepteur du produit met en place une procdure damlioration de son
obligation dinformation.
XX
Consentement dutilisation des donnes obligatoirement recueilli (indpendant des CGU)
Le consentement dutilisation est-il explicite et en-dehors des conditions gnrales dutilisation ?
Avant utilisation, le consentement clair est-il recueilli sur laccs des informations sensibles (exemple : golocalisation,
liste de contacts, calendrier, photos, vidos, etc.) tant que les plateformes et les systmes dexploitations nassurent pas cela
systmatiquement ?
Cette obligation de recueil du consentement est-elle mise en uvre galement en cas de modification(s) des CGU ?
Justification : le consentement daccs aux donnes gnrales doit tre recueilli.
Le consentement daccs aux donnes spcifiques de son smartphone doit tre explicite.
Exemple : lutilisateur doit approuver une notification ou effectuer un rglage spcifique avant lutilisation de sa camra, de sa
golocalisation ou autre contenu de son smartphone.
XX
Consentement rvisable et accessible tout moment
Laffichage et la gestion du consentement par lutilisateur est-il disponible concernant la collecte et le traitement de ses
donnes?
Justification : lutilisateur a le droit de changer son consentement tout moment. Ce qui justifie galement une gestion
indpendante des conditions gnrales dutilisation (qui sont acceptes la premire utilisation uniquement).
Exemple : un lment de rglage est accessible pour modifier le consentement.
XX
Rectification et suppression tout moment
Le respect du droit des utilisateurs de corriger leurs donnes et/ou de les effacer est-il mis en uvre ?
Justification : lutilisateur a le droit de changer ses donnes ou de les effacer tout moment ce qui justifie galement que le
consentement soit donn indpendamment des conditions gnrales dutilisation (qui sont acceptes la premire utilisation
uniquement).
Exemple : un lment de rglage est accessible pour modifier ou effacer ses donnes personnelles.
2.4 Domaine : contenu de sant

Le domaine contenu de sant (tableau 4) est le domaine qui value la fiabilit des informations. Il aborde les notions de contenu
gnr par le produit ou de contenu interprt lorsquun algorithme ou un professionnel du secteur analyse et traite le contenu
gnr.
BinDhim (65) a publi une enqute montrant que 77 % des utilisateurs ne vrifient pas la crdibilit des informations.
Tableau 4. Liste des critres se rapportant au contenu de sant du produit

SOUS-DOMAINES
NIVEAU DEXIGENCE
INTITULS
Conception
du contenu initial
Standardisation
Faible
Modre
leve
Implication des utilisateurs (patients,

professionnels, personne spcifique)
Mthodologie dingnierie
des besoins utilisateurs
Organisation du service de linformation
Expertise des auteurs du contenu
Dclarations dintrts
Citation des sources cls

et rfrences bibliographiques
Actualisation des sources cls

et rfrences bibliographiques
Niveau de preuve
Description de la destination dusage
Langue du produit
Thsaurus-Glossaire
Interoprabilit : standards de smantique,

terminologies de rfrences
Prcision et reproductibilit des donnes
Granularit des donnes
Perte dinformations
(par agrgation, par compression, etc.)
Performance de la mesure
dans le contexte dutilisation
Possibilit de synchronisation des donnes
Souhait
Recommand
Obligatoire
SOUS-DOMAINES
INTITULS
Faible
Modre
leve
Pertinence des donnes collectes
Minimisation des donnes collectes
Nombre dinterfaces/
priphriques/applications
Pertinence des informations dans le contexte
Fils de discussions lectroniques
Assistance fonctionnelle, hotline
Types dalgorithmes
Interprtation humaine
dun contenu de sant
Interprtation automatise
dun contenu de sant
Contenu gnr
Contenu interprt
Souhait
NIVEAU DEXIGENCE
Recommand
Obligatoire
2.4.1 Sous-domaine : conception du contenu initial

XX
Implication des utilisateurs (patients, professionnels, personnes spcifiques)
Les principaux utilisateurs sont-ils impliqus dans les phases de spcification, de conception, de recette et de maintenance
(ajustements suite des volutions ou des corrections) ? Ce critre est-il document ?
Justification : la conception avec les diffrentes parties prenantes spcifie de manire transparente est un gage de qualit.
Exemple : une App dapprentissage de lavage des mains est ralise en collaboration avec des personnes ralisant des
formations sur le terrain.
XX
Mthodologie dingnierie des besoins utilisateurs
La mthodologie dingnierie des besoins utilisateurs (identification, dfinition, analyse/hirarchisation des besoins) est-elle
documente ?
Justification : lvaluation des besoins des utilisateurs permet damliorer les objectifs de conception du produit. Lutilisation
doutil ou de mthode de recueil, danalyse et de structuration des besoins contribue amliorer la pertinence du produit.
Cette valuation permet didentifier lutilisateur principal du produit. Ce critre est-il document ?
Exemples : les valuateurs externes ont accs la mthodologie utilise par le concepteur (grille danalyse, critoire, Living
Lab, etc.).
Pour en savoir plus :
Hilliard (66) a enqut pour connatre les besoins utilisateurs dans le cadre de mucoviscidose de ladulte. Jibb (67) a dvelopp
un algorithme pour la douleur lie au cancer. Cela a abouti la mise en place dun processus de conception dune App pour
cancer des adolescents. La motivation de lutilisateur est dvelopper (68, 69). Silow-Carroll (70) a enqut sur les besoins
des patients. Les rponses dpendent de lge et des besoins spcifiques.
XX
Organisation du service de linformation
La prsence dun comit de validation ou dune organisation grant la dlivrance dinformations est-elle mise en place ? Ce
critre est-il document ?
Justification : la rdaction et la gestion du contenu disponible dans le produit sappuie sur un comit de validation qui garantit
la qualit de linformation publie.
Exemple : une App diffusant des synthses de recommandations de bonnes pratiques destination des professionnels de
sant met en place un comit de lecture pour surveiller que la synthse respecte bien les recommandations originales.
XX
Expertise des auteurs du contenu
Des experts (professionnels de sant, ingnieurs, organismes professionnels, associations de patients ou consommateurs,
etc.) sont-ils impliqus dans lapport du contenu du produit ? Ce critre est-il document ?
Justification : le niveau dexpertise des auteurs du contenu du produit est un gage de qualit. La reconnaissance par ses pairs
ou ladossement des organismes ou associations professionnelles amliore la crdibilit du contenu produit.
Exemples : des professionnels de sant appuys par leur association professionnelle scientifique ont mis en place une
plateforme dinformations sur la conduite tenir en cas de crise dasthme. LApp cite le niveau dexpertise des experts
impliqus.
Une association de patients met en place une App dinformations et une FAQ pour les familles et les aidants des patients. Elle
fait appel une association professionnelle en relation avec la pathologie pour donner un avis externe sur le contenu de lApp.
XX
Dclarations dintrts
Les dclarations des liens dintrts, en rapport avec le produit, des diffrents contributeurs sont-ils consultables par tous ?
Justification : les dclarations des liens dintrts ventuels est un gage de transparence pour les utilisateurs et valuateurs
externes. Les liens dintrts peuvent entraner des biais qui pourraient remettre en cause la fiabilit du produit.
Exemple : les valuateurs externes ralisent des contrles par chantillonnage afin de vrifier la vracit de ces dclarations
ou les biais ventuels qui proviendraient de ces liens.
XX
Citation des sources cls et rfrences bibliographiques
Les sources cls et rfrences relatives des publications argumentant le contenu de lApps/OC sont-elles documentes et
peuvent-elles tre consultables par tous41 ?
Justification : dans le domaine de la sant, la citation des sources bibliographiques et dune slection objective des meilleures
donnes disponibles est un gage de qualit requis. Laccs la liste de rfrences doit tre consultable facilement.
Exemple : la citation peut seffectuer soit en intra-Apps, soit sur un site web ressources, soit par une documentation externe, etc.
XX
Actualisation des sources cls et rfrences bibliographiques
Le processus de veille et de mise jour des sources cls et des rfrences relatives des publications sont-ils documents ?
Justification : la veille bibliographique permet de mettre jour et dadapter ltat des connaissances traites par lApps/OC.
La date de la mise jour de linformation est citer.
Exemple : une alerte lie des bases de donnes et un suivi de sommaires de revues spcifiques est mis en place et date
pour une App dinformation traitant dune maladie rare.
XX
Niveau de preuve
Sil existe une valuation spcifique du produit et des niveaux de preuves, ces rfrences spcifiques sont-elles consultables
par tous ?
Justification : la HAS a produit des guides danalyse critique de la littrature, de gradation de niveaux de preuves ou de
mthodologie dvaluation42,43,44,45,46.
Certaines Apps/OC ont fait lobjet dessai contrl randomis (ECR) ou certains types dApps ont fait lobjet de revue
systmatique. Ces rfrences sont majeures et doivent tre accessibles pour justifier lintrt du produit.
Il y a aussi une rflexion sur des approches dvaluations alternatives pour la sant mobile telles que :
lintgration clinique (utilisation du produit) ;
le changement comportemental li lutilisation du produit ;
etc.
41. On entend par consultable par tous le fait que laccs linformation ne requiert pas ni lachat, ni linstallation de lappli.
42. www.has-sante.fr/portail/upload/docs/application/pdf/analiterat.pdf
43. www.has-sante.fr/portail/upload/docs/application/pdf/2013-06/etat_des_lieux_niveau_preuve_gradation.pdf
44. www.has-sante.fr/portail/upload/docs/application/forcedownload/2016-03/guide_methodologique_analyse_critique.pdf
45. www.has-sante.fr/portail/upload/docs/application/pdf/eval_interventions_ameliorer_pratiques_guide.pdf
46. www.has-sante.fr/portail/upload/docs/application/pdf/2011-11/guide_methodo_vf.pdf
Ces approches ne sont pas considres comme des niveaux de preuve et doivent sappuyer sur une mthodologie qualitative
rigoureuse pour tre cite. La recherche acadmique est en dveloppement sur ce secteur.
Exemple : une Apps/OC est utilise lors dun essai contrl randomis (ECR) dans le cadre dun programme de suivi et de
promotion de lactivit physique chez des personnes ges. Les rsultats de lECR ont mis en vidence une diminution des
chutes pour le groupe intervention. LApps/OC cite la publication dans ses rfrences et son rle comme outil de suivi.
noter que Kumar (71) a propos dadapter la mthodologie dvaluation pour la publication de la fiabilit des mesures ou
de lefficacit thrapeutique. Tomlinson (72) a projet lvolution mthodologique de lvaluation du secteur de la sant mobile
pour les prochaines annes. Whittaker (36) propose les diffrentes phases dvaluation mthodologiques (du focus group
ltude dimpact) pour valuer la qualit des Apps.
Bull (68) souhaite que les approches psychosociales et psychologiques soient mieux values.
Hussain (20) a expos les diffrentes approches actuellement publies pour valuer une App.
XX
Description de la destination dusage
La destination dusage principal (objectifs ou finalits) du produit fait-elle lobjet dune description prcise et consultable par tous?
Justification : cette dclaration est un lment important pour dfinir lusage qui sera fait du produit.
Si lusage dclar par le fabricant est un instrument, appareil, quipement ou encore un logiciel destin tre utilis chez
lhomme des fins, notamment, de diagnostic, de prvention, de contrle, de traitement, dattnuation dune maladie ou
dune blessure (directive 93/42/CEE relative aux dispositifs mdicaux) il est ligible pour tre un dispositif mdical. Le fabricant
devra se rapprocher de lAgence nationale de scurit du mdicament et des produits de sant (ANSM) et se conformer aux
dispositions lgales et rglementaires applicables47.
Si lusage dclar nest pas adapt, une requalification de la destination dusage est envisageable.
noter que dans certains cas, la destination dusage dclare peut masquer lintention de collecter dautres types de donnes
pour diffrentes fins (collecte de donnes, espionnage, golocalisation, etc.). Une attention particulire est porter pour
dtecter cette mauvaise pratique.
Exemple : une Apps/OC dont la destination dusage est de mesurer la frquence cardiaque de repos moyenne de lutilisateur
dans le cadre dune activit physique rgulire na pas vocation servir de rfrence pour la rhabilitation cardiaque.
Wolf (73) a valu des Apps/OC photographiant des mlanomes. Lutilisation sous supervision mdicale est plus efficace.
XX
Langue du produit
LApps/OC et sa documentation associe sont-elles disponibles dans la langue de lutilisateur ?
Justification : la traduction de lApps/OC ou le fait dutiliser une Apps/OC dans une autre langue que sa langue maternelle peut
entraner un risque de mauvaise interprtation des donnes par incomprhension, faux-amis ou une mauvaise traduction
des concepteurs dans leur processus de traduction.
Exemple : un concepteur a utilis un traducteur automatis pour la traduction du texte de son App. Un test de lecture par un
utilisateur montre que la traduction nest pas fiable. Le concepteur du produit met en place une procdure damlioration de
la traduction de son App pour ne citer que les langues rellement supportes.
XX
Thsaurus-Glossaire
LApps/OC sappuie-t-elle sur un thsaurus pour les termes prsents dans lApp ?
Justification : une liste de termes et leurs dfinitions permettent dviter toute ambigut et mauvaise interprtation de la part
de lutilisateur.
Exemple : une App a plac des liens vers un thesaurus pour les mots considrs comme critiques pour la comprhension
du texte.
2.4.2 Sous-domaine : standardisation

XX
Interoprabilit: standards de smantique, terminologies de rfrences
La smantique des flux dinformations est explicite et les terminologies utilises entre le professionnel de sant et le patient
sappuient-ils sur des standards (exemples : HL7, SNOMED, etc) ?
Justification : linteroprabilit est un enjeu important pour le traitement, la diffusion et la conservation des donnes. Lutilisation
de standard est promouvoir et fait lobjet dun travail europen48.
47. ansm.sante.fr/Produits-de-sante/Dispositifs-medicaux
48. ec.europa.eu/digital-single-market/en/interoperability-standardisation-connecting-ehealth-services
Exemple : le concepteur du produit met en place une stratgie dinter-oprabilit ds la conception du produit.
Pour en savoir plus : Interoprabilit des donnes (EU eHealth interoperability framework) est un des lments du livre vert de
la Commission europenne sur la e-sant (74).
XX
Prcision et reproductibilit des donnes
Le niveau de prcision des mesures (fidlit) par rapport un talon-or et le niveau de la reproductibilit des donnes sont-ils
documents et en adquation de la destination dusage du produit ?
Justification : si des mesures sont collectes, leurs caractristiques mtrologiques doivent tre transparentes pour en
connatre leurs niveaux de prcision et de fiabilit. Ce niveau de prcision est faire correspondre au niveau dutilisation
attendu du produit.
Ce domaine est critique car la fiabilit des donnes collectes peut varier entre les produits disponibles sur le march et les
usages attendus. Lutilisateur doit connatre le niveau de prcision et de reproductibilit des donnes mesures pour lusage
attendu.
Exemple : un produit quantifiant lactivit physique est talonn par rapport un talon-or et son niveau de prcision (ou sa
marge derreur) est cit par le fabricant.
XX
Granularit des donnes
Le plus petit niveau de donnes mesur est-il justifi en regard de la destination dusage du produit (rafraichissement, frquence
dchantillonnage, etc.) ?
Justification : le signal brut collect peut tre plus ou moins prcis en fonction des rglages et des capacits des capteurs.
Dans certaines situations, la perte de donnes lie une granularit trop faible peut entraner une mauvaise interprtation.
Exemple : le rglage de lacclromtre du capteur mis en place pour suivre la mobilit dun utilisateur nest pas adapt en
fonction de la taille de petits sujets. Le concepteur du produit met en place une procdure damlioration de la mesure.
XX
Perte dinformations (par agrgation, par compression, etc.)
Les modalits dagrgation, de lissage des donnes, de production des courbes, ou autres traitements sont-ils documents
et justifis en regard de la destination dusage du produit ?
Justification : il sagit, ici, dapprcier le risque ventuel de perte dinformations en relation son utilisation. Le traitement du
signal brut est effectu de manire adapte en fonction de lusage attendu du produit. Dans certaines situations, la perte de
donnes lie au lissage des donnes peut entraner une mauvaise interprtation.
Exemple : la mesure, par un objet connect, de la force produite par lutilisateur donne des rsultats de force maximale
instable car le lissage des donnes est trop important. Le concepteur du produit met en place une procdure damlioration
du traitement de son signal pour amliorer son produit.
XX
Performance de la mesure dans le contexte dutilisation
La performance de la mesure (robustesse contextuelle) dans le milieu ou le contexte dutilisation est-elle documente et
justifie en regard de la destination dusage du produit ?
Justification : la mesure effectue en situation relle peut diffrer par rapport aux mesures effectues en laboratoire.
La mesure de donnes de sant ou de bien-tre dans lenvironnement de lutilisateur doit tre de qualit.
Exemple : un capteur dactivit plac sur le poignet auprs dutilisateurs atteints dun syndrome extrapyramidal peut prsenter
des donnes errones dues aux tremblements de repos lis la maladie.
XX
Possibilit de synchronisation des donnes
La possibilit de synchroniser les donnes sur diffrents quipements est-elle prsente ? Le consentement pralable de
lutilisateur a-t-il t prvu ?
Justification : la sant mobile peut utiliser plusieurs supports : smartphone, tablettes, montres, etc. Les possibilits de
synchronisation sur plusieurs supports pour un mme utilisateur sont proposer par le fabricant.
Exemple : lutilisateur se connecte avec un identifiant et mot de passe sur sa tablette chez lui ou son smartphone en extrieur
pour suivre son activit physique.
2.4.3 Sous-domaine : contenu gnr

Notez bien que cette partie devrait intgrer galement les sous-domaines standardisation et cyberscurit (authentification
des utilisateurs, de lApp, intgrit et authenticit des donnes, etc.).
XX
Pertinence des donnes collectes
Le choix des donnes collectes est-il justifi en regard de la destination dusage du produit ?
Justification : le fabricant doit pouvoir justifier les lments utiliss pour son produit et viter toute drive de collecte en masse
ou dutilisation malveillante. Certains produits pouvant proposer un service et durant son utilisation collecter des donnes sans
lien avec le service propos (mais ayant une valeur commerciale par exemple).
Exemple : les valuateurs externes rechercheront ladquation entre lobjectif dclar et lutilisation relle.
XX
Minimisation des donnes collectes
Le choix des donnes collectes est-il conforme au principe de minimisation de donnes qui impose de ne collecter que les
donnes ncessaires la destination dusage du produit ?
Pour toutes les donnes collectes, linformation auprs de lutilisateur est-elle accessible et transparente ?
Justification : le principe de minimisation est conforme et expos de manire transparente pour lutilisateur afin quil soit
inform de manire objective sur lutilisation de ses donnes.
Exemple : une App de recherche prospective sur diffrents paramtres de qualit de vie de lutilisateur dcrit les donnes
relles collectes et la priode de collecte.
XX
Nombre dinterfaces/priphriques/applications
Le nombre dinterfaces/priphriques/applications avec lesquels dialogue lApps/OC est-il adapt aux ressources du terminal
et en relation avec la destination dusage du produit ? Pour toutes les donnes collectes, linformation auprs de lutilisateur
est-elle accessible et transparente ?
Justification : le nombre dinterfaces/priphriques/applications est expos de manire transparente pour lutilisateur afin
quil soit inform de manire objective sur lutilisation de ses donnes. LApps/OC utilise ce qui est strictement ncessaire la
destination dusage dclare afin dviter la collecte ou lutilisation abusive de donnes.
Exemple : une App de suivi alimentaire pour les utilisateurs utilise lappareil photographique du smartphone, une balance de
cuisine et un pse-personne connecte. Lutilisateur est inform des connexions avec les priphriques.
XX
Pertinence des informations dans le contexte
Le contenu correspond-il (utilit, intrt, etc.) aux besoins de lutilisateur dans la situation o il se trouve ?
Justification : lorsque du contenu est gnr lors de son utilisation, il doit tre adapt et utile lutilisateur.
Exemple : une App de suivi dactivit physique gnre des conseils ou des encouragements en fonction de lactivit ralise
par lutilisateur.
XX
Fil de discussion lectronique
Le fil de discussion est-il modr et rgi par une charte dutilisation dfinissant notamment les conditions dutilisation et le
comportement adopter ?
Justification : une charte dutilisation et une modration sont des moyens damliorer la qualit des fils de discussions. Ces
moyens permettent dviter la diffusion dinformations errones ou malveillantes. Les ventuels commentaires dsobligeants
dutilisateurs ne devront tre retirs dlibrment par le modrateur, que dans la limite du respect de la charte dutilisation et
de la rglementation.
Exemple : le concepteur met en place un fil de discussion sur laddiction dans le monde de la sant sur une App dducation
la sant. Il met en place le suivi de tous les commentaires par 2 modrateurs qui valident le contenu produit par les utilisateurs.
XX
Assistance fonctionnelle, hotline
Une hotline permettant de solliciter une demande dassistance est-elle mise la disposition des utilisateurs pour les
demandes relatives lutilisation du produit (comprhension des contenus et utilisation des fonctionnalits) ? Les questions
frquemment poses sont-elles documentes et peuvent tre consultes (FAQ, etc.) ?
Un processus qualit de collecte, dadressage, de suivi et de restitutions des retours utilisateurs peut tre document en
fonction de lobjet de lApps/OC.
Justification : un soutien lutilisation du produit permet damliorer la qualit dutilisation. Ce soutien peut prendre diffrentes
formes en fonction des objectifs du produit et de diffrents facteurs dutilisation (gestion de donnes, interface plusieurs
niveaux, etc.).
Exemple : une App pense-bte pour la prise de mdicaments propose une FAQ pour le rglage des alertes et notifications.
2.4.4 Sous-domaine : contenu interprt

XX
Types dalgorithmes
Les types dalgorithmes utiliss sont-ils cits afin que lutilisateur sache si lApps/OC utilise des algorithmes propritaires et/
ou des algorithmes ouverts ou reprenant des calculs ou des scores publis ?
Justification : le contenu gnr peut tre interprt par un algorithme propre au fabricant ou reprenant des quations de
calculs publis. Le(s) type(s) dalgorithme utilis(s) doi(ven)t tre transparent(s) pour lutilisateur.
Exemple : une App de normes de dosage biologiques destination des mdecins calcule les zones thrapeutiques utilisables.
Les normes sont lies une base de donnes identifies et les calculs suivent des quations rfrences dans lApp.
Albrecht (75) propose des lments de scurit dans le dveloppement des algorithmes.
Bierbrier (76) liste les Apps de calculs mdicaux les plus usuels et a valu la fiabilit des calculs. Six Apps sur 14 sont prcises
100 %. Les erreurs ne sont pas vitales mais il convient dvaluer les calculs et les fonctions de ces Apps de calculs.
Concernant la fiabilit des calculs, Chyjek (77) a valu des Apps mesurant des dates daccouchements. Plus de la moiti
proposaient des dates inexactes.
Huckvale (78) a valu les erreurs de calcul de glycmie plus de la moiti (8 en input et 5 en output).
XX
Interprtation humaine dun contenu de sant
En cas dinterprtation humaine (non automatise) de contenus vise de sant (donnes de sant, contenu scientifique, etc.),
celle-ci est-elle assure par des professionnels de sant qualifis ?
Justification : linterprtation de contenu scientifique ou de donnes de sant ncessite limplication de mdecins ou de
professionnels de sant selon les cas.
Exemples : un cardio-frquencemtre connect collecte des donnes dactivit physique dun utilisateur. Les informations
sont transmises un mdecin/cardiologue pour avis.
Une App dun journal club propose une revue de presse et une interprtation des donnes de la littrature. Les valuateurs
externes professionnels de sant du secteur sassurent de linterprtation ou de labsence de biais de slection des articles.
XX
Interprtation automatise dun contenu de sant
Les algorithmes ayant pour objet dinterprter des contenus vise de sant (donnes de sant, contenu scientifique, etc.)
sont-ils valus ? Le plan et les comptes rendus des tests sont-ils documents ?
Justification : linterprtation de contenu scientifique ou de donnes de sant ralise de manire automatique ncessite
dvaluer la fiabilit de linterprtation. La crdibilit des tests des algorithmes est un lment critique valuer pour garantir
cette fiabilit.
Ce critre est amen voluer dans les prochaines annes car le secteur de la sant mobile et le niveau technologique actuel
contribue au dveloppement des algorithmes.
Exemples : un cardio-frquencemtre connect collecte des donnes dactivit physique dun utilisateur. En fonction des
rsultats, un programme dentranement est propos de manire automatise lutilisateur. Les valuateurs externes devraient
valuer le niveau de risque de linterprtation en consultant la fiabilit des tests utiliss par le(s) concepteur(s).
Un multi-moteur de recherche darticles se propose de classer les meilleurs articles disponibles. Les valuateurs externes
pourraient effectuer diffrents tests cibls pour comparer la pertinence des rsultats obtenus ou les plans de test utiliss par
le(s) concepteur(s).
Une requte automatise est lance sur les bases de donnes scientifiques pour cibler des articles spcifiques dun domaine
particulier.
2.5 Domaine : contenant technique

Le domaine contenant technique (tableau 5, page suivante) est valu principalement par des valuateurs externes.
LUnion europenne souhaite le dveloppement dApps/OC dans lesquels lutilisateur peut avoir confiance (79).
2.5.1 Sous-domaine : conception technique

Le sous-domaine conception technique renvoie galement au sous-domaine de cyberscurit (utilisation sre dun code tiers
externe, etc.).
XX
Configuration et performances des quipements49
La configuration et les performances des quipements sont-elles documentes et sont-elles en adquation avec la destination
dusage du produit et de son utilisateur principal ?
Justification : la performance des quipements peut devenir un critre rdhibitoire si elle ne correspond pas aux niveaux de
lusage attendu du produit.
49. La notion dquipement renvoie tous les matriels faisant fonctionner lapplication (smartphone, ordiphone, tablette, etc.) ou objet connect.
Tableau 5. Liste des critres se rapportant au contenant technique du produit

SOUS-DOMAINES
INTITULS
Faible
Modre
leve
Configuration et performances
des quipements
Mthodologie de dveloppement logiciel
Suivi des mises jour
Interface avec un dossier

patient informatis50
Rtrocompatibilit
Import, export et rversibilit des donnes
Modle de donnes
Modalits dhbergement des donnes
Hbergement des donnes

et procdure de sauvegarde
Conception technique
Flux des donnes
Souhait
NIVEAU DEXIGENCE
Recommand
Obligatoire
Le niveau dquipement peut tre :

la dfinition et la taille de lcran dans le cas de lecture dimages/vidos51 ;
la qualit sonore dans le cas denregistrement ou de diffusion sonore ;
les caractristiques mtrologiques en fonction des capteurs et des donnes collecter ;
etc.
Exemple : une App propose de prendre des photos de mlanome pour que le patient les stocke et les prsente son
dermatologue. Cela ncessite un appareil photographique adapt et un traitement de limage fiable.
XX
Mthodologie de dveloppement logiciel
Un contrle qualit du dveloppement logiciel et lutilisation des frameworks est-il mis en place ?
Justification : la mthodologie de conception logicielle doit sappuyer sur des mthodes et une dmarche qualit explicites.
Exemple : quelques mthodes de dveloppement logiciel sont cits : agile, Scrum, Extreme Programming, UML, etc.
Les valuateurs externes devraient valuer la crdibilit de conception.
50. Linterface avec un dossier patient informatis nest pas une obligation lgale mais sa mise en uvre implique notamment le respect des dispositions relatives au partage de
donnes et au secret mdical.
51. www.knowtex.com/nav/prometee-un-living-lab-pour-faire-rimer-medecine-et-numerique_42225
XX
Suivi des mises jour
Lhistorique des versions incluant les modifications apportes (volutions et corrections) est-il document ?
Justification : une liste des versions et des modifications historiques apportes est maintenir jour pour tracer le
dveloppement du produit. Le niveau de qualit du dveloppement de lApp ncessite une transparence dans la conception
et son suivi de mise jour.
Exemple : les valuateurs externes pourront demander la liste de cet historique.
2.5.2 Sous-domaine : flux des donnes

XX
Interface avec le dossier informatis du patient
LApps/OC propose-t-elle une fonctionnalit dinterface avec un dossier patient informatis? Cette interface respecte-t-elle les
conditions lgales et rglementaires applicables au partage de donnes de sant ?
Justification : le dossier informatis du patient et son interconnexion avec lenvironnement du monde de la sant mobile est
un enjeu important. Le sujet du dossier du patient informatis est en dveloppement et sera amen voluer, il convient de
suivre les obligations rglementaires sur ce sujet.
Exemple : un pse-personne connect transmet lhistorique du poids de lutilisateur dans son dossier patient lectronique.
XX
Rtrocompatibilit
La compatibilit descendante (compatibilit dun produit vis--vis des anciennes versions) est-elle documente ?
Justification : si un produit a collect des donnes personnelles ou effectu des interactions avec lutilisateur, la continuit de
lutilisation des donnes est garantir au cours des diffrentes versions de lApps/OC.
Exemple : un capteur dactivit physique garantit la continuit des donnes recueillies entre les versions du produit auprs des
utilisateurs.
XX
Import, export et rversibilit des donnes
Les fonctionnalits dimport, dexport et de conversion des donnes dans des formats standards (rversibilit) sont-elles
documentes ?
Justification : si un produit a collect des donnes personnelles ou effectu des interactions avec lutilisateur, limport, lexport
et la conversion des donnes est garantir.
Exemple : un pse-personne connect propose un import/export de donnes dans diffrents standards compatibles.
XX
Modle de donnes
Le modle de donnes dcrivant la faon dont les donnes sont reprsentes et gres est-il document ?
Justification : lexpression modle de donnes est utilise pour expliquer comment sont gres les donnes (base de
donnes, reprsentations mathmatiques, etc.).
Exemple : les valuateurs externes pourront demander le type de modle de donnes utilis pour en valuer la pertinence.
XX
Modalits dhbergement des donnes
Les modalits dhbergement des donnes sont-elles documentes et conformes aux dispositions lgales et rglementaires?
Justification : les modalits dhbergement des donnes suivent des modalits rglementaires (recours un hbergeur agr
en cas dexternalisation de lhbergement de donnes de sant caractre personnel, scurit de lhbergeur, etc.). Pour les
autres situations non rglementes, les modalits dhbergements doivent tre transparentes.
Exemple : les valuateurs externes pourront demander le type dhbergement et valuer les risques encourus.
XX
Hbergement des donnes et procdure de sauvegarde
La procdure de sauvegarde dfinissant notamment la priodicit, le format, les zones de stockages et les mcanismes de
rcupration de ces sauvegardes est-elle documente et conforme aux dispositions lgales et rglementaires ?
Justification : la procdure de sauvegarde des donnes est une garantie de scurit maintenir. Pour les autres situations
non rglementes, les procdures de sauvegarde doivent tre transparentes.
Exemple : le fabricant communique aux utilisateurs les processus de sauvegarde quil utilise.
2.6 Domaine : scurit/fiabilit

Le domaine scurit/fiabilit (tableau 6, page suivante) porte principalement sur la cyberscurit, la fiabilit des informations et
les risques lis aux donnes personnelles. Les outils dvaluation de ces domaines peuvent tre des approches par analyse
de risque ou de menace . En fonction de la situation, il sera peut tre ncessaire de faire appel des valuateurs externes.
Tableau 6. Liste des critres se rapportant la scurit et fiabilit du produit

SOUS-DOMAINES
Cyberscurit
INTITULS
NIVEAU DEXIGENCE
Faible
Modre
leve
Analyse de la menace
Scurit dans le dveloppement
Scurit des fonctions cryptographiques
Mthodologie de protection/
vrification du code
Utilisation sre dun code tiers externe
Authentification des utilisateurs/des donnes
Authentification de lApps/OC
Intgrit et authenticit des donnes
Transfert/changes des donnes scurises
Partage et accs aux donnes

avec dautres Apps/OC
Stockage scuris des donnes sur le terminal
Stockage scuris des donnes

sur le(s) serveur(s) distant(s)
Inscurit et failles des services distants
Maintien en condition de scurit
Sensibilisation de lutilisateur, causes

potentielles de brche de confidentialit
valuation de la scurit
Signalement et transparence sur la violation

de donnes ou en cas dincident de scurit
SOUS-DOMAINES
INTITULS
Faible
Modre
leve
Fiabilit et maintenabilit hardware

(capteurs) et software
Disponibilit de linfrastructure
Assistance technique hotline
Qualit des matriaux,

innocuit des dispositifs
Optimisation des fichiers mdia
Contre-indications, risques
potentiels, limitations dusage
Niveau de disponibilit
Maintenance prventive
Fonctionnement vis--vis
des autres Apps/OC
Destinataire des donnes collectes,

confidentialit des donnes personnelles, et
consentement pour la transmission des tiers
Pseudonymisation des donnes
Anonymisation des donnes
Dlais de suppression et temps

de mise en uvre
Couverture assurance et juridique

concernant la perte de donnes
Fiabilit
Confidentialit
Souhait
NIVEAU DEXIGENCE
Recommand
Obligatoire
Notez que diffrents moteurs de recherche52,53,54 localisent et rpertorient les objets connects disponibles sur le web. Les
objets mal protgs peuvent ainsi, tre identifis et utiliss par des personnes malveillantes.
52. censys.io
53. www.shodan.io
54. thingful.net
2.6.1 Sous-domaine : cyberscurit

La satisfaction des exigences de scurit dun produit passe en premier lieu par la mise en uvre de fonctions de scurit
(chiffrement, authentification, vrification dintgrit, etc.) qui sont dtailles dans la suite de ce document.
Elle passe galement par le respect de principes de conception et par lemploi de mthodes visant limiter le risque
dintroduction de failles au cours du cycle de dveloppement et dexploitation de lApps/OC.
Le cadre juridique pour le stockage des donnes ou les lments de cyberscurit est sujette voluer rgulirement. Il
convient de suivre ces volutions pour rester conforme la rglementation.
XX
Analyse de la menace
Une analyse de la menace a-t-elle t entreprise sur lApps/OC ? La protection des donnes est-elle prise en compte par
construction et par dfaut dans la conception de lApps/OC?
Justification : une analyse de la menace doit tre mene sur lApps/OC pralablement sa mise en uvre. Cette analyse de
la menace doit permettre didentifier les biens sensibles manipuls par lApps/OC, et les fonctions de scurit permettant de
couvrir les menaces susceptibles de porter atteinte la confidentialit, lintgrit et la disponibilit des biens sensibles. Cette
analyse de la menace doit galement permettre dajuster le curseur de scurit au bon niveau .
Les notions de protection by design et by default dsignent des mesures de protection qui sont prises en compte dans les
spcifications mme dun produit logiciel et visant contrer une menace identifie.
Exemple : les valuateurs externes pourront demander si une analyse de la menace a t effectue (voir par exemple la
mthode EBIOS : Expression des besoins et identification des objectifs de scurit55). Les valuateurs externes pourront
demander si la conception de lApps/OC intgre (built-in) les fonctions dauthentification/ de pseudonymisation, de transfert et
de stockage scuris des donnes.
Martinez-Perez (80) propose des recommandations sur la scurit des donnes aprs une analyse de la littrature.
XX
Scurit dans le dveloppement
Les mthodes et outils utiliss dans les diffrentes tapes du cycle de dveloppement de lApps/OC pour prvenir et dtecter
des failles de scurit sont-ils documents ?
Justification : Les dveloppements sont susceptibles dintroduire des failles involontaires et doivent donc sappuyer sur des
outils et mthodes de conception scuriss. La scurit dans le dveloppement logiciel participe aux dispositions prises pour
amliorer la qualit globale dun produit de sant mobile.
Exemple : les valuateurs externes pourront demander les mthodes et outils de conception employs par les dveloppeurs.
XX
Scurit des fonctions cryptographiques
Les dveloppeurs ont-ils privilgi lutilisation de services et de primitives cryptographiques connus et prouvs (par exemple,
ceux proposs par le systme dexploitation de lappareil mobile) plutt que le redveloppement de fonctions analogues ?
Justification : le domaine ncessite de sappuyer sur des systmes robustes et reconnus. Le dveloppement de telles
fonctionnalits est particulirement difficile et requiert des comptences expertes.
Exemple : les valuateurs externes pourront demander le type de service cryptographique.
XX
Mthodologie de protection/vrification du code
Lintgrit du code fait-elle lobjet de procdure de protection et de vrification rgulire afin dviter que lApps/OC ne soit
dtourne de son utilisation normale et utilise par exemple comme outil despionnage du porteur du terminal ou pour viter
une altration malveillante de lintgrit du code et/ou des donnes?
Justification : les mesures de protection en intgrit sont aussi essentielles que celles relatives la confidentialit des donnes.
Exemple : les valuateurs externes pourront demander la mthodologie de protection.
XX
Utilisation sre dun code tiers externe
LApps/OC utilise-t-elle des codes tiers pour fonctionner ? Ces codes tiers ont-ils fait lobjet dune valuation visant estimer
leur scurit et leur robustesse ?
Justification : le concepteur faisant appel un code tiers externe assume la responsabilit de son utilisation dans son produit.
charge pour lui de maintenir un niveau de fiabilit, dabsence de collecte de donnes de marketing linsu de lutilisateur et
de scurit son utilisation.
Exemple : les valuateurs externes pourront valuer le processus de gestion des codes tiers externes. Les valuateurs
pourraient galement valuer la pertinence du modle conomique des Apps/OC tierces externes par rapport aux finalits
du produit.
55. www.ssi.gouv.fr/guide/ebios-2010-expression-des-besoins-et-identification-des-objectifs-de-securite
XX
Authentification des utilisateurs/des donnes
Les mcanismes dauthentification des utilisateurs vis--vis de lApps/OC ou des services distants sont-ils documents ?
Sont-ils compatibles des exigences danonymats des utilisateurs (par exemple, utilisation de pseudonymes de connexion non
relis lidentit de lutilisateur) ?
Justification : lorsque des changes de donnes ont lieu entre lApps/OC et des services distants, les mcanismes
dauthentification de lutilisateur utiliss sont prciser.
Exemple : les valuateurs externes valuent les risques dauthentification des utilisateurs en rapport aux documents fournis
par le fabricant.
XX
Authentification de lApps/OC
LApps/OC authentifie-t-elle les services distants avec lesquels elle change des donnes ? Cette authentification est-elle
rciproque ? Comment cette authentification est-elle mise en uvre ? Limpossibilit dauthentifier un serveur conduit-elle
une rupture de la communication et un avertissement de lutilisateur ? Existe-t-il un mcanisme dattestation distante ?
Justification : Lauthentification de lApps/OC vis--vis de linfrastructure devrait tre rciproque. Cette fonction dauthentification
rciproque doit permettre lApps/OC de sassurer de lidentit des services distants avec lesquels elle change des donnes,
dune part, et ces services de sassurer que les donnes quils reoivent manent effectivement dune Apps/OC lgitime.
NB : il convient de distinguer la fonction dauthentification de lutilisateur vis--vis de lApps/OC et la fonction dauthentification
de lApps/OC vis--vis de services distants.
Le cas chant, les services distants peuvent complter cette authentification des Apps/OC par une procdure dite dattestation,
qui permet dinterdire ou dautoriser laccs aux services en fonction de ltat des Apps/OC (ltat correspondant une
mesure de lintgrit de lApps/OC).
Exemple : les valuateurs externes valuent les risques dauthentification dun produit en rapport aux documents fournis par
le fabricant.
XX
Intgrit et authenticit des donnes
Les mcanismes de vrification dintgrit et dauthenticit des donnes changes entre lApps/OC et les services distants
sont-ils documents ?
Justification : les mcanismes de vrification dintgrit et dauthenticit des donnes doivent permettre aux composants de
lApps/OC (locaux et distants) de dtecter toute altration des donnes changes et dapporter une preuve sur leur origine.
Exemple : les valuateurs externes valuent les risques lis lintgrit des donnes dun produit en rapport aux documents
fournis par le fabricant.
XX
Transfert/changes des donnes scurises
La confidentialit et lintgrit des donnes transmises sur des serveurs distants est-elle assure pendant le transit ? Cette
protection seffectue-t-elle laide dun protocole de chiffrement robuste utilisant des suites cryptographiques ltat de lart
(par exemple, TLS) ? Ce protocole est-il utilis indpendamment du rseau support (Wifi, connexion de donnes cellulaire,
etc.) ?
Un chiffrement des donnes complmentaires du canal confidentiel tabli avec les ventuels serveurs distants est-il
assur?
Justification : la scurisation des changes de donnes est assurer par le concepteur pour lutilisateur. De mme que le
respect des obligations en matire de transfert de donnes en dehors de lUnion europenne.
Exemple : les valuateurs externes pourront demander qui dispose des cls et comment celles-ci sont-elles protges ?
Existe-t-il un mcanisme de recouvrement ?
XX
Partage et accs aux donnes avec dautres Apps/OC
LApps/OC accde-t-elle des donnes ou des ressources gres par des Apps/OC tierces ? Lutilisateur est-il en mesure de
contrler de faon discrtionnaire laccs ces donnes et ces ressources ? LApps/OC prvoit-elle de partager les donnes
quelle gre avec dautres Apps/OC? Quels dispositifs de scurit sont mis en place pour empcher les accs illgitimes ces
donnes (par exemple, via une App malveillante) ?
Justification : laccs aux donnes et aux ressources externes par une application doit respecter le cadre juridique du partage
dinformation. Lapplication doit notamment minimiser autant que possible lexposition des donnes quelle manipule.
Exemple : une zone de rglage permet lutilisateur de diffuser ses donnes dactivit physique plusieurs Apps/OC
slectionnables.
XX
Stockage scuris des donnes sur le terminal
Un chiffrement des donnes stockes sur le terminal, complmentaire du dispositif de chiffrement global propos par le
systme dexploitation est-il assur ?
Justification : la scurit des donnes sur le terminal et sur le serveur est garantir par le concepteur.
XX
Stockage scuris des donnes sur le(s) serveur(s) distant(s)
Un chiffrement des donnes stockes sur le(s) serveur(s) distant(s), complmentaire du dispositif de chiffrement global propos
par le systme dexploitation est-il assur ?
Justification : la scurit des donnes sur le(s) serveur(s) distant(s) et sur le serveur est garantir par le concepteur.
NB : Se reporter galement aux dispositions rglementaires concernant les hbergeurs agrs donnes de sant (HDS)
lorsque lApps/OC le ncessite.
XX
Inscurit et failles des services distants
Les exigences de scurit, dintgrit et, le cas chant, de disponibilit des services distants avec lesquels lApps/OC interagit
sont-elles satisfaites ? Par quels moyens ?
Justification : Les incidents de scurit affectant une infrastructure peuvent tre potentiellement plus graves quun incident
isol sur le terminal dun patient, notamment en termes de vol de donnes. La protection des services distants est donc aussi
essentielle, sinon plus, que celle des Apps/OC.
Exemple : les valuateurs externes pourront valuer les risques de scurit lis aux services distants.
Pour information concernant les risques lis aux services web distants : le site OWASP recense les 10 plus importantes
vulnrabilits (81) :
faille dinjection ;
violation de gestion dauthentification et de session ;
cross-site Scripting (XSS) ;
rfrences directes non scurises un objet ;
mauvaise configuration Scurit (serveurs, etc.) ;
exposition de donnes sensibles ;
manque de contrle daccs au niveau fonctionnel ;
falsification de requte inter-sites (CSRF) ;
utilisation de composants avec des vulnrabilits connues ;
redirections et renvois non valids.
NB : la notion de services distants ne se limite pas aux seuls services web, mme si ces derniers sont prpondrants dans
les domaines des Apps/OC. La liste prcdente ne saurait tre considre comme tant exhaustive vis--vis des menaces
lies aux services distants.
XX
Maintien en condition de scurit
Le dveloppeur/concepteur assure-t-il le suivi et la correction des failles identifies sur lApps/OC?
Ce suivi sapplique-t-il galement au logiciel tiers (par exemple, des bibliothques) utilises par lApps/OC ?
Justification : le maintien en conditions de scurit de lApps/OC et des services distants est garantir par le concepteur.
Exemple : les valuateurs externes pourront valuer les risques lis la veille de la scurit du produit.
XX
Sensibilisation de lutilisateur, causes potentielles de brche de confidentialit
LApps/OC permet-elle de sensibiliser lutilisateur aux bonnes pratiques de scurit ?
Justification : le but est de limiter la diffusion de donnes personnelles lors de la session de son/sa smartphone/tablette (par
mauvaise rinitialisation) ou lors dattaque tentant de se faire passer auprs de lutilisateur pour linfrastructure authentique (par
exemple attaque par phishing).
Des recommandations gnriques sur la scurisation de son/sa smartphone/tablette devraient tre accessibles (chiffrement
du systme activ, verrouillage activ, systme jour, etc.).
Exemple : LApp adresse une notification sur le fait dutiliser un mcanisme de verrouillage de son smartphone pour protger
le contenu de ce dernier contre la perte ou le vol.
Lors de la cession de son/sa smartphone/tablette, lutilisateur est sensibilis aux bonnes pratiques pour effacer correctement
les donnes personnelles prsentes dans son ancien appareil.
Il est conseill de lire les 21 recommandations de lANSSI pour scuriser son ordiphone56, les bonnes pratiques de
linformatique57, les recommandations de scurit relatives aux mots de passe58 ou les recommandations de scurit relatives
aux rseaux Wi-Fi59.
XX
valuation de la scurit
Une valuation de la robustesse des fonctions de scurit et un audit de lApps/OC a-t-il t ralis pour valuer si le niveau
de scurit est adapt au produit ?
Justification : lanalyse des risques peut tre ralise par diffrentes approches mthodologiques et permet de dterminer
lexigence de scurit attendue.
Exemple : les valuateurs externes pourront demander la faon dont cet audit a t ralis et sil tait ralis de manire
indpendante.
XX
Signalement et transparence sur la violation de donnes ou en cas dincident de scurit
Un processus de signalement et de transparence est-il prvu en cas dincident de scurit ?
Justification : en cas de violation de donnes et/ou dincident de scurit, lditeur de lApp ou le concepteur de lobjet
connect sengage faire preuve de transparence vis--vis dautorits comptentes (celles en charge de la sant, ANSSI
CERT-FR, CNIL, autorits judiciaires le cas chant) et vis--vis de ses utilisateurs.
Exemple : une App a adress une notification pour mettre jour lApp suite une faille de scurit identifie.
Pour information
Scurit de linformation ISO 2700160
OWASP IoT Framework Assessment61
Recommandation ENISA62 :
identifier et protger les donnes sensibles sur lappareil mobile (diminuer les risques de vol ou pertes de donnes) ;
grer les informations de connexion du compte de manire scurise (le risque de spyware, surveillance, maliciel financier
qui utilisent les mots de passe pour dautres fonctions) ;
sassurer que les donnes sensibles sont protges durant leur transit (risque dattaque en usurpation de rseau sur les
nombreux rseaux utilises par les smartphones) ;
implmenter lauthentification et lautorisation dutilisateur correctement ainsi que la gestion des sessions ;
maintenir la scurit des APIs (services) du back-office (backend) et de la plateforme (serveur) (risques dattaques sur les
systmes de back-offices) ;
scuriser lintgration de donnes avec les services de parties tiers et les Apps (risque de fuite de donnes) ;
prter une attention particulire la collecte et aux stockages des consentements pour la collecte et lutilisation des
donnes utilisateurs (risque de divulgation non-intentionnelle dinformation personnelle) ;
implmenter des contrles pour prvenir les accs non-autoriss aux ressources de paiements (portefeuille, SMS, appels
tlphoniques, etc.) (risque dabus dusage/vulnrabilits des ressources de paiements) ;
assurer la scurit dans la distribution/prestation des Apps mobiles (attnuation de tous les risques dcrits dans le top 10) ;
vrifier avec prcaution chaque interprtation de code dexcution derreurs (runtime interprtation of code errors).
TOP10 risques (ENISA)63 :
fuite de donnes suite la perte ou le vol de lappareil (risque haut) ;
partage involontaire des donnes par lutilisateur (risque haut) ;
attaques sur un tlphone mal rinitialis (risque haut) ;
attaques par phishing (risque modr) ;
attaques par spyware (risque modr) ;
attaques par usurpation de rseau (risque modr) ;
attaques par surveillance (logiciel tiers prenant le contrle de la camra, du partage dcran, etc.) (risque modr) ;
attaques par composition de numros ou SMS surtaxs (diallerware attacks) (risque modr) ;
attaques par maliciels (logiciels malveillants) financiers (interception de transaction bancaire, interposition, etc.) (risque
modr) ;
encombrement/congestion de rseau (risque faible).
56. www.ssi.gouv.fr/entreprise/guide/recommandations-de-securite-relatives-aux-ordiphones
57. www.ssi.gouv.fr/guide/guide-des-bonnes-pratiques-de-linformatique
58. www.ssi.gouv.fr/uploads/IMG/pdf/NP_MDP_NoteTech.pdf
59. www.ssi.gouv.fr/uploads/IMG/pdf/NP_WIFI_NoteTech.pdf
60. www.iso.org/iso/fr/home/standards/management-standards/iso27001.htm
61. www.owasp.org/index.php/IoT_Framework_Assessment
62. www.enisa.europa.eu/media/enisa-en-francais
63. www.enisa.europa.eu/activities/Resilience-and-CIIP/critical-applications/smartphone-security-1/top-ten-risks (accd le 25/02/2016)
2.6.2 Sous-domaine : fiabilit

Concernant la fiabilit du contenu produit, gnr ou interprt, il est ncessaire de se reporter au domaine contenu.
XX
Fiabilit et maintenabilit hardware (capteurs) et software
Les taux de pannes, derreur de mesure, les risques de tous types au niveau hardware sont-ils valus et documents ?
Les bugs rcurrents et de suret de fonctionnement du software sont-ils documents ? Les conditions dutilisations ou les
avertissements en fonction de lutilisation sont-ils consultables par tous ?
Justification : le suivi de la fiabilit du produit est une tape importante prendre en compte lors de la conception. Les
modalits de suivi sont tracer.
Exemple : les valuateurs externes pourront demander la faon dont ce suivi est ralis pour en valuer la crdibilit et
lefficacit.
XX
Disponibilit de linfrastructure
Les mesures visant assurer la disponibilit de linfrastructure support de lApps/OC sont-elles documentes ?
Justification : la fonction support de lApps/OC et sa disponibilit sont des lments de qualit et de crdibilit pour son
maintien jour.
Exemple : les valuateurs externes pourront demander la faon dont la fonction support est organise.
XX
Assistance technique, hotline
Une hotline permettant de solliciter une demande dassistance technique (bug informatique, configuration du poste de
travail, systme dexploitation, etc.) est-elle mise la disposition des utilisateurs et des personnes ressources ? Les problmes
frquemment rencontrs sont-ils documents et peuvent-ils tre consults (FAQ, etc.) ?
Justification : une assistance technique sous un format adapt est disposition des utilisateurs pour les aider rsoudre les
problmes rencontrs.
Exemple : les valuateurs externes pourront demander la faon dont la hotline fonctionne ou la foire aux questions a t
conue et les problmes usuels rencontrs. Un processus de Debug utilis par les dveloppeurs peut tre document.
XX
Qualit des matriaux, innocuit des dispositifs
Le processus didentification des risques lis aux matriaux utiliss (allergie, risques physiques, etc.) et de linnocuit des
dispositifs (exemple : risque de brlure, etc.) est-il document et valu par des professionnels de sant indpendants et
qualifis ?
Justification : les objets connects ne doivent pas nuire physiquement lutilisateur.
Exemple : les bracelets de maintien dun objet connect sont hypoallergniques.
XX
Optimisation des fichiers mdia
Le choix des procds doptimisation des fichiers mdia (images et vidos) est-il document et justifi au regard de la
destination dusage du produit ?
Justification : il sagit de sassurer que les risques lis la perte de donnes par compression, aux dlais de connexion,
daffichage, de transmission, etc. sont acceptables. Loptimisation de la dfinition et du poids des fichiers mdias sans
augmenter les risques de perte de qualit pour lutilisateur est ralis et test.
Exemple : le temps daffichage dune vido dinterview est trop long pour une App dinformation grand public sur la sant. Le
concepteur du produit met en place une procdure doptimisation des fichiers.
XX
Contre-indications, risques potentiels, limitations dusage
Les contre-indications, les risques potentiels et les limitations dusage sont-ils valus et documents par un groupe comptent.
Ces informations sont-elles accessibles et consultables par les utilisateurs ?
Justification : lApps/OC peut prsenter des limites dutilisation ou de fiabilit. Linformation auprs de lutilisateur doit tre
transparente.
Exemple : un capteur optique dun cardiofrquencemtre perd sa fiabilit selon la pigmentation de la peau (tatouage, couleur
de peau, etc.). Lutilisateur est inform de cette limitation dusage.
XX
Niveau de disponibilit
Le niveau de disponibilit est-il document et adapt la destination dusage du produit (par exemple de 7 jours sur 7 et 24
heures sur 24 des dlais moins tendus comme de 9h 18h les jours ouvrs) ?
Justification : la destination dusage de certains produits ncessite une connexion permanente avec le rseau Web distant.
Exemple : un moniteur dactivit dun sportif en cours de reprise du sport aprs blessure permet de collecter les doses
defforts raliss et les phases de repos. Cela ncessite de stocker et/ou de pouvoir transmettre les donnes collectes en
continu.
XX
Maintenance prventive
Des systmes de dtection de panne et dalertes sont-ils prvus pour prvenir les pannes susceptibles dentraner une gne
ou un dommage lutilisateur (exemple : alerte batterie faible, etc.) ?
Justification : lutilisateur doit tre inform de ltat de fonctionnement ou de notification de mise jour ou de renouvellement
de batterie lors de collecte de donnes en continue ou dutilisation spcifique.
Exemple : un objet connect adresse un signal sonore ou une vibration pour spcifier que sa batterie est faible.
ISO/IEC/IEEE 15288:2015 : Ingnierie des systmes et du logiciel - Processus du cycle de vie du systme.
XX
Fonctionnement vis--vis des autres Apps/OC
La compatibilit et les conflits inter-Apps/OC sont-ils valus et surveills ?
Justification : le suivi de la compatibilit ou de conflit avec dautres Apps/OC est mis en place pour collecter les problmes
rencontrs par les utilisateurs et les informer des incompatibilits.
Exemple : un utilisateur rencontre un problme avec une Apps/OC qui entre en conflit avec la camra de son smartphone.
Une alerte dincompatibilit est reue par le concepteur de lApps/OC. Une information est adresse aux utilisateurs par
notification en attendant quune correction ventuelle soit apporte.
2.6.3 Sous-domaine : confidentialit

La loi informatique et liberts64 dfinit les principes respecter lors de la collecte, du traitement et de la conservation de
donnes personnelles, notamment pour ce qui concerne la confidentialit.
La CNIL met disposition des catalogues de bonnes pratiques destines traiter les risques que les traitements de donnes
caractre personnel (DCP) peuvent faire peser sur les liberts et la vie prive des personnes concernes65.
Le rglement gnral sur la protection des donnes (General Data Protection Regulation GDPR) a t adopt en avril 201666
et doit tre mis en uvre au niveau national pour le 6 mai 201867. Il convient de suivre ces volutions.
Sunyaev (82) a ralis en 2013 une tude montrant que seulement 30,5 % des Apps de sant mobile les plus utilises
possdaient une politique de confidentialit.
L Association franaise des correspondants la protection des donnes caractre personnel (AFCDP) a rdig une synthse
de travaux sur Quantified Self connect et informatique & liberts68.
XX
Destinataire des donnes collectes, confidentialit des donnes personnelles, et consentement pour la transmission des tiers
La transmission des donnes collectes (respectant les conditions lgales et rglementaires) des tiers est-elle documente
de manire explicite (destinataires, etc.) ?
Ces informations peuvent-elles tre consultes en dehors des conditions gnrales dutilisation ?
Lutilisateur peut-il modifier son consentement ?
Justification : toute transmission des tiers requiert le consentement pralable de lutilisateur conformment la loi.
Exemple : un lment de rglage est accessible pour modifier le consentement de transmission des tiers.
XX
Pseudonymisation des donnes
Le processus de pseudonymisation est-il document et consultable ?
Justification : Le processus de pseudonymisation des donnes personnelles est un enjeu important pour le domaine de la
sant mobile.
Exemple : les valuateurs externes pourront demander la faon dont la pseudonymisation est ralise. Les valuateurs
externes pourront demander comment les moyens indirects de lever lanonymat sont contrls. Par exemple, si lApps/OC
recours des identifications uniques de lappareil sur lequel elle est installe, et si ces identifiants uniques sont lis dune
quelconque faon lidentit de lutilisateur (numro de tlphone ?, etc.).
XX
Anonymisation des donnes
Les donnes individuelles, dont notamment les donnes de sant, transmises des fins de statistiques sont-elles anonymises?
Le processus danonymisation est-il document et consultable ?
64. Loi n 78-17 du 6 janvier 1978 relative l'informatique, aux fichiers et aux liberts.
65. www.cnil.fr/fr/PIA-privacy-impact-assessment
66. eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32016R0679&from=EN
67. ec.europa.eu/justice/data-protection
68. esante.gouv.fr/sites/default/files/asset/document/201502_synthese_qs_v10.3_finale.pdf
Justification : lanonymisation des donnes est obligatoire avant toute transmission des tiers en vue dun traitement statistique.
Exemple : les valuateurs externes pourront demander la faon dont lanonymisation est ralise.
Notion de big data et de gouvernance abord dans le livre vert de la Commission europenne (74).
Bonnes pratiques sur les donnes personnelles pour le Conseil des acadmies canadiennes (83).
Description du contexte et recommandations pour lAFNOR (84).
Documentation CNIL (34).
XX
Dlais de suppression et temps de mise en uvre
La dure et les dlais de conservation ou de suppression des donnes sont-ils documents et consultables par les utilisateurs?
Justification : la conservation de donnes de sant sur les serveurs ou tout autre support est communiquer lutilisateur. La
dure de conservation ncessaire laccomplissement des finalits est prciser et ne pas dpasser, dfaut dune autre
obligation lgale imposant une conservation plus longue.
Exemple : la page dinformation du concepteur dcrit la politique de conservation des donnes. Les valuateurs externes
pourront demander la documentation sur ce sujet.
XX
Couverture assurance et juridique concernant la perte de donnes
Une couverture assurance et juridique au bnfice des utilisateurs est-elle prvue pour faire face une perte ventuelle de
donnes collectes ? Une attestation est-elle consultable ?
Justification : la couverture juridique ou dassurance permet de protger la responsabilit du concepteur.
Exemple : les valuateurs externes pourront demander la documentation sur ce sujet.
2.7 Domaine : utilisation/usage

Le domaine utilisation/usage (tableau 7) porte principalement sur la manire dont lutilisateur va pouvoir utiliser lApps/OC.
Ce domaine fait appel des notions dvaluation qui peuvent tre subjectives ou difficilement valuables. Cest pourtant un
domaine qui contribue lutilisation rgulire et efficace du produit.
Tableau 7. Liste des critres se rapportant lutilisation du produit
SOUS-DOMAINES
Faible
Modre
leve
Ergonomie
Processus dinstallation et configuration
Aide lutilisation/instructions
Convivialit et intuitivit
Lisibilit texte et image
Niveau dutilisation
Accessibilit du contenu pour des

personnes en situation de handicap
Utilisation/design
Souhait
NIVEAU DEXIGENCE
INTITULS
Recommand
SOUS-DOMAINES
Faible
Modre
leve
Facilit demploi
Prvention des erreurs
Cas dusages, scnarios mtier
Flexibilit/customisation
Dlais de rponse, temps daffichage
valuation par les professionnels

de sant externe
valuation par la population cible principale
Enqute de satisfaction
Utilisabilit (adhsion des utilisateurs

dans le temps, rgularit dutilisation)
Niveau dimplication utilisateur

(acteur de sa prise en charge)
Posologie et utilisation
(mesure de lobservance)
Infrastructure ouverte
Capacit de recherche
Capacit de retrouver un patient
Possibilit dimprimer des rsums

(slection)
lments sociaux (vie prive

et rseaux sociaux)
Utilisation/design
Acceptabilit
Intgration/import
Souhait
NIVEAU DEXIGENCE
INTITULS
Recommand
2.7.1 Sous-domaine : utilisation/design

XX
Ergonomie
Le processus de conception de linterface sappuie-t-il sur une dmarche ergonomique (normes & standard existant ISO,
AFNOR, etc.) ? Ce processus est-il document ?
Justification : lergonomie dutilisation est un facteur dimplmentation pour lutilisateur.
Charte Internet de ltat69 : la charte ergonomique des sites Internet publics a pour objet de dfinir un ensemble de rgles
ergonomiques communes aux interfaces des sites Internet publics. Elle sinscrit dans le respect des standards du Word Wide Web
Consortium (W3C) et des principes des rfrentiels gnraux dinteroprabilit (RGI), daccessibilit (RGAA) et de scurit (RGS).
Cruz Zapata (85) propose des recommandations pour les dveloppeurs concernant linterface.
XX
Procdure dinstallation et configuration
La procdure dinstallation et de configuration a-t-elle t teste sur les principaux OS, navigateurs Internet et plates-formes
proposs dans lenvironnement dutilisation ? Cette procdure est-elle documente ?
Justification : les phases de tests sont assurer par le concepteur pour garantir une exprience utilisateur de qualit.
XX
Aide lutilisation/instructions
Un systme daide lutilisation du produit est-il mis la disposition des utilisateurs (aide contextuelle, aide en ligne, manuel
utilisateur, tutoriel, didacticiel, e-learning, etc.) ? Ce systme favorise-t-il les capacits dapprentissage de lutilisateur
(apprenabilit) ?
Justification : le niveau de soutien didactique propos par le concepteur lutilisateur permet doptimiser lutilisation du produit.
Exemple : lors du lancement de lApps/OC, des zones daide sont proposes pour aider lutilisateur lors de sa premire
utilisation.
XX
Convivialit et intuitivit
La convivialit et lintuitivit de linterface et de la navigation ont-elles t testes auprs de diffrents profils dutilisateurs ? Le
plan et compte-rendu des tests sont-ils documents ?
Justification : les profils dutilisateurs diffrents dans leur manire dapprendre ou selon des critres spcifiques lis aux
utilisateurs cibles sont sollicits par le concepteur pour adapter lApps/OC.
XX
Lisibilit texte et image
La lisibilit des diffrents mdias utiliss (texte, image, vidos) a-t-elle t teste ? Le plan et compte-rendu des tests sont-ils
documents ? Linterface ou lOS permet-il le changement de la lisibilit de lApps/OC (modification de la taille/de la police de
caractres, etc.) ?
Justification : la lisibilit par des utilisateurs ayant des capacits diffrentes est un facteur daccessibilit du produit.
Exemple : lutilisateur a accs une zone de rglage pour adapter la taille de la police de caractres et tendre en plein cran
la vido.
XX
Niveau dutilisation
Les diffrents profils utilisateurs sont-ils identifis en fonction de la destination dusage du produit et des difficults possibles
pour la lisibilit de linterface ou de niveau dutilisations ? Le niveau prrequis pour un utilisateur novice, confirm ou expert
est-il accessible tous ?
Justification : diffrents types dutilisateurs peuvent naviguer diffremment dans linterface du produit.
Exemple : des utilisateurs daltoniens et des personnes ges ont t identifis afin de travailler sur lutilisation des couleurs et
des contrastes de linterface dune App dinformation sur la rhabilitation respiratoire.
Arnhold (86) a ralis une valuation de linterface des Apps pour personnes ges atteintes de diabtes. Watkins (87) a ralis
une revue systmatique sur les personnes ges et le niveau de lecture/comprhension en sant (health literacy).
Monkman (88) value le risque en fonction de linterface et du niveau de lecture/comprhension en sant (health literacy) de
lutilisateur.
69. references.modernisation.gouv.fr/sites/default/files/Charte_ergonomique_v2.0_2.pdf
XX
Accessibilit du contenu pour des personnes en situation de handicap
Les recommandations daccessibilit concernant les personnes en situation de handicap sont-elles appliques ?
Justification : laccessibilit du produit est garantir par le concepteur.
Exemple : un test utilisateur spcifique est mis en place par le concepteur pour les utilisateurs en situation de handicap.
Charte Internet de ltat70 : La charte ergonomique des sites Internet publics a pour objet de dfinir un ensemble de rgles
ergonomiques communes aux interfaces des sites Internet publics. Elle sinscrit dans le respect des standards du Word Wide
Web Consortium (W3C) et des principes des rfrentiels gnraux dinteroprabilit (RGI), daccessibilit (RGAA) et de scurit
(RGS).
XX
Facilit demploi
Un processus de simplification dutilisation est-il mis en place ? Ce processus est-il document ?
Justification : les retours utilisateurs doivent permettre aux concepteurs de faire voluer vers la simplification leurs produits.
Exemple : des lments de menu ont t supprims suite une mauvaise ou non-utilisation de ces lments dans une App
de bases de donnes de mdicaments destination des mdecins. Le dlai daccs linformation recherche a t diminu.
XX
Prvention des erreurs
Un systme dalerte adapt lors de dcisions critiques de lutilisateur est-il mis en place pour prvenir les msusages ventuels?
Justification : certaines interactions peuvent entrainer des erreurs de la part de lutilisateur. Des lments dalertes sont
garantir par le concepteur.
Exemple : une App de calcul dindice de masse corporelle adresse une alerte concernant lutilisation dunit de mesure de la
taille ou met en place un menu droulant pour limiter les erreurs de saisie.
XX
Cas dusages, scnarios mtier
Les cas dusages (ou scnarios mtier) couvrent-ils les fonctions principales du produit et permettent-ils de mieux apprhender
les diffrentes utilisations de lApps/OC (les scnarios) ? Ces cas dusage sont-ils documents et tests ?
Justification : la navigation et le parcours des utilisateurs dans une App peuvent tre trs diffrents. De mme, que pour le
paramtrage dun objet connect. Lidentification de diffrents scnarios permet de prvenir les ventuels msusages ou
damliorer la navigation dans lApp.
Exemple : une App permettant de grer la prise de mdicaments permet de paramtrer dans lagenda des prises
mdicamenteuses heures fixes de manire itratives durant une priode dfinie. Certains utilisateurs ne connaissant pas
cette fonction paramtrent les diffrents jours un par un une semaine lavance. Lidentification de ce scnario doit permettre
de mettre en place une assistance spcifique.
Caburnay (89) effectue une revue du design des Apps portant sur le diabte.
Collins (90) a dvelopp des outils pour valuer la qualit des questionnaires de sant pour les patients au travers des Apps
(health literacy71).
Diffrents outils sont proposs pour valuer la comprhension des patients.
XX
Flexibilit/customisation
Ladaptation en fonction du niveau, des besoins ou des exigences des utilisateurs est-elle envisage ?
Justification : la sant mobile a permis de dvelopper des Apps/OC rservs des niches de professionnels ou de
patients. Il est possible de dcliner des versions spcifiques correspondantes aux besoins de lutilisateur.
Exemples : une plateforme dchanges de documents entre patients et professionnels permet des niveaux daccs diffrents
et des niveaux de visualisations des informations diffrents en fonction des droits des utilisateurs.
Un panneau de rglage spcifique permet dactiver un menu simplifi ou avanc en fonction des besoins de lutilisateur.
XX
Dlais de rponse, temps daffichage
Les dlais de rponse et les temps daffichages sont-ils tests et adapts en fonction de la destination dusage du produit ?
Le plan incluant la dfinition de lenvironnement de test et le compte-rendu des tests sont-ils documents ?
Justification : la fluidit de la navigation est un facteur de fidlit des utilisateurs.
Exemple : les valuateurs externes pourront tester les temps de rponse lors de banc dessais.
70. references.modernisation.gouv.fr/sites/default/files/Charte_ergonomique_v2.0_2.pdf
71. health.gov/healthliteracyonline/2010/Web_Guide_Health_Lit_Online.pdf

Georgsson (91) a effectu une valuation des tches (suivant norme ISO 9241-11). Il montre que les tches les plus complexes
donnent plus derreurs. Cinq 8 utilisateurs trouvent 80-85 % des problmes dinterface. Les niveaux de ralisation des
taches sont grads en 3 niveaux : sans aide, avec une aide, avec une aide et chec.
2.7.2 Sous-domaine : acceptabilit

XX
valuation par les professionnels de sant externe
Lvaluation de lApps/OC est-elle ralise par des professionnels de sant ou des organisations de professionnels de sant
indpendantes ?
Justification : dans le cadre de la gestion de qualit, une valuation externe est un lment mettre en place.
Exemples : un groupe de professionnels de sant met en place une Apps/OC de recueil de donnes de patients pour effectuer
des statistiques de prise en charge et de suivi de patients. Ils publient un article sur le sujet dans une revue relue par ses pairs.
Une association professionnelle effectue une valuation dune dizaine dApps/OC concernant un champ spcifique de son
secteur dactivit. Elle diffuse les rsultats ses membres et les propritaires des Apps/OC citent cette valuation dans leur
prsentation.
XX
valuation par la population cible principale
Lvaluation de lApps/OC est-elle ralise par les utilisateurs ou des groupes dutilisateurs indpendants ?
Justification : le test en condition relle auprs des utilisateurs cibles permet dobtenir des retours sur la qualit du produit.
Exemple : une Apps/OC permettant de mesurer un/des angle(s) sur des captures vidos ne mmorisent pas les mesures
effectues sur le sujet. Ce retour utilisateur permet une adaptation de la part du concepteur.
XX
Enqute de satisfaction
La satisfaction des utilisateurs est-elle value ? Les rsultats de cette valuation sont-ils documents et consultables pour
tous ?
Justification : la transparence du retour utilisateurs est un niveau dinformation. Il peut tre manipul par des faux utilisateurs
financs pour des donner des avis positifs.
Exemple : les valuateurs externes pourront analyser les donnes et valuer leur niveau de fiabilit.
XX
Utilisabilit (adhsion des utilisateurs dans le temps, rgularit dutilisation)
Lvaluation de lutilisation rgulire de lApps/OC est-elle ralise si cet objectif fait partie de ceux de lApps/OC?
Justification : des Apps/OC ont actuellement une dure de vie dutilisation limite. Les concepteurs devraient suivre les
statistiques dutilisation/frquentation.
Exemple : le concepteur diffuse son taux dutilisation pour mettre en avant la popularit et la fidlit de ses utilisateurs.
XX
Niveau dimplication utilisateur (acteur de sa prise en charge)
Pour une Apps/OC dont lobjectif vise au fait que lutilisateur devient acteur de sa propre prise en charge, le niveau dimplication
de lutilisateur est-il stimul et valu ? Ce processus est-il transparent et document ?
Justification : la mesure de soi (quantified self) est un objectif spcifique en plein essor dans le milieu de la sant mobile. Le
concepteur doit mettre en avant les moyens mis en uvre pour per-mettre cette autonomie de prise de mesure.
Exemple : un pse-personne connect encourage le patient suivre diffrents paramtres mesurs sur plusieurs semaines
pour adapter son comportement et son hygine de vie progressivement.
XX
Posologie et utilisation (mesure de lobservance)
Lobservance du traitement permise par lApps/OC est-elle ralise si cet objectif fait partie de ceux de lApps/OC? Ce
processus est-il document ?
Justification : les utilisateurs reoivent diffrents types de rappels pour amliorer leur observance thrapeutique.
Exemple : les alertes SMS, et les notifications adresses sur le tlphone portable permettent au patient de mieux suivre son
traitement.
Hall (92) a montr limpact fort des SMS dans diffrents secteurs de la sant.
Hamine (47) a montr limpact rel de la sant mobile sur lobservance pour les malades chroniques.
2.7.3 Sous-domaine : intgration/import

XX
Infrastructure ouverte
Lutilisateur peut-il entrer manuellement des donnes dans lApps/OC?
Justification : certains praticiens souhaitent ajouter des commentaires certaines donnes recueillies sur le patient ou
certaines situations (perte de connexion, dconnexion Internet chez lutilisateur durant plusieurs jours) ncessitent dajouter
des donnes dans lApps/OC.
Exemple : le capteur dactivit de lutilisateur est tomb en panne durant plusieurs jours. Lutilisateur copie les donnes
enregistres pour des jours similaires en termes dactivit sur les jours manquants de son agenda de suivi.
XX
Capacit de recherche
Lutilisateur a-t-il sa disposition un moteur de recherche dinformations ou un systme de recherche de donnes lorsque cela
est pertinent ?
Justification : les lApps/OC portant sur des bases de donnes dinformations diverses, ou incluant des donnes collectes
devraient permettre deffectuer des recherches via un moteur de recherche.
Exemple : une Apps/OC recensant les recommandations de bonnes pratiques permet une recherche spcifique.
XX
Capacit de retrouver un patient
Si le patient y consent, le professionnel de sant a-t-il la capacit de retrouver un/des patient(s) ?
Justification : pour certains professionnels stockant de linformation mdicale au travers dApp de gestion de cabinet ou autre,
un moteur de recherche permet daccder plus rapidement au document demand.
Exemple : les rsultats dexamen biologiques dun patient sont archivs dans une base de donnes et peuvent tre recherchs
via une interrogation spcifique.
XX
Possibilit dimprimer des rsums (slection)
Une extraction de donnes partielles permet-elle dimprimer des rsums ?
Justification : lextraction de donnes spcifiques permet lutilisateur de conserver auprs de lui un dtail concernant un
rsum darticle, un rsultat dune mesure effectue, un tat de forme ressenti ou une compilation de donnes.
Exemple : un praticien collecte des articles spcifiques concernant des mthodes dvaluation spcifiques au travers dune
App dinformations mdicales.
XX
lments sociaux (vie prive et rseaux sociaux)
Lenvoi de donnes vers les rseaux sociaux sappuie-t-il sur un intrt dmontr ? Le transfert de donnes vers les rseaux
sociaux est-t-il conforme la loi et la rglementation (consentement exprs de lutilisateur, respect de la vie prive, etc.) ?
Justification : les rseaux sociaux sont utiliss, entre autre, pour renforcer le soutien ou dvelopper des facteurs dmulation
pour suivre les prescriptions dun praticien ou son comportement. Limplmentation de ce dispositif ncessite un intrt
dmontr sil est propos.
Exemple : une App de type agenda de lhumeur utilise par des patients dpressifs permet de partager son humeur sur
les rseaux sociaux avec un groupe damis. Les rfrences cliniques de lintrt de cette diffusion sont consultables par tous.
Cette fonctionnalit doit suivre la loi et la rglementation ainsi que lavis mdical ventuel sur lintrt de ce partage.
3. Mise en uvre du rfrentiel de bonnes pratiques

Diffrentes thories de lvaluation et diffrentes approches en fonction de lobjectif recherch sont publies sur le sujet. Khoja
(93) a dcrit les diffrentes phases du cycle de vie dune App et les processus dvaluation qui pourrait en dcouler pour
chacune des phases.
Pour les dveloppeurs, il existe galement des travaux de normalisations (par exemple : ISO/IEC 90003, Ingnierie du logicielLignes directrices pour lApp de lISO 9001:2008 aux logiciels informatiques ou IEC/FDIS 82304-1, logiciels de sant-Partie 1 :
exigences gnrales pour la scurit des produits) qui fournissent des standards sur diffrents champs concerns par le sujet
de la sant mobile. Ces lments permettent aux dveloppeurs de produits daller rechercher des certifications.
Par ailleurs, il existe des documents de recommandations comme le PAS 277:2015 (Health and wellness apps Quality
criteria across the life cycle Code of practice) labor par le British Standards Institute (94) qui se propose de donner des
recommandations pour les dveloppeurs.
Lobelo (95) propose galement un cadre dorganisation dans ce quil qualifie de Wild Wild West pour ce qui concerne le
domaine de lactivit physique et de la sant et le bien-tre mobile.
Les plateformes de magasins en ligne fournissent aussi des recommandations72 pour aider les dveloppeurs bien figurer
dans leur store73.
3.1 Les dclinaisons possibles du rfrentiel de bonnes pratiques de la HAS

Le rfrentiel de bonnes pratiques de la HAS peut tre utilis et adapt par diffrents acteurs du secteur :
les dveloppeurs pourront trouver des lments intgrer dans leur(s) projet(s) ;
les valuateurs externes pourront cibler la documentation demander ;
les organisations professionnelles pourront construire des tableaux de synthses (benchmarking) ou des illustrations
synthtiques (graphes en radar) sur des Apps/OC spcifiques en reprenant les critres du rfrentiel.
Chacun des 5 domaines du rfrentiel peut ainsi tre valu spcifiquement ou des synthses peuvent tre constitues pour
comparer les valuations de diffrentes Apps/OC dun mme secteur (objectif principal et utilisateur principal communs).
Les critres obligatoires permettent deffectuer une premire analyse de lApp/OC. Sils ne sont pas prsents, lvaluation
nest pas poursuivie.
Pour certains critres en relation avec des Apps/OC spcifiques (notamment les flux de donnes), des mthodes danalyse de
risque ou danalyse de menace sont mettre en place comme propos pour certains critres.
Concernant linterface dutilisation sous langle de lutilisateur (interface homme-machine-IHM), cette partie peut faire lobjet
dvaluation complmentaire avec des chelles standards comme les 10 questions du System Usability Scale74 (SUS) de
Brooke (96) ou les 21 questions de lapproche par Quality of experience (QoE) de Martinez-Perez (97).
Le rfrentiel de bonnes pratiques de la HAS peut servir de rfrence pour construire diffrents livrables :
registre ;
label ;
score ;
valuation par les pairs ;
banc dessai ;
benchmark.
Ou diffrentes approches en fonction des objectifs viss par lvaluateur :
approche par objectifs/domaines (qualit de linformation, processus de conception, scurit, etc.) ;
approche par segmentation (pathologies spcifiques, etc.) ;
approche par cible (patients, tudiants, professionnels de sant, concepteurs/usage spcifique) ;
etc.
Un suivi de lutilisation du rfrentiel permettrait didentifier les usages raliss.
72. developer.apple.com/app-store/review/guidelines/#physical-harm
73. www.fiercehealthcare.com/mobile/apple-debuts-app-review-guidelines-quest-to-boost-quality
74. www.usability.gov/how-to-and-tools/methods/system-usability-scale.html
Annexe 1. Le Mobile App Rating Scale (MARS) (98, 99)

Disponible sur le site : mhealth.jmir.org/article/downloadSuppFile/3422/14733
partir de 349 items regroups suite une revue de littrature, le score a t rduit 23 items et ct de 1 5 dans 4
domaines objectifs et 1 domaine subjectif.
Concordance inter-examinateur : CCI=0.79 et Consistance interne : alpha=0.90
Section A Engageant (amusant, intressant, personnalisable, interactif (envoie des alertes, messages, reminder,
feedback, permet le partage), bien cibl sur laudience.
Score sur 25 points
1. Divertissant : est-ce que lapplication est divertissante utiliser ? Est-ce quelle utilise des stratgies pour amliorer
limplication au travers laspect divertissant (par exemple : un ct ludique) (5 niveaux de rponses ct de 1 5 avec
descriptif).
2. Intrt : est-ce que lapplication est intressante utiliser ? Est-ce quelle use de diffrentes stratgies pour amliorer
limplication au travers dune prsentation intressante du contenu ? (5 niveaux de rponses ct de 1 5 avec descriptif).
3. Personnalisable : est-ce quelle fournit/conserve tous les rglages ncessaires/les rglages de prfrences des applis
(exemple : son, contenu, notifications, etc.) ? (5 niveaux de rponses ct de 1 5 avec descriptif).
4. Interactivit : est-ce quelle permet lutilisateur dentrer des donnes, fournir un feedback, contenu rapide (reminders,
options de partage, notifications, etc.) ? Note : ces fonctions ont besoin dtre personnalisables et ne pas scraser les
unes sur les autres. (5 niveaux de rponses ct de 1 5 avec descriptif).
5. Groupe cible : est-ce que le contenu de lapplication (information visuelle, langage, design) est appropri pour laudience
cible ? (5 niveaux de rponses ct de 1 5 avec descriptif).
Section B Fonctionnalit - fonctionnement de lapplication, facile apprendre, navigation, flux/parcours logique,
design gestuel de lapplication
Score sur 20 points
6. Performance : comment fonctionne avec prcision/vitesse les lments de lapplication (fonctions) ainsi que ces
composantes (boutons/menus) ? (5 niveaux de rponses ct de 1 5 avec descriptif).
7. Facilit dutilisation : avec quelle facilit est-il possible dapprendre utiliser lapplication ; quel est le niveau de clart
des icnes/tiquettes de menu et les instructions ? (5 niveaux de rponses ct de 1 5 avec descriptif).
8. Navigation : est-ce que le dplacement entre les crans est logique/prcis/non-interrompu ; est-ce que tous les liens
vers les crans sont prsents ? (5 niveaux de rponses ct de 1 5 avec descriptif).
9. Design gestuel : est-ce que les interactions (toucher/glisser/pincer/dfiler) sont conformes et intuitifs avec lensemble
des composantes/crans ? (5 niveaux de rponses ct de 1 5 avec descriptif).
Section C Esthtique - design des graphismes, attractivit visuelle, cohrence des couleurs, et style uniforme
Score sur 15 points
10. Mise en page : est-ce que la disposition et la taille des boutons/icnes/menus/contenu de lcran est approprie ou
peut-on zoomer si ncessaire ? (5 niveaux de rponses ct de 1 5 avec descriptif).
11. Graphisme : quel niveau est la qualit de la rsolution des graphismes utiliss pour les boutons/icones/menus/
contenu ? (5 niveaux de rponses ct de 1 5 avec descriptif).
12. Attractivit visuelle : quel niveau lapplication est-elle visuellement belle ? (5 niveaux de rponses ct de 1 5 avec
descriptif).
Section D Information - contenu de haute qualit dinformations (exemple : texte, feedback, mesures, rfrences)
provenant de source fiable. Slectionner non adapt si la composante de lapplication ne convient pas.
Score sur 35 points
13. Prcision de la description de lapplication (sur le store) : est-ce que le contenu de lapplication est dcrit ? (5 niveaux
de rponses ct de 1 5 avec descriptif).
14. Buts : est-ce que lapplication a des buts spcifiques, mesurables et atteignables ? (5 niveaux de rponses ct de 1
5 avec descriptif).
15. Qualit de linformation : est-ce que lapplication prsente un contenu correct, bien crit, et adapt lobjectif/au sujet
vis par lapplication ? (5 niveaux de rponses ct de 1 5 avec descriptif).
16. Quantit dinformation : est-ce que ltendu du domaine couvert est compris dans le cadre de lapplication ; et
comprhensible en restant concis ? (5 niveaux de rponses ct de 1 5 avec descriptif).
17. Information visuelle : est-ce que lexplication visuelle des concepts au travers de schma/graphique/image/vidos,
etc.- est clair, logique, et correct ? (5 niveaux de rponses ct de 1 5 avec descriptif).
18. Crdibilit : est-ce que lapplication provient dune source lgitime (spcifie dans la description sur le store ou dans
lapplication elle-mme) ? (5 niveaux de rponses ct de 1 5 avec descriptif).
19. Fonde sur des preuves : est-ce que lapplication a t teste/value par un essai contrl ; a d tre vrifie par une
tude fonde sur les preuves ? (5 niveaux de rponses ct de 1 5 avec descriptif).
Score totale de qualit : A + B + C + D
PARTIE SUBJECTIVE
Section E
Score sur 20 points
20. Est-ce que vous recommanderiez cette application des personnes qui pourraient en tirer un bnfice ? (5
niveaux de rponses ct de 1 5 avec descriptif).
21. Combien de fois pensez-vous que vous pourriez utiliser cette application dans les 12 prochains mois si elle vous
tait pertinente ? (5 niveaux de rponses ct de 1 5 avec descriptif).
22. Paieriez-vous pour cette application ? (5 niveaux de rponses ct de 1 5 avec descriptif).
23. Quel est de manire globale la note que vous attribueriez cette application ? (5 niveaux de rponses ct de 1
5 avec descriptif).
Annexe 2. Lvaluation par les pairs du Journal of

Medical Internet Research JMIR Formulaire de Health Apps, 2014
Disponible sur le site : tinyurl.com/appsform
Domaines
Paramtres/critres (compils par rapport au formulaire du site)
propos du rpondant
Nom, e-mail, fonction, autres personnes rpondants aux questionnaires
propos de lAppli
Nom, version, MJ, cycle MJ, plateforme, pays, URL, accs testeur, URL crateur, URL informations
gnrales et guide utilisateur, URL copies dcran, copyright, URL tiers, hardware additionnel, prix,
nom de la compagnie, type dentreprise, contact principal, Email contact principal, rle principal du
contact, noms des contributeurs/organisation, lien vers la page contributeur, support utilisateur.
Dtails de lapplication
Cible audience principale, dtaill les cibles spcifiques, objectif principal de lapplication, concurrent
similaire et diffrence, classification (support de livres mdicaux, suivi et valuation de sant, gestion
cabinet, aide gnrique non mdicale, dossier de patient informatis, diagnostic mdical, traitement
pathologie, prvention, cible une structure ou fonction du corps, accessoire pour un dispositif mdical,
autre), description des fonctionnalits, auteurs du contenu et cursus et statut, dclaration dintrt
auteur, dclaration de financement et des sources des fonds, localisation dans lapplication de la
citation des financements, liens dintrt, localisation dans lapplication de la citation des conflits
dintrt, contre-indications, localisation dans lapplication de la citation des contre-indications,
limitations connues, risques potentiels.
Scurit et vie prive
Politique de confidentialit des donnes personnelles, localisation dans lapplication de la citation

de la politique de confidentialit des donnes personnelles, rglages utilisateurs des paramtres de
confidentialit, transparence des personnes ayant accs aux donnes utilisateurs par URL ou menu,
scurit des protocoles de transmissions.
Accord de la FDA
Statut de la demande daccord, dtail de la demande ou pas de laccord.
Dveloppement et
processus de test, et EBM
Niveau dvaluation formative ou dveloppement appuy sur les retours des utilisateurs, valuation
formative et publications cls, quel est le niveau de preuve de lapplication (pas de revue par les pairs
ou dvaluation, revue par les pairs planifie, revue par les pairs, tude observationnelle en cours,
tude observationnelle termine, essai randomis en cours (pilote/petit), essai randomis termin
(pilote/petit), essai randomis en cours (large effectif), essai randomis termin (large effectif), quels
sont les critres de jugement principaux et secondaires, registre dinscription de lessai, thorie ou
preuves justifiant le contenu de lapplication, source de EBM/thorie et publications cls, revue par
ses pairs et publications cls, revue par un journal externe ou blog, valuation des rsultats des
tudes observationnelles et publications cls, valuation des rsultats des tudes randomises
et publications cls, valuation des rsultats et donnes cls des publications probantes, note
complmentaire.
MJ : mise jour, URL : uniform resource locator, EBM : Evidence-based medicine, FDA : Food and drug administration.
Annexe 3. Recherche documentaire

XX
Bases de donnes bibliographiques
La recherche documentaire, limite aux publications en langue anglaise et franaise, a t ralise partir des sources
suivantes :
pour la littrature internationale : la base de donnes Medline ;
pour la littrature francophone : la Banque de donnes en sant publique ;
la Cochrane Library ;
les sites Internet publiant des recommandations, des rapports dvaluation technologique ou conomique ;
les sites Internet comptents dans le domaine tudi, y compris des sites dvaluation dApps/OC en sant et des sites
dactualit.
La stratgie dinterrogation des bases de donnes prcise pour chaque question et/ou types dtude les termes de recherche
utiliss, les oprateurs boolens et la priode de recherche.
Les termes de recherche utiliss sont soit des termes issus de thsaurus (descripteurs), soit des termes libres (du titre ou du
rsum). Ils sont combins avec les termes dcrivant les types dtudes.
Le tableau ci-dessous prsente de faon synthtique les tapes successives de cette interrogation dans la base de donnes
Medline. Le nombre total de rfrences obtenues par interrogation de cette base de donnes bibliographiques est 643.
Stratgie de recherche dans la base de donnes Medline
Type dtude/sujet
Termes utiliss mes utiliss
Recommandations & confrences de consensus

tape 1
Priode
01/2005 12/2015
(Cell Phones OR Mobile Applications)/maj OR (mobile application OR mobile

applications OR mobile app OR mobile apps OR smartphone application OR
smartphone applications OR Smartphone app OR Smartphone apps OR app
stores OR Mobile Medical Application OR Mobile Medical Applications OR medical
apps OR medical app OR standalone software OR health apps OR health app
OR mhealth OR mobile health)/ti,ab OR (ehealth OR apps OR app)/ti OR ((Medical
Informatics Applications/maj OR Software/Maj:NoExp OR (application OR
applications OR health OR medical)/ti) AND (mobile OR smartphone OR phone)/ti)
ET
tape 2
(guide OR guidance* OR recommendation* OR guideline* OR statement* OR

consensus OR position paper)/ti OR (Guidelines as topic OR health planning
guidelines OR Practice Guidelines as topic OR Consensus Development
Conferences as topic OR Consensus Development Conferences, NIH as topic)/de
OR (practice guideline OR guideline OR Consensus Development Conference OR
Consensus Development Conference, NIH OR Government Publications)/pt
Mta-analyses & revues systmatiques
01/2010 12/2015
tape 1
ET
tape 3
(metaanalys* OR meta-analys* OR meta analysis OR systematic review* OR

systematic overview* OR systematic literature review* OR systematical review* OR
systematical overview* OR systematic literature review* OR systematic literature
search)/ti,ab OR meta-analysis as topic/de OR meta-analysis/pt OR cochrane
database syst rev/so
Type dtude/sujet
Termes utiliss mes utiliss
valuation des applications
Priode
01/2010 12/2015
tape 1
ET
tape 4
(quality control framework OR regulatory framework OR evaluation framework OR

ehealth framework OR Mobile App Rating scale OR MARS OR scoring OR quality
assessment)/ti,ab OR (framework OR frameworks OR certificat* OR label* OR
standard OR criteria)/ti OR Software Validation/de
OU
tape 5
(mhealth OR mobile health OR apps OR app OR standalone software)/ti AND

(evaluat* OR Assessment)/ti
* : troncature ; de : descriptor ; ti : title ; ab : abstract ; pt : publication type ; so :journal title ;
XX
Sites consults
Exemples de portails ou sites dvaluation/classification dapplications en sant
Agency of Healthcare Quality of Andalusia (appSaludable) : www.calidadappsalud.com/distintivo/catalogo
AppCheck : www.appcheck.de
dmd Sant (dmdpost) : www.dmd-sante.com
HealthOn : www.healthon.de
iMedicalApps (iPrescribeApps) : www.imedicalapps.com
IMS Health (AppScript) : www.imshealth.com
Medappcare : www.medappcare.com/conseil-scientifique
myhealthapps.net : myhealthapps.net/about
UKs National Health Service : NHS choices (Health Apps Library) : apps.nhs.uk/review-process/#
Exemples de sites avec catalogue dapplications en sant (sans valuation)
Eat right : www.eatrightpro.org/resources/media/trends-and-reviews/app-reviews
Infirmier.com : www.infirmiers.com/ressources-infirmieres/documentation/tour-horizon-de-quelques-applicationsmobiles-bien-utiles.html
National Health Portal : mhealth : www.nhp.gov.in/mobile-apps
UF Diabetes Institute : mhealth : diabetes.ufl.edu/my-diabetes/diabetes-resources/diabetes-apps/
US department of Veterans Affairs : VA mobile health (VA App Store) : mobile.va.gov
Zur Institute : Mental Health Apps : www.zurinstitute.com/mentalhealthapps_resources.html
Sites dactualits sur la m-sant
Buzz-esant - le blog du digital sant : linkis.com/buzz-esante.fr/Ab5Ye
Connected doctors : www.theconnectedmag.fr
DSIH e-sante : www.dsih.fr
GeekMedical : www.geekmedical.fr
Le monde de la e-sant : lemondedelaesante.wordpress.com
MedCityNews : medcitynews.com
mHealth News : www.mhealthnews.com
Mobihealthnews : mobihealthnews.com
objetconnecte.net : www.objetconnecte.net/category/sante-connectee/
Proxima mobile : www.proximamobile.fr/article/france-un-guide-mobile-pour-800-applications-de-sante?cat=none
Smart Phone Healthcare : www.smartphonehc.com
Autres sites consults
Agence des systmes dinformation partags de sant - ASIP Sant : www.asipsante.fr
Agence fdrale des mdicaments et des produits de sant - AFMPS : www.fagg-afmps.be/fr/
Agence nationale de scurit du mdicament et des produits de sant - ANSM : ansm.sante.fr/Activites/Mise-surle-marche-des-dispositifs-medicaux-et-dispositifs-medicaux-de-diagnostic-in-vitro-DM-DMIA-DMDIV/Logiciels-etapplications-mobiles-en-sante/%28offset%29/1
Agency for Healthcare Research and Quality - AHRQ : www.ahrq.gov
Alberta Medical Association : www.topalbertadoctors.org
College of Physicians ACP : www.acponline.org/clinical/guidelines/index.html#acg

General (tat de Californie) : www.attorneygeneral.jus.gov.on.ca/french/default.asp
Bibliothque mdicale Lemanissier : www.bmlweb.org/consensus.html
Bibliothque interuniversitaire de mdecine - BIUS
CATAAlliance [CATA Mobile Health Advisory Board (MHAB)] : www.cata.ca/Communities/MHAB/
Catalogue et Index des sites mdicaux francophones - CISMeF : www.cismef.org
Centre fdral dexpertise des soins de sant - KCE : kce.fgov.be/fr
Commission nationale de linformatique et des liberts - CNIL : www.cnil.fr
Conseil de lEurope : www.coe.int/web/portal/home
Conseil National de lOrdre des Mdecins - CNOM : www.conseil-national.medecin.fr/e-sante/les-publications-1143
Contrleur europen de la protection des donnes - EDPS/CEPD : secure.edps.europa.eu/EDPSWEB/
E.sante.gouv : esante.gouv.fr
European Commission : ec.europa.eu/digital-agenda/en/mhealth
Euroscan : www.euroscan.bham.ac.uk
Food and Drug Administration - FDA : www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/
ConnectedHealth/default.htm
Groupe Speciale Mobile Association - GSMA : www.gsma.com
Guidelines International Network - GIN : www.g-i-n.net
HealthIT.gov : www.healthit.gov/patients-families/health-conditions
Institute for Clinical Systems Improvement : www.icsi.org
International Medical Device Regulators Forum - IMDRF : www.imdrf.org
International mHealth Standardization Consortium - IMHSC : www.imhsc.org/legislation_3.html
International Network of Agencies for Health Technology Assessment - INAHTA : www.inahta.org
CRD databases : www.crd.york.ac.uk/crdweb/
Medical Technology Association of Australia - MTAA : www.mtaa.org.au/homepage
Medicines or Healthcare products Regulatory Agency - MHRA : www.gov.uk/government/organisations/medicines-andhealthcare-products-regulatory-agency
National Guideline Clearinghouse - NGC : www.guideline.gov
National Health and Medical Research Council - NHMRC : www.nhmrc.gov.au/publications/index.htm
National Institute for Health and Clinical Excellence - NICE : www.nice.org.uk/page.aspx?o=home
National Institute of Health - NIH : obssr.od.nih.gov/scientific_areas/methodology/mhealth/
National Telecommunications and Information Agency - NTIA : www.ntia.doc.gov
New Zealand Guidelines Group - NZGG : www.nzgg.org.nz
NHS Evidence : www.evidence.nhs.uk
Observatoire de la m-sant : www.ifop.com/?option=com_offer&id=186
Organisation Mondiale de la Sant - OMS : www.who.int/fr
Privacy Rights Clearing House Association : www.privacyrights.org/content/about-privacy-rights-clearinghouse
Scottish Intercollegiate Guidelines Network - SIGN : www.sign.ac.uk/index.html
SFT - Socit franaise de tlmdecine : www.sft-antel.org/site/accueil.html
The Cochrane Library : www.mrw.interscience.wiley.com/cochrane/cochrane_search_fs.html
Therapeutic Goods Administration - TGA : www.tga.gov.au
Tripdatabase : www.tripdatabase.com/index.html
American
Attorney
En complment, une veille a t ralise sur Twitter avec les mots cls suivants : #mhealth OU mobile health OU m sant
OU #msant. Des comptes Twitter pertinents dans le domaine ont galement t suivis tout au long de ltude.
Annexe 4. Liste des tableaux

Tableau 1. Compilation non exhaustive des sites valuant les Apps/OC en sant au niveau de diffrents pays (prsent par
ordre alphabtique)
Tableau 2. Modulation du rfrentiel par une matrice de risque
Tableau 3. Liste des critres se rapportant aux informations utilisateurs
Tableau 4. Liste des critres se rapportant au contenu de sant du produit
Tableau 5. Liste des critres se rapportant au contenant technique du produit
Tableau 6. Liste des critres se rapportant la scurit et fiabilit du produit
Tableau 7. Liste des critres se rapportant lutilisation du produit
Annexe 5. Glossaire
Anonymisation
Moyen visant faire disparatre tout lien avec une personne. Le traitement de donnes personnelles, qui est normalement
interdit par la loi, peut tre autoris par la CNIL si les informations sensibles du traitement font lobjet, bref dlai, dun procd
danonymisation reconnu conforme la loi.
Big data
On parle depuis quelques annes du phnomne de big data, que lon traduit souvent par donnes massives . Avec le
dveloppement des nouvelles technologies, dinternet et des rseaux sociaux ces vingt dernires annes, la production de
donnes numriques a t de plus en plus nombreuse : textes, photos, vidos, etc. Le gigantesque volume de donnes
numriques produites combin aux capacits sans cesse accrues de stockage et des outils danalyse en temps rel de plus
en plus sophistiqus offre aujourdhui des possibilits ingales dexploitation des informations. Les ensembles de donnes
traits correspondant la dfinition du big data rpondent trois caractristiques principales : volume, vlocit et varit.
Cross-Site Request Forgery
Abrg CSRF (parfois prononc sea-surfing en anglais). Lobjet de cette attaque est de transmettre un utilisateur authentifi
une requte HTTP falsifie qui pointe sur une action interne au site, afin qu'il l'excute sans en avoir conscience et en utilisant
ses propres droits. Lutilisateur devient donc complice dune attaque sans mme s'en rendre compte. L'attaque tant actionne
par l'utilisateur, un grand nombre de systmes d'authentification sont contourns (source : Wikipedia).
Consentement
Consentement de la personne concerne, toute manifestation de volont, libre, spcifique, claire et univoque par laquelle
la personne concerne accepte, par une dclaration ou par un acte positif clair, que des donnes caractre personnel la
concernant fassent lobjet dun traitement.
Destinataire
La personne physique ou morale, lautorit publique, le service ou tout autre organisme qui reoit communication de donnes
caractre personnel, quil sagisse ou non dun tiers. Toutefois, les autorits publiques qui sont susceptibles de recevoir
communication de donnes caractre personnel dans le cadre dune mission denqute particulire conformment au droit
de lUnion ou au droit dun tat membre ne sont pas considres comme des destinataires ; le traitement de ces donnes par
les autori-ts publiques en question est conforme aux rgles applicables en matire de protection des donnes en fonction
des finalits du traitement.
Donnes caractre personnel
Toute information se rapportant une personne physique identifie ou identifiable (ci-aprs dnomme personne concerne);
est rpute tre une personne physique identifiable une personne physique qui peut tre identifie, directement ou
indirectement, notamment par rfrence un identifiant, tel quun nom, un numro didentification, des donnes de localisation,
un identifiant en ligne, ou un ou plusieurs lments spcifiques propres son identit physique, physiologique, gntique,
psychique, conomique, culturelle ou sociale.
Donne sensible
Information concernant lorigine raciale ou ethnique, les opinions politiques, philosophiques ou religieuses, lappartenance
syndicale, la sant ou la vie sexuelle. En principe, les donnes sensibles ne peuvent tre recueillies et exploites quavec le
consentement explicite des personnes.
Empowerment
L'empowerment, parfois aussi appele autonomisation au Qubec, est l'octroi de davantage de pouvoir aux individus ou aux
groupes pour agir sur les conditions sociales, conomiques, politiques ou cologiques qu'ils subissent (source : Wikipedia).
E-sant
Application des technologies de l'information et de la communication l'ensemble des activits en rapport avec la sant.
Golocalisation
Technologie permettant de dterminer la localisation dun objet ou dune personne avec une certaine prcision. La technologie
sappuie gnralement sur le systme GPS ou sur les interfaces de communication dun tlphone mobile. Les applications et
finalits de la golocalisation sont multiples : de lassistance la navigation, la mise en relation des personnes, mais aussi
la gestion en temps rel des moyens en personnel et en vhicules des entreprises, etc.
Mobile Health
Pratiques mdicales et de sant publique supportes par des appareils mobiles, tels que les tlphones mobiles, les dispositifs
de surveillance des patients, les PDA et autres appareils sans fil.
Ordiphone
Tlphone mobile coupl un assistant numrique personnel.
Phishing
Lhameonnage, phishing ou filoutage est une technique utilise par des fraudeurs pour obtenir des renseignements personnels
dans le but de perptrer une usurpation d'identit. La technique consiste faire croire la victime qu'elle s'adresse un tiers
de confiance banque, administration, etc. afin de lui soutirer des renseignements personnels : mot de passe, numro de
carte de crdit, date de nais-sance, etc. C'est une forme d'attaque informatique reposant sur l'ingnierie sociale. Elle peut se
faire par courrier lectronique, par des sites web falsifis ou autres moyens lectroniques (source : Wikipedia).
Pseudonymisation
Le traitement de donnes caractre personnel de telle faon que celles-ci ne puissent plus tre attribues une personne
concerne prcise sans avoir recours des informations supplmentaires, pour autant que ces informations supplmentaires
soient conserves sparment et soumises des mesures techniques et organisationnelles afin de garantir que les donnes
caractre personnel ne sont pas attribues une personne physique identifie ou identifiable.
Quantified-self
Le quantified-self dsigne la pratique de la mesure de soi et fait rfrence un mouvement n en Californie qui consiste
mieux se connatre en mesurant des donnes relatives son corps et ses activits.
Smartphone
Un smartphone est un tlphone mobile disposant d'un cran tactile et d'un appareil photo numrique, et des fonctions d'un
assistant numrique personnel et d'un ordinateur portable (source : Wikipedia).
Tiers
Une personne physique ou morale, une autorit publique, un service ou un organisme autre que la personne concerne, le
responsable du traitement, le sous-traitant et les personnes qui, places sous lautorit directe du responsable du traitement
ou du sous-traitant, sont autorises traiter les donnes caractre personnel.
Traitement
Toute opration ou tout ensemble doprations effectues ou non laide de procds automatiss et appliques des
donnes ou des ensembles de donnes caractre personnel, telles que la collecte, lenregistrement, lorganisation, la
structuration, la conservation, ladaptation ou la modification, lextraction, la consultation, lutilisation, la communication par
transmission, la diffusion ou toute autre forme de mise disposition, le rapprochement ou linterconnexion, la limitation,
leffacement ou la destruction.
Violation de donnes caractre personnel
Une violation de la scurit entranant, de manire accidentelle ou illicite, la destruction, la perte, laltration, la divulgation non
autorise de donnes caractre personnel transmises, conserves ou traites dune autre manire, ou laccs non autoris
de telles donnes.
Annexe 6. Mthode de travail

Ce document a t ralis de novembre 2015 septembre 2016. Il a t conduit pour la Haute Autorit de Sant (HAS) dans
le Service valuation de la pertinence des soins et amlioration des pratiques et des parcours (SA3P) par M. Pierre Trudelle,
chef de projet, en collaboration avec M. Marc Fumey, Adjoint au chef de service, avec laide dun groupe de travail et de deux
experts externes.
Le secrtariat a t effectu par Mme Michle Le Moigne, assistante de gestion, et avec le soutien de Mme Isabelle Le Puil,
assistante de gestion, pour la gestion rationalise des avis de lecture (GRaAL).
Un appel candidatures pour participer au groupe de travail a t ouvert en ligne entre le mois de novembre 2015 et le 31
dcembre 2015 (note de cadrage 19 novembre 2015). Le bureau de la Commission des parcours et des pratiques (CPP) de
la HAS a arrt la composition finale du groupe de travail et dlimit lattribution vers le groupe de lecture et celui des parties
prenantes lors de la runion 10 fvrier 2016. Les dclarations dintrts des membres du groupe de travail sont consultables
sur le site de la HAS (www.has-sante.fr).
Les runions du groupe de travail ont eu lieu les 22 mars 2016, 3 mai 2016 et 6 septembre 2016 toute la journe. Un groupe de
lecture, un groupe de parties prenantes et un groupe provenant du comit stratgique de filire (appel GT28 en rfrence la
mesure 28 du contrat stratgique de filire) a adress ses cotations en utilisant une chelle de Likert cte de 1 (dsaccord
total) 9 (accord total) sur lensemble des critres retenus via linterface GRaAL de la HAS entre la runion 2 et 3 du groupe de
travail de la HAS. Le groupe de lecture tait compos de membres slectionns lors de la CPP (principalement de personnes
non retenues lors de lappel participation du groupe de travail) et de personnes suggres par le groupe de travail.
La recherche documentaire a t effectue par Mme Marie Georget, documentaliste, et Mme Laurence Frigre assistantedocumentaliste, sous la direction de Mme Frdrique Pags, responsable du service documentation-veille de la HAS.
Le groupe de travail a contribu la rdaction des parties techniques de ce guide avec le soutien lors de la dernire runion
dexperts de lANSSI et de la CNIL. La slection et lanalyse de la littrature ont t ralises par M. Pierre Trudelle. La rdaction
de recommandations europennes sur le sujet se droulait en parallle la rdaction de ce document. M. Pierre Trudelle a
fait partie du groupe de travail (mHealth assessment guidelines) pour apporter et traduire les lments franais et synchroniser
les informations entre les groupes.
Le service juridique de la HAS a particip la rdaction du chapitre juridique et la relecture des critres sous la supervision de
Mme Ariane Sachs, juriste ; M. Emmanuel Planchet, juriste ; et Mme Christine Vincent, Chef du service juridique de la HAS.
La mise en forme du document a t ralise par M. Eric Darvoy, maquettiste-infographiste, sous la direction de Mme Annie
Chevallier, responsable du ple dition-diffusion au service communication-information.
Le passage en CPP a t effectu le 27 septembre 2016.
Le passage au Collge de la Haute Autorit de Sant a eu lieu le 26 octobre 2016.
Annexe 7. Participants
XX
Groupe de travail
Dr Vincent Achard, Matre de confrence universitaire, praticien hospitalier, Universit dAix-Marseille
Pr Rachid Bouchakour, Directeur dinstitut - CNRS, Universit dAix-Marseille
Dr Paul Cattaneo, Chirurgien-Dentiste, Paris
Dr Pascal Charbonnel, Mdecin Gnraliste Libral, Vice-Prsident du CMG, Les Ulis
Dr Sbastien Cossin, Mdecin de sant publique, CHU de Bordeaux
M. Mathieu Escot, Responsable des tudes, UFC- Que choisir, Paris
Dr Matthieu Faure, Ingnieur, Nmes
M. Marc Fumey, Adjoint au Chef de service, Service valuation de la pertinence des soins et amlioration des pratiques
et des parcours (SA3P), HAS, Saint-Denis
Dr Lela Gofti-Laroche, PharmD, PhD, Praticien Hospitalier, CHU Grenoble Alpes
M.Marin Guy, Kinsithrapeute, Centre Aquitain du Dos, Mrignac
Dr Philippe Hak, Docteur Ingnieur ETP/SUPELEC, Responsable du Dept nergie & Environnement lECE, Paris
Dr Ccile Hubsch, MD-PhD, Neurologue, Fondation Ophtalmologique A. de Rothschild, Paris
Dr Benjamin Kretz, Chirurgien vasculaire, CH de Colmar
Dr Pierre Liot, Chef de projet HAS, Service valuation de la pertinence des soins et amlioration des pratiques et des
parcours (SA3P), HAS, Saint-Denis
Dr Jacques Lucas, Vice-prsident CNOM, Paris
Dr Didier Mennecier, Praticien Hospitalier Militaire, Saint Mand
M. Lock Menvielle, EDHEC Business School, Nice
M. Herv Nabarette, Conseiller technique auprs du directeur, Direction de lvaluation mdicale, conomique et de
sant publique, HAS, Saint-Denis
Dr Grgory Perrard, Cardiologue, membre de la Commission Numrique du Syndicat National des Spcialistes des
Maladies du Coeur et des Vaisseaux, BAILLEUL
M. Vincent Rialle, Matre de confrence-Praticien Hospitalier mrite, Universit Grenoble-Alpes
M. Valentin Roby, Doctorant en droit public, Universit Lille 2
Dr Philippe Roux, Gnraliste, Samatan
Dr ric Sermet, Psychiatre, Lyon
M. Pierre Trudelle, Chef de projet HAS, pilote du projet, Service valuation de la pertinence des soins et amlioration des
pratiques et des parcours (SA3P), HAS, Saint-Denis
XX
Experts externes
M. Erik Boucher de Crvecur, Ingnieur expert, service de lexpertise technologique, CNIL, Paris
M. Benjamin Morin, Chef adjoint de la division scientifique et technique, Sous-direction Expertise ANSSI, Paris
XX
Groupe de lecture
Dr Marie-Christine Bene, Professeur des universits-praticiens hospitaliers, Universit de Nantes CHU de Nantes,
Dr Xavier Billres, Praticien Hospitalier, SAMU 13, CHU de Marseille
Dr Marie-Jos Botto Mongaboure, Praticien Hospitalier, Paris
Dr Franois Carbonnel, Mdecin gnraliste, Chef de clinique des Universits, Universit de Montpellier
M. Patrick Corne, Kinsithrapeute, Saint Max Lorraine
Dr Didier Cugy, Praticien Attach Consultant, CHU de Bordeaux
M. Stphane Delliaux, Matre de Confrences des Universits - Praticien Hospitalier, CHU dAix-Marseille
M. Clment Gravereaux, Doctorant-Chercheur, Universit Rennes 2 - Responsable de la Stratgie Digitale CHP de SaintGrgoire
M. Yoann Guymard, Infirmier rfrent en soin domicile (CMS) sur le canton de Vaud, Suisse
Dr Olivier Heloir, Pharmacien, Nord Pharma, Ligny en Cambrsis
Dr Bruno Housset, Professeur des Universits-Praticien Hospitalier, Chef de service, CHI de Crteil, Facult de Crteil
Dr David Lechaux, Chirurgien, CH de Saint Brieuc
Mme Blandine Meyrieux-Lefevre, Infirmire - Institut Godinot, Reims
M. Alexandre Perez, Kinsithrapeute, Bordeaux
M. Philippe Ruyer, Masseur-Kinsithrapeute, Les Angles
M. Martin Seyres, Doctorant-Chercheur, Bordeaux

M. Romain Tavignot, Infirmier Anesthsiste, Centre Antoine Lacassagne,Nice
M. Yannick Ung, Ergothrapeute, Doctorant-chercheur, Paris Descartes-Sorbonne
XX
Groupe partie prenante
Pr Francois-Andr Allaert, Titulaire de la Chaire dvaluation des allgations de sant ESC Dijon
Dr Patrick Bacquaert, Mdecin Chef IRBMS - Mdecin de mdecine physique, Villeneuve d Ascq
M. Jrme Beranger, Co-fondateur dADEL (Algorithm Data Ethics Label) et Chercheur (PhD) associ lInserm 1027 quipe 4 - Universit Paul Sabatier, Toulouse
Dr Fabrice Denis, Oncologue-Radiothrapeute, Le Mans
Pr Sbastien Faure, Professeur des universits, UFR sant, dpartement pharmacie, INSERM U1066, Universit dAngers
M. Frdric Faurennes, Directeur Associ VIRTUAL CARE, Chantilly
Dr Sylvia Franc, Praticien Hospitalier en Diabtologie, CH Sud-Francilien, Corbeil Essonne, directeur scientifique du
Centre de Recherche CERITD, Evry
Mme Karine Gueye-Gauchet, Conseillre Mdico -Technique, Champigny Sur Marne
Dr Aurore Guillaume, Endocrinologue, Groupe Elgar, Saint Jean de Luz
Dr Ccile Monteil, Mdecin aux urgences pdiatriques de lhpital Robert Debr, Directrice Mdicale chez iLumens,
Fondatrice dEppocrate, Paris
Mr David Sainati, Prsident, MEDAPPCARE, Paris
M. Alain Tassy, Grant, Virtualtel, Meudon
Dr Mobin Yasini, Directeur Recherche et Dveloppement, mHealth Quality (dmd Sant), Paris
XX
Groupe de travail 28 (en rfrence la mesure 28 du contrat de filire) du comit stratgique de filire consults
M. Alain Boulanger, Direction gnrale de la concurrence, de la consommation et de la rpression des fraudes, Paris
Mme Raphalle Bove, Direction gnrale de la concurrence, de la consommation et de la rpression des fraudes, Paris
Mme Hlne Bruyere, ANSM, Saint-Denis
M. Aymeric Buthion, DGE, Ministre de lconomie et des Finances, Paris
M. Emmanuel Clout, Responsable programme labellisation, Agence des Systmes dInformation Partags de Sant,
Paris
Dr Thierry Dart, Docteur en mdecine, Agence des Systmes dInformation Partags de Sant, Paris
M. Marcelo Dias de Amorim, Direction Gnrale pour la Recherche et lInnovation, Paris
Isabelle Diaz, Direction des Affaires Scientifiques, Les Entreprises du Mdicament, Paris
Mme Florence on, Directrice du service juridique, Agence des Systmes dInformation Partags de Sant, Paris
M. Vincent Franchi, DGE, Ministre de lconomie et des Finances, Paris
M. Guirec Le Lous, UrgoTech, Paris
M. Pierre Leurent, Prsident du Directoire, Voluntis, Paris
Mme Elinaz Mahdavy, Orange Healthcare Responsable des Affaires Europennes, Bruxelles
M. Francis Mambrini, Fdration des diteurs dInformatique Mdicale et Paramdicale Ambulatoire, Boulogne Billancourt
Dr Florence Oll, Pharmacienne, Syndicat National de lIndustrie des Technologies Mdicales, Paris
M. Stphane Pasquier, FSSI, Ministres chargs des Affaires Sociales, Paris
M. Robert Picard, Prsident Forum Living Labs Sant Autonomie, Paris
Dr Pierre Simon, Socit Franaise de Tlmdecine, Paris
M. Jean Vannimenus, DGRI / SSRI - Secteur A3, Paris
M. Dominique Vital, Directeur Recherche et Dveloppement, STAGO, Asnires sur Seine
Rfrences
1. de la Vega R, Miro J. mHealth: a strategic field without
a solid scientific soul. a systematic review of pain-related
apps. PLoS One 2014;9(7):e101312.
15. Yasini M, Marchand G. Toward a use case based

classification of mobile health applications. Stud Health
Technol Inform 2015;210:175-9.
2. Canada Health Infoway. Mobile health computing

between clinicians and patient. Montral: CHI; 2014.
16. Vallespin B, Cornet J, Kotzeva A. Ensuring EvidenceBased Safe and Effective mHealth Applications. Stud
Health Technol Inform 2016;222:248-61.
3. Park LG, Howie-Esquivel J, Dracup K. A quantitative

systematic review of the efficacy of mobile phone
interventions to improve medication adherence. J Adv
Nurs 2014;70(9):1932-53.
4. Bailey SC, Belter LT, Pandit AU, Carpenter DM, Carlos
E, Wolf MS. The availability, functionality, and quality
of mobile applications supporting medication selfmanagement. J Am Med Inform Assoc 2014;21(3):542-6.
5. Fiordelli M, Diviani N, Schulz PJ. Mapping mHealth
research: a decade of evolution. J Med Internet Res
2013;15(5):e95.
6. Gagnon MP, Ngangue P, Payne-Gagnon J, Desmartis
M. m-Health Adoption by Healthcare Professionals: A
Systematic Review. J Am Med Inform Assoc 2015.
7. Canadian Advanced Technology Alliance. Mobile health
Canada turn up the volume. Ottawa: CATA; 2014.
8. World Health Organization. mHealth. New horizons for
health through mobile technologies : second global survey
on eHealth. Geneva: WHO; 2011.
www.who.int/goe/publications/goe_mhealth_web.pdf
9. Center for Health + Biosciences, Rice University's Baker
Institute for Public Health, Moore Q, Johnson A. U.S.
Health care technologies. Houston: BIPP; 2015.
17. Labrique AB, Vasudevan L, Kochi E, Fabricant R, Mehl

G. mHealth innovations as health system strengthening
tools: 12 common applications and a visual framework.
Glob Health Sci Pract 2013;1(2):160-71.
18. Bender JL, Yue RY, To MJ, Deacken L, Jadad AR. A lot
of action, but not in the right direction: systematic review
and content analysis of smartphone applications for the
prevention, detection, and management of cancer. J Med
Internet Res 2013;15(12):e287.
19. Yetisen AK, Martinez-Hurtado JL, da Cruz
Vasconcellos F, Simsekler MC, Akram MS, Lowe CR.
The regulation of mobile medical applications. Lab Chip
2014;14(5):833-40.
20. Hussain M, Al-Haiqi A, Zaidan AA, Zaidan BB,
Kiah ML, Anuar NB, et al. The landscape of research
on smartphone medical apps: Coherent taxonomy,
motivations, open challenges and recommendations.
Comput Methods Programs Biomed 2015;122(3):393-408.
21. Cook SE, Palmer LC, Shuler FD. Smartphone mobile
applications to enhance diagnosis of skin cancer: A guide
for the rural practitioner. W V Med J 2015;111(5):22-8.
10. Aungst TD, Clauson KA, Misra S, Lewis TL,

Husain I. How to identify, assess and utilise mobile
medical applications in clinical practice. Int J Clin Pract
2014;68(2):155-62.
22. World Health Organization. From innovation to

implementation eHealth in the WHO European Region
Copenhagen: WHO; 2016.
www.euro.who.int/__data/assets/pdf_file/0012/302331/
From-Innovation-to-Implementation-eHealth-Report-EU.
pdf?ua=1
11. Lewis TL, Boissaud-Cooke MA, Aungst TD,

Eysenbach G. Consensus on use of the term "App" versus
"Application" for reporting of mHealth research. J Med
Internet Res 2014;16(7):e174; discussion e.
23. Huckvale K, Prieto JT, Tilney M, Benghozi PJ, Car

J. Unaddressed privacy risks in accredited health and
wellness apps: a cross-sectional systematic assessment.
BMC Med 2015;13:214.
12. Agarwal S, LeFevre AE, Lee J, L'Engle K, Mehl

G, Sinha C, et al. Guidelines for reporting of health
interventions using mobile phones: mobile health (mHealth)
evidence reporting and assessment (mERA) checklist.
BMJ 2016;352:i1174.
24. Food and Drug Administration. Mobile medical

applications : Guidance for Food and Drug Administration
Staff. Silver Spring: FDA; 2015.
www.fda.gov/downloads/MedicalDevices/
DeviceRegulationandGuidance/GuidanceDocuments/
UCM263366.pdf
13. Dumez H, Minvielle E, Marrauld L. Etat des lieux de

linnovation en sant numrique. Paris: Fondation de
l'avenir; 2015.
www.fondationdelavenir.org/wp-content/uploads/2015/11/
Etat-des-lieux-sante-num%C3%A9rique-EditionAug.pdf
14. Mosa AS, Yoo I, Sheets L. A systematic review of
healthcare applications for smartphones. BMC Med Inform
Decis Mak 2012;12:67.
25. Cortez NG, Cohen IG, Kesselheim AS. FDA

regulation of mobile health technologies. N Engl J Med
2014;371(4):372-9.
26. Royal College of Physicians. Using apps in clinical
practice [En ligne]. London: RCP; 2015.
27. Medecine & Healthcare producs Regulary Agency.

Medical device stand-alone software including apps [En
ligne]: MHRA; 2014.
www.gov.uk/government/publications/medical-devicessoftware-applications-apps/medical-device-stand-alonesoftware-including-apps
28. International Medical Device Regulators Forum.
Software as a Medical Device (SaMD): Key definitions :
IMDRF; 2013.
www.imdrf.org/docs/imdrf/final/technical/imdrf-tech131209-samd-key-definitions-140901.pdf
29. Quinn P, Habbig AK, Mantovani E, De Hert P. The data
protection and medical device frameworks - obstacles to
the deployment of mHealth across Europe? Eur J Health
Law 2013;20(2):185-204.
30. ITU. Filling the gap: Legal and regulatory challenges of
mobile health (mHealth) in Europe : ITU; 2014.
www.itu.int/en/ITU-D/Regional-Presence/Europe/
Documents/ITU%20mHealth%20Regulatory%20gaps%20
Discussion%20Paper%20June2014.pdf
31. Charani E, Castro-Sanchez E, Moore LS, Holmes
A. Do smartphone applications in healthcare require a
governance and legal framework? It depends on the
application! BMC Med 2014;12:29.
32. Academy of Medical Sciences, Royal Academy of
Engineering. Health apps: regulation and quality control.
London: AMS; 2015.
www.raeng.org.uk/publications/reports/health-appsregulation-and-quality-control
33. Conseil national de lordre des mdecins. Sant
connecte. De la e-sant la sant connect. Livre blanc.
Paris: CNOM; 2015.
www.conseil-national.medecin.fr/sites/default/files/
medecins-sante-connectee.pdf
34. Commission nationale de l'informatique et des liberts.
tude de benchmark sur les rgulations concernant
l'utilisation dans le domaine de la sant et du bien-tre des
capteurs, smartphones et autres objets connects. Paris:
CNIL; 2013.
35. Schulke DF. The regulatory arms race : mobile health
applications and agency posturing. Boston University Law
Rev 2013;93(1699):1700-52.
36. Whittaker R, Merry S, Dorey E, Maddison R. A
development and evaluation process for mHealth
interventions: examples from New Zealand. J Health
Commun 2012;17 Suppl 1:11-21.
37. Gonnermann A, von Jan U, Albrecht UV. Draft guideline
for the development of evidence based medicine-related
apps. Stud Health Technol Inform 2015;210:637-41.
38. McMillan B, Hickey E, Patel MG, Mitchell C. Quality
assessment of a sample of mobile app-based health
behavior change interventions using a tool based on the
National Institute of Health and Care Excellence behavior
change guidance. Patient Educ Couns 2015.
39. Albrecht UV, Von Jan U, Pramann O. Standard

reporting for medical apps. Stud Health Technol Inform
2013;190:201-3.
40. Salber P, Niksch A. A beginner's guide to digital health
for ambulatory care clinicians. J Ambul Care Manage
2015;38(1):91-4.
41. Murfin M. Know your apps: an evidence-based
approach to evaluation of mobile clinical applications. J
Physician Assist Educ 2013;24(3):38-40.
42. Chan S, Torous J, Hinton L, Yellowlees P. Towards
a framework for evaluating mobile mental health apps.
Telemed J E Health 2015;21(12):1038-41.
43. Huckvale K, Car M, Morrison C, Car J. Apps for
asthma self-management: a systematic assessment of
content and tools. BMC Med 2012;10:144.
44. Safavi S, Shukur Z. Conceptual privacy framework
for health information on wearable device. PLoS One
2014;9(12):e114306.
45. Payne HE, Lister C, West JH, Bernhardt JM. Behavioral
functionality of mobile apps in health interventions: a
systematic review of the literature. JMIR Mhealth Uhealth
2015;3(1):e20.
46. Free C, Phillips G, Watson L, Galli L, Felix L, Edwards
P, et al. The effectiveness of mobile-health technologies
to improve health care service delivery processes:
a systematic review and meta-analysis. PLoS Med
2013;10(1):e1001363.
47. Hamine S, Gerth-Guyette E, Faulx D, Green BB,
Ginsburg AS. Impact of mHealth chronic disease
management on treatment adherence and patient
outcomes: a systematic review. J Med Internet Res
2015;17(2):e52.
48. Elbert NJ, van Os-Medendorp H, van Renselaar
W, Ekeland AG, Hakkaart-van Roijen L, Raat H, et
al. Effectiveness and cost-effectiveness of ehealth
interventions in somatic diseases: a systematic review of
systematic reviews and meta-analyses. J Med Internet Res
2014;16(4):e110.
49. Jones SP, Patel V, Saxena S, Radcliffe N, Ali Al-Marri
S, Darzi A. How Google's 'ten Things We Know To Be
True' could guide the development of mental health mobile
apps. Health Aff (Millwood) 2014;33(9):1603-11.
50. de la Torre-Diez I, Lopez-Coronado M, Vaca C, Aguado
JS, de Castro C. Cost-utility and cost-effectiveness studies
of telemedicine, electronic, and mobile health systems
in the literature: a systematic review. Telemed J E Health
2015;21(2):81-5.
51. Russell-Minda E, Jutai J, Speechley M, Bradley K,
Chudyk A, Petrella R. Health technologies for monitoring
and managing diabetes: a systematic review. J Diabetes
Sci Technol 2009;3(6):1460-71.
52. Liang X, Wang Q, Yang X, Cao J, Chen J, Mo X,
et al. Effect of mobile phone intervention for diabetes
on glycaemic control: a meta-analysis. Diabet Med
2011;28(4):455-63.
53. Holtz B, Lauckner C. Diabetes management via

mobile phones: a systematic review. Telemed J E Health
2012;18(3):175-84.
54. Gray LJ, Leigh T, Davies MJ, Patel N, Stone M,
Bonar M, et al. Systematic review of the development,
implementation and availability of smart-phone
applications for assessing type 2 diabetes risk. Diabet Med
2013;30(6):758-60.
55. Liu F, Kong X, Cao J, Chen S, Li C, Huang J,
et al. Mobile phone intervention and weight loss
among overweight and obese adults: a meta-analysis
of randomized controlled trials. Am J Epidemiol
2015;181(5):337-48.
56. O'Reilly GA, Spruijt-Metz D. Current mHealth
technologies for physical activity assessment and
promotion. Am J Prev Med 2013;45(4):501-7.
57. Stephens J, Allen J. Mobile phone interventions to
increase physical activity and reduce weight: a systematic
review. J Cardiovasc Nurs 2013;28(4):320-9.
58. Wearing JR, Nollen N, Befort C, Davis AM, Agemy CK.
iPhone app adherence to expert-recommended guidelines
for pediatric obesity prevention. Child Obes 2014;10(2):13244.
59. Bort-Roig J, Gilson ND, Puig-Ribera A, Contreras RS,
Trost SG. Measuring and influencing physical activity with
smartphone technology: a systematic review. Sports Med
2014;44(5):671-86.
60. Fanning J, Mullen SP, McAuley E. Increasing physical
activity with mobile devices: a meta-analysis. J Med
Internet Res 2012;14(6):e161.
61. Marcano Belisario JS, Huckvale K, Greenfield G, Car J,
Gunn LH. Smartphone and tablet self management apps
for asthma (Review). Cochrane Database of Systematic
Review 2013;Issue 11:CD010013.
62. Huckvale K, Morrison C, Ouyang J, Ghaghda A, Car
J. The evolution of mobile apps for asthma: an updated
systematic assessment of content and tools. BMC Med
2015;13:58.
63. Riezebos RJ. Peer-reviewing of mHealth applications.
Requirements for peer-reviewing mobile health applications
and development of an online peer review tool Amsterdam:
University of Amsterdam; 2014.
dare.uva.nl/cgi/arno/show.cgi?fid=573074
64. Lewis TL, Wyatt JC. mHealth and mobile medical
Apps: a framework to assess risk and promote safer use. J
Med Internet Res 2014;16(9):e210.
65. BinDhim NF, Hawkey A, Trevena L. A systematic review
of quality assessment methods for smartphone health
apps. Telemed J E Health 2015;21(2):97-104.
66. Hilliard ME, Hahn A, Ridge AK, Eakin MN, Riekert KA.
User preferences and design recommendations for an
mHealth app to promote cystic fibrosis self-management.
JMIR Mhealth Uhealth 2014;2(4):e44.
67. Jibb LA, Stevens BJ, Nathan PC, Seto E, Cafazzo

JA, Stinson JN. A smartphone-based pain management
app for adolescents with cancer: establishing system
requirements and a pain care algorithm based on literature
review, interviews, and consensus. JMIR Res Protoc
2014;3(1):e15.
68. Bull S, Ezeanochie N. From foucault to freire through
facebook: Toward an integrated theory of mHealth. Health
Educ Behav 2015.
69. Patel MS, Asch DA, Volpp KG. Wearable devices as
facilitators, not drivers, of health behavior change. JAMA
2015;313(5):459-60.
70. Silow-Carroll S, Smith B. Clinical management apps:
creating partnerships between providers and patients.
Issue Brief (Commonw Fund) 2013;30:1-10.
71. Kumar S, Nilsen WJ, Abernethy A, Atienza A, Patrick
K, Pavel M, et al. Mobile health technology evaluation:
the mHealth evidence workshop. Am J Prev Med
2013;45(2):228-36.
72. Tomlinson M, Rotheram-Borus MJ, Swartz L, Tsai AC.
Scaling up mHealth: where is the evidence? PLoS Med
2013;10(2):e1001382.
73. Wolf JA, Moreau JF, Akilov O, Patton T, English JC,
3rd, Ho J, et al. Diagnostic inaccuracy of smartphone
applications for melanoma detection. JAMA Dermatol
2013;149(4):422-6.
74. European Commission. Summary report on the public
consultation on the green paper on mobile health [En
ligne]. Brussels: EC; 2015.
ec.europa.eu/digital-single-market/en/news/summaryreport-public-consultation-green-paper-mobile-health
75. Albrecht UV, Pramann O, Von Jan U. Medical Apps.
the road to trust. Eur J Biomed Info 2015;11(3):en7-en12.
76. Bierbrier R, Lo V, Wu RC. Evaluation of the accuracy of
smartphone medical calculation apps. J Med Internet Res
2014;16(2):e32.
77. Chyjek K, Farag S, Chen KT. Rating pregnancy wheel
applications using the APPLICATIONS scoring system.
Obstet Gynecol 2015;125(6):1478-83.
78. Huckvale K, Adomaviciute S, Prieto JT, Leow MK,
Car J. Smartphone apps for calculating insulin dose: a
systematic assessment. BMC Med 2015;13:106.
79. European Commission, Joint Research Centre, Gemo
M, Lunardi D, Tallacchini M. Wearable sensors and digital
platforms in health: empowering citizens through trusted
and trustworthy ICT technology. Luxembourg: European
Union; 2015.
80. Martinez-Perez B, de la Torre-Diez I, Lopez-Coronado
M. Privacy and security in mobile health apps: a review
and recommendations. J Med Syst 2015;39(1):181.
81. Open Web Application Security Project. OWAPS TOP
10 2013. Les dix risques de scurit applications web les
plus critiques : OWAPS; 2015.
82. Sunyaev A, Dehling T, Taylor PL, Mandl KD. Availability

and quality of mobile health app privacy policies. J Am
Med Inform Assoc 2014;22(e1):e28-33.
83. Conseil des acadmies canadiennes. Laccs aux
donnes sur la sant et aux donnes connexes au
Canada. Ottawa: CAC; 2015.
sciencepourlepublic.ca/uploads/fr/assessments%20
and%20publications%20and%20news%20releases/
health-data/HealthDataExecSumFr.pdf
84. Association franaise de normalisation. Le livre blanc
donnes massives - Big Data. Impact et attentes pour la
normalisation. Saint-Denis: AFNOR; 2015.
85. Cruz Zapata B, Fernandez-Aleman JL, Idri A, Toval
A. Empirical studies on usability of mHealth apps: a
systematic literature review. J Med Syst 2015;39(2):1.
86. Arnhold M, Quade M, Kirch W. Mobile applications
for diabetics: a systematic review and expert-based
usability evaluation considering the special requirements
of diabetes patients age 50 years or older. J Med Internet
Res 2014;16(4):e104.
87. Watkins I, Xie B. eHealth literacy interventions for older
adults: a systematic review of the literature. J Med Internet
Res 2014;16(11):e225.
95. Lobelo F, Kelli HM, Tejedor SC, Pratt M, McConnell

MV, Martin SS, et al. The Wild Wild West: A framework to
integrate mHealth software applications and wearables
to support physical activity assessment, counseling and
interventions for cardiovascular disease risk reduction.
Prog Cardiovasc Dis 2016;58(6):584-94.
96. Brooke J. SUS - A quick and dirty usability scale [En
ligne]: Usualy. gov; 1996.
www.usability.gov/how-to-and-tools/methods/systemusability-scale.html
97. Martinez-Perez B, de la Torre-Diez I, CandelasPlasencia S, Lopez-Coronado M. Development and
evaluation of tools for measuring the quality of experience
(QoE) in mHealth applications. J Med Syst 2013;37(5):9976.
98. Queensland University of Technology. Mobile
Application Rating Scale (MARS). App Classification.
Brisbane: QUT; 2015.
99. Stoyanov SR, Hides L, Kavanagh DJ, Zelenko O,
Tjondronegoro D, Mani M. Mobile app rating scale: a new
tool for assessing the quality of health mobile apps. JMIR
Mhealth Uhealth 2015;3(1):e27.
88. Monkman H, Kushniruk A. A health literacy and

usability heuristic evaluation of a mobile consumer health
application. Stud Health Technol Inform 2013;192:724-8.
89. Caburnay CA, Graff K, Harris JK, McQueen A,
Smith M, Fairchild M, et al. Evaluating diabetes mobile
applications for health literate designs and functionality,
2014. Prev Chronic Dis 2015;12:E61.
90. Collins SA, Currie LM, Bakken S, Vawdrey DK, Stone
PW. Health literacy screening instruments for eHealth
applications: a systematic review. J Biomed Inform
2012;45(3):598-607.
91. Georgsson M, Staggers N. Quantifying usability: an
evaluation of a diabetes mHealth system on effectiveness,
efficiency, and satisfaction metrics with associated user
characteristics. J Am Med Inform Assoc 2015.
92. Hall AK, Cole-Lewis H, Bernhardt JM. Mobile text
messaging for health: a systematic review of reviews. Annu
Rev Public Health 2015;36:393-415.
93. Khoja S, Durrani H, Scott RE, Sajwani A, Piryani U.
Conceptual framework for development of comprehensive
e-health evaluation tool. Telemed J E Health 2013;19(1):4853.
94. British Standards Institution. Health and wellness apps.
Quality criteria across the life cycle. Code of practice.
London: BSI; 2015.
shop.bsigroup.com/upload/271432/PAS%20277%20(2015)
bookmarked.pdf
www.has-sante.fr
Haute Autorit de Sant Octobre 2016 N ISBN 978-2-11-151440-9
Toutes les publications de la HAS sont tlchargeables sur

HAS Objets Connectes

Transféré par

Droits d'auteur :

Formats disponibles

HAS Objets Connectes

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HAS Objets Connectes

Transféré par

Droits d'auteur :

Formats disponibles

valuation et amlioration

Rfrentiel de bonnes pratiques

Ce document et les ressources complmentaires

Ce document a t valid par le Collge de la Haute Autorit de sant en octobre 2016.

2. Le rfrentiel de bonnes pratiques....................................................................................14

3. Mise en uvre du rfrentiel de bonnes pratiques...................................................... 43

Association franaise de normalisation

Association franaise des correspondants la protection des donnes caractre personnel

Agence nationale de scurit du mdicament et des produits de sant

Agence nationale de la scurit des systmes dinformations

Applications mobiles/objet connect

Agence des systmes dinformation partags de sant

Marquage CE (conforme aux exigences)

Computer Emergency Response Team pour la France

Conditions gnrales dutilisation

Commission nationale de linformatique et des liberts

Cross-Site Request Forgery

Donnes caractre personnelles

Expression des besoins et identification des objectifs de scurit

Essai contrl randomis

European Union Agency for Network and Information Security

Foire aux questions

General Data Protection Regulation

Haute Autorit de Sant

Hbergeur de donnes de sant

Health On the Net foundation

Indice de masse corporelle

Interface homme machine

International Organization for Standardization

Mobile health (sant mobile)

Open Web Application Security Project

Publically Available Specification

Personal Digital Assistant

Rfrentiel gnral dinteroprabilit

Rfrentiel gnral daccessibilit pour les administrations

Rfrentiel gnral de scurit

Short Message Service

Technologies de linformation et de la communication pour lducation

Transport Layer Security

Cross-Site Scripting (parfois not CSS)

World Wide Web Consortium

1.1 Dfinitions et concepts : Applications, objets connects

1.2 Classifications retrouves dans la littrature

1.3 valuation de la sant mobile dans diffrents pays

ZTG Zentrum fr Telematik und Telemedizin GmbH

AppSaludable : Catlogo de aplicaciones

Agency of Healthcare Quality of Andalusia

Academy of Nutrition and Dietetics

Greater New York Hospital Association

Groupe Pasteur Mutualit

SANOFI & DMD sant

Royal Dutch Medical Association (KNMG)24

Medical App Checker

UKs National Health Service (NHS) Apps

1.3.1 Systme dvaluation mis en place un niveau rgional ou national

1.3.2 chelles et scores dvaluation

1.4 Mesure dimpact et/ou defficacit

1.4.1 Revue systmatique sur la sant mobile

1.4.2 Quelques rsultats sur des problmes de sant