Ce qui suit est un retour d'expérience suite au développement de composants HL7 pour le projet OpenSIL.

Le monde de la santé est vaste, vraiment très vaste. Ce qui implique des données qui sont fortement variables d'un domaine à l'autre, tant en termes de relation et d'organisation que du contenu de ces données elles-mêmes.

Pour exemple, les informations concernant la mutuelle d'un patient et celles concernant les résultats d'analyses d'un spécimen anonyme sont de nature et de contenu très différents.

D'un autre côté, la communication entre établissements de santé au niveau international est devenu nécessaire. Cette nécessité implique de pouvoir s'échanger avec un protocole standard toutes les informations requises par la structure de santé quelle que soit leur nature.

De cette constatation ont émergé plusieurs solutions partielles.

La solution américaine fut la conception d'un format standard d'échange de données de santé appelé HL7 (Health level 7). Ce standard, inventé sur le tas en 1987 dans sa version v1 et v2 est un joyeux bazar.

hl7 logo

Exemple partiel d'un document en HL7v2:
MSH|^~\&|EPIC|EPICADT|SMS|SMSADT|1999122[...]
^ALLEN MYLASTNAME^BONNIE^^^^|||||||||| ||2688684||||199912271408||
[...]


Totalement en mode texte, et utilisant des séparateurs pour ordonner les données, il a le grand avantage d'être fortement flexible. Ce qui permet d'un côté la transmission d'à peu près n'importe quoi, mais de l'autre un manque absolu de rigueur… Une même information pouvant être encodée de plusieurs façons différentes.

La France, se basant sur les travaux us (choix très discutable), a mis au point sa version nationale de HL7, appelée HPRIM santé (Harmoniser et promouvoir l'informatique médicale) et maintenue par interop'santé. Souffrant des mêmes tares que son ainé, cette norme a en plus le désavantage de rester totalement fermée. Ce qui n'arrange rien à l'affaire, bien au contraire.

interop sante logo

Après HL7v1 et v2, et devant les multiples problèmes rencontrés par ces standards, l'organisation HL7 a décidé de concevoir une autre version, plus moderne et orientée objet (échanges permis en XML au lieu de simple texte): HL7v3.

Exemple de HL7v3

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<poqmmt000001UVQualityMeasureDocument xsi:schemaLocation=""
xmlns:ns2="urn:hl7-org:v3-rim" xmlns:ns3="urn:hl7-org:v3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<typeId root="2.16.840.1.113883.1.3"
extension="POQM_HD000001"/>
<id root="3a721717-28af-424a-b9f2-68c51396236a"/>
<code code="57024-2" codeSystem="2.16.840.1.113883.6.1"
displayName="Health Quality Measure
document"/>
<title>(DRAFT) Anticoagulation therapy</title>
<text>Ischemic stroke patients.</text>
<effectiveTime>
<low>20140507</low>
<height>20140507</height>
</effectiveTime>
<setId root="84c88ecd-0fea-470b-8ae1-f80b42617a0a"
extension="STK-3"/>
<versionNumber value="1"/>
<author typeCode="AUT">
<assignedPerson classCode="ASSIGNED">
<representedOrganization classCode="ORG"
determinerCode="INSTANCE">
<id root="2.16.840.1.113883.19.5"/>
<name>Joint Commission</name>
<contactParty/>
</representedOrganization>
</assignedPerson>
</author>
[...]


Et là, premier couac : Le souci de la variabilité des données qui avait empoisonné HL7 v1 et v2 s'est une fois de plus posé lors de la conception de HL7v3.
Dans un premier jet, les concepteurs de HL7 ont choisi l'option d'un modèle exhaustif. HL7 v3 était alors composé de centaines de classes dans lesquelles il fallait piocher pour construire l'information voulue.

Non seulement d'une grande complexité, difficilement maintenable, et qui, de toute façon, ne permettait pas de représenter toutes les données à transporter, HL7 a fini par renoncer à cette approche.

La seconde solution, plus élégante, fût de créer un noyau de classes appelée RIM, permettant de représenter des informations basiques (par exemple, une classe "Document" pour représenter un document, une classe "Act" pour représenter une action…). Au final, le RIM contient une trentaine de classes.

Ci dessous le diagramme de classes du RIM:

HL7 RIM 2012

Les différents domaines médicaux doivent étendre ce RIM pour transporter les informations voulues. Chaque domaine étant indépendant des autres.
L'avantage direct est que HL7 peut être implémenté sans pour autant être exhaustif. Il suffit d'implémenter le noyau de HL7v3 (ie. le RIM), et les domaines nécessaires à votre application.

En fait, HL7v3 souffre d'autres problèmes que ses ainés (On n'entrera pas dans le détail ici, le but n’étant pas de dresser une liste des défauts de HL7v3), mais on peut saluer l'action de HL7 qui va globalement dans le bon sens en ouvrant le standard HL7v3.

Du côté français, HPRIM reste largement utilisé. Néanmoins, sous la pression de l’Europe, il y a un effort réel de migration vers un standard international basé sur HL7v3 via HL7 France (qui est enfin ouvert !).

En conclusion, HPRIM et HL7 sont représentatifs de ce qui se fait dans la santé en informatique.

On fait du bricolage, puis on standardise lentement les choses. En tant que professionnel de l'informatique ayant bossé des années ailleurs que dans la santé, j'ai toujours le sentiment que la santé a en permanence 5 ou 10 ans de retard. C'est vraiment regrettable…


Catégories ,


← Plus anciens Plus récents →

forge OxyGen LIMS 0.14.1 Released !