Niveau de santé 7 - Health Level 7

Cet article concerne la famille des normes. Pour l'organisation qui les a créés, voir Health Level Seven International .

Health Level Seven ou HL7 fait référence à un ensemble de normes internationales pour le transfert de données cliniques et administratives entre les applications logicielles utilisées par divers prestataires de soins de santé. Ces normes se concentrent sur la couche application, qui est la « couche 7 » dans le modèle OSI . Les normes HL7 sont produites par Health Level Seven International , une organisation internationale de normalisation , et sont adoptées par d'autres organismes de normalisation tels que l' American National Standards Institute et l'Organisation internationale de normalisation .

Les hôpitaux et autres organisations de prestataires de soins de santé ont généralement de nombreux systèmes informatiques différents utilisés pour tout, des dossiers de facturation au suivi des patients. Tous ces systèmes devraient communiquer entre eux (ou « interfacer ») lorsqu'ils reçoivent de nouvelles informations ou lorsqu'ils souhaitent récupérer des informations, mais tous ne le font pas.

HL7 International spécifie un certain nombre de normes, de lignes directrices et de méthodologies flexibles grâce auxquelles divers systèmes de santé peuvent communiquer entre eux. Ces lignes directrices ou normes de données sont un ensemble de règles qui permettent de partager et de traiter les informations de manière uniforme et cohérente. Ces normes de données sont destinées à permettre aux organisations de soins de santé de partager facilement des informations cliniques. Théoriquement, cette capacité à échanger des informations devrait aider à minimiser la tendance des soins médicaux à être géographiquement isolés et très variables.

HL7 International considère les normes suivantes comme ses principales normes – les normes les plus couramment utilisées et mises en œuvre :

  • Version 2.x Messaging Standard - une spécification d'interopérabilité pour les transactions médicales et de santé
  • Norme de messagerie de la version 3 - une spécification d'interopérabilité pour les transactions médicales et de santé
  • Clinical Document Architecture (CDA) - un modèle d'échange de documents cliniques, basé sur HL7 Version 3
  • Document de continuité des soins (CCD) - une spécification américaine pour l'échange de résumés médicaux, basée sur le CDA.
  • Étiquetage structuré des produits (SPL) - les informations publiées qui accompagnent un médicament, basées sur HL7 Version 3
  • Clinical Context Object Workgroup (CCOW) - une spécification d'interopérabilité pour l'intégration visuelle des applications utilisateur

Les autres normes/méthodologies HL7 incluent :

Normes primaires

Les normes principales de HL7 sont celles que Health Level Seven International considère comme les plus couramment utilisées et mises en œuvre.

Messagerie version 2

La norme HL7 version 2 (également connue sous le nom de Pipehat) a pour objectif de prendre en charge les flux de travail des hôpitaux. Il a été créé à l'origine en 1989.

HL7 version 2 définit une série de messages électroniques pour soutenir les processus administratifs, logistiques, financiers ainsi que cliniques. Depuis 1987, la norme a été régulièrement mise à jour, résultant en les versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1 et 2.8.2. Les normes v2.x sont rétrocompatibles (par exemple, un message basé sur la version 2.3 sera compris par une application prenant en charge la version 2.6).

Les messages HL7 v2.x utilisent une syntaxe de codage non XML basée sur des segments ( lignes ) et des délimiteurs à un caractère . Les segments ont des composites ( fields ) séparés par le délimiteur composite. Un composite peut avoir des sous-composites (composants) séparés par le délimiteur de sous-composite, et les sous-composites peuvent avoir des sous-sous-composites (sous-composants) séparés par le délimiteur de sous-sous-composite. Les délimiteurs par défaut sont un retour chariot pour le séparateur de segment, une barre verticale ou une barre verticale ( |) pour le séparateur de champ, un caret ( ^) pour le séparateur de composant, une esperluette ( &) pour le séparateur de sous-composant et le signe dièse (#) pour le séparateur de troncature par défaut. Le tilde ( ~) est le séparateur de répétition par défaut. Chaque segment commence par une chaîne de 3 caractères qui identifie le type de segment. Chaque segment du message contient une catégorie spécifique d'informations. Chaque message a MSHcomme premier segment, qui comprend un champ qui identifie le type de message. Le type de message détermine les types de segments attendus dans le message. Les types de segment utilisés dans un type de message particulier sont spécifiés par la notation de grammaire de segment utilisée dans les normes HL7.

Voici un exemple de message d'admission. MSHest le segment d'en-tête, PIDl'Identité du Patient, PV1est les informations de la Visite du Patient, etc. Le 5ème champ du PIDsegment est le nom du patient, dans l'ordre, nom de famille, prénom, prénom (ou leurs initiales), suffixe, etc. Selon la version standard de HL7 V2.x, davantage de champs sont disponibles dans le segment pour des informations supplémentaires sur le patient. 

MSH|^~\&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-0500||ADT^A01^ADT_A01|01052901|P|2.5
NEV||200605290901||||200605290900
PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35209 ^^M~PICKLES DE NICKELL^10000 W 100TH AVE^BIRMINGHAM^AL^35200^^O|||||||0105I30001^^^99DEF^AN
PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||67890^GRAINGER^LUCY^X^^^ MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHERMAN^T^^^MD^0010^UAMC^L|||||||||||||||| |||||||||||200605290900
OBX|1|NM|^Hauteur du corps||1.80|m^Mètre^ISO+|||||F
OBX|2|NM|^Poids corporel||79|kg^Kilogramme^ISO+|||||F
AL1|1||^ASPIRINE
DG1|1||786.50^DOULEUR THORACIQUE, NON SPECIFIEE^I9|||A

HL7 v2.x a permis l' interopérabilité entre les systèmes électroniques d'administration des patients (PAS), les systèmes de gestion électronique de la pratique (EPM), les systèmes d'information de laboratoire (LIS), les systèmes diététiques, de pharmacie et de facturation ainsi que les dossiers médicaux électroniques (DME) ou électroniques. Systèmes de dossier de santé (DSE). Actuellement, la norme de messagerie HL7 v2.x est prise en charge par tous les principaux fournisseurs de systèmes d'information médicale aux États-Unis.

Messagerie version 3

La norme HL7 version 3 a pour objectif de prendre en charge tous les flux de travail de soins de santé. Le développement de la version 3 a commencé vers 1995, aboutissant à une première publication standard en 2005. Le standard v3, contrairement à la version 2, est basé sur une méthodologie formelle (le HDF) et des principes orientés objet.

JANTE - ISO/HL7 21731

Le modèle d'information de référence (RIM) est la pierre angulaire du processus de développement de HL7 Version 3 et une partie essentielle de la méthodologie de développement de HL7 V3. RIM exprime le contenu des données nécessaires dans un contexte clinique ou administratif spécifique et fournit une représentation explicite des connexions sémantiques et lexicales qui existent entre les informations véhiculées dans les champs des messages HL7.

Cadre de développement HL7 - ISO /HL7 27931

Le cadre de développement HL7 Version 3 (HDF) est un processus en constante évolution qui cherche à développer des spécifications qui facilitent l'interopérabilité entre les systèmes de santé. Le RIM HL7, les spécifications de vocabulaire et le processus d'analyse et de conception basé sur un modèle se combinent pour faire de HL7 Version 3 une méthodologie pour le développement de normes consensuelles pour l' interopérabilité des systèmes d'information de santé . Le HDF est l'édition la plus récente de la méthodologie de développement HL7 V3.

Le HDF documente non seulement la messagerie, mais également les processus, outils, acteurs, règles et artefacts pertinents pour le développement de toutes les spécifications standard HL7. À terme, le HDF englobera toutes les spécifications de la norme HL7, y compris toutes les nouvelles normes résultant de l'analyse des architectures et des exigences des dossiers de santé électroniques.

Les spécifications HL7 s'appuient sur des codes et des vocabulaires provenant de diverses sources. Le travail de vocabulaire V3 garantit que les systèmes mettant en œuvre les spécifications HL7 ont une compréhension sans ambiguïté des sources de code et des domaines de valeur de code qu'ils utilisent.

Messagerie V3

La norme de messagerie HL7 version 3 définit une série de messages texte sécurisés (appelés interactions ) pour prendre en charge tous les flux de travail des soins de santé.

Les messages HL7 v3 sont basés sur une syntaxe de codage XML, comme illustré dans cet exemple : 

<POLB_IN224200 ITSVersion="XML_1.0" xmlns="urn:hl7-org:v3"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
  <id root="2.16.840.1.113883.19.1122.7" extension="CNTRL-3456"/>
  <creationTime value="200202150930-0400"/>
  <!-- The version of the datatypes/RIM/vocabulary used is that of May 2006 -->
  <versionCode code="2006-05"/>
  <!-- interaction id= Observation Event Complete, w/o Receiver Responsibilities -->
  <interactionId root="2.16.840.1.113883.1.6" extension="POLB_IN224200"/>
  <processingCode code="P"/>
  <processingModeCode nullFlavor="OTH"/>
  <acceptAckCode code="ER"/>
  <receiver typeCode="RCV">
    <device classCode="DEV" determinerCode="INSTANCE">
      <id extension="GHH LAB" root="2.16.840.1.113883.19.1122.1"/>
      <asLocatedEntity classCode="LOCE">
        <location classCode="PLC" determinerCode="INSTANCE">
          <id root="2.16.840.1.113883.19.1122.2" extension="ELAB-3"/>
        </location>
      </asLocatedEntity>
    </device>
  </receiver>
  <sender typeCode="SND">
    <device classCode="DEV" determinerCode="INSTANCE">
      <id root="2.16.840.1.113883.19.1122.1" extension="GHH OE"/>
      <asLocatedEntity classCode="LOCE">
        <location classCode="PLC" determinerCode="INSTANCE">
          <id root="2.16.840.1.113883.19.1122.2" extension="BLDG24"/>
        </location>
      </asLocatedEntity>
    </device>
  </sender>
  <!-- Trigger Event Control Act & Domain Content -->
</POLB_IN224200>

Architecture de documents cliniques (CDA)

Article principal : Architecture de documents cliniques

L' architecture de document clinique (CDA) HL7 est une norme de balisage basée sur XML destinée à spécifier l'encodage, la structure et la sémantique des documents cliniques à échanger. La norme a été publiée conjointement avec l'ISO sous le nom ISO/HL7 27932.

Document de continuité des soins (CCD)

Article principal : Document de continuité des soins

Le CCD est une spécification américaine pour l'échange de résumés médicaux, basée sur le CDA.

Étiquetage structuré des produits (SPL)

Article principal : Étiquetage structuré des produits

SPL décrit les informations publiées qui accompagnent un médicament, basées sur HL7 Version 3.

CCOW

Article principal: CCOW

CCOW , ou "Clinical Context Object Workgroup", est un protocole standard conçu pour permettre à des applications disparates de partager le contexte utilisateur et le contexte patient en temps réel et au niveau de l'interface utilisateur. Les implémentations CCOW nécessitent généralement un système de coffre-fort CCOW pour gérer la sécurité des utilisateurs entre les applications.

Autres normes et méthodes

Ressources d'interopérabilité rapide des soins de santé (FHIR)

Article principal: Ressources d'interopérabilité rapide des soins de santé

Fast Healthcare Interoperability Resources est un projet de norme de HL7 International conçu pour être plus facile à mettre en œuvre, plus ouvert et plus extensible que la version 2.x ou la version 3. Il s'appuie sur une suite Web moderne de technologie API, y compris un RESTful basé sur HTTP. protocole, HTML et feuilles de style en cascade pour l'intégration de l'interface utilisateur, un choix de JSON ou XML pour la représentation des données, OAuth pour l'autorisation et ATOM pour les résultats des requêtes.

Cadre d'interopérabilité sensible aux services

Article principal : HL7 Services Aware Interoperability Framework

Le cadre d'architecture d'entreprise prenant en charge les services HL7 (SAIF) assure la cohérence entre tous les artefacts HL7 et permet une approche standardisée du développement et de la mise en œuvre de l'architecture d'entreprise (EA), ainsi qu'un moyen de mesurer la cohérence.

SAIF est une façon de penser à la production de spécifications qui décrivent explicitement la gouvernance, la conformité, la conformité et la sémantique comportementale qui sont nécessaires pour obtenir une interopérabilité de travail sémantique calculable. La technologie de transmission d'informations envisagée peut utiliser une approche de messagerie, d'échange de documents ou de services.

Le SAIF est le cadre requis pour rationaliser l'interopérabilité des autres normes. SAIF est une architecture pour réaliser l'interopérabilité, mais ce n'est pas une conception de solution complète pour la gestion de l'architecture d'entreprise.

Syntaxe Arden

Article principal: syntaxe Arden

La syntaxe Arden est un langage d'encodage des connaissances médicales. HL7 International a adopté et supervise la norme en commençant par la syntaxe Arden 2.0. Ces modules de logique médicale ( MLM ) sont utilisés dans le cadre clinique car ils peuvent contenir des connaissances suffisantes pour prendre des décisions médicales uniques. Ils peuvent produire des alertes, des diagnostics et des interprétations ainsi qu'une fonction d'assurance qualité et un soutien administratif. Un MLM doit s'exécuter sur un ordinateur qui répond à la configuration minimale requise et sur lequel le programme correct est installé. Ensuite, le MLM peut donner des conseils pour quand et où cela est nécessaire.

MLLP

Une grande partie de la messagerie HL7 est transportée par le protocole de couche inférieure minimale (MLLP), également connu sous le nom de protocole de couche inférieure (LLP) ou de protocole de couche minimale (MLP). Pour la transmission via TCP/IP, des caractères d'en-tête et de fin sont ajoutés au message pour identifier le début et la fin du message car TCP/IP est un flux continu d'octets. Le protocole HLLP (Hybrid Lower Layer Protocol) est une variante de MLLP qui inclut une somme de contrôle pour aider à vérifier l'intégrité du message. Parmi les autres éditeurs de logiciels, MLLP est pris en charge par Microsoft, Oracle, Cleo .

MLLP ne contient aucune sécurité ou cryptage inhérent, mais s'appuie sur des protocoles de couche inférieure tels que Transport Layer Security (TLS) ou IPsec pour protéger les informations de santé protégées en dehors d'un réseau sécurisé.

Spécifications fonctionnelles EHR et PHR

Spécifications fonctionnelles d'un dossier de santé électronique .

Détails du message

Le segment OBR

Un segment OBR contient des informations sur un examen, une étude diagnostique/une observation. Il s'agit d'un segment obligatoire dans un message ORM (order message) ou ORU (Observation Result).

Voir également

Les références

Définition des uvres Culturelles Libres logo notext.svg Cet article incorpore le texte d'un travail de contenu gratuit . Sous licence Creative Commons Attribution-ShareAlike 3.0 Texte extrait de Spronk 2007 . Pour savoir comment ajouter du texte de licence ouverte aux articles de Wikipédia, veuillez consulter cette page d'instructions . Pour plus d'informations sur la réutilisation du texte de Wikipédia , veuillez consulter les conditions d'utilisation .

Liens externes

Avis critiques