Honest alternatives to iNTERFACEWARE Iguana

Once you decide that Iguana deserves a contingency plan, the next question is obvious: what would you replace it with?

The less obvious answer is that there is no universally correct interface engine. A twenty-bed clinic, a national laboratory network, and a software vendor embedding an engine into its product are not shopping for the same thing.

I have tried to look at the options the way I would look at a real interface project: what problem does each one solve well, and what inconvenience arrives in the same box?

Option one: keep Iguana 6 running for now

This is a real option, not an absence of courage.

If the current version is stable, licensed for your environment and supported by people who understand your channels, keeping it in place while you prepare may be the lowest-risk short-term decision. It avoids a rushed rewrite and gives you time to export, document and test properly.

The weakness is that it does not answer the longer-term questions around vendor capacity, security updates, licensing or deployment restrictions. I would only choose this path with a dated review point, a tested restore, clear support contacts and a migration proof already underway.

Option two: wait for Iguana X

The proposed direction for Iguana X has some attractive ideas. iNTERFACEWARE says it intends to remove the license system, release the source under MPL 2.0, reduce external dependencies and allow fully on-premises operation.

Open code can reduce one kind of vendor lock-in, but it does not manufacture maintainers, support cover or production maturity. The same roadmap says important work remains on the queue, security model, and platform dependencies. For a technically strong team that likes Iguana's architecture, it may be worth evaluating. I would not make an unfinished roadmap my only continuity plan.

Option three: Open Integration Engine

Open Integration Engine is the community fork that continued after NextGen moved Mirth Connect 4.6 to a proprietary commercial license. It will feel familiar to anyone who already knows Mirth: channels, JavaScript transformations, connectors, queues and the usual Java-based operational model.

The project is moving. Version 4.6.0 was released in July 2026; it has a public governance model, and it is pursuing Eclipse Foundation stewardship. That makes it considerably more credible than a forgotten fork with one enthusiastic maintainer.

Its strength is control. It is open source, deploys wherever the JVM runs, and has a large amount of inherited Mirth knowledge around it. Its trade-off is also control: your team owns more of the patching, plugins, deployment engineering and support arrangement. “Free” interface engines have a habit of sending their invoices in hours rather than currency.

Option four: Rhapsody or Corepoint

Rhapsody and Corepoint remain the reassuring enterprise choices. They cover the healthcare standards people expect, provide on-premises, SaaS and managed deployment options, and can wrap the engine with 24x7 support, high availability and a substantial services organization.

If your procurement team wants a mature vendor, formal support commitments and an architecture that has already been used at very large scale, these belong on the shortlist.

The trade-offs are cost, training and weight. A large enterprise platform can solve problems you genuinely have, but it can also bring processes and complexity that a smaller integration team did not ask for. Get the full price: licenses, non-production environments, high availability, training, migration and ongoing support.

Option five: Qvera

Qvera is a credible healthcare-specific commercial engine with broad standards and protocol support. It can run on-premises, in cloud environments and in containers, and its visual approach may suit teams that want less code than Iguana normally involves. It also has an established support and services model.

I would assess it in the same way as any other commercial replacement: prove a difficult channel, confirm how source control and environment promotion work, test the operational dashboard, and obtain firm figures for licensing and migration. A long feature list is useful, but the difficult five percent of your interfaces normally makes the decision.

Option six: Integration Soup

This is the option I keep coming back to for my own work.

Integration Soup sits in a useful middle ground. It has the workflow designer, dashboard, queues, logging, alerts, scheduling, transformations and code extension points I expect from a proper interface engine. It works with HL7, FHIR, JSON, XML, CSV, databases, files, web services and DICOM, with AWS and Azure extensions where cloud services are part of the workflow.

At the same time, it is unusually easy to reason about. The current browser interface still feels like the full product, not a text editor wearing an interface-engine badge. Receivers, transformations, routing and destinations remain visible as one operational workflow. When code is the clearest answer, C# and the .NET ecosystem are there; when code would just be showing off, the visual activities do the job.

The honest caveat is that Integration Soup is a smaller vendor than the large enterprise incumbents. That should prompt proper questions about support cover, releases and continuity, just as it should for every vendor after the events at iNTERFACEWARE. The useful difference is that the team is offering a concrete Iguana migration service, price-matched licensing for approved migrations and hands-on conversion support rather than simply saying “our engine can do HL7 too”.

What I would put in the evaluation

I would give each shortlisted supplier the same representative channel. Not the easy ADT relay. Give them the one with shared Lua modules, a VMD, a database lookup, two destinations, a custom ACK rule and the failure case everyone is frightened to touch.

Then score the result against the things that matter after the demo:

• Can we deploy it where our organization permits?
• Can we export and version everything needed to rebuild it?
• Can support staff see why a message failed without becoming developers?
• Can developers use code cleanly when the mapping stops being simple?
• Are queues, retries, alerts, certificates and audit history part of the product?
• What does high availability actually include?
• Who answers a production support case, and when?
• Can the vendor prove the migrated output against the current Iguana behavior?

My direction

If I were advising a large hospital that valued enterprise scale above simplicity, I would evaluate Rhapsody or Corepoint. If retaining an open-source Mirth-style model was the main requirement, I would test Open Integration Engine. Qvera deserves a place in a commercial shortlist.

For teams that liked Iguana because it made powerful integration work approachable, I think Integration Soup is the most natural place to start. It covers the whole operational job without making every interface feel like a software-development project, but it does not trap you in a toy environment when proper code is needed.

The deciding factor, though, is not my preference. It is whether your own ugliest channel can be rebuilt, replayed, and shown to behave correctly. That is what the final post in this series will cover.

Business continuity concerns with iNTERFACEWARE Iguana

I have been watching the iNTERFACEWARE situation for the last few weeks, and it has reached the point where I wanted to comment publicly.

Iguana is not a little utility sitting on somebody's laptop. For many organizations, it is the thing moving admissions, orders, results, referrals, documents, and billing data while everyone else gets on with providing healthcare. When the vendor behind that engine suddenly changes direction, the practical question is not whether the story is entertaining. It is whether the interfaces will remain supportable.

What can actually be verified?

There are plenty of colorful claims circulating online. I am not going to repeat the ones I cannot verify, and I do not know the circumstances under which any individual employee left.

The public record is concerning enough on its own.

An archived copy of the iNTERFACEWARE company page from 8 June 2026 listed five people in its leadership team: a VP of Finance, a VP of Sales and Marketing, Eliot Muir as founder and CEO, a lead developer and an HR manager. The page celebrated the company's people and workplace culture.

The current company page is startlingly different. It says that the company is now “mostly Eliot”. Engineering, sales and customer support are all assigned to Eliot, while human resources is marked vacant. It also says directly that the employees are gone and describes the one-person organization as an experiment whose results are still coming in.

That is not a rumor about a restructuring. It is the vendor's own description of itself.

There has also been a significant licensing statement. Eliot Muir has said that the next Iguana 6 release will be free, but that its new terms will prohibit running it on AWS, Google Cloud, Microsoft Azure or Oracle Cloud. He also said users of that release would need to sign the new terms.

Separately, iNTERFACEWARE now describes an intention to make Iguana X free under the Mozilla Public License 2.0. That direction may become interesting, but the same page says that the queue needs rewriting, the existing licensing system is to be removed, external dependencies are to be reduced, and the security model needs to be rethought. Those are plans, not a production support guarantee.

Why this matters even if Iguana is still running perfectly

The awkward thing about interface engines is that a healthy dashboard can make everything feel safe.

Your ADT feed can process every message today while the organization is quietly accumulating a very different sort of risk. Who answers a difficult support case? Who reviews and ships a security fix? Who can explain the licensing position to your legal team? Who maintains the build and release infrastructure? What happens if the one available person is ill, overloaded, or simply working on something else?

This is the old “bus factor” discussion, except it is no longer theoretical.

Healthcare interfaces also have unusually long lives. A channel created for a pathology system can still be running years later, complete with one strange Z-segment, a certificate that expires on a Sunday and a receiver that only accepts its own creative interpretation of HL7. The engine vendor does not merely provide an executable. It provides continuity around all of that accumulated behavior.

The proposed cloud restriction is another concern. Whether or not you agree with the security argument behind it, deployment location is normally a decision made by the customer's security, infrastructure and governance teams. A licensing change that rules out the major cloud providers can collide with an organization's approved architecture overnight.

Do not panic, but do not sit still

I would not turn off a working Iguana instance because of a dramatic webpage. Rushed interface-engine migrations are a splendid way to replace one risk with six new ones.

I would, however, do the following now:

• Export every channel. Put the Git exports or project archives somewhere controlled by your organization, not only inside the running engine.
• Collect the dependencies. Include Lua modules, VMD files, shared libraries, environment settings, certificates, connection details and a diagram of linked channels.
• Preserve safe test evidence. Keep de-identified examples of successful messages, failures, ACKs and edge cases. A channel without representative test data is only half an export.
• Get the commercial position in writing. Confirm the version you may run, where you may host it, what support remains available, and what happens at renewal.
• Test a restore. A backup that has never been restored is a comforting theory.
• Assess alternatives before there is an incident. The right time to prove a migration is while the existing system is still processing normally.

The engine is still only half the decision

Iguana became popular for good reasons. Its code-led approach is flexible, its live annotations are genuinely useful, and many teams have years of knowledge invested in it. None of that vanished in June.

But product capability is only one half of a platform decision. The other half is stewardship: support capacity, predictable licensing, security maintenance, release discipline and a migration path that does not depend on wishful thinking.

My conclusion is not “everyone must leave Iguana tomorrow”. It is that every Iguana customer now needs a documented continuity plan. Staying may be one option in that plan, but doing nothing is not a plan.

In the next post, I will look at the realistic alternatives, including the unglamorous option of staying put for a while, the emerging open-source choices, the large enterprise engines, and the newer systems trying to make this work less painful.

HL7 Soup Online - HL7 Soup in a Browser

I have to admit I was a little suspicious the first time I saw HL7 Soup was producing a browser version.

Not because there is anything wrong with browsers. It is just that existing HL7 tools that run in a browser tend to be as user friendly as a cabbage. They exist, but they don't really do a lot. They tend to be little more than pipe counters.

HL7 Soup Online surprised me because it still feels like HL7 Soup.

The familiar parts are all there. You still get the plain-English story at the top, the raw editable HL7 message where I naturally spend most of my time, the list of messages underneath, and the structured field editor sitting on the right. It is not trying to hide the HL7 from you, which is a relief. It is just trying to keep the useful context close enough that you do not have to keep counting pipes like you are doing some sort of integration penance.

This is the thing I have always liked about HL7 Soup. It understands that an HL7 message is both text and structure at the same time. If you click a date in the raw message, the field editor knows what it is. If you click a value in the story, you are not taken away from the message, you are taken into it. That is a small distinction, but it is the difference between using a tool and wrestling with one.

The new trick is that I can do this from a browser.

That makes it useful in a slightly different way from the Windows application. If I am on a machine without HL7 Soup installed, or I am talking to someone on a call, or I just want to look at a message quickly, there is now a very low-friction option. Load the web page, use the sample messages, paste in a safe test message, and you are away.

There is an important caveat though, and it is worth saying plainly. The hosted browser version is the one I would use for samples, training, demos, vendor conversations, and quick non-sensitive investigations. It is running in the browser, so the practical limit is browser memory. That is the trade-off.

For real patient data, production logs, enormous message files, and anything that needs to stay inside your organization, the installed or self-hosted version is still the right place to work. That version can use local or server-side processing and is the serious option for large files. The public browser version is weaker in that sense, but it is also free and immediately available, which is a fairly compelling argument when all you need is to understand a message in front of you.

One of the first things I tried was anonymizing a message.

This is exactly the sort of feature I wish had always been sitting one click away. Every HL7 person has had the conversation where someone wants to send a sample to a vendor, but the sample has just enough real-looking patient data in it to make everyone nervous. In HL7 Soup Online the anonymizer keeps the shape of the message, but swaps out the sensitive-looking values. You still have the same segments, fields, and testing problem, just without casually throwing patient details around.

Even better, this is available in the free browser version. That makes it useful even if all you ever use the hosted site for is cleaning up samples before a support email.

Statistics are also built in.

This is one of those features that does not sound exciting until you need it. If you have a file full of messages and you want to know how often a field is populated, or what values are actually being sent, statistics save a ridiculous amount of manual checking. In the screenshot I selected MSH-7 and HL7 Soup showed the values across the loaded messages. That is the sort of thing that helps when a vendor says "we always send that field" and the messages are quietly saying something else.

The right-click menu is still where a lot of the useful bits live.

Right-click in the message editor and you will see the usual practical commands: copy, paste, anonymize, filter, validation, highlight, statistics, update, expand and collapse. The new one that caught my eye is "Copy message as link".

That means you can take the message you are looking at and turn it into a browser link. Instead of emailing a block of HL7 and hoping it survives the trip through Outlook, Teams, Slack, or whatever else is trying to be helpful that day, you can send a link that opens the message in HL7 Soup Online.

For example: Open this sample MDM^T01 message in HL7 Soup Online

That is a small feature, but I think it will be a big practical one. HL7 discussions often start with "look at this message", and now that can mean an actual shared view rather than a pasted wall of pipes.

The biggest surprise for me though is the interface designer.

This did not exist back when I first wrote about HL7 Soup. Back then I was mostly excited that the editor made HL7 readable. Now the web interface can take a representative message and start turning it into an interface definition.

That is a different level of usefulness. A sample message is where many interface conversations begin, but it is not where they should end. The important questions are things like: which fields are required, what values are expected, what tables are valid, what should be highlighted, and what should fail validation?

The interface designer gives those decisions somewhere to live. Instead of putting everything into a PDF specification that immediately begins drifting away from reality, you can define expectations against the same message structure people are actually testing. I only played with it briefly, but I can already see this becoming the part that deserves its own post.

So where does this leave us?

I think HL7 Soup Online is now my preferred HL7 Soup. I have installed it locally, so I have a secure browser based web app, that runs just as fast as the Windows application, and even has some new functionality. It was included with my existing Integration Soup license, so it didn't even cost me anything.

And most importantly, it still feels like HL7 Soup. It still has that pleasing habit of making HL7 feel less like a punishment and more like something you can reason about.

That is about the highest compliment I can give an HL7 tool.

Try it here: https://hl7soup.integrationsoup.com/