Swiss Medical Informatics - SGMI

tre de sortie, 3)protocole opératoire, et4)demande d’admission.
Au moment de l’admission, les documents d’admission
sont envoyés du médecin traitant àl’hôpital, et
lorsque le patient quitte l’hôpital del’hôpital aumédecin
traitant. Cette communication est présente pourpratiquement
tous les patients. Un flux d’information rapide peut
donc réduire des processus manuels.
Tous lesacteurs médicaux qui ontété visités implémentent
les documents de ces groupes de processussur un support
Figure 1
Processus de communication entre hôpitaux et partenaires externes.
Figure 2
Processus de création d’une lettre de sortie dans un des hôpitaux partenaires
du projet.
Figure 3
Le scénario d’un serveur de documents àl’intérieur des hôpitaux et l’échange
avec les partenaires externes.
PROCEEDINGS ANNUAL MEETING 2009
papier(par fax ou courrier). Des parties de ces documents
peuvent être générées automatiquement par le système
d’information clinique de l’hôpital. Dans tous les cas, l’information
doit être ajoutée manuellement par les médecins
ou les secrétaires. Aucun des documents n’est créé en
utilisant un code standard autre qu’ICD pour le diagnostic.
La figure 2illustre leprocessus de création d’une lettre
de sortie de l’un des partenaires.
Nous avonsdéfini les premières spécifications d’un avis de
sortie avec une architecture utilisant un serveur derésultats,
tel qu’illustréàlafigure 3. L’avis de sortie estuncourt
texte qui résume le séjour du patient àl’hôpital. Lorsque
le patient quitte l’hôpital, le médecin hospitalier écrit cet
avis directemententexte libre (semi-structuré) dans le système
d’information. Le document est envoyé au médecin
traitant soit par fax, par courrier ou par le patient luimême.
Le but est d’informer le médecin traitant du diagnostic,
des interventions possibles, de la médication àla
sortie, ainsi que des contrôles àréaliser par la suite.
Le flux des événements proposé dans le système électronique
peut être résumé ainsi:
1 lemédecin hospitalier crée un avis de sortie(ou un autre
type de document comme une lettre de sortie);
2 ladestination du document est choisie;
3 ledocument est générépartiellement avec les données
du dossier de patient;
4 ledocument est complété avec de l’information additionnelle;
5 ledocument est encrypté (unsystème d’encryptagen’a
pas encore été choisi);
6 ledocument est envoyé au serveur dedocument;
7 leserveurnotifie le médecin traitant qu’unnouveau document
est accessible (ou le médecin traitant vérifie
cela activement);
8 lemédecin traitant se connecte au serveur etcrée une
connexion sécurisée;
9 lemédecin traitant télécharge le document dans son
application médicale par la connexion sécurisée;
10 le document est décrypté;
11 le médecin traitant vérifie ledocument et confirme sa
validité, puis sort du système.
Dans ce contexte, il est spécialement important queleflux
d’information soit rapide, et que lemédecin traitant soit
informé sur le statut de son patient dès qu’il quitte l’hôpital.
Un processus similaire peut être créé pour la demande
d’admission, lalettre de sortie, le protocole opératoire ou
d’autres types de documents plus simples.
Conclusions
L’interopérabilité pour échanger de l’information médicale
est un domaine sensible. Son potentiel est aussi grand
que lapeur de perdre lecontrôle sur les données en cas
d’abus. La plupart des stratégies eHealth visent une solution
globale au niveau national et àlong terme, comme
c’est le cas de la Confédération helvétique. Même si cela
est nécessaire, il est quand même important de gagner de
l’expérience avec des solutions simples mais réellement
Swiss Medical Informatics 2009; n o 67
19