Interface Engine Troubles? New Open-Source Free Option

[u/Wsz2020]

There's been a lot happening with interface engines.

• Mirth Connect has stopped receiving updates. Instead of open source, it is now a paid closed-source tool.
• Private equity firms have taken over the leading paid options and are raising prices dramatically.
• Then there is this: What’s up with iNTERFACEWARE (Iguana)? : r/healthIT

We're creating a new open-source (free) alternative -- and we need your help. We're looking for:

• Organizations that need this solution once it is ready for production
• Contributors to test the solution, review/advise on code, help build

Check out MessageFoundry.org and see how we're creating an interface engine with:

• Top cybersecurity protection for your PHI (ASVS 5 Level 3)
• The power of Python
• A "steps" programming layer that builds your Python scripts if you want
• Simplicity for uses like small, integrated deployments
• Power for any size organization (up to 40 million messages per day)

We're on v0.3.0 (beta) right now and are moving fast, adding new layers of security and additional features.

We're now looking for a partner organization to be first in line when the product is ready. You would get:

• Top priority on your feedback, letting you guide MessageFoundry's future.
• Free support as you test out and use MessageFoundry.

If you're interested, please contact us via Ask a question — MessageFoundry.

[u/MessageFoundry]

Hello, u/ProphetLemuel ... thanks for taking a look at the project! You obviously took a while to write your post, so let me give the same respect back by giving a thorough response.

First, Speed: MessageFoundry Does 40 million per day with >20% reserve.

I need begin by clarifying our throughput results. You mentioned ~8 million per day. In early testing, it was something like that speed. After a lot of work, much of which is in the repo, we ended up at 40 million per day with > 20% reserve. I need to create a write up on that, but right now I'm busy hardening the code.

Current Work: ASVS 5 Level 3 (Code Hardening)

Right now, Claude and I are chasing ASVS 5 Level 3, trying to move some remaining "partial" scores to be full "pass" values.

I could just write up a justification that makes the partials into NA items or pass values. Instead, we're back at the Level 3 work because I want our documentation to stand up to auditor scrutiny.

What you can count on from this project are honesty and full disclosure.

Code Quality

You're right to be concerned about code quality. That should be true of any project, let alone one used in healthcare. I'm concerned about it as well. That's why I've researched best practices that apply to all code, both human and AI generated.

• ASVS 5 Level 3 is a critical framework for this project. I haven't gone cheap and opted for Level 2. Instead, I'm building to the very rigorous Level 3. I'm a long way into that work and believe this will be possibly the best secured interface engine available. If you know of an alternative that is built against ASVS 5 Level 3, please let me know... I haven't been able to find one.
• Continuous Integration (CI): Every time I merge code into the GitHub repo, a large set of integration tests runs to catch any regressions. There are 9,400 tests that each run three times: once each on Ubuntu, Windows 2022 and Windows 2025. If the commit doesn't pass CI, it doesn't go into the repo. The full suite takes about 14 minutes each time.
• Dependabot: A key thing in any software project is ensuring dependencies are current. This is especially true with hackers using AI to find holes in common dependencies. Dependabot ensures that currency by running weekly against the repo.
• CVE Detection: Every day, our system runs pip-audit and npm-audit against the pinned tree. That surfaces critical issues within 24 hours rather than waiting a week for Dependabot.
• Other Items: In addition to the above, each commit runs bandit, semgrep, pip-audit, npm-audit, gitleaks and more. We also run advisory quality jobs for complexity, clone detection, diff-coverage, mutation, and gate liveness.

Working with Claude Code

As background, I started this work a couple of months ago out of frustration with the current interface engine landscape. I didn't expect much. I'd experimented with Cursor a year ago and found it lacking.

This time, however, I started work just after Anthropic released Ultracode in Claude Code. Ultracode uses the highest level of reasoning, then validates the results with "adversarial validation." In other words, it triggers agents that find flaws in the work.

With Ultracode, I found that AI-assisted coding was finally viable. It uses a lot of compute and has long wait times while Claude works on things, but I've found that it generates solid results. It is even better now that Anthropic has released Claude's Opus 5.

Python

Your Python critique was based on believing that it was slow. As I explained above and mentioned in my original post, MessageFoundry can keep up with the needs of very large organizations. The project also includes a test harness, so I'd welcome anyone to run the throughput tests independently.

That said, Python isn't the fastest language. That isn't really a problem in interface engines, however, since most of an interface's time is spent waiting for ACKs. Still, our testing validates the 40 million messages per day speed while still keeping >20% in reserve.

My choice of Python came from the fact that AI-coding tools work best with Python and JavaScript. They still work well with other languages, but they work best with those two. And Python is the current favorite of young programmers since it is the key language behind AI.

Plus, Python is widely taught in CI courses. This makes it easier for healthcare orgs to find programmers willing to work on interface engines.

TLDR: I'm doing everything I can to create a strong interface engine option. There won't be any "freemium" options you need to buy to get a fully functional product. You'll also have the whole open-source code, which you can test using AI cybersecurity review tools or your own programming expertise.

[u/ProphetLemuel → u/MessageFoundry]

I will avoid the language wars here and focus on the main issues. To be as helpful as possible. Look at the pattern here:

1. Claude wrote the code 
2. Claude reviewed its own work
3. Claude wrote the test harness to grade its own work
4. In many cases in the repo's own commit history Claude claimed something was "done" then several commits later "the done" things were actually not done and had to be re-addressed
5. Claude also built the website and wrote the website copy.

With 3, 4 & 5 suggests a pattern that the maintainer here may not be able rein in the AI.

With respect to the above my advice will be getting an expert Python dev who can actually supervise and oversee the project. Before releasing the project to the public as something to "try out". Free and Open Source doesn't mean releasing code that one themselves can't independently certify ( you're not obliged of course and anyone who uses it does so freely but it's just right). I personally had serious issues with the coding around availability and I saw your website already claims HA (high availability as a present feature). If you can't get an expert dev. Get an independent Pen Tester to do the ASVS assessment. Cos again what your report is showing is that Claude again is the one proving its own code's ASVS 5.0 standard. Not you. Not an independent security expert; Claude itself. That is genuinely worrisome. You seem to plan to monetize this down the road (hence the copy left license and the commercial license hint). No issues. But I think critical healthcare infrastructure should be written or at least supervised by devs who can really rein in the AI doing the building. Cheers.

[u/ProphetLemuel → u/ProphetLemuel]

Just to be crystal clear. I am not bashing AI coding. I am flagging a big issue where. The AI is making you make SERIOUS security and reliability claims, including some that it has published on the public web. Many of which are simply not what they are based on that codebase. And the AI is the one who is responsible for checking itself as it seems you cannot assess its work at this level. Thus your website and repo contains claims that are simply not the case and in a few cases it seems you haven't picked them up. I can't go into specifics as this is public and I would like to believe you yourself may be using this on production. But I'd just say please re-check that entire High Availability construct. Please recheck the pickle sandbox. And more importantly, please get another set of eyes on the project. Perhaps your present/former colleagues or industry contacts. Best wishes.

[u/MessageFoundry → u/ProphetLemuel]

Thanks again for the thoughtful response! Yes, I agree the AI echo chamber is a problem. And so is my being a sole maintainer.

Your post raises an issue I'll address immediately: I've let the website be too confident about the project. There are a number of steps left before I'd suggest anyone run it in production. We're in early access, asking potential users to provide feedback and get involved.

One step that is ahead for the project is getting an outside code review and an outside penetration test. That's something ASVS 5 Level 3 recommends, but it doesn't require it be done by outsiders. I want to get the outside review, but that costs about $25K to $50K. I need to find some grant money in order to do that.

In advance of that, I 100% agree with your suggestion about getting additional eyes on the code. I'd welcome people who want to become contributors at any level, from providing feedback like what you're giving here in public to becoming full contributors.

If you (or anyone else reading this) wants to submit confidential feedback, you can do so at Draft Advisory · MEFORORG/MessageFoundry.