Erste Schritte

Diese Seite führt dich einmal komplett durch Brio-IO — nicht an Screenshots entlang, sondern an einem laufenden System. Als Kulisse dient die öffentliche Demo: ein vollständiges Brio-IO im Browser, mit vorkonfigurierten Channels und fließendem Traffic.

Warum Demo und nicht „lokal installieren”? Brio-IO ist im Early Access. Es gibt bewusst keinen öffentlichen Self-Service-Download — Zugänge richten wir persönlich ein. Wie ein eigener Server betrieben wird, steht im Kapitel Betrieb; zum Kennenlernen ist die Demo der schnellere und ehrlichere Weg.

Was du brauchst

Einen Demo-Zugang. Der ist personalisiert — kein Self-Service-Formular, keine Zugangsdaten auf der Website. Wenn du noch keinen hast: frag uns nach einem Zugang und schreib kurz dazu, welche Schnittstellen du integrieren willst.

Zwei Dinge, die du vorher wissen solltest:

• Die Demo wird alle zwei Stunden auf einen frischen Seed-Stand zurückgesetzt. Was du änderst, ist zum Ausprobieren gedacht, nicht zum Behalten.
• Schick ausschließlich Testdaten durch. Keine echten Patienten-, Personen- oder Klinikdaten.

1. Einloggen

Öffne die Demo und melde dich mit deinen Zugangsdaten an. Nach dem Login landest du im Dashboard: eine Übersicht der Channels mit ihren Kennzahlen — empfangen, gesendet, Fehler.

Anders als bei einer frischen Installation ist hier schon etwas los: Der eingebaute Message Generator speist laufend synthetische HL7v2-Nachrichten (ADT^A01) durch die Channels, über nahezu den ganzen Zwei-Stunden-Zyklus. Wer zehn Minuten nach einem Reset kommt, sieht Leben — nicht ein leeres Dashboard.

2. Einen Channel ansehen

Ein Channel ist die Verarbeitungsstrecke einer Nachricht. Er hat genau einen Source-Connector (wo Nachrichten hereinkommen), optional Filter und Transformer, und einen oder mehrere Destination-Connectors (wohin das Ergebnis geht):

Source  →  Filter  →  Transformer  →  Destinations

Öffne einen der vorkonfigurierten Channels. Du siehst dieselbe Reihenfolge im Editor wieder. Zwei der Demo-Channels sind mit Absicht unterschiedlich geskriptet: einer nutzt das moderne Property-Idiom (GraalJS), einer den klassischen E4X-Stil aus Mirth (Rhino). Was der Unterschied bedeutet, steht im Transformer-Handbuch.

3. Eine eigene Nachricht durchschicken

Das ist der Moment, der die Frage beantwortet, die wirklich zählt: „funktioniert das mit meinen Daten?”

1. Öffne bei einem Connector den Test-Modus.
2. Klick auf „Aus Datei laden” und wähle deine Datei. Erlaubt sind .hl7, .txt, .xml und .json bis 1 MB. Die Datei wird lokal im Browser gelesen und landet im Nachrichtenfeld — sie geht nicht über einen Umweg durch irgendeinen Dateiablage-Dienst.
3. Generieren schickt die Nachricht durch den Connector — inklusive der konfigurierten Transformer.

Du kannst den Text im Nachrichtenfeld auch direkt tippen oder einfügen, wenn du keine Datei zur Hand hast.

4. Das Ergebnis im Message-Browser lesen

Im Message-Browser taucht deine Nachricht auf. Und hier liegt der eigentliche Wert: Brio-IO speichert die Nachricht stufenweise, nicht nur am Ende.

Stufe	Was du siehst
RAW	genau das, was hereinkam — unverändert
TRANSFORMED	das Ergebnis nach Filter und Transformer
SENT	was an die Destination ging

Öffne die Stufen nebeneinander: links dein Original, rechts das Ergebnis. Jede Stufe lässt sich über den Download-Knopf herunterladen — auch das kanonische XML, gegen das deine Skript-Pfade laufen würden.

Wenn eine Nachricht nicht durchgeht, ist das genauso sichtbar: Der Status wird ERROR, und im Hinweise-Bereich der Nachricht steht, woran es lag. Eine Nachricht, die ein Filter verworfen hat, erscheint als FILTERED — sie verschwindet nicht stillschweigend.

5. Einen Transformer ändern und deployen

Bearbeite im Channel-Editor den Transformer eines Channels — ändere eine Zeile, speichere und deploye den Channel neu. Die nächsten Nachrichten tragen deine Änderung. Im Message-Browser siehst du den Unterschied unmittelbar: die RAW-Stufe unverändert, die TRANSFORMED-Stufe mit deinem neuen Wert.

Ein Beispiel, das in der Demo genau so läuft (GraalJS):

msg.MSH.MSH_6.MSH_6_1 = 'BRIO-DEMO-MODERN';
var zbr = createSegment('ZBR', msg);
zbr.ZBR_1 = 'script-created';
msg;

Drei Dinge stecken darin: ein Feld schreiben, ein neues Segment anlegen, und die Nachricht zurückgeben. Alle drei erklärt das Transformer-Handbuch im Detail.

6. Branches: eine Änderung beobachten, bevor sie live geht

Einer der Demo-Channels trägt einen Shadow-Branch. Er beobachtet den echten Traffic des laufenden Channels und führt die Pipeline auf einer Live-Kopie aus — ohne ein echtes Ziel anzurufen. Im Message-Browser erscheinen dafür SHADOW_SENT-Einträge, die mit dem Traffic mitwachsen.

Im Vergleich siehst du dann Nachricht für Nachricht, ob main und Branch dasselbe Ergebnis erzeugen — mit dem Urteil DIFFERENT, wenn sie es nicht tun. Das ist der Punkt, an dem eine Änderung überprüfbar wird, bevor sie Konsequenzen hat.

Ehrliche Grenze: Einen Branch deployen kannst du heute nicht. Der Knopf ist absichtlich deaktiviert, und der Server lehnt einen solchen Deploy mit einem Fehler ab. Der Grund steht im Kapitel Konzepte — es ist kein Bug, sondern eine bewusste Sperre, solange alle Branches denselben Laufzeit-Kontext teilen. Der Validierungsweg ist Shadowing plus Vergleich.

Wie es weitergeht

• Konzepte — Channel- und Connector-Modell, kanonisches XML, Git als Konfigurationsquelle, Branches.
• Transformer-Handbuch — Feldpfade lesen und schreiben, Segmente anlegen, Wiederholfelder, alle drei Engines.
• Connector-Referenz — welche Protokolle es gibt und wie sie konfiguriert werden.
• Mirth-Migration — was wörtlich weiterläuft und was nicht.