Configuration de Production

Cette démo comporte une production d'interopérabilité contenant 16 composants.

Configuration de Production HL7 + Kafka Producer

La première partie de cette démonstration consiste à envoyer un fichier HL7 SIU qui sera transmis aux 2 autres flux HL7 (HTTP et TCP), et transformé et transmis au serveur Kafka. Les flux HTTP et TCP transformeront les messages HL7 de la même manière avant de les envoyer également à Kafka.

Introduction

Cet article vise à explorer le fonctionnement du système FHIR-PEX et a été développé, en tirant parti des capacités d'InterSystems IRIS.

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab.

Aujourd'hui, parlons d'interopérabilité.

Problème

Lorsque vous avez une production d'interopérabilité active, vous avez deux flux de processus distincts : une production active qui traite les messages et un flux de processus CI/CD qui met à jour le code, la configuration de la production et les paramètres par défaut du système.

De toute évidence, le processus CI/CD affecte l'interopérabilité. Mais il y a des questions :

• Que se passe-t-il exactement lors d'une mise à jour ?
• Que devons-nous faire pour minimiser ou éliminer les temps d'arrêt de la production lors d'une mise à jour ?

J'ai récemment eu besoin de surveiller depuis HealthConnect les enregistrements présents dans une base de données NoSQL dans le Cloud, plus précisément Cloud Firestore, déployé dans Firebase. D'un coup d'œil rapide, j'ai pu voir à quel point il serait facile de créer un adaptateur ad-hoc pour établir la connexion en tirant parti des capacités d'Embedded Python, et je me suis donc mis au travail.

Bienvenue dans le prochain chapitre de ma série CI/CD, où nous discutons des approches possibles vers le développement de logiciels avec les technologies InterSystems et GitLab.
Aujourd'hui, nous reprenons la discussion sur l'interopérabilité, et plus particulièrement sur le suivi de vos déploiements d'interopérabilité. Si vous ne l'avez pas encore fait, configurez Alerte pour toutes vos productions d'interopérabilité afin de recevoir des alertes sur les erreurs et l'état de la production dans son ensemble.

Le paramètre de délais d'inactivité Inactivity Timeout est commun pour tous les hôtes métier d'interopérabilité (Interoperability Business Hosts). Un hôte métier possède le statut Inactif lorsqu'il n'a reçu aucun message pendant le nombre de secondes spécifié dans le champ de délai d'inactivité " Inactivity Timeout ". La fonction de surveillance de la production " Monitor Service " examine périodiquement l'état des services et des opérations métier au sein de la production et marque les éléments comme étant inactifs s'ils n'ont rien fait pendant le délai d'inactivité.
La valeur par défaut est 0 (zéro). Si ce paramètre est 0, l'hôte métier ne sera jamais marqué comme Inactif, quelle que soit la durée de son inactivité.

Ce paramètre est extrêmement utile, car il génère des alertes qui, associées aux alertes configurées, permettent de signaler les problèmes de production en temps réel. Le fait que l'élément "Business Host" soit inactif signifie qu'il peut y avoir des problèmes de production, d'intégration ou de connectivité réseau qui nécessitent d'être examinés.
Cependant, le Business Host ne peut avoir qu'un seul paramètre constant pour le délai d'inactivité, ce qui peut générer des alertes inutiles pendant les périodes connues de faible trafic : nuits, week-ends, vacances, etc.
Dans cet article, je décrirai plusieurs approches pour la mise en œuvre dynamique des délais d'inactivité (Inactivity Timeout). Bien que je fournisse un exemple fonctionnel (qui fonctionne actuellement en production pour l'un de nos clients), cet article est plutôt un guide pour votre propre mise en œuvre dynamique des délais d'inactivité, donc ne considérez pas la solution proposée comme la seule alternative.

Quels sont les avantages/inconvénients à utiliser la ressource Person avec un lien vers les ressources Patient et Practitioner, plutôt qu'utiliser directement les ressources Patient et Practitioner sans avoir recours aux ressources

InterSystems FAQ rubric

Record maps sont utilisés pour faire correspondre efficacement des fichiers contenant des enregistrements délimités ou des enregistrements de largeur fixe aux classes de messages utilisées par la fonction d'interopérabilité, et pour faire correspondre des fichiers de classes de messages de la fonction d'interopérabilité à des fichiers texte.

Bonjour La Communauté,

en utilisant un Business Service de type SQL, il peut arriver que nous ayons besoin de rejouer certaines lignes de la table source.

Prenons comme exemple le Business Service "from customer SQL" utilisant la classe générique EnsLib.SQL.Service.GenericService

Parmi les points problématiques de la maintenance des interfaces HL7 figure la nécessité d'effectuer un test de régression fiable lors du déploiement dans de nouveaux environnements et après les mises à jour. La classe %UnitTest permet de créer des tests unitaires et de les intégrer au code de l'interface. Les données de test peuvent également être enregistrées au sein de la classe de test unitaire, ce qui permet de réaliser rapidement et facilement des tests de fumée et des tests de régression.

Ressources:

• Classe %UnitTest standard

La possibilité de renvoyer facilement des messages a toujours été une caractéristique importante de nos capacités d'interopérabilité.

Avec la sortie de la version 2024.3, nous avons rendu cela encore plus facile !