Mirth Connect 4.5.2 exposure checklist

Which version is running: Administrator, About, or the first lines of the server log at start-up.

Good looks like: You know the number. If it is 4.5.2 or earlier, you are on the last open-source release.

Why it matters: Every other check depends on knowing what you run.

Who can reach the Administrator console, and from where.

Good looks like: A short list of named people, from inside the network or over a VPN, never from the open internet.

Why it matters: The console can read every message the engine holds.

Whether the console still accepts the default administrator credentials.

Good looks like: It does not.

Why it matters: Defaults are the first thing anyone tries.

Whether every account is a named person.

Good looks like: No shared logins; people who left are gone.

Why it matters: A shared login cannot be traced to a person, and a leaver's login cannot be trusted.

Which channels listen on the network, on which ports, and whether anything outside the site can reach them.

Good looks like: Each listener is known, needed, and reachable only by the system that sends to it.

Why it matters: A listener nobody remembers is a door nobody watches.

Whether messages travel encrypted between systems: TLS on MLLP where the other side supports it, a VPN where it does not.

Good looks like: Nothing crosses the open internet in the clear.

Why it matters: An HL7 message carries a patient's name, dates and identifiers in plain text.

Whether message storage is pruned, and where old messages with patient data sit.

Good looks like: A retention setting you chose, on a disk you know.

Why it matters: Years of stored messages are a second copy of your patient data, often on the least watched machine.

Whether channel code (JavaScript transformers and filters) is in version control and reviewed.

Good looks like: A repository, a history, a second pair of eyes.

Why it matters: Channel code decides what reaches the billing system; a quiet edit changes claims.

Whether there is a backup of the channels and the server configuration, and whether a restore has been tried.

Good looks like: A dated export and a dated restore test.

Why it matters: A backup that has never been restored is a hope.

Whether someone is responsible for the engine by name, with time set aside.

Good looks like: A name and a cadence.

Why it matters: An engine with no owner is maintained by whoever is in the room when it breaks.