OpenHIE Architecture Specification
5.0-fr
5.0-fr
  • Vue d’ensemble de la spécification
  • Comment utiliser la spécification
  • Cahier des charges de l’Architecture
    • Architecture
    • Principes architecturaux
    • Normes et profils
  • Spécifications de composants OpenHIE
    • Exigences non fonctionnelles
    • Registre clients (Client Registry, CR)
    • OpenHIE Facility Registry (FR)/Registre de l’établissement
    • OpenHIE Finance and Insurance Service (FIS/Service financier et d’assurances)
    • OpenHIE Health Management Information System (HMIS)/Système d’information de gestion de la santé
    • OpenHIE Health Worker Registry (HWR)/Registre des professionnels de santé
    • OpenHIE Interoperability Layer (IOL)/Couche d’interopérabilité
    • OpenHIE Logistics Management Information System (LMIS)/Système d’information de gestion logistique
    • OpenHIE Product Catalogue (PC)/Catalogue produits Open HIE
    • OpenHIE Shared Health Record (SHR)/Dossier médical partagé
    • OpenHIE Terminology Service (TS)/Service de terminologie
    • Systèmes de point de service
  • Spécification du flux de travail (Échange)
    • Flux de travail de rapports agrégés
      • Exporter les données agrégées
      • Valider et enregistrer les données agrégées
    • Alerte/Envoi de rappels ou d’informations
      • Envoyer le flux de travail d’alerte du client
      • Envoyer un flux de travail d’alerte aux professionnels de santé
    • Care Services Discovery
      • Flux de travail d’interrogation des dossiers des professionnels de santé et/ou de l’établissement
      • Flux de travail des dossiers Query Care Services
      • Flux de travail de recherche de services de soins
      • Flux de travail demande de mises à jour des services de soins
    • Flux de travail du laboratoire
      • Commander un test de laboratoire
      • Rapport des résultats du laboratoire
    • Flux de travail de gestion de l’identité des patients
      • Créer un flux de travail d’enregistrement démographique du patient
      • Mettre à jour le flux de travail d’enregistrement démographique du patient
      • Requête des enregistrements démographiques des patients par le flux de travail des identifiants
      • Requête des enregistrements démographiques des patients par le flux de travail des données démograph
    • Dossier médical partagé
      • Enregistrer le flux de travail des données cliniques au niveau du patient
      • Interroger le flux de travail des données cliniques au niveau du patient
    • Flux de travail du service de terminologie
      • Développer l’ensemble de valeurs
      • Traduire le code
      • Vérifier l’existence du code
      • Vérifier l’appartenance au code
      • Requête sur l’ensemble de valeurs
      • Requête sur les systèmes de code
      • Requête de schémas de concept
      • Code de recherche
    • Flux de travail des vaccins
    • Flux de travail des services financiers et d’assurance OpenHIE
      • HFW-001 : Inscrire un bénéficiaire
      • HFW-002 : Requête sur un bénéficiaire
      • HFW-003 : Vérifier l’admissibilité à la couverture
      • HFW-004 : Processus de demande
      • HFW-005 : Suivi de la demande
  • Comment fournir des commentaires et apporter sa contribution
  • Journal des modifications et gestion des versions
Powered by GitBook
On this page
  • Exigences relatives au flux de travail OpenHIE IOL
  • Exigences fonctionnelles relatives à OpenHIE IOL
  1. Spécifications de composants OpenHIE

OpenHIE Interoperability Layer (IOL)/Couche d’interopérabilité

Alors que les rôles des autres composants OHIE qui fournissent des services peuvent être plus facilement compris, c’est l’IOL qui sécurise et orchestre l’échange d’informations. Tel un chef d’orchestre, l’IOL fournit la force centrale qui permet à tous les composants du HIE de travailler ensemble et d’interagir avec les systèmes de point de service en dehors du HIE.

Voir également Exigences non fonctionnelles.

Exigences relatives au flux de travail OpenHIE IOL

Pour être un composant OHIE IOL, l’application IOL doit être en mesure de prendre en charge la norme requise suivante :

N°

Norme IHE

Recommandation/Exigence

IOLWF-1

· AT (Audit Trail/piste d’audit) - décrit comment les messages d’audit peuvent être envoyés et stockés dans un référentiel central qui, dans ce cas, serait l’IOL

· NA (Node Authentication/authentification de nœuds) - décrit comment l’IOL peut authentifier les clients (systèmes externes) qui souhaitent envoyer une demande dans l’échange

Obligatoire

En plus de cela, la couche d’interopérabilité est conçue pour être le point d’entrée unique dans un HIE. Cela signifie que l’IOL devrait être impliqué dans chaque flux de travail OpenHIE. Il gère de manière transparente le routage, la sécurité et l’audit des transactions, car ce sont des fonctions communes qui sont nécessaires dans tous les flux de travail.

Exigences fonctionnelles relatives à OpenHIE IOL

N°

Exigences fonctionnelles relatives au IOL

Recommandation/Exigence

IOLF-1

Le système devrait fournir un point d’accès central pour les services du HIE. Par exemple, cette interface donnera accès au CR, PR, FR et SHR. Ce point d’accès central simplifie la gestion de la sécurité et fournit un point d’entrée unique dans le HIE.

Recommandé

IOLF-2

Le système fournit des fonctions d’acheminement qui permettent aux messages d’être acheminés vers les bons systèmes du fournisseur de services au sein du HIE.

Exigence

IOLF-3

Le système fournit un mécanisme de journalisation central pour les messages envoyés via l’échange. Cette fonction devrait enregistrer des copies des messages qui transitent par la couche d’interopérabilité à des fins d’audit et de génération de rapports.

Exigence

IOLF-4

Le système devrait permettre la réexécution des transactions ayant échoué à un niveau central, ce qui évite aux systèmes de point de service d’avoir à renvoyer des données, par exemple, en cas de problème avec un composant d’infrastructure.

Recommandé

IOLF-5

Devrait prendre en charge la transformation des messages qui voyagent de la couche d’interopérabilité vers les systèmes du fournisseur de services et vice versa si le fournisseur de services n’est pas en mesure de communiquer dans le format requis, c’est-à-dire fournir des adaptateurs spécifiques à la mise en œuvre pour transformer les messages de la forme interne de la couche d’interopérabilité en une forme attendue par le fournisseur de services (par exemple, SHR, CR, PR).

Recommandé

IOLF-6

Le système devrait permettre l’acheminement des messages vers le composant d’architecture approprié ou le système de point de service externe.

· Effectue des tâches d’orchestration pour des transactions complexes afin d’alléger la charge des systèmes clients. Cette orchestration peut contacter plusieurs fournisseurs de services au sein du HIE au nom d’un client et compiler une réponse appropriée qui sera renvoyée au client.

· Des exemples d’orchestration pourraient être l’exécution d’un plan de soins ou la validation d’éléments (tels que des identifiants ou des codes) dans un message par rapport à d’autres fournisseurs de services au sein du HIE (par exemple, PR, CR, FR, TS).

· Les tâches d’orchestration sont celles qui sont nécessaires pour terminer la transaction en cours et doivent donc être exécutées ponctuellement, car la transaction ne peut pas continuer sans ces étapes.

Recommandé

IOLF-7

Les systèmes incluent une interface dans laquelle un moteur de flux de travail peut être connecté.

· Ce moteur de flux de travail devrait être capable de suivre l’état à long terme des soins d’un patient et d’effectuer des actions basées sur ce contexte (comme l’envoi d’alertes) pour améliorer les soins aux patients.

· Ce moteur de flux de travail est hors de portée pour une couche d’interopérabilité. Cependant, la couche d’interopérabilité devrait exposer une interface pour permettre la mise en œuvre de ce type de systèmes.

Exigence

IOLF-8

Le système devrait prendre en charge la possibilité d’être étendu en permettant l’ajout ou la suppression de fonctions de médiation supplémentaires, selon les besoins.

Recommandation

IOLF-9

Le système prend en charge un mécanisme de gestion et de suivi des erreurs, par exemple, une console pour visualiser les transactions qui ont échoué.

Exigence

IOLF-10

Le système permet aux transactions ayant échoué d’être regroupées par type d’erreur et par raison afin que les erreurs puissent être rectifiées efficacement en trouvant la cause première de l’erreur, en résolvant le problème et en réexécutant ces transactions.

Exigence

IOLF-11

Le système devrait prendre en charge la possibilité pour un utilisateur de réexécuter des transactions erronées via le HIE une fois que la raison de leur échec a été rectifiée.

Recommandation

IOLF-12

Le système fournit aux utilisateurs autorisés une vue des mesures permettant de surveiller le flux de messages via le HIE.

Exigence

IOLF-13

Le système gère la sécurité du HIE par l’authentification (vérification de l’identité), l’autorisation (autorisation d’interagir avec des composants HIE spécifiés) et le cryptage et décryptage des messages.

Exigence

IOLF-14

Le système prend en charge l’authentification et l’autorisation des systèmes qui essaient d’envoyer des données au HIE.

Exigence

IOLF-15

Le système devrait prendre en charge le cryptage des données en vol (lorsqu’elles ne se trouvent pas sur un réseau physiquement sécurisé) et au repos (chaque fois que des données sont stockées, par exemple lorsque des transactions sont stockées pour la journalisation).

Recommandation

IOLF-16

Le système devrait recueillir les statistiques de surveillance, telles que les charges de transaction et les mesures de performance, et fournir une vue de celles-ci pour surveiller le flux de messages via le HIE.

Recommandation

PreviousOpenHIE Health Worker Registry (HWR)/Registre des professionnels de santéNextOpenHIE Logistics Management Information System (LMIS)/Système d’information de gestion logistique

Last updated 2 years ago

- divisé en deux parties logiques

IHE ATNA