Il est y précisé que désormais l’hébergement de données de santé à caractère personnel concerne aussi les données sur support papier.

Texte actuel de l’article 1111-8

Si cette disposition permettra plus facilement aux établissements d’externaliser leurs archives papier, cela implique toutefois que les prestataires spécialisés dans l’archivage papier devront se conformer au décret sur l’hébergement de données de santé, et donc se soumettre à la procédure d’agrément.

Le référentiel de constitution des dossiers de demande d’agrément paru en Mars 2009 leur est donc opposable.

A noter, que le consentement du patient est toujours un pre-requis à l’hébergement, on imagine alors les quelques soucis à pouvoir externaliser les archives qui engorgent actuellement les hôpitaux.

Voici le début de l’article 1111-8 du CSP tel qu’il devrait être publié dans les prochains jours :

” Les professionnels de santé ou les établissements de santé ou la personne concernée peuvent déposer des données de santé à caractère personnel, recueillies ou produites à l’occasion des activités de prévention, de diagnostic ou de soins, auprès de personnes physiques ou morales agréées à cet effet. Cet hébergement de données, quel qu’en soit le support, papier ou informatique, ne peut avoir lieu qu’avec le consentement exprès de la personne concernée.

Les traitements de données de santé à caractère personnel que nécessite l’hébergement prévu au premier alinéa, quel qu’en soit le support, papier ou informatique, doivent être réalisés dans le respect des dispositions de la loi n° 78-17 du 6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés. La prestation d’hébergement, quel qu’en soit le support, fait l’objet d’un contrat. Lorsque cet hébergement est à l’initiative d’un professionnel de santé ou d’un établissement de santé, le contrat prévoit que l’hébergement des données, les modalités d’accès à celles-ci et leurs modalités de transmission sont subordonnées à l’accord de la personne concernée.

Les conditions d’agrément des hébergeurs des données, quel qu’en soit le support, sont fixées par décret en Conseil d’Etat pris après avis de la Commission nationale de l’informatique et des libertés et des conseils de l’ordre des professions de santé. Ce décret mentionne les informations qui doivent être fournies à l’appui de la demande d’agrément, notamment les modèles de contrats prévus au deuxième alinéa et les dispositions prises pour garantir la sécurité des données traitées en application de l’article 34 de la loi n° 78-17 du 6 janvier 1978 précitée, en particulier les mécanismes de contrôle et de sécurité dans le domaine informatique ainsi que les procédures de contrôle interne. Les dispositions de l’article L. 4113-6 s’appliquent aux contrats prévus à l’alinéa précédent.”

A l’heure du SaaS, du green computing et de la télé médecine, stocker des données sur du papier puis les faire héberger, c’est plutôt cocasse !

Depuis 2007 des offres SaaS apparaissent pour le monde de la Santé : gestion de dossiers médicaux de spécialités voire de gestion complète de cabinet médical, SIR, PACS et même jusqu’à d’ambitieux projets de SIH complets.

Aujourd’hui les offres SaaS évoluent, et du coup la définition du “S” pour “Software” gagne en précision sémantique : Il s’agit moins de fournir des applications intégrées voire monolithiques que de fournir, à la demande, des composants (intégrant fonctions et données) répondant à des besoins basiques ou spécifiques et généralement sans IHM (sans l’interactivité utilisateur).

Amazon WS, Google Apps ou encore eBay ont déjà ouvert la voie en mettant à disposition des services Web qui, s’ils permettaient initialement d’exposer les fonctionnalités de leur propre business, offrent désormais des fonctions de base pour le traitement des informations (stockage, indexation, gestion de files de messages, etc.).
On parle même de HaaS (Hardware as a Service) pour un service comme Amazon Elastic Compute Cloud qui fourni des machines virtuelles (qui n’est d’ailleurs pas sans rappeler la location de temps machine sur les mainframes).

Les architectures orientées services (SOA) permettent de simplifier l’implémentation et l’évolutivité des processus métier du SI par une mise en œuvre de composants réutilisables (les services).
Dans le domaine des systèmes d’informations de santé (SIS), l’intégration des informations et l’interopérabilité sont des objectifs majeurs, la SOA est un bon moyen d’assurer rapidement l’évolution et l’adaptation d’un SIS aux contraintes réglementaires et aux nouvelles gouvernances régulièrement mises en œuvre pour améliorer notre système de Santé.

Pourquoi dès lors, ne pas imaginer de bâtir un SIS orienté services dont certains d’entre eux seraient déployés en mode SaaS. Ces services étant développés, testés, maintenus et sécurisés par un fournisseur garantissant un niveau de service ad-hoc (SLA), ils pourraient même aller jusqu’à constituer les composants du cœur même du SIS.

Le déploiement SaaS pourrait par ailleurs donner un petit coup de pouce à l’avènement de nombreux projets SOA dont les mises en œuvre sont souvent longues et complexes, même s’il faut rappeler qu’une SOA ne résout déjà pas – à elle seule – les problématiques existantes d’un SI (performances insuffisantes en production, évolutions poussives des implémentations existantes, etc.).

Ainsi, je pense qu’il sera possible de trouver à moyen terme des offres SaaS pour des implémentations de tout ou partie des profils d’intégration IHE par exemple (ou de tout autre type de services à valeur ajoutée basé sur les standards ayant cours : HL7, ISO, etc.).
La modélisation des composants (services applicatifs et fonctionnels) et des processus métiers de la SOA pourra avantageusement s’appuyer sur les caractéristiques des profils IHE : homogénéité des profils, fonctions communes entre profils, identification précise des rôles, des acteurs et des transactions, interfaces techniques basées sur les standards Web services.

Un SIS pourra par exemple, mixer l’usage des services PIX/PDQ (d’un fournisseur spécialisé dans les composants de gestion d’identités patients) avec les services plus “techniques” (CT, ATNA) managés par un autre fournisseur. Ce même SIS disposera de son propre entrepôt XDS mais utilisera le registre (partagé par d’autres entités d’un même domaine) géré par un dernier fournisseur SaaS (spécialisé dans l’indexation).

La mise en place d’un SI composé de services déployés en mode SaaS nécessitera une attention toute particulière sur les engagements du fournisseur en matière de disponibilité et de continuité de service. Les problèmes récents (juillet et août 2008) rendant les services Google Mail, Docs et Apps indisponibles pendant près d’une heure donne une idée des risques actuels (même avec les poids lourds de l’Internet) et de leur impact dans le domaine des affaires …ou de la santé: pouvez vous (encore) imaginer votre DMP sur Google Health ?

Les fournisseurs SaaS spécialisés en santé (en France, nécessairement agréés “hébergeurs de données de santé”) assureraient en priorité l’amélioration continue de la qualité et de la sécurité, et plus classiquement le provisionning et le suivi de la facturation. Le support et la maintenance seraient assurés directement (fournisseur & éditeur) ou en collaboration étroite avec des éditeurs tiers.

A noter que, au delà de la disponibilité, les autres critères de sécurité (intégrité, confidentialité et auditabilité) applicables à l’exploitation de ces services seront particulièrement cruciaux pour les SIS.

En conclusion, les services SaaS utilisés par des SIS conçus en SOA permettraient aux établissements médicaux et autres réseaux de santé de se doter – avec des investissements raisonnables et maîtrisés – de systèmes d’informations interopérables et évolutifs.
Charge aux éditeurs et aux hébergeurs de prendre le virage SOA et SaaS.