The Mirth Connect RFP: 47-Point Vendor Evaluation Checklist (With Free RFP Template)

You are about to spend somewhere between forty thousand and four hundred thousand dollars hiring a vendor to build, migrate, or operate your Mirth Connect integration engine. The wrong choice ships late, hemorrhages messages, and gets you a compliance finding. The right choice quietly runs ten thousand messages an hour for the next five years.

The difference is not luck. It is your evaluation process. Most healthcare RFPs treat integration vendors like commodity software resellers — they ask about company size and pricing, get back marketing PDFs, pick the lowest bid, and find out twelve months later that the vendor has never actually deployed a Mirth channel into production.

This guide gives you a 47-point evaluation framework, a 1-to-5 scoring rubric out of 235 total points, fifteen reference questions that actually surface signal, twelve red flags that should disqualify a vendor on sight, and a downloadable RFP template you can adapt in an afternoon. It is written for the procurement lead, integration architect, or CIO who has to sign the SOW and live with the consequences.

Why a Mirth-specific RFP exists at all

Generic "healthcare integration vendor" RFPs do not work for Mirth procurement. The product is too specific. The talent pool is too narrow. The licensing situation in 2026 is too unsettled. A vendor can be excellent at Rhapsody or Iguana and still be a bad fit for your Mirth project, because the channel architecture, deployment model, scripting language, and support expectations are different.

You are also not just buying a product. You are buying a five to ten year operating relationship. The vendor will hold the keys to message routing for your hospital, lab network, or payer connection. The cost of switching them out mid-stream is between three and nine months of parallel running and almost always blows past the original contract value. So the RFP needs to evaluate the things that actually matter at year three, not the things that look impressive on a slide deck.

The framework below is built around six categories that together cover the full lifecycle: who the vendor is, what they can technically do, how deeply they know Mirth specifically, how they run projects, how they price, and how they handle compliance. Each category has a fixed weight in points, so you cannot game the score by stuffing one section.

The 47-point evaluation framework

Forty-seven points spread across six categories, scored 1 to 5 each. Maximum possible score: 235. The point allocation is intentional — technical capability is the largest bucket because that is where most failures originate, and compliance is large because regulatory exposure is asymmetric. A weak vendor on compliance can sink the project even if everything else is perfect.

Category 1 — Company and Experience (8 points)

1. Years in business under current ownership. Five or more years preferred. New entities or recent acquisitions add transition risk.
2. Number of healthcare clients in production. Twenty or more in active production gives confidence in domain depth.
3. Verifiable client references. Three named, contactable references for the exact service you are buying — not generic case studies.
4. Financial stability. Audited financials, profitability statement, or D&B report. You do not want to be a vendor's largest customer the year they fold.
5. HITRUST certification. CSF r2 Implemented Level or higher, current and unexpired. Validated against the HITRUST registry, not a screenshot of an old badge.
6. SOC 2 Type II report. Type II (covering a 6-12 month observation period) — not just Type I. Reviewed within the last twelve months.
7. Cyber and professional liability insurance. Five million dollars or more in cyber liability, two million dollars or more in errors and omissions, with proof of current coverage.
8. Security incident history. Disclosed in writing — any breaches, ransomware, OCR investigations, or material security incidents in the last five years. Vendors who say "we have never had one" without context are usually hiding something.

Category 2 — Technical Capability (12 points)

9. HL7 v2.x depth. Can they speak fluently about ADT, ORU, ORM, SIU, MDM, and DFT message types and recover from real-world malformed messages?
10. HL7 v3 / CDA / CCDA experience. Demonstrated production deployments — most teams claim it but few have shipped it.
11. FHIR R4 implementation experience. Bulk Data, SMART on FHIR, subscriptions, US Core profiles, search parameter performance.
12. DICOM messaging and imaging interfaces. Modality worklists, ORU-to-PACS routing, basic compositing.
13. X12 EDI experience. Especially 837, 835, 270/271, 276/277 for payer-side workflows.
14. Custom protocol handling. TCP, MLLP, SFTP, REST, SOAP, JMS, Kafka, S3, and proprietary lab feeds.
15. Proven scalability. Documented references of a single Mirth deployment processing 10,000+ messages per hour sustained.
16. High availability and disaster recovery. Active/active or active/passive cluster design, documented RPO/RTO, real failover drills.
17. Monitoring and observability stack. What they install for metrics, log aggregation, alerting, channel-level dashboards.
18. Security engineering. mTLS, key rotation, secret management (Vault, AWS Secrets Manager), Log4j-level patch response time.
19. Cloud certifications. Named AWS, Azure, or GCP partner status if you run on cloud.
20. Multi-tenant or multi-facility experience. Demonstrated ability to isolate tenants without channel sprawl.

Category 3 — Mirth-Specific Expertise (8 points)

21. Years working specifically with Mirth Connect or Mirth Connect / NextGen Connect. Three or more years for senior engineers. Anything less and you are training them on your dollar.
22. Total Mirth channels deployed across all engagements. Five hundred or more channels in production is a credible threshold for a mid-size firm.
23. Performance tuning case studies. Documented before/after numbers — message-per-second improvements, memory leak fixes, queue throughput.
24. Plugin and extension development. Custom Mirth plugins, server extensions, deployed transformer libraries.
25. Mirth-to-Mirth or Mirth-to-other-engine migrations. Number of completed migrations in the last two years.
26. BridgeLink / OpenIntegrationEngine awareness. Position on the post-license-change open source forks, support stance.
27. Commercial license familiarity. Practical experience with the NextGen commercial Mirth Connect post 2025 license change, including pricing models and tier negotiation.
28. Mirth-certified or recognized contributors on staff. Named engineers, GitHub commit history, conference talks, blog posts that you can verify.

Category 4 — Project Management (6 points)

29. Delivery methodology. Agile, hybrid, or waterfall — what fits your governance model, and can they describe it in concrete sprint cadence rather than slogans.
30. Communication cadence. Daily standups, weekly status, monthly steering committee — written into the SOW, not assumed.
31. Status reporting format. Sample status report from a prior engagement, RAG indicators, burn-down, channel health view.
32. Change management process. How they handle scope creep, change orders, and out-of-scope requests without holding the project hostage.
33. Risk register and mitigation. Written risk register from a prior engagement, with how they actually retired risks.
34. Escalation path. Named individuals at three levels — project lead, account director, and an executive sponsor reachable for production outages.

Category 5 — Pricing and Commercial (6 points)

35. Pricing model clarity. Time and materials, fixed price, or managed service — clearly explained with worked examples for your scope.
36. SLA terms and credits. Uptime, response time, resolution time, financial credits when missed. Anything without a credit is marketing.
37. Payment terms. Net 30, net 45, milestone-based — and whether they require deposits.
38. Change order process and pricing. Pre-agreed rate card, approval workflow, turnaround time. Avoid vendors who say "we will negotiate when needed."
39. Intellectual property ownership. Who owns the channels, scripts, transformers, and documentation — you should, with the vendor retaining only their pre-existing IP libraries.
40. Termination and exit clauses. Termination for convenience, knowledge transfer obligations, source code and documentation handover, parallel run support.

Category 6 — Compliance (7 points)

41. HIPAA Security and Privacy Rule program. Named privacy officer, documented policies, last risk analysis date.
42. Business Associate Agreement. Vendor-ready BAA template that does not strip your indemnification or limit liability to fees paid.
43. Audit log strategy for Mirth channels. Who accessed what, when, with what message visibility — exportable for OCR investigations.
44. Data retention and minimum necessary policy. How long messages and traces are retained, and at what level of detail.
45. Breach notification SLA. Time to notify in writing — should be no longer than 24 hours from discovery.
46. Encryption in transit and at rest. TLS 1.3, AES-256, named key management approach.
47. Access control and least privilege. Role-based access to Mirth Administrator, named accounts (no shared admin), MFA, quarterly access reviews.

Scoring rubric: 1 to 5, total out of 235

Each of the 47 points is scored on a five-point scale. The wording for each level should be calibrated up front so two reviewers reach the same score on the same evidence. Below is the generic rubric — you adapt it per criterion in the template.

Two reviewers should independently score each vendor, then reconcile. A gap of 2 or more on any criterion triggers a follow-up question to the vendor before final scoring. Do not let the loudest reviewer pull the score — write down the evidence cell-by-cell so the reconciliation is about facts, not personality.

Weighting and pass/fail thresholds

The 235-point scale gives you natural decision bands. These thresholds are calibrated against twelve years of healthcare integration engagements — they are not arbitrary.

You should also set category minimums. Any vendor scoring below 18 on Technical Capability (out of 60) or below 18 on Compliance (out of 35) is disqualified regardless of total score — those two categories are where weak vendors hurt you most.

15 reference questions that actually surface signal

References are the single most valuable evaluation input — and the most commonly wasted. Vendors hand-pick happy clients. Generic questions like "are you satisfied?" produce generic answers. The fifteen below are designed to surface specifics that vendors cannot coach references on.

1. What was the actual message volume per day at steady state, and how did that compare to what the vendor estimated during the RFP?
2. What uptime did you achieve in production for the first twelve months, and what caused any outages over thirty minutes?
3. What was the average and the 95th percentile time-to-first-response on Sev 1 incidents?
4. What was the biggest surprise — positive or negative — in the first six months of the engagement?
5. If you were starting over, would you hire them again? Why or why not?
6. How did the onboarding go, specifically the first thirty days?
7. How did they handle the first scope change request, and what did the change order process feel like in practice?
8. Were the SLAs met, missed, or quietly renegotiated?
9. How well did they document the channels, transformers, and routing logic — could a new engineer pick it up six months later without their help?
10. What did post-go-live support actually look like, after the launch celebration?
11. Did they ever push back on a bad idea from your side, or did they just build whatever you asked for?
12. How was knowledge transfer at the end of the project — could your team operate the system without them?
13. How did the actual final cost compare to the original SOW, percentage-wise?
14. How did they handle the first production outage — root cause analysis quality, communication during the incident, prevention follow-through?
15. Would you recommend them specifically for HL7 / FHIR / X12 work, or only for the narrow scope they delivered for you?

Run the call yourself — do not delegate to procurement. Take notes verbatim. The signal is in the pauses, the qualifiers ("mostly", "eventually", "after some pushback"), and the questions the reference asks you back.

12 red flags that should disqualify on sight

Any one of these on its own is a yellow flag. Two or more in the same proposal is a disqualification, regardless of what the rest of the document says.

1. Vague or hourly-only pricing with no worked example for your scope. Translation: they have not actually sized the work.
2. No healthcare references provided — only adjacent industries like banking or retail. Healthcare integration is not transferable from other domains.
3. Generic case studies with no Mirth Connect specifics — they could be about any integration engine.
4. Cannot name specific Mirth channels they deployed when asked in a live conversation. Real practitioners can talk about ADT-to-EHR routing in their sleep.
5. Missing BAA template or BAA template that limits liability to fees paid. Both are deal-breakers under federal law and basic risk management.
6. SLA undefined or weasel-worded — "commercially reasonable", "best efforts", "as soon as practicable". An SLA without numbers and credits is a press release.
7. Hourly rate suspiciously low — under USD 35 per hour in 2026 is almost always offshore with no senior engineer on the account. You will pay the difference in rework.
8. Hourly rate suspiciously high — over USD 250 per hour with no Mirth-specific differentiation. You are paying for a brand, not the work.
9. No 24/7 support story for production. Healthcare integrations do not respect business hours.
10. Refuses reference calls or only offers references behind NDA with no questions allowed. Real references happen on Zoom with your questions.
11. No named HL7, FHIR, X12, or DICOM expert on the account team. A team of generalists will not survive a CDA implementation.
12. Will not sign IP assignment for channels and scripts written for you. They are planning to resell your code.

The 10-week RFP process timeline

The procurement cycle below is what actually works for a mid-size healthcare integration RFP. Compress it and you lose evaluation depth. Stretch it and vendors lose interest or staff up wrong.

Sample SOW structure

Once you have a winning vendor, the Statement of Work is where bad decisions get locked in or avoided. Use this skeleton — it covers the scope clauses that healthcare procurement teams routinely forget.

1. Background and objectives — one page, plain English, no jargon.
2. Scope of services — explicit list of in-scope channels, interfaces, source and destination systems, message types, volumes.
3. Out of scope — equally explicit. This section prevents 80% of change-order disputes.
4. Deliverables and acceptance criteria — what counts as "done" for each deliverable, with measurable criteria.
5. Timeline and milestones — with named deliverables tied to each.
6. Project team and roles — named individuals from both sides, with backups.
7. Pricing and payment schedule — tied to acceptance of deliverables, not calendar dates.
8. SLAs and service credits — uptime, incident response, resolution times, credit calculation.
9. Change order process — pre-agreed rate card, approval workflow, no-fault termination of small changes under a defined dollar threshold.
10. IP ownership — explicit assignment of all work product, with a carve-out for vendor's pre-existing libraries that are listed in an annex.
11. BAA and security addendum — incorporated by reference.
12. Termination and transition — termination for cause, for convenience, transition assistance period (minimum 90 days), source code and documentation handover.
13. Insurance and indemnification — minimum coverage levels, mutual indemnification.
14. Governance — steering committee cadence, escalation matrix, dispute resolution.

Side-by-side vendor comparison

Once you have completed the 47-point scoring for each finalist, lay them next to each other. The format below makes the trade-offs visible to a CIO or board member in under two minutes. Category subtotals matter as much as the headline total — a vendor who scores 195 with weak compliance is more dangerous than one who scores 185 with balance across all six categories.

Build this as a single sheet in Excel or Google Sheets. Color the category cells using a 0-100 percent scale (red below 60 percent, amber 60-80 percent, green above 80 percent). Add a final row called "Reviewer confidence" — a 1-to-5 gut check from each evaluator independent of the numeric score. When confidence diverges sharply from score, dig in before signing.

The downloadable RFP template

To save you the eight to twelve hours of rebuilding this from scratch, we have packaged the full 47-point framework, the scoring rubric, the reference question script, the red-flag checklist, and a sample SOW into a single editable Word document. It is the same template our integration practice uses with healthcare buyers across the US, Europe, and the Middle East.

The template is gated — drop your work email and we will send the file plus a 30-minute optional review call with our integration architecture team to walk through it in your context. The call is genuinely free; we use it to learn what healthcare procurement teams are wrestling with this year, and you get a second opinion on your scoring before you sign.

Where most teams cut the wrong corner

The two most common shortcuts that end badly: skipping the reference calls because "we have already heard great things", and treating the demo as a sales pitch instead of a scripted scenario. Both feel like they save a week. Both routinely cost six months.

Reference calls work when you do them yourself, with the fifteen questions above, and you write down the answers verbatim. They do not work when procurement runs them as a checkbox exercise. Demos work when you give the vendor a real malformed HL7 message file ahead of the session and ask them to build a channel live that ingests it, transforms it, and routes it correctly. They do not work when the vendor controls the screen and walks through their pre-built showcase.

If you are unsure where to push hardest in your specific situation — single-EHR hospital, multi-site lab network, payer-side X12 platform, or specialty clinic group — that is exactly the conversation the optional review call is built for.

Need expert help running a Mirth Connect procurement or building the integration after award? Explore our Healthcare Interoperability Solutions to see how we engineer integration engines for production scale. We also offer specialized Healthcare Software Product Development for teams building on top of Mirth. Talk to our team to request the full RFP template and book a 30-minute review call.

Further reading

• Mirth Connect commercial transition — migration strategies for open-source users
• Mirth Connect alternatives in 2026 after the licensing change
• Mirth Connect vs Rhapsody vs Iguana — 2026 comparison
• Top 10 Mirth Connect integration failures and how vendors should prevent them
• How to set up Mirth Connect for high availability
• Mirth Connect performance tuning — 10,000 messages per hour