Getting started

This page walks you through Brio-IO once, end to end — not along screenshots, but along a running system. The stage is the public demo: a complete Brio-IO in the browser, with preconfigured channels and live traffic.

Why the demo and not a local install? Brio-IO is in Early Access. There is deliberately no public self-service download — we set up access personally. How to run your own server is covered in Operations; to get to know the product, the demo is the faster and more honest route.

What you need

A demo account. It is personal — no self-service form, no credentials published on the website. If you do not have one yet, ask us for access and tell us briefly which interfaces you want to integrate.

Two things to know up front:

• The demo is reset to a fresh seed state every two hours. What you change is meant for trying things out, not for keeping.
• Send test data only. No real patient, personal or clinical data.

1. Sign in

Open the demo and sign in. You land on the dashboard: an overview of the channels with their counters — received, sent, errors.

Unlike a fresh installation, something is already happening here: the built-in message generator continuously feeds synthetic HL7v2 messages (ADT^A01) through the channels, across nearly the whole two-hour cycle. Arrive ten minutes after a reset and you will see activity, not an empty dashboard.

2. Look at a channel

A channel is the processing path of a message. It has exactly one source connector (where messages arrive), optional filters and transformers, and one or more destination connectors (where the result goes):

Source  →  Filter  →  Transformer  →  Destinations

Open one of the preconfigured channels; the editor shows the same order. Two of the demo channels are scripted differently on purpose: one uses the modern property idiom (GraalJS), one the classic E4X style from Mirth (Rhino). What that difference means is covered in the Transformer handbook.

3. Push your own message through

This is the moment that answers the question that actually matters: “does this work with my data?”

1. Open test mode on a connector.
2. Click “Load from file” and pick your file. Allowed are .hl7, .txt, .xml and .json up to 1 MB. The file is read locally in the browser and lands in the message field — it does not travel through any file storage service on the way.
3. Generate sends the message through the connector, including the configured transformers.

You can also type or paste the message text directly if you do not have a file at hand.

4. Read the result in the message browser

Your message appears in the message browser. And this is where the real value sits: Brio-IO stores the message in stages, not only at the end.

Stage	What you see
RAW	exactly what arrived — unchanged
TRANSFORMED	the result after filter and transformer
SENT	what went to the destination

Open the stages side by side: your original on the left, the result on the right. Every stage can be downloaded — including the canonical XML your script paths would run against.

If a message does not make it through, that is just as visible: the status becomes ERROR, and the message’s notes area says why. A message dropped by a filter shows up as FILTERED — it does not vanish silently.

5. Change a transformer and deploy

Edit a channel’s transformer in the channel editor — change a line, save and redeploy the channel. The next messages carry your change. The message browser shows the difference immediately: the RAW stage unchanged, the TRANSFORMED stage with your new value.

An example that runs in the demo exactly like this (GraalJS):

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

Three things are in there: writing a field, creating a new segment, and returning the message. All three are explained in detail in the Transformer handbook.

6. Branches: watch a change before it goes live

One of the demo channels carries a shadow branch. It observes the real traffic of the running channel and executes the pipeline on a live copy — without calling a real destination. SHADOW_SENT entries appear in the message browser and grow with the traffic.

The comparison then shows you message by message whether main and the branch produce the same result, with the verdict DIFFERENT when they do not. That is the point where a change becomes checkable before it has consequences.

An honest limit: you cannot deploy a branch today. The button is deliberately disabled, and the server rejects such a deploy with an error. The reason is in Concepts — it is not a bug but a deliberate block for as long as all branches share one runtime context. The validation path is shadowing plus comparison.

Where to go next

• Concepts — channel and connector model, canonical XML, Git as the configuration source, branches.
• Transformer handbook — reading and writing field paths, creating segments, repeating fields, all three engines.
• Connector reference — which protocols exist and how they are configured.
• Mirth migration — what keeps running verbatim and what does not.