Musterinstanz 'Healthcare: HL7 an HL7' verwalten

Mithilfe von Musterparametern können Sie eine Musterinstanz mit Werten generieren, die für Ihre eigene Musterinstanz festgelegt werden. Sie müssen jedoch auch die Musterinstanz implementieren und verwalten. Möglicherweise müssen darüber hinaus bestimmte operative Kontexte geändert werden.

Das Muster nutzt eine einfache Topologie, bei der alle Nachrichtenflüsse auf einem einzelnen Nachrichtenbroker ausgeführt werden. Dieses Thema enthält Informationen zur Implementierung und Verwaltung einer Musterinstanz, die diese einfache Topologie verwendet. Außerdem erfahren Sie, wie Sie die Musterinstanz verwalten können.

Das Muster enthält einige spezielle Anpassungspunkte, über die Sie eigene Änderungen hinzufügen können.

Dieses Thema enthält folgende Abschnitte:

Einrichtung
Nachrichtengruppe 'HL7v25P' vorbereiten
Anpassung
Musterimplementierung
Überwachung und Fehlerbehandlung

Einrichtung

Warteschlangen

Vor der Generierung der Musterinstanz können Sie ein MQSC-Script für die Definition der vom Muster benötigten Warteschlangen generieren, indem Sie im Abschnitt General (Allgemein) der Registerkarte Configure Pattern Parameters (Musterparameter konfigurieren) das Kontrollkästchen Generate scripts (Scripts generieren) aktivieren. Dieses Script namens queues.mqsc befindet sich im Stammverzeichnis des Musterinstanzprojekts und definiert grundlegende Warteschlangen und Themen.

Sie können das MQSC-Script mit folgendem Befehl ausführen (dabei gibt MBQMGR den Namen des Warteschlangenmanagers für Ihren Broker an):

runmqsc MBQMGR < queues.mqsc

Durch eine entsprechende Bearbeitung dieses MQSC-Scripts können Sie ihm Beschreibungen für Ihre Umgebung hinzufügen und geeignete Warteschlangenlängen festlegen.

Sie müssen insbesondere die Länge der Warteschlange flowprefix.DUPID prüfen, die den Speicher für doppelte Daten enthält. In dieser Warteschlange sind alle Daten gespeichert, die für die Duplikatprüfung verwendet werden. Wenn die Duplikatprüfung aktiviert ist, wird die erforderliche Länge dieser Warteschlange durch die Multiplikation der maximalen Empfängernachrichtenrate mit der Dauer der Ablaufeinstellung berechnet. Wenn die maximale Rate beispielsweise zehn Nachrichten pro Sekunde beträgt und als Ablaufeinstellung 24 Stunden (86.400 Sekunden) festgelegt sind, lautet die erforderliche Länge 864000.

Es wird erwartet, dass andere Warteschlangen überwacht werden und deren Inhalt in regelmäßigen Abständen gelöscht wird. Da diese Warteschlangen mit einer Standardgröße erstellt werden, müssen Sie deren Verwendung überprüfen und sicherstellen, dass ihre Länge ausreicht.

Sie müssen das MQSC-Script vor der Implementierung der Musterinstanz ausführen.

Konfigurierbarer Service

Wenn Sie die Sequenzbildung aktiviert und die Option für separate Sequenzwarteschlangen ausgewählt haben, generiert das Muster eine konfigurierbare Servicedatei. Wenn Sie eine Instanz des Musters generieren, wird diese Datei im Stammverzeichnis des Containerprojekts erstellt, das die generierten Nachrichtenflüsse enthält. Dieser konfigurierbare Service teilt den Resequence-Knoten mit, wo folgegebundene Informationen gespeichert werden sollen. Der konfigurierbare Service muss vor der Implementierung des Musters für den Broker implementiert werden.

Nachrichtengruppe 'HL7v25P' vorbereiten

Laden Sie die Nachrichtengruppe 'HL7v25P' herunter. Weitere Informationen hierzu finden Sie unter Ressourcen für das Muster Healthcare: HL7 an HL7.

Diese Nachrichtengruppe erfüllt die Standards, die im HL7-Standard der Version 2.5 festgelegt sind. Als Nachricht wird vom Muster die HL7-Nachricht in der Nachrichtendefinitionsdatei segments.mxsd verwendet. Wenn Quellen- oder Zielanwendungen Änderungen am Standard vornehmen, müssen diese Änderungen im Nachrichtenmodell reflektiert werden. Die gängigsten Änderungen lauten wie folgt:

Neues Z-Segment erstellen

Z-Segmente werden von Anwendungen zum Senden oder Empfangen von Daten verwendet, die außerhalb der HL7-Spezifikation definiert sind. Sie können Z-Segmente modellieren und diese in Ihrer Implementierung verwenden:

  1. Erstellen Sie eine neue Nachrichtendefinitionsdatei. In dieser Datei wird der anwendungsspezifische Code getrennt von der Hauptnachrichtengruppe 'HL7v25P' gespeichert. Klicken Sie mit der rechten Maustaste auf die Nachrichtengruppe 'HL7v25P' und wählen Sie New > Message Definition File (Neu > Nachrichtendefinitionsdatei) aus.
  2. Setzen Sie die Eigenschaft Target Namespace (Zielnamensbereich) dieser Nachrichtendefinitionsdatei auf urn:hl7-org:v2xml.
  3. Öffnen Sie die neue Nachrichtendefinitionsdatei und wählen Sie die Registerkarte Properties (Eigenschaften) aus. Fügen Sie die Datei datatypes.mxsd hinzu.
  4. Erstellen Sie in Ihrer neuen Datei mit der Erweiterung .mxsd ein neues globales Element, das denselben Namen wie die Z-Segmentdefinition trägt, die von der Quellen- oder Zielanwendung bereitgestellt wird.
  5. Ändern Sie für dieses Element den Wert von Type (Typ) in New local complex (Neuer lokaler komplexer Typ).
  6. Erstellen Sie einzelne Felder als lokale Elemente. Wenn das Z-Segment Felder mit untergeordneten Feldern enthält, wählen Sie im Menü unter Type (Typ) einen geeigneten Typ für das Element aus, indem Sie auf More (Weitere) klicken. Diese Typen sind in der Datei fields.mxsd definiert. Stellen Sie sicher, dass die resultierende Struktur der Spezifikation des Quellen- oder Zielproviders entspricht.
  7. Fügen Sie der HL7-Nachricht das neue Element hinzu:
    1. Öffnen Sie die Nachrichtendefinitionsdatei segments.mxsd, wählen Sie die Registerkarte Properties (Eigenschaften) aus, fügen Sie die von Ihnen erstellte neue Nachrichtendefinitionsdatei ein, und speichern Sie die Änderung.
    2. Fügen Sie der HL7-Nachricht für das neue Element, das Sie erstellt haben, einen Elementverweis hinzu:
      1. Erweitern Sie die HL7-Nachricht in der Nachrichtendefinitionsdatei segments.mxsd.
      2. Klicken Sie mit der rechten Maustaste auf Choice (Auswahl) und wählen Sie Add Element Reference (Elementverweis hinzufügen) aus.
    3. Öffnen Sie die Eigenschaften des von Ihnen erstellten globalen Elements und setzen Sie den Tag auf den Elementnamen.
  8. Öffnen Sie für jedes Element im neuen Z-Segment die Eigenschaften und setzen Sie den Namensbereich auf urn:hl7-org:v2xml.
Herstellerspezifische Zusätze zum HL7-Standard

HL7-Implementierungen können die durch HL7 definierten Standardsegmente ergänzen, indem am Ende eines Segments zusätzliche Felder hinzugefügt werden. Diese Zusätze werden in der Regel durch ein Remainder-Feld am Ende jeder Segmentdefinition modelliert. Sie können vor dem Remainder-Feld jedoch die zusätzlichen Felder hinzufügen, die von Herstellern benötigt werden.

Anpassung

Den Benutzern des Musters stehen drei Hauptanpassungspunkte zur Verfügung. Darüber hinaus sind jedoch noch weitere Anpassungspunkte verfügbar.

Quellenanpassung

Der Hauptnachrichtenfluss 'TransformAndRoute' ruft den untergeordneten Fluss 'SubCustomize' auf, bevor er die Nachrichten an verschiedene Ziele verteilt und gegebenenfalls das kanonische Format der Nachricht erstellt.

Der standardmäßige untergeordnete Fluss 'SubCustomize' hat keine Auswirkung auf die Nachricht, Sie können mit diesem Anpassungspunkt jedoch Daten aus der Quelle standardisieren, damit Ihre Anforderungen erfüllt werden. Es kann beispielsweise vorkommen, dass Ihr Standard für Datumsangaben das Format JJJJ-MM-TT vorschreibt, die Quelle jedoch ein anderes Datumsformat verwendet. Mit diesem Anpassungspunkt können Sie beliebige Quellendaten ändern. Es kann auch gelegentlich sinnvoll sein, an diesem Punkt Daten einzufügen, die in anderen Quellen wie zum Beispiel Datenbanken verfügbar sind.

Zielanpassung

Für jedes Ziel gibt es einen standardmäßigen untergeordneten Fluss zur Anpassung (namens Destn, wobei n für die Nummer des Ziels steht), der keine Auswirkung auf die Nachricht hat. Sie können mit diesem untergeordneten Fluss jedoch eine Ausgabenachricht erstellen, die den Spezifikationen entspricht, die von dem betreffenden Ziel benötigt werden. Das Ziel könnte beispielsweise die folgenden Änderungen erfordern:

Verwendung von Quellenfeeds oder kanonischen Feeds

Wenn Sie sich für die Generierung eines Quellenfeeds oder kanonischen Feeds entschlossen haben, generiert jede vom Fluss 'Receiver' verarbeitete Nachricht eine Kopie der Quellennachricht oder der Nachricht nach der Kanonisierung. Diese Nachrichten werden in eine WebSphere MQ-Warteschlange geschrieben oder veröffentlicht, je nachdem, was durch Ihre Musterparameter angegeben ist.

Möglicherweise möchten Sie Nachrichten an Ziele senden, die nicht mit dem Muster kompatibel sind. Beispiele hierfür wären ein Data-Warehouse, ein Nicht-HL7-Ziel oder ein Ziel, das einen anderen Transportmechanismus verwendet. Sie können Nachrichten an Ziele senden, die nicht mit dem Muster kompatibel sind, indem Sie Nachrichtenflussanwendungen für die Verarbeitung der Nachrichten aus den Quellenfeeds oder kanonischen Feeds schreiben.

Musterimplementierung

Erstellen Sie eine neue Brokerarchivdatei (BAR-Datei) an der Position, an der Sie diese Ressourcen speichern möchten.

Die HL7v25P-Nachrichtengruppe muss in einer eigenen BAR-Datei gepackt werden:

  1. Wählen Sie die HL7v25P-Nachrichtengruppe aus und erstellen Sie die BAR-Datei.
  2. Implementieren Sie die BAR-Datei für alle Ausführungsgruppen, auf denen das Muster oder Teile davon ausgeführt werden soll(en).
  3. Vergewissern Sie sich nach der Implementierung der HL7v25P-Nachrichtengruppe, dass alle erforderlichen Warteschlangen definiert und die Dateien eventueller konfigurierbarer Services implementiert sind.
  4. Erstellen Sie mindestens eine BAR-Datei, die die Flüsse enthält, welche Sie für eine bestimmte Ausführungsgruppe implementieren möchten. Im einfachsten Fall, bei dem alles in einer einzelnen Laufzeitumgebung ausgeführt wird, müssen Sie die Flüsse 'Receiver' und 'TransformAndRoute' sowie alle Zielflüsse einschließen.
  5. Zur Leistungssteigerung nach der Erstellung der Flüsse kann es sinnvoll sein, die Einstellung Additional instances (Zusätzliche Instanzen) für jeden Fluss zu erhöhen, der keine Sequenzbildungsanforderungen hat:
    1. Klicken Sie auf die Registerkarte Manage (Verwalten).
    2. Wählen Sie die Eigenschaften von Flüssen aus, die Sie konfigurieren möchten, und legen Sie Werte fest, die von Ihrer Implementierung benötigt werden.

Überwachung und Fehlerbehandlung

Bei allen Nachrichtenflüssen im Muster werden Fehlerbenachrichtigungen in eine Fehlerwarteschlange geschrieben. Darüber hinaus wird ein Warteschlangentrace an der Position ausgegeben, die Sie während der Generierung des Musters definiert haben. Der MQRFH2-Header der Fehlernachricht enthält Informationen, die angeben, wo der Fehler aufgetreten ist. In diesem Abschnitt finden Sie Details zum Verhalten der einzelnen Nachrichtenflüsse.

Fehler im Fluss 'Receiver'

Der Fluss 'Receiver' wird als Transaktion ausgeführt und sämtliche Ausgabenachrichten werden beim erfolgreichen Abschluss des Nachrichtenflusses festgeschrieben. Falls Bestätigungen erforderlich sind, sendet der Fluss 'Receiver' als letzte Aktion die Bestätigung (ACK). Sobald die Verarbeitung der Bestätigung erfolgreich abgeschlossen ist, wird der Fluss beendet und die Nachrichten werden festgeschrieben.

Für jede Aktion im Fluss 'Receiver' gilt Folgendes:

Falls ein Fehler auftritt, geschieht Folgendes:

Der Administrator muss die Fehlerwarteschlange und das Ereignisprotokoll überwachen, um festzustellen, wann Nachrichten nicht von der Empfängerwarteschlange verarbeitet wurden. Auf diese Weise kann er erforderliche Korrekturmaßnahmen ergreifen, um den Fehler zu beheben.

Fehler im Fluss 'TransformAndRoute'

Der Fluss 'TransformAndRoute' wird als einzelne Transaktion ausgeführt. Sobald der Nachrichtenfluss erfolgreich abgeschlossen wurde, werden sämtliche Ausgabenachrichten an folgenden Positionen festgeschrieben:

Falls ein Fehler auftritt, geschieht Folgendes:

Der Administrator muss die Fehlerwarteschlange und das Ereignisprotokoll überprüfen, um festzustellen, welche Fehler aufgetreten sind. Sowohl die Fehlerwarteschlange als auch die Rücksetzwarteschlangen enthalten Informationen. Nach der Verarbeitung einer korrigierten Nachricht müssen diese Informationen gelöscht werden, um ein Ansteigen der Daten in der Warteschlange zu verhindern.

Der Administrator muss eine Rücksetzwarteschlange für die Eingabewarteschlange konfigurieren.

Wenn für eine Nachricht vom Fluss 'Routing and Transformation' ein Rollback durchgeführt wird, werden spätere Nachrichten dennoch verarbeitet und an die Sender-Flüsse übergeben. Diese Aktion kann jedoch bei jedem Ziel, das eine lockere oder strikte Sequenzbildung implementiert, eine Auswirkung auf die Sender-Flüsse haben, da die Folgenummer der fehlerhaften Nachricht fehlt. Dies führt dazu, dass Nachrichten in die Sequenzwarteschlange eingereiht werden, bis entweder eine Nachricht mit der richtigen Folgenummer empfangen wird, oder dass die Nachricht aufgrund einer Zeitlimitüberschreitung beendet wird, damit die fehlende Folgenummer übersprungen werden kann (nur bei der lockeren Sequenzbildung). Daher müssen Fehler im Fluss 'TransformAndRoute' möglichst schnell korrigiert werden.

Für die Korrektur eines Fehlers im Fluss 'TransformAndRoute' stehen zwei Möglichkeiten zur Verfügung:

Fehler im Fluss 'Sender'

Sender-Flüsse, die die Sequenzbildung unterstützen, enthalten den Resequence-Knoten 'Maintain Sequence'. Ein Resequence-Knoten unterteilt den Fluss in zwei Transaktionen. Wenn vor dem Resequence-Knoten eine Ausnahmebedingung auftritt, wird eine Nachricht in die Fehlerwarteschlange außerhalb der Transaktion geschrieben und für die Eingabenachricht wird ein Rollback zur Eingabewarteschlange für den Fluss 'Sender' durchgeführt. Die Eingabewarteschlange muss mit einer Rücksetzwarteschlange konfiguriert werden.

Diese Art der Fehlerbehandlung wird auch angewandt, wenn der Fluss 'Sender' keine Sequenzbildung aufweist.

Korrigieren Sie den Fehler mit einer der folgenden Lösungen:

Wenn an diesem Punkt im Fluss Fehler auftreten, bedeutet dies, dass eine Folgenummer fehlt. Wenn für den Fluss 'Sender' eine Sequenzbildung verwendet wird, muss der Administrator die Fehlerwarteschlange überprüfen und den Fehler möglichst schnell korrigieren. Spätere Nachrichten in der Folge werden in internen Sequenzwarteschlangen gespeichert; daher kann ein Fehler zu einer hohen Menge an Nachrichten führen.

Wenn ein Fehler nach dem Resequence-Knoten, aber vor dem Versenden der Nachricht an die Zielanwendung auftritt, wird eine Fehlernachricht geschrieben und die Nachricht wird auf die interne Sequenzwarteschlange zurückgesetzt. Um diese Art von Fehler zu beheben, muss der Administrator sicherstellen, dass die Zielanwendung sowohl verfügbar als auch verbunden ist. Der Resequence-Knoten versucht weiterhin, die Nachricht zuzustellen, damit die Nachricht zugestellt wird, sobald die Verbindung hergestellt wird. Bei einer strikten Sequenzbildung werden spätere Nachrichten erst zugestellt, wenn die vorherige Zustellung erfolgreich war.

Ein Fehler kann auch nach der Zustellung einer Nachricht auftreten. Diese Art von Fehler tritt auf, wenn die Zielanwendung die Nachricht nicht verarbeiten kann und eine NACK-Meldung sendet. In diesem Fall setzt der Fluss die Nachricht nicht auf den Resequence-Knoten zurück, da die Nachricht denselben Fehler möglicherweise wiederholt verursacht. Stattdessen wird eine Nachricht in die Fehlerwarteschlange geschrieben. Der Administrator muss die Fehlerwarteschlange überprüfen und das Problem bei der Zielanwendung beheben. In diesem Fall fließen Nachrichten mit einer höheren Folgenummer weiterhin.

Administratoren, die Fehler beheben müssen, finden die wichtigsten Informationen in den Nachrichten, die sich in der Fehlerwarteschlange und in den Rücksetzwarteschlangen befinden. Darüber hinaus steht jedoch auch die SEQNOS-Warteschlange zur Verfügung, in der der Status der aktuellen folgegebundenen Informationen gespeichert ist. Diese Warteschlange bietet einen Überblick über den Fluss der Nachrichten an jedes der Musterziele.

Zurück zur Spezifikation des Musters 'Healthcare: HL7 an HL7'