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.