programme « Hôpital numérique» - crsa-pays-de-la … · programme Hôpital Numérique Aboutissement à un autodiagnostic arrêté et un plan d’action réaliste Apport intéressant

Mise en conformité des systèmes

d’information hospitaliers avec le

programme « Hôpital numérique»

Rapport final de l’accompagnement

Janvier 2014

2014 – Agence Régionale de Santé des Pays de la Loire – Direction de l’Efficience de l’Offre - 2

1. Rappel de la démarche et retour sur l’accompagnement individuel

2. Restitution des résultats de l’accompagnement

3. Restitution des points de difficultés rencontrés dans la mise en œuvre du plan

d’actions

Plan




3. Restitution des points de difficultés rencontrés dans la mise en œuvre du plan d’actions

Sommaire


Rappel de la démarche de travail proposée pour l’accompagnement des

établissements de santé sur l’atteinte des pré-requis techniques.

Phase 1

Finalisation du dispositif

d’accompagnement

individuel et collectif

Phase 2

Accompagnement collectif – animation des formations-actions

Accompagnement à l’élaboration des plans d’actions pour l’atteinte des indicateurs définis

par le programme Hôpital Numérique pour un groupe d’une vingtaine d’établissements

régionaux

Phase 3

Accompagnement individuel

Evaluation « à chaud » de l’accompagnement

Phase

préalable :

Finalisation

du cadrage et

lancement de

la démarche

Evaluation à

froid de

l’accompagne

ment

Clôture de

l’accompagne

ment

T3 2013 T4 2013 Janvier 2014

11/09 : Réunion de lancement avec les

établissements

1er et 2/10 : 1ère journée

d’accompagnement collectif

Entre le 04/10 et le 14/10 : préparation

de l’accompagnement individuel

Entre le 14/10 et le 10/01/14 :

accompagnement individuel des

établissements

29 Janvier 2014 : 2ème journée

d’accompagnement collectif

Janvier 2014 : évaluation à froid et

conclusion


En s’appuyant sur la boîte à outils fournie par le niveau national, l’accompagnement proposer

devait permettre d’aider les établissements à :

Cet accompagnement individuel poursuivait 3 objectifs

3. Cadrer

certains

livrables clés

(Plan de

Reprise

d’Activité,

Politique de

Sécurité, …)

2. Définir le

plan d’actions

qui leur

permettrait

d’atteindre les

pré-requis

techniques

d’ici fin 2014

1. Aboutir à un

état des lieux

d’atteinte des

pré-requis

techniques

exhaustif et

réaliste


L’accompagnement méthodologique s’est effectué en s’appuyant sur la boîte à

outils proposée par le Ministère de la Santé

• La boîte à outils est disponible à l’adresse suivante :

http://www.sante.gouv.fr/spip.php?page=article&id_article=12293

• Cette boîte à outils comprend :

• Un outil d’autodiagnostic (format Excel) et son guide d’utilisation

• 7 fiches pratiques :

• Fiche n°1 : Cellule Identito-Vigilance

• Fiche n°2 : MAJ Référentiel de Structure

• Fiche n°3 : PRA

• Fiche n°4 : Calcul du taux de disponibilité

• Fiche n°5 : Procédure Mode dégradé

• Fiche n°6 : RSSI et référent sécurité

• Fiche n°7 : Charte SI

A réaliser pour avoir un

autodiagnostic complet d’atteinte

des pré-requis, ainsi qu’un plan

d’actions généré automatiquement

A utiliser dans le cadre de la mise

en œuvre du plan d’actions, et ce

pour atteindre des indicateurs de

pré-requis spécifiques



D’un point de vue méthodologique, cet accompagnement devait aider les

établissements à lever les difficultés rencontrées pour mener l’exercice

d’autodiagnostic

Note: Verbatim récoltés à l’issue des journées d’accompagnement individuel

COMPREHENSION

DES INDICATEURS

et fonctionnement

de l’outil national

d’auto-diagnostic

DEMARCHE

PROJET

INVENTAIRE

APPLICATIF

• Interprétation de certains indicateurs

• Contenu exigé dans les différents onglets de l’outil

• Périmètre des applicatifs concernés par les calculs

• Recul par rapport aux résultats d’autodiagnostic

• Manque de temps pour mettre en application le

programme HN

• Mobilisation des acteurs sur le programme Hôpital

Numérique

• Aboutissement à un plan d’actions pragmatique

• Etat des lieux exhaustif des applications

• Formalisation de l’inventaire et cartographie

des applications

• Périmètre des applications à intégrer dans

les prérequis


Evaluation de l’accompagnement proposé

Note: Verbatims colectés à l’issue des journées d’accompagnement individuel

Points d’amélioration

Clarifier les instructions

d'utilisation de l'outil

d'autodiagnostic

Apporter plus d’éléments sur

les risques

Améliorer la fiabilité des

calculs produits par l'outil

d'autodiagnostic

Points forts

Bonne maîtrise du contenu du

programme Hôpital Numérique

Aboutissement à un autodiagnostic

arrêté et un plan d’action réaliste

Apport intéressant en termes de

méthodologie

Lien et partage d’expérience avec les

autres établissements

Effort d’adaptation au contexte de

l’établissement

Regard extérieur

Aide pour une prise de conscience de

la direction

La présence deux jours sur place a

permis de se concentrer pleinement

sur les enjeux HN

Echanges de qualité dans la réflexion

à mener Aide à la mobilisation des acteurs

concernés

Apporter plus de livrables ou

outils

Aide pour plan d’actions structuré et

clair

Bonne structuration de la démarche Satisfaction de l’ensemble de

l’établissement sur les explications et

l’appui apporté

Influence positive sur la direction

d’établissement (prise de conscience) Explications claires sur les indicateurs

Bonne structuration des 2 journées de

travail

Accompagnement clair Emulation de la DSI autour du

programme HN suite aux deux jours

A c

haud

A fro

id




3. Regards croisés sur les plans d’actions et premières difficultés rencontrées dans la mise en œuvre

Sommaire


Evolution des résultats d’atteinte des indicateurs de pré-requis techniques

avant et après accompagnement

52%

45%

52%

71%

31%

52%

0%

10%

20%

30%

40%

50%

60%

70%

80%

Identité Mouvements

Fiabilité Disponibilité

Confidentialité

juil-13 janv-14

Remarque préalable :

• Les résultats à janvier 2014 n’intègrent pas

les avancées des établissements suite au

lancement des plans d’actions.

Facteurs d’analyse des écarts entre les 2

périodes :

• Une base de réponse sur l’ensemble des

indicateurs plus complète après

l’accompagnement (un remplissage initial

d’oSIS hétérogène entre les

établissements de l’échantillon)

• Des indicateurs (notamment sur le P2)

revus à la baisse car resserrement des

conditions pour lesquelles le critère

pouvait être considéré comme atteint.

• Pour le calcul des seuils d’éligibilité,

l’accompagnement à l’autodiagnostic

portait sur l’intégralité du parc applicatif

existant, sans retirer ceux pour lesquels

des financements vont être demandés

dans le cadre des domaines fonctionnels.

- Moyenne des résultats consolidés d’atteinte

des indicateurs de pré-requis techniques -

Sources : oSIS, juillet 2013 / résultats d’accompagnement

individuel, janvier 2014


83,4

24,0

41,0

79,5

17,0

41,0

82,5

53,0

80,0

38,3

58,0

40,0

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

90,0

Identité Mouvements Fiabilité Disponibilité Confidentialité

Moyenne pour l’ensemble des 20 établissements sur les indicateurs de

prérequis

Détail des résultats d’autodiagnostic post accompagnement

sur chaque indicateur P

1.1

Réfé

ren

tie

l un

iqu

e d

’ide

ntité

s d

es p

atie

nts

P1

.2 C

ellu

le d

’ide

ntito

-vig

ilance

op

éra

tio

nn

elle

P1

.3 R

éfé

ren

tie

l un

iqu

e d

e s

éjo

urs

/mo

uve

me

nts

P1

.4 R

éfé

ren

tie

l un

iqu

e d

e

str

uctu

re

P2

.1 P

lan

de

re

pri

se

d’a

ctivité

du

SI

P2

.2 T

au

x d

e d

isp

on

ibili

té

de

s a

pp

lica

tio

ns

P2

.3 P

rocé

du

re d

e fo

nctio

nn

em

en

t e

n

mo

de

dé

gra

dé

/re

tou

r à

la

no

rma

le

P3

.1 P

olit

iqu

e d

e s

écu

rité

P3

.2 C

ha

rte

fo

rma

lisa

nt le

s r

èg

les

d’a

ccè

s e

t d

’usa

ge

du

SI

P3

.3 In

form

atio

n d

u p

atie

nt su

r le

s c

on

ditio

ns

d’u

tilis

atio

n d

es d

on

né

es d

e s

an

té

P3

.4 C

ap

acité

de

s a

pp

lica

tio

ns à

in

tég

rer

un

dis

po

sitif d

’au

the

ntifica

tion

pe

rso

nn

elle

P3

.5 C

ap

acité

de

s a

pp

lica

tio

ns

à tra

ce

r le

s c

on

ne

xio

ns

Indicateur

Note la

plus

haute

Note la plus

haute la

plus

souvent

obtenue

Note la plus

basse la plus

souvent

obtenue

Note la

plus

basse

P.1.1 100% 100% / 11 33% / 2 0%

P.1.2 100% 100% / 10 13% / 1 0%

P.1.3 100% 100% / 14 50% / 2 0%

P.1.4 100% 100% / 3 33% / 7 0%

P.2.1 100% 80% / 3 0% / 12 0%

P.2.2 100% 33% / 3 0% 12 0%

P.2.3 100% 100% / 7 0% / 7 0%

P.3.1 100% 100% / 3 20% / 10 0%

P.3.2 100% 71% / 3 43% / 7 0%

P.3.3 100% 100% / 11 50% / 7 50%

P.3.4 100% 100% / 6 50% / 9 0%

P.3.5 100% 100% / 7 0% / 11 0%


Présentation des indicateurs qui ont posé le plus de difficultés

Indicateur 1.1 / Taux d'application

au cœur du processus de soins

• Quid de l'utilisation de l'INS ? voir foire aux questions nationale (FAQ) sur les indicateurs du socle commun du programme hôpital numérique (« Le guide des

indicateurs précise dans la partie "définition" que "le référentiel unique d'identités du patient doit intégrer l'INS". L'exigence ne

porte pas sur la propagation de l'INS au sein du SIH mais sur sa gestion par le référentiel d'identités du patient.»)

Indicateur 1.4 / Référentiel de

structure

• Définition ?

• Niveau de détail attendu ?

• Qui doit le constituer ?

• Qui doit le valider ?

• Exemple de référentiel de

structure ?

Indicateur 2.1 / Plan de Reprise

d’Activité

• PRA uniquement ou PCA ?


• Articulation avec le Plan Blanc

et avec le document de Politique

de sécurité ?

• Charge de travail nécessaire

pour le réaliser ?

• Document interne DSI ou

communiqué au sein de

l’établissement ?

Indicateur 2.2 / Taux de

disponibilité

• Définition ?

• Périmètre à couvrir ?

• Méthode de calcul ?

• Pré-requis nécessaires ?

• Indicateur pour la DSI ou à

partager au sein de


• Pré-requis nécessaires à son

calcul ?

Indicateur 3.1 / Politique de sécurité


• Périmètre à couvrir dans le

document ?

• Contenu de l’analyse des

risques à produire ?

• Articulation avec le Plan blanc et

le PRA ?

Indicateur 3.4 / Capacité des

applications à intégrer un dispositif

d’authentification personnelle

• Quid du sso ?

• Le sso peut-il pallier l’absence

d’authentification personnelle

sur une application ?

• Quel impact si l’éditeur ne

prévoit pas de développer cette

fonctionnalité ?

Indicateur 3.5 / Capacité des

applications à tracer les

connexions

• Que faire si la fonctionnalité

n’existe et n’est pas développée

par l’éditeur ?

• Comment le faire accepter aux

praticiens ?


• Procédures / Documents Un indicateur portant sur l’existence d’une procédure ou d’un document ne peut être considéré comme acquis que si

les 3 conditions suivantes sont remplies par l’établissement :

1. Procédure formalisée dans un document / existence d’un document unique formalisée

2. Procédure ou document diffusé parmi les personnels concernés

3. Application de la procédure ou utilisation régulière du document par les acteurs concernés

• Périmètre des applications à inclure dans le calcul des seuils d’éligibilité • Pour l’évaluation des seuils d’éligibilité (indicateurs P1.1, P1.3, il est important que l’établissement cerne le

périmètre des applications considéré pour le calcul*.

Eléments de réponse généraux apportés pendant l’accompagnement pour la

réalisation de l’autodiagnostic

* Se reporter aux pages 15 et 16 du document national : http://www.sante.gouv.fr/IMG/pdf/HN_-_Boite_a_outils_pre-requis_-

_Mode_d_emploi_autodiagnostic_et_plan_d_actions_-_Octobre_2012.pdf

Dans le périmètre Hors périmètre

• Applicatifs ou outils (type base Access) gérant de la donnée médicale, personnelle, d’activité :

• Dossier médical (observations et synthèses, comptes-rendus, recueil de l’activité et des diagnostics) ;

• Prescriptions (prescriptions de médicaments, demandes d’examens dont biologie, prescriptions de chimiothérapie) ;

• Dossier de soins (prise en charge du patient, gestion du travail infirmier) ;

• Dossiers de spécialité (dossier transfusionnel, réanimation, urgences, autre) ;

• Production des activités médico-techniques (bloc, anesthésie, laboratoire, pharmacie, anatomopathologie, imagerie SIR, imagerie PACS, radiothérapie) ;

• PMSI ; • Gestion administrative du patient

• Applicatifs utilisés par les fonctions supports, la gestion de la restauration (sauf si des informations liées au régime patient sont incluses), le biomédical ne doivent pas être inclus.

• Outils type bureautiques hors Access.

http://www.sante.gouv.fr/IMG/pdf/HN_-_Boite_a_outils_pre-requis_-_Mode_d_emploi_autodiagnostic_et_plan_d_actions_-_Octobre_2012.pdf











Réponses spécifiques apportées sur les indicateurs de pré-requis Hôpital

Numérique durant l’accompagnement

Indicateur Thématique Question posée Réponse apportée

P1.1 P1.3

Cartographie applicative

Quelles sont les bonnes pratiques de formalisation d'une cartographie applicative dans le secteur hospitalier ?

Un guide méthodologique élaboré par la HAS sur le sujet est disponible sous : http://www.sante.gouv.fr/IMG/xls/Guide_methodologique_pour_l_auditabilite_des_SI_-_fiche_pratique_1.xls

P1.4 Interprétation des indicateurs HN

Qu'entend-on par un référentiel unique de structure ?

Il s'agit d'un document intégrant les données de structure suivantes : pôles, services, UF, UM, unités de soins… Ce référentiel peut être informatisé et alimenter automatiquement les applicatifs métiers et/ou être disponible sur un fiche type bureautique dont les modifications sont reportées manuellement dans les applicatifs métier.

P2.1 PRA

Y a-t-il un document type pour un PRA dans un établissement de santé ? Jusqu’à quel niveau de détail aller dans le PRA ? PRA / PCA ?

Une fiche pratique a été mise à disposition par le niveau national avec des rubriques communes aux établissements et d'autres à remplir par les établissements eux-mêmes. Concernant le niveau de détail, il est attendu dans cet indicateur la capacité de l’établissement à prouver l’existence d’un document intitulé PRA. L’atteinte de l’indicateur ne dépend pas du niveau de détail qui y est présenté. Il est nécessaire de bien replacer ce document dans son utilité première : rassembler dans un document unique l’ensemble des éléments de description du parc applicatif, de l’architecture technique et de procédures permettant une réponse appropriée en cas de sinistre majeur d'un centre informatique (y compris les procédures tacites de mode dégradé / retour à la normale définies avec les métiers). L’ensemble de ces éléments existe mais de manière diffuse et non formalisée au sein de l’établissement. L’intérêt de la V0 du PRA est de les regrouper dans un document unique. Par ailleurs, le PRA est un document clé pour le fonctionnement de la DSI. Il faut le faire évoluer de manière régulière (évolution du SIH, des procédures, …).


Dans le calcul du taux de disponibilité ou d'indisponibilité de l'application (indicateur 2.2), se limite-t-on à l'application ou inclut-on le serveur hébergeant l'application ?

D'après la fiche pratique #4 qui fournit un exemple de méthode d'évaluation du taux de de disponibilité des applications, il est indiqué qu'il existe deux approches pour définir et mesurer le taux de disponibilité : soit on mesure le fonctionnement de l'application sur les serveurs, soit on mesure que l'application est utilisable sur le poste de travail. Dans le cadre des prérequis HN, il est proposé une mesure simple faite au niveau des serveurs de l'établissement. Néanmoins, dans une démarche plus mature de suivi du niveau de service, il conviendra de considérer la disponibilité au niveau de l'utilisateur d'un service.

P 3.1 Politique de sécurité du SI

Quel est le niveau de détail attendu dans le document de PSSI ? De quel risque parlons-nous ? Quelle interaction avec le Plan Blanc ?

Une fiche pratique est là encore mise à disposition dans la boîte à outils nationale et constitue un modèle sur lequel les établissements peuvent s’appuyer. Certains pourront s'interroger sur la possible articulation entre le Plan Blanc de l’établissement et le PRA. Il englobe l’ensemble des nouvelles règles de sécurité, de protection des données / matériels / outils à respecter par les utilisateurs. L’univers de risque sur lequel construire le document PSSI intègre l’ensemble des facteurs humains, matériels, environnementaux faisant courir un risque pour le fonctionnement du SIH et la protection des données qui y sont contenues. Les établissements pourront s’appuyer sur l’outillage et la méthodologie proposés parallèlement et mis à disposition des établissements sur le deuxième semestre 2014.


Si chaque application permet une authentification personnelle, la reconnexion via SSO suite à une déconnexion par temporisation d'inactivité est-elle autorisée ?

L'indicateur P3.4 : Taux d'application gérant des données de santé à caractère personnel intégrant un dispositif d'authentification personnelle. Il est précisé : "le système (le SI) doit comprendre une déconnexion de l’utilisateur sur tempo d’inactivité". Il n’est pas précisé l’implémentation technique. Donc la déconnexion de la session utilisateur répond au besoin. La technique du SSO consiste à rejouer de manière automatique le dispositif d'authentification personnelle de l'utilisateur à l'application. Donc, dans la mesure où les applications traitant des données de santé à caractère personnel ont un dispositif d'authentification personnelle et qu'il est prévu une déconnexion de l'utilisateur sur temporisation d'inactivité, le système répond aux exigences.

1/2

NB : l’ensemble des réponses apportées en cours d’accompagnement ont permis d’alimenter au fur et à mesure une FAQ projet. Les

éléments restitués ici en proviennent en majorité.

http://www.sante.gouv.fr/IMG/xls/Guide_methodologique_pour_l_auditabilite_des_SI_-_fiche_pratique_1.xls




Réponses spécifiques apportées sur les indicateurs de pré-requis Hôpital

Numérique durant l’accompagnement

Indicateur Thématique Question posée Réponse apportée

P3.4

Interprétation des indicateurs HN

Les documentations produit précisent que l’application intègre les fonctionnalités de renouvellement de mot de passe. Ce renouvellement doit-il être fait par les utilisateurs eux-mêmes ou un administrateur ? Le renouvellement doit-il être demandé de façon automatique à l’utilisateur après un certain délai ? Quelles sont réellement les attentes sur cet indicateur ?

De manière générale, le guide sur les indicateurs Hôpital Numérique ne précise pas l'implémentation technique : elle est laissée au jugement de l'établissement. Il faut avoir un raisonnement pragmatique : La mesure de protection doit être adaptée au contexte. Les règles doivent être inscrites dans la PSSI et la Charte, afin quelles soient connues et appliquées par tous. Sur le changement de mot de passe, il faut que ce soit le plus transparent et le plus simple pour l’utilisateur . Donc c’est forcément l’application qui demande à l’utilisateur de renouveler son mot de passe de façon non bloquante (au bout d’un délai ou d’un nombre d’utilisation). Dans le cas de l'utilisation du SSO : il est juste nécessaire d'appliquer le renouvellement du mot de passe au compte SSO (si pas d'utilisation d'une carte à puce). Les mots de passe des applications peuvent être changés automatiquement et à périodes régulières avec un intervalle de temps court, car ils ne perturbent pas le fonctionnement des utilisateurs. Hors SSO, dans le cas de l'utilisation d'un identifiant/mot de passe par application, il est préférable d'"éduquer" l'utilisateur à changer lui-même ses mots de passe périodiquement (règle PSSI implémentée dans les logiciels) sur sollicitation du logiciel. La fréquence doit être adaptée et peut être réduite par itérations (par exemple : tous les ans, puis tous les 6 mois avec les campagnes d'information associées). Le choix d'un changement de mot de passe par l'administrateur semble lourd organisationnellement et pour l'utilisateur, et non conforme aux règles de confidentialité. ATTENTION à la problématique des administrateurs système et applicatif : dans le cas où ils peuvent avoir accès aux données médicales, la règle doit (ou devrait) leur être appliquée ...

P3.4


Les documentations produites précisent que l’application intègre les fonctionnalités de déconnexion automatique. Si l’établissement a mis en place une déconnexion de la session multi-applications automatiquement au bout de X minutes d’inactivité, cela peut-il répondre au critère ou, faut-il que ce critère soit vérifié pour chaque application du périmètre ?

De manière générale, le guide sur les indicateurs Hôpital Numérique ne précise pas l'implémentation technique : elle est laissée au jugement de l'établissement. Il faut avoir un raisonnement pragmatique : La mesure de protection doit être adaptée au contexte. Les règles doivent être inscrites dans la PSSI et la Charte, afin quelles soient connues et appliquées par tous. Dans la même veine que la réponse concernant le renouvellement des MdP, l'objectif est de réduire le risque d'usurpation de compte et de divulgation de données médicales par simple affichage, donc de ne pas permettre l'accès à une session applicative ouverte et non "surveillée" par son propriétaire. Il est préconisé : - d'adapter les temps de déconnexion au contexte métier et en concertation avec l'utilisateur final (laboratoire, urgence, bloc opératoire, ...) ; - (plus complexe) de traiter la problématique des affichages qui permettent la visualisation de données médicales (type monitoring - affichage, occupation des lits ou box par exemple) . Les autres actions du logiciel doivent nécessiter une identification ou authentification. Le choix du lieu de déploiement de ces systèmes est important (présence de public ?).

P3.5


Pour les indicateurs 3.5, jusqu'à quel niveau de traçabilité (nom utilisateur / horodatage) de la connexion faut-il aller ? Peut-on se limiter à la session utilisateur, ou s'agit-il de la connexion dans l'applicatif ? Doit-on avoir une vision des dossiers patients visités par l'utilisateur ?

A priori, traçabilité du nom de l'utilisateur, de l'heure et de la durée de connexion dans l'applicatif. A voir côté patient. Obtenir un arbitrage de l'ARS

2/2

NB : l’ensemble des réponses apportées en cours d’accompagnement ont permis d’alimenter au fur et à mesure une FAQ projet. Les

éléments restitués ici en proviennent en majorité.


Méthodologie de travail proposée pour la réalisation des travaux

d’autodiagnostic

• Nous proposons aux établissements de s’appuyer sur l’outil d’autodiagnostic proposé par le

Ministère de la Santé http://www.sante.gouv.fr/spip.php?page=article&id_article=12293

• Cet outil se décompose en 5 onglets principaux.

• L’outil d’autodiagnostic peut être complété selon la méthodologie suivante, utilisée pour

l’accompagnement des 20 établissements concernés :

Etape Méthodologie Acteurs mobilisés

Réalisation d’un inventaire détaillé du

SIH et d’une cartographie applicative

Appui possible sur le guide

méthodologique HAS

• DSI

• Prestataires externes

Remplissage des onglets:

1) DIAG1-INVENTAIRE et

2) DIAG1-EXIGENCES APPLIS

• Travail en chambre sur la base de la

cartographie applicative

• Réalisation par un acteur identifié au

sein de la DSI (chef de projet Hôpital

Numérique)

• Personnels de la DSI

• Prestataires externes

Remplissage de l’onglet

3) DIAG2-QUESTIONNAIRE

• Organisation et animation d’un atelier

de travail pluridisciplinaire (2h)

• Membres de la Cellule Identito-vigilance

• Service Qualité / Gestion des risques

• Personnels de la DSI

Finalisation du plan d’actions

• Appui sur l’onglet 5) PLAN D’ACTION

• Réalisation d’un atelier de travail (2h)

• Direction Générale

• Membres de la Cellule Identito-Vigilance

• DSI

NB : l’outil national permet, suite aux résultats d’autodiagnostic de générer automatiquement le plan d’actions pour l’établissement

Points d'amélioration identifiés sur l'outil d'autodiagnostic :

- les formules de calculs des seuils d'atteinte aux indicateurs P1.1 et P1.3 produisent dans certains cas des résultats erronés. La restriction du classeur par mot de

passe rend impossible la compréhension des formules utilisées.

- Bien que précisée dans le guide d'utilisation de l'outil, la suppression des informations renseignées dans l'onglet 2 lors de l'actualisation des données (bouton

"actualiser") rend pénible l'utilisation de cet onglet, obligeant ainsi l'utilisateur à renseigner à nouveau les informations.







3. Regards croisés sur les plans d’actions et premières difficultés rencontrées

dans la mise en œuvre

Sommaire


Structuration type des plans d’actions définis avec les établissements

accompagnés

• Elaboration ou finalisation ou mise à jour de la

cartographie applicative afin de mettre en évidence le

référentiel unique d’identités, de mouvements

• Rédaction, validation et mise à jour dans les applicatifs

métier du référentiel de structure

• Renforcement de la professionnalisation de la Cellule

Identito-Vigilance (CIV) : comptes-rendus

systématiques, plans d’actions pour correction des

anomalies identifiées dans la base d’identités des

patients

• Finalisation de la fiche de poste du Référents SSI

(lorsque non identifié)

• Contact avec les éditeurs pour s’assurer de la capacité

des applicatifs à intégrer

• l’INS,

• l’authentification personnelle,

• la déconnexion par temporisation d’inactivité,

• la traçabilité des connexions.

• Le cas échéant, en fonction des réponses des éditeurs,

identification de premières actions compensatoires

• Au sein de la DSI, mise en place d’un dispositif de suivi

des indisponibilités

• Organiser et animer les réunions

de travail avec les chefs de

service pour la définition du taux

de disponibilité cible

• Réalisation d’une première

analyse de risque SSI

• Mise à jour ou rédaction de la

charte informatique et diffusion

aux utilisateurs

• Réalisation d’une V0 du PRA et

de la PSSI

• Réalisation d’une

V1 du PRA et de la

PSSI

2014

Échéance 1er trimestre 2014 Échéance 1er semestre 2014 Échéance fin 2014

NB : les établissements sont majoritairement confiants dans leur

capacité à atteindre les pré-requis techniques du programme

Hôpital Numérique d’ici la fin d’année 2014.

Peu (2 établissements sur 20) ont cependant revu leur échéance

initiale à la hausse (en avance par rapport à celle imaginée

auparavant).


Dispositif généralement envisagé par les établissements pour le pilotage

et le suivi d’avancement des plans d’actions

• Pour la mise en œuvre du plan d’actions :

• Création, au sein du portefeuille de projets de la DSI et de l’établissement, d’un projet « Hôpital

Numérique »

• 1 responsable coordinateur de la mise en œuvre identifié (généralement le responsable

informatique ou DSIO)

• Dans un établissement, mise en place d’un groupe de travail pluridisciplinaire, incluant des

représentants des domaines fonctionnels pour la mise en œuvre du plan d’actions

• Dans un établissement, mise en place d’un Comité du Dossier Patient intégrant à la fois les

problématiques Hôpital Numérique et d’Identito-vigilance

• Pour l’instruction et les arbitrages définitifs :

• Copil SIH dans un premier temps : instance dédiée à la fois pour la définition et un premier niveau

de validation des travaux

• Comité de Direction dans un second temps : instance de validation finale


Avancement des plans d’actions et difficultés rencontrées

(suite aux relances récentes par mail et téléphones de janvier 2014)

Nombre établissements

Plan d’actions lancé Plan d’actions non lancé

18 1

- Démarrage des plans d’actions -

- Inventaire des actions lancées -

Nombre établissements

4

11

11

10

8

11

6

Etude pour le choix de nouveaux applicatifs

Elaboration du référentiel de structure

Rédaction du PRA (y compris avec des éléments de PCA et de retour à la

normale)

Lancement des travaux sur le calcul des taux de disponibilité

Rédaction d’une première version de la Politique de Sécurité du Système

d’Information

Elaboration d’une nouvelle version de la charte informatique

Retour vers les éditeurs pour la mise en place de l’authentification personnelle,

du renouvellement de mot de passe après temporisation d’activité

Mise en place de la traçabilité des connexions 4

Pas d’information

1


Partage des difficultés remontées par les établissements

(janvier 2014)

Manque de temps Mobilisation des acteurs

Charge de travail /

Manque de ressources

Manque des compétences

techniques

Manque de moyens

financiers

Manque de sponsor de la

Direction de l'établissement

Manque des compétences

méthodologiques (vision

processus)

- Difficultés dans la mise en œuvre du plan d’actions -


Les slides suivantes constituent des zooms méthodologiques pour adresser les

indicateurs de pré-requis les plus complexes

• Nous avons proposé de faire des zooms méthodologiques sur les indicateurs suivants :

• P1.4 : Référentiel de Structure

• P2.1 : Plan de Reprise d’Activités

• P2.2 : Calcul du taux de disponibilité

• P3.1 : Politique de Sécurité du SI

• P3.2 : Charte Informatique

• Pour chacun de ces indicateurs, le zoom est effectué en 1 à 2 slides (le cas échéant)

1 slide avec des propositions méthodologiques 1 slide avec des bonnes pratiques / pré-requis formalisés


Fiche de capitalisation par indicateur

Indicateur 1.4 / Référentiel de structure

Rappel des

questions

posées par les

établissements

• Définition ?


• Qui doit le préparer ?

• Qui doit le valider ?

• Exemple de référentiel de structure ?

Méthodologie

de travail

possible pour

les

établissements

• Désignation au sein le Comité de Direction une personne

responsable de la construction du référentiel de structure

• Proposition par le chef de projet du référentiel de structure :

périmètre, description, …

• Validation par le Comité de Direction et le Conseil de

Surveillance du référentiel de structure

• Définition d’un processus de travail pour l’actualisation du

référentiel de structure : réunion entre le chef de projet

référentiel et la DSI

• Pilotage par la DSI de l’intégration du référentiel de structure

dans les applicatifs métiers

Eléments de

compréhension

• Envisager le référentiel de structure comme un recensement des différentes unités fonctionnelles de l’établissement

• Construire un document qui présente l’ensemble des unités médicales, soignantes, administratives de l’établissement, à un niveau

suffisamment fin (pôles, services, unités de soins…)

• Définir dans le référentiel une codification pour chacune des entités

• Intégrer dans le SIH, le référentiel de structure

Charge de

travail

indicative

Dépend de la taille de l’établissement

Interlocuteurs à

associer • Comité de Direction Générale

• DSI

Documents

d’appui

• Fiche pratique n°1 - Boîte à outils

nationale

• Référentiels de structure d’autres

établissements



Indicateur 2.1 / Plan de reprise d’activités (PRA)

Rappel des

questions

posées par les

établissements

• PRA uniquement ou PCA ?


• Articulation avec le Plan Blanc et avec le document de

Politique de sécurité ?

• Charge de travail nécessaire pour le réaliser ?

• Document interne DSI ou communiqué au sein de


Méthodologie

de travail

possible pour

les

établissements

• Désignation d’un chef de projet coordinateur de la rédaction du

PRA

• Proposition par le chef de projet d’un calendrier et d’une

méthodologie de travail sur le PRA

• Appui sur le modèle fourni dans la fiche pratique n°3 de la boîte

à outils nationale

• Animation d’une réunion de cadrage du PRA associant

l’ensemble des personnels de la DSI. Réunion qui permet de :

1. Définir le niveau d’ambition à atteindre dans chacune

des versions du PRA (V0, V1, …)

2. Partager le calendrier de production des premières

versions (V0, V1, …)

3. Répartir entre les contributeurs les parties à rédiger

• Réalisation de réunions de travail pour suivi de l’avancement

dans la rédaction des parties

• Réalisation d’ateliers de travail avec les personnels de la DSI,

les prestataires afin de définir des logigrammes d’intervention en

gestion des incidents (bonnes pratiques préalables à la

définition du PRA)

Eléments de

compréhension

• Recommandations :

• Etre pragmatique : ne pas multiplier les documents (PRA, PCA, …)

• Avoir un document centralisant l’ensemble des éléments descriptifs du SIH (applications et infrastructure) ainsi que l’ensemble

des procédures de fonctionnement mises en place au sein de la DSI (sauvegardes, maintenance, …), avec les directions

métiers (mode dégradé), avec les prestataires externes (intervention sur sites nécessaires, le cas échéant)

• Ne pas chercher à avoir un PRA d’emblée exhaustif, le construire par palier (V0, V1)

• Se donner des temps de production des versions du PRA limitées (3 mois, 6 mois, …) afin d’assurer une progression

régulière

• Bonnes pratiques : formaliser les logigrammes de gestion des incidents (mineurs/majeurs, techniques/applicatifs)

Charge de

travail

indicative

20 JH (pour la V0)

Interlocuteurs à

associer

• Ensemble des personnels de la

DSI

• Responsables métier (si

nécessaires pour la partie

fonctionnement en mode

dégradé)

• Prestataires externes le cas

échéant

Documents

d’appui


nationale

• PRA d’autres établissements


EXEMPLE DE LOGIGRAMME REALISE POUR L’INTERVENTION EN INCIDENT MAJEUR

Bonnes pratiques / pré-requis

Exemple de logigramme formalisable 2/2



Indicateur 2.2 / Calcul du taux de disponibilité

Rappel des

questions

posées par les

établissements

• Définition ?

• Périmètre à couvrir ?

• Méthode de calcul ?

• Pré-requis nécessaires ?

• Indicateur pour la DSI ou à partager au sein de l’établissement ?

• Pré-requis nécessaires à son calcul ?

Méthodologie

de travail

possible pour

les

établissements

• Elaborer une liste des applicatifs du SIH (se baser idéalement sur la cartographie applicative)

• Pré-évaluer au sein de la DSI les indisponibilités connues (arrêts programmés imposés par l'éditeur, coupures électriques imposées par EDF, …) et en déduire une première version du taux de disponibilité "atteignable".

• En réunion de travail avec chaque chef de service utilisateur de l'application, échanger sur les besoins et exigences métiers en matière de disponibilité.

• Présenter les contraintes techniques associées à l'exploitation des applications (mises à jour, …).

• Formaliser le consensus obtenu.

• Mettre en place le processus de suivi des indisponibilités : soit par l'acquisition d'une nouvelle solution logicielle, soit par l'ajout de fonctionnalité à la solution existante, soit simplement par la création d'un fichier de suivi des indisponibilités sous tableur.

• Mesurer les taux de manière périodique et communiquer vers les utilisateurs les taux de disponibilité réellement constatés

Eléments de

compréhension

• Il s'agit de mesurer le taux de disponibilité des applications du SIH, conformément à ce qui est requis par l'indicateur P2.2.

• Pour ce faire, il est question de mesurer le taux d'indisponibilité et d'en déduire la disponibilité.

• L'indisponibilité comprend les arrêts programmés (opérations de maintenance) et non programmés (pannes)

• L'exigence de l'indicateur porte sur :

• La définition d'une méthode

• La mesure et le suivi des taux

• Aucun taux de disponibilité cible n'est imposé par HN, seules la définition d'une méthode et la mesure des taux sont

requises.

Charge de

travail

indicative

• Réunions d'1 h pour chaque

application

• 2 J/H pour la mise en place de la

méthode (définition et création du

fichier de suivi)

Interlocuteurs à

associer

• DSI

• Chefs du service utilisant

l’application / Agents du service

Documents

d’appui


nationale

• Document Tableur


CRITERES D’EVALUATION DE LA CRITICITE DES APPLICATIONS ET DES INCIDENTS

CRITERES D’EVALUATION DE LA CRITICITE DES APPLICATIONS ET DES INCIDENTS

Criticité de l'application

Application non critique Application critique

- Application n'alimentant pas le dossier patient - Application tournant en jours et heures ouvrés - Application impactant moins de 20 utilisateurs

- Application alimentant le dossier patient - Application devant tourner 24/24, 7/7 - Application impactant plus de 20 utilisateurs

Criticité de l'incident

Qualification de l'Incident Majeur

- Passage obligatoire en mode dégradé - Temps de résolution a priori dépassant le temps d'intervention négocié dans les contrats de services (sinon incident mineur)


Outils pour la définition des taux de disponibilité des applications

1/2

Objectifs des réunions : 1. Mieux comprendre le

fonctionnement du service et des enjeux métier liés à la disponibilité de l’application

2. Définir ensemble un niveau de service attendu sur l’application (taux de disponibilité)

3. S’accorder sur des délais d’intervention possibles de la DSI sur l’application (arrêts autorisés, temps de réponse maximum en cas d’incident)

4. S’accorder en cas de panne grave sur un fonctionnement en mode dégradé

Etape de la réunion Durée Questions à poser

Temps 1 : Connaissance du fonctionnement du service et du niveau d’utilisation de l’application

60 min

• Présentez-nous votre activité ? • Quelle est votre plage d’ouverture du service ? • Comment fonctionne la prise en charge du patient ? • Comment utilisez-vous votre application ? • Qui l’utilise ? Combien d’utilisateurs au total ?

Temps 2 : Définition du taux de disponibilité cible

30 min

• Utilisez-vous l’application sur toute la durée d’ouverture du service ? • Y-a-t-il des pics d’activité dans la journée ? La semaine ? • A quel moment pouvons-nous prévoir des opérations de sauvegarde, de maintenance

sur l’application sans perturber le fonctionnement du service ? • En cas d’incident mineur, quel est le temps d’intervention maximum autorisé de

notre part ?

Temps 3 : Définition du mode dégradé

30 min

• En cas de forte perturbation du service, quel mode dégradé pouvons-nous mettre en place ?

• En cas de passage en mode papier, quel circuit pour intégrer les données papier dans l’application ?

• Une fois l’application redémarrée, quelles opérations de contrôle du bon fonctionnement mettre en place entre vous et la DSI ?



Outils pour la définition des taux de disponibilité des applications

2/2

ILLUSTRATION DES DUREES D'INDISPONIBILITE DES APPLICATIONS - BASE DE DISCUSSION AVEC LES CHEFS DE SERVICE



Indicateur 3.1 / Politique de Sécurité du SI

Rappel des

questions

posées par les

établissements


• Périmètre à couvrir dans le document ?

• Contenu de l’analyse des risques à produire ?

• Articulation avec le Plan blanc et le PRA ?

Méthodologie

de travail

possible pour

les

établissements

• Procéder en mode projet en sollicitant systématiquement les "sachants" dans l'établissement (cadres de santé, DIM, …)

• Définition d'un groupe de travail chargé d'élaborer la PSSI (=organisation du projet) et définition du périmètre retenu pour la PSSI

• Recueil des éléments stratégiques (Politique générale, si disponible).

• Réalisation de l'appréciation des risques (cf. outil)

• Choix des principes et déclinaison en règles adaptées au contexte de l'ES | Définition du processus de collecte et de suivi des incidents de sécurité SSI

• Finalisation et validation de la PSSI - Direction de l'ES

• Communication de la PSSI et sensibilisation des agents

• Collecte et suivi des incidents de sécurité SSI

Eléments de

compréhension

• La Politique de Sécurité du SI constitue le cadre local de référence

et de cohérence en matière de sécurité de l’information dans un

établissement.

• Dans le cadre d'Hôpital Numérique, il est indiqué que la politique de

sécurité consiste en un ensemble de mesures portant sur l'organisation

(définition des responsabilités, formalisation et diffusion des procédures,

…) permettant le respect de la confidentialité des informations relatives

au patient, notamment en termes de modalités de partage des

informations mises en œuvre.

• De plus, un processus de collecte et de suivi des évènements de

sécurité doit être mis en œuvre.

Charge de

travail

indicative

15 J/H minimum

Interlocuteurs à

associer

• Directeur

• Ensemble des Directions

(métiers, DAF, DRH, DSI, …)

• DIM

• Référents métiers

• Référent SSI

• Cadres de santé

Documents

d’appui

• Outil spécifique ARS

PDL d’analyse des

risques (mis à

disposition fin 1er

semestre 2014)

• Corpus documentaire

mis à disposition par

l'ASIP Santé http://esante.gouv.fr/pgssi-

s/presentation

• Guide d'élaboration

d'une PSSI proposé par

l'ANSSI http://www.ssi.gouv.fr/fr/guides-

et-bonnes-pratiques/outils-

methodologiques/pssi-guide-d-

elaboration-de-politiques-de-

securite-des-systemes-d-

information.html

http://esante.gouv.fr/pgssi-s/presentation




http://www.ssi.gouv.fr/fr/guides-et-bonnes-pratiques/outils-methodologiques/pssi-guide-d-elaboration-de-politiques-de-securite-des-systemes-d-information.html


































Cartographie de l’univers de risques (réalisée avec des établissements

indépendamment de l’outillage spécifique sur l’analyse de risques)

EXEMPLE DE CARTOGRAPHIE SIMPLIFEE DES RISQUES

TECHNIQUE HUMAIN IMMOBILIER ENVIRONNEMENTAL

FOURNISSEURS/ PRESTATAIRES

Risques identifiés

Logiciel Négligence Incendie Inondation Cessation d'activité Matériel Fraude Electricité Tempête Rupture de contrat

Infrastructure Perte de compétences clés Travaux Défaut de maintenance

Vol/Dégradation de matériel Canalisation

Arrêt de production sur un produit

Climatisation Explosion Occurrence Forte Moyenne Faible Très faible Faible Criticité Forte Faible Moyenne Forte Forte Complexité Faible Faible Forte Forte Faible

Outils / Procédures de maîtrise des risques associés PRA PSSI Plan Blanc Plan Blanc PRA



Indicateur 3.3 / Charte Informatique

Rappel des

questions

posées par les

établissements

• /

Méthodologie

de travail

possible pour

les

établissements

• Appui sur la politique de sécurité pour actualisation de

la charte informatique

• Définir, de manière partagée avec la DRH, une

procédure de :

• diffusion de la charte auprès des personnels

de l’établissement

• suivi de la bonne lecture / prise de

connaissance par les personnels de la charte

informatique

• Prévoir, le cas échéant, avec la DRH les actions

d’information des Institutions Représentatives des

Personnels, avant diffusion générale

Eléments de

compréhension

• Attendre une première version de la PSSI avant de mettre à jour la charte informatique : en effet, des règles

d’usage des données, logiciels et matériels informatiques vont être définies dans la PSSI et qu’il faudra réintégrer

dans la charte informatique

• Faire de la charte informatique un document qui engage la responsabilité des utilisateurs au respect des règles.

Engagement obtenu soit par :

• signature individuelle

• annexion au Règlement Intérieur

• Nécessité cependant de s’assurer que les personnels ont bien pris connaissance de la charte informatique

Charge de

travail

indicative

5 JH

Interlocuteurs à

associer

• DSI

• Comité de Direction

Générale

• Présidence de CME

• DRH

• Instances représentatives du

personnel

Documents

d’appui

• Fiche pratique n°7 – Boîte à

outils nationale

Agence Régionale de Santé

Pays de la Loire

CS 56233

44262 NANTES Cedex 2

T. 02.49.10.40.00

www.ars.paysdelaloire.sante.fr

http://www.ars.paysdelaloire.sante.fr/