Architecture du canal Mirth Connect : source, filtre, transformateur, destination

Réponse directe

Un canal NextGen Connect (Mirth Connect) est source, filtre, transformateur, destination. Placez les URL d'environnement dans la carte de configuration, pas dans le XML du canal. Les messages en erreur ne sont pas automatiquement relancés. Exportez les canaux vers Git.

Cartographie des canaux

Mirth Connect est le nom du produit que la plupart des ingénieurs d'interface recherchent encore. Le nom du vendeur est NextGen Connect (Mirth Connect par NextGen Healthcare). Le 19 mars 2025, avec version 4.6, NextGen a déplacé les nouvelles versions vers une licence commerciale ; la source pour 4.6+ n'est pas sur GitHub. Source plus ancienne, notes de mise à niveau et FAQ restent. Cette page est une architecture de canaux, pas un avis sur la licence.

Un canal est un pipeline :

Source connector
    → source filter (accept / drop)
    → source transformer (normalize)
    → destination 1..n
         → destination filter
         → destination transformer
         → send + response
    → postprocessor

Cartes (du Liste de cartes de variables NextGen):

La configurationMap contient la configuration d’environnement : bases FHIR, hôtes MLLP, préfixes de chemin. NextGen le stocke sous forme de fichier plat et ne l'inclut pas dans les exportations de configuration du serveur, afin que le même canal XML puisse circuler entre les tests et la production. C'est là le point.

Hybrid v2 plus FHIR se trouve toujours sur ce pipeline – le Manuel de migration v2 vers FHIR. Les identifiants de commande/résultat appartiennent à flux de travail en radiologie et en laboratoire, pas dans une deuxième copie de ces cartes à l'intérieur de chaque transformateur.

Pièges d'identification

L'indexation des champs HL7 dans Rhino est basée sur 1 (msg['PID']['PID.3']['PID.3.1']). Les champs vides sont jetés si vous appelez .toString() sans garde - c'est un bug du transformateur, pas un "mauvais ADT".

Jeux de données de test

Désidentifié. Le canal XML est énorme ; garder les jeux de données de test comme messages + sortants attendus, pas sous forme de captures d'écran de l'administrateur.

ADT entrant (même exemple de Jane que l'article ADT) :

MSH|^~\&|HIS|HOSP-A|MIRTH|HOSP-A|20260917103000||ADT^A01^ADT_A01|MSG0001|P|2.5
PID|1||HOSP-MRN-0001^^^HOSP-A^MR||EXAMPLE^JANE^Q||19770412|F
PV1|1|I|||||||||||||||||VN-2026-00042^^^HOSP-A^VN|||||||||||||||||||||||||20260917103000

Carte de configuration (ne commettez jamais de vrais secrets ; il s’agit d’un exemple) :

his.mllp.host=his-test.example.org
his.mllp.port=2575
fhir.base=https://fhir-test.example.org/fhir
fhir.patient.mrn.system=https://hosp-a.example.org/mrn

Corps HTTP de destination (Patient tronqué) :

{
  "resourceType": "Patient",
  "identifier": [
    {
      "system": "https://hosp-a.example.org/mrn",
      "value": "HOSP-MRN-0001"
    }
  ],
  "name": [{ "family": "EXAMPLE", "given": ["JANE", "Q"] }],
  "birthDate": "1977-04-12"
}

Tests minimaux :

1. Filtre source : ADT^A01 accepté ; ORM abandonné (ou acheminé ailleurs).
2. Protection du transformateur : PID-3 vide → filtré ou ERREUR avec une raison, pas une TypeError.
3. Carte de configuration : XML du même canal par rapport aux bases de test et de production.
4. File d'attente de destination : arrêter le serveur FHIR, envoyer A01, message QUEUED, le serveur renvoie, message ENVOYÉ une fois.
5. Git : exportez le XML du canal, modifiez une ligne de transformateur, diff affiche cette ligne – pas une réorganisation des propriétés de 4 000 lignes.

Ne collez jamais de PHI en production dans les descriptions de canaux, les messages de test stockés dans Git ou le volet « Générer » de l'administrateur sur une machine de production.

Modes de défaillance et restauration

Les files d'attente de destination ne constituent pas la table des erreurs.

ERREUR signifie que le message est pas je vais réessayer tout seul. Les opérateurs retraitent ou vous acheminez les échecs vers un canal d'erreur (Channel Writer) qui appelle un humain. Réessayer est la file d'attente de destination. En mélangeant les deux, l'ADT A03 se trouve derrière un message A08 invalide et fausser l’état des séjours.

Exportation Git : les canaux vivent au format XML dans la base de données du moteur. Il n’y a pas de natif « le repo est le runtime ». Modèle pratique : REST exporte chaque canal vers un fichier ({id}-{name}.xml), formatage stable pour faciliter les comparaisons, pull request, import + déploiement sur la cible. Ne stockez pas configuration.properties dans le même dépôt que les secrets de production ; magasin clés et injecter des valeurs par environnement.

Désactivez une destination défaillante en annulant le déploiement cette destination (ou la chaîne) sans toucher au flux HIS. Maintenez le MLLP entrant actif si les expéditeurs cliniques ne peuvent pas mettre en mémoire tampon.

Service associé

Si vous avez besoin de canaux NextGen Connect / Mirth conçus, exportés et testés (ADT, ORM/ORU, FHIR HTTP), c'est-à-dire Mirth Connect. Pour une étude ciblée de l’architecture des canaux, utilisez formulaire de contact projet.

Cette page n'est pas une licence NextGen, ni un remplacement de Git par l’historique des canaux, ni une référence de débit.