Rhino JavaScript to TypeScript

Mirth transformers run on Rhino, an ES5 JavaScript engine embedded in the JVM. intu-dev stages run TypeScript on a Node.js worker pool. Most logic translates directly; a few patterns do not.

What translates directly

Ordinary transformation code — reading fields, building strings, conditionals, loops, date formatting — moves across with little more than syntax modernization. If a transformer is mostly “read these segments, write this payload”, the import will land close to correct.

What changes for the better

Types. msg['PID']['PID.5']['PID.5.1'] becomes typed access with completion in the editor. Misspelling a field is now a compile-time error rather than an undefined that surfaces in production.

Modern JavaScript. const, let, arrow functions, destructuring, template literals, optional chaining, async/await, and the modern standard library are all available.

npm types. FHIR resource types mean a FHIR transformer is written against real shapes rather than untyped objects.

What needs rethinking

Java interop. Rhino can reach into Java classes — java.util.Date, Packages.*, JDBC calls from inside a transformer. None of that exists in a Node.js runtime. Date handling moves to JavaScript dates or a library; database access moves out of the transformer and into a database destination, which is where it belonged anyway.

Global variable maps. Mirth’s channel and global maps are a shared mutable namespace. Prefer explicit inputs and outputs; where state genuinely has to persist between messages, be deliberate about it rather than reaching for a global by habit.

Code templates. Shared functions become modules in the project, imported where needed — which means they are typed and testable.

Destination-specific logic in the source transformer. Very common in Mirth channels, and worth fixing during the migration rather than carrying over. Move it into the destination transformer. See The pipeline model.

A practical approach

1. Import the channel and read the transformer that came across.
2. Run it in the browser against a captured sample.
3. Fix what the type checker complains about — that is usually the Rhino-specific code.
4. Split anything destination-specific out of the source transformer.
5. Save the sample as a fixture and move to the next channel.

Doing this per channel rather than as one big rewrite keeps every step verifiable, and lets you cut over incrementally.