HL7v2

HL7v2 (Health Level Seven International Version 2) est un format de messagerie clinique qui fournit des données sur les événements se produisant au sein d'une organisation.

Consultez la documentation de la suite de produits HL7 Version 2 pour en savoir plus sur HL7v2.

Magasins HL7v2

Un magasin HL7v2 est un datastore résidant dans un ensemble de données. Les magasins HL7v2 contiennent des messages HL7v2.

La ressource HL7V2Store fournit une représentation des attributs d'un magasin HL7v2. Vous pouvez choisir différentes options pour chacun de vos magasins HL7v2. Par exemple, vous pouvez :

  • publier les modifications apportées au magasin HL7v2 (si, par exemple, votre application reçoit un nouveau message) dans un sujet Cloud Pub/Sub ;
  • choisir comment analyser les messages ingérés dans un magasin HL7v2.

Messages HL7v2

Les messages HL7v2 bruts peuvent être difficiles à lire. Prenons l'exemple du message suivant :

MSH|^~\&|FROM_APP|FROM_FACILITY|TO_APP|TO_FACILITY|20180101000000||ADT^A01|20180101000000|P|2.5|
EVN|A01|20110613083617|
PID|1|843125^^^^MRN|21004053^^^^MRN~2269030303^^^^ORGNMBR||SULLY^BRIAN||19611209|M|||123 MAIN ST^^CITY^STATE^12345|
PV1||I|H73 RM1^1^^HIGHWAY 01 CLINIC||||5148^MARY QUINN|||||||||Y||||||||||||||||||||||||||||20180101000000|

L'API Cloud Healthcare peut :

  1. Analyser un message
  2. Extraire plusieurs champs du segment d'en-tête de message (MSH) pour permettre le filtrage
  3. Représenter le contenu du message sous forme de données JSON pour un traitement ou un échange de données ultérieur

La ressource Message fournit une représentation d'un message HL7v2. Elle inclut les informations suivantes :

  • L'heure à laquelle le message a été créé
  • La personne ayant créé le message
  • Les données contenues dans le message

La ressource Message du message précédent se présente comme suit :

{
  "name": "projects/PROJECT_ID/locations/LOCATION/datasets/DATASET_ID/hl7V2Stores/HL7V2_STORE_ID/messages/W5_pxOBkoLoCxiFxE4cg8zwEWRzMlOzIfaLBrZPf0Zg=",
  "data": "TVNIfF5+XCZ8RlJPTV9BUFB8RlJPTV9GQUNJTElUWXxUT19BUFB8VE9fRkFDSUxJVFl8MjAxODAxMDEwMDAwMDB8fEFEVF5BMDF8MjAxODAxMDEwMDAwMDB8UHwyLjV8DUVWTnxBMDF8MjAxMTA2MTMwODM2MTd8DVBJRHwxfDg0MzEyNV5eXl5NUk58MjEwMDQwNTNeXl5eTVJOfjIyNjkwMzAzMDNeXl5eT1JHTk1CUnx8U1VMTFleQlJJQU58fDE5NjExMjA5fE18fHwxMjMgTUFJTiBTVF5eQ0lUWV5TVEFURV4xMjM0NXwNUFYxfHxJfEg3MyBSTTFeMV5eSElHSFdBWSAwMSBDTElOSUN8fHx8NTE0OF5NQVJZIFFVSU5OfHx8fHx8fHx8WXx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHwyMDE4MDEwMTAwMDAwMHw=",
  "sendFacility": "FROM_FACILITY",
  "sendTime": "2018-01-01T00:00:00Z",
  "messageType": "ADT",
  "createTime": "2018-01-01T00:00:00Z",
  "patientIds": [
    {
      "value": "843125",
      "type": "MRN"
    },
    {
      "value": "21004053",
      "type": "MRN"
    },
    {
      "value": "2269030303",
      "type": "ORGNMBR"
    }
  ],
  "parsedData": {
    "segments": [
      {
        "segmentId": "MSH",
        "fields": {
          "5": "TO_FACILITY",
          "2": "FROM_APP",
          "3": "FROM_FACILITY",
          "0": "MSH",
          "1": "^~\\&",
          "10": "P",
          "4": "TO_APP",
          "9": "20180101000000",
          "8.1": "ADT",
          "11": "2.5",
          "8.2": "A01",
          "6": "20180101000000"
        }
      },
      {
        "segmentId": "EVN",
        "fields": {
          "1": "A01",
          "2": "20110613083617",
          "0": "EVN"
        }
      },
      {
        "segmentId": "PID",
        "fields": {
          "1": "1",
          "3[0].1": "21004053",
          "3[1].1": "2269030303",
          "3[0].5": "MRN",
          "0": "PID",
          "11.4": "STATE",
          "11.5": "12345",
          "2.1": "843125",
          "2.5": "MRN",
          "5.1": "SULLY",
          "11.3": "CITY",
          "8": "M",
          "11.1": "123 MAIN ST",
          "3[1].5": "ORGNMBR",
          "7": "19611209",
          "5.2": "BRIAN"
        }
      },
      {
        "segmentId": "PV1",
        "fields": {
          "44": "20180101000000",
          "7.1": "5148",
          "16": "Y",
          "2": "I",
          "3.2": "1",
          "3.4": "HIGHWAY 01 CLINIC",
          "7.2": "MARY QUINN",
          "3.1": "H73 RM1",
          "0": "PV1"
        }
      }
    ]
  }
}

Créer et ingérer des messages

Vous pouvez stocker des messages HL7v2 dans un magasin HL7v2 à l'aide des méthodes suivantes :

  • messages.create : crée une ressource Message et la stocke dans le magasin HL7v2. La réponse de cette méthode contient le corps du message.

  • messages.ingest : ingère une ressource Message et la stocke dans le magasin HL7v2. La réponse de cette méthode contient le corps du message et un champ d'accusé de réception, hl7ack, qui vérifie que le message a été accepté.

    Notez les informations importantes suivantes concernant la valeur du champ hl7ack :

    • La valeur contient un type de réponse. Un type de réponse AA indique Application Accept, ce qui signifie que le message a été validé et ingéré avec succès.
    • L'installation d'envoi et l'installation de réception sont inversées.
    • La valeur contient l'ID de contrôle du message d'origine.

Si votre application nécessite une réponse ACK, utilisez messages.ingest. Si votre application ne nécessite pas de réponse ACK, utilisez messages.create. Les réponses ACK ne sont pas conservées dans les magasins HL7v2.

Lorsque vous créez ou ingérez un message HL7v2, un ID lui est attribué par le serveur. Vous pouvez utiliser cet ID pour interagir avec le message (par exemple, pour le supprimer ou pour lui attribuer des étiquettes définies par l'utilisateur).

MLLP et adaptateur Google Cloud MLLP

La valeur minimale Protocole de couche (MLLP) est la norme utilisée pour la transmission de messages HL7v2 via des connexions TCP/IP. au sein d'un réseau, tel qu'un hôpital.

Le protocole MLLP n'offre pas de mappage exact avec l'API REST HL7v2 de l'API Cloud Healthcare, qui utilise HTTP. Par conséquent, un adaptateur MLLP doit être utilisé pour convertir les messages transmis par le protocole MLLP en un format compatible avec l'API HTTP/REST. Pour transmettre des messages via le protocole MLLP, puis à l'API Cloud Healthcare, utilisez l'adaptateur MLLP de Google Cloud. Pour suivre un tutoriel utilisant cet adaptateur MLLP, consultez la page Transmettre les messages HL7v2 via des connexions TCP/IP.

Si votre application nécessite qu'une autorité de confiance signe le message HL7v2, utilisez l'autorisation binaire avec l'adaptateur MLLP de Google Cloud. Pour suivre un tutoriel utilisant cet adaptateur MLLP, consultez la page Transmettre les messages HL7v2 via des connexions TCP/IP avec l'autorisation binaire.

L'administrateur n'analyse ou n'inspecte pas les messages HL7v2 ; l'API Cloud Healthcare analyse et valide les messages lorsqu'ils sont ingérés dans un magasin HL7v2. Vous pouvez ensuite valider davantage le message en l'affichant ou en le libellant pour l'analyser.

Pendant son exécution, l'adaptateur maintient une connexion TCP longue durée entre le réseau du système de soins et l'adaptateur. Il expose également un socket TCP pour accepter les messages HL7v2 via MLLP. L'adaptateur détermine les limites du message en détectant les octets de bloc de début et de fin de chaque message, comme défini dans la norme MLLP.

Lorsque l'adaptateur MLLP reçoit un message HL7v2 du système de soins sur la connexion TCP, il ingère le message dans le magasin HL7v2. Le magasin répond ensuite de manière synchrone à l'adaptateur MLLP avec ACK ou NACK. Une ACK est envoyée si le message est correctement formé et comporte un segment d'en-tête valide. L'adaptateur MLLP envoie la réponse ACK ou NACK au système de soins.

L'adaptateur MLLP peut également écouter un abonnement Pub/Sub associé au datastore HL7v2. Lorsqu'un message HL7v2 est créé ou ingéré dans le datastore, l'adaptateur MLLP reçoit la notification et publie le message auprès du système de soins.

MLLP et sécurité

MLLP n'est pas compatible de manière native avec les systèmes de chiffrement et d'authentification. Par conséquent, une connexion TCP utilisant MLLP doit être encapsulée dans une connexion sécurisée à l'aide d'un réseau privé virtuel (VPN). Vous pouvez utiliser Cloud VPN pour créer une connexion sécurisée entre le cluster GKE sur lequel l'adaptateur MLLP s'exécute et votre application sur site. Pour en savoir plus, consultez la page Configurer Cloud VPN.

HL7v2, MLLP et Pub/Sub

Un aspect fondamental de l'utilisation de HL7v2 avec l'API Cloud Healthcare implique la configuration des notifications Pub/Sub. En utilisant une application d'abonné avec Pub/Sub, vous pouvez recevoir des notifications lorsqu'un message HL7v2 est créé ou ingéré dans un datastore HL7v2.

Consultez la page Configurer les notifications Pub/Sub pour découvrir comment utiliser les sujets Pub/Sub avec la mise en œuvre HL7v2 de l'API Cloud Healthcare.

Architecture du format HL7v2, du protocole MLLP et de Google Cloud

Le schéma suivant montre comment un message HL7v2 est envoyé par un système de soins et ingéré dans l'API Cloud Healthcare. L'adaptateur MLLP est déployé sur Google Kubernetes Engine, et le message est transmis via un VPN à l'aide de Cloud VPN. Après l'ingestion, une application d'abonné au sujet Pub/Sub du magasin HL7v2 reçoit une notification indiquant que le message a été ingéré. L'API Cloud Healthcare génère également un ACK pour l'adaptateur MLLP et le renvoie via le tunnel VPN vers le système de soins.

Le message HL7v2 envoyé par le système de soins est un message "ADT", qui est courant dans HL7v2. Lorsqu'un système de soins envoie un message ADT, il ne s'attend pas à ce qu'un nouveau message soit généré et renvoyé par le système distant/sur site.

mllp_adapter

Le schéma montre les éléments suivants :

  1. Le système de soins sur site.
  2. Un message HL7v2 de type ADT quitte le système de soins.
  3. Le message HL7v2 est ingéré via l'adaptateur MLLP dans un datastore HL7v2.
  4. Le sujet Pub/Sub configuré du datastore HL7v2 reçoit une notification indiquant que le message a été ingéré.
  5. Une application d'abonné écoute les notifications des ingestions de messages HL7v2 depuis son sujet Pub/Sub.