What Should You Ask Before Hiring a Custom EHR Development Partner?

A Series B CTO came to us after burning $400K with a development shop that didn’t understand FHIR. They’d hired a team with a strong portfolio in fintech and e-commerce. The team was technically capable. But they’d never built on a FHIR data model, didn’t know what a SMART on FHIR scope was, and treated HIPAA as “we’ll add encryption at the end.”

The result: 8 months of development, a system that couldn’t exchange data with any other clinical system, and a compliance audit that flagged 23 issues. They started over with us. The $400K was gone.

That conversation happens more often than it should. This piece exists, so it happens less.

I. Why Does the Right Partner Matter More Than the Right Platform?

There’s a pattern in how CTOs evaluate custom EHR builds. They spend weeks comparing platforms – Medplum vs Healthie vs Canvas vs Oystehr. They build comparison matrices. They run proof-of-concept projects.

Then they spend 3 days evaluating development partners.

The platform is ~30% of your build. It provides the FHIR data store, auth, audit logging, and compliance infrastructure. The other 70% is what your development team builds on top: specialty-specific workflows, custom UI, integrations, clinical logic, AI features, and the user experience that makes your platform worth using.

Three things a platform can’t give you:

• Healthcare domain expertise. A developer who’s never built clinical software will treat an Encounter resource like a database row. A healthcare developer knows that an Encounter has clinical context, billing implications, and compliance requirements that change the architecture.
• Compliance as architecture. HIPAA isn’t a checkbox. It’s a set of architectural decisions about encryption, access control, audit logging, and BAA chains that need to be made at the foundation level. Security architecture that’s bolted on after development costs 3-5x more than security designed in from the start.
• The ability to say “don’t build that.” A good partner tells you when a feature isn’t worth building, when a platform choice is wrong for your use case, and when your timeline is unrealistic. A vendor who says yes to everything is either lying or doesn’t understand the problem well enough to push back.

II. What Are the 10 Questions to Ask Every EHR Vendor?

Ask all 10. The answers tell you more than any pitch deck.

A. Question 1: Have you built a custom EHR before?

Why it matters: Generic software development experience doesn’t transfer. Healthcare has unique data models (FHIR), unique compliance (HIPAA, ONC), and unique workflow patterns (clinical events, provider-patient relationships, order-result cycles).

Good answer: “Yes. Here are 3 projects with anonymized metrics: a clinical platform that reduced documentation time by 70%, a cloud migration of 30TB across 180 databases, a specialty module that improved clinical outcomes by 15%.”

Bad answer: “We’ve built health-adjacent apps.” Or: “We have 100+ projects across industries.” Generic portfolio with no healthcare-specific proof = red flag.

B. Question 2: Do you have experience with our target platform?

Why it matters: Building on Medplum requires TypeScript + FHIR + Bot framework expertise. Canvas requires Python + plugin architecture. Oystehr requires serverless + Zambda patterns. Platform-specific experience reduces ramp-up time by months.

Good answer: “Yes, we’ve shipped production on Medplum/Canvas/Oystehr. Here’s a case study.”

Bad answer: “We can learn any platform.” True, but you’re paying for the learning curve. That’s 2-3 months of billable hours that experienced teams don’t need.

C. Question 3: What’s your HIPAA compliance posture?

Why it matters: Every vendor handling PHI needs a signed BAA, documented security practices, and ideally SOC 2 Type II or progress toward it.

Good answer: “We provide a BAA. We have SOC 2 readiness [or certification]. Our security architecture follows the 6-layer model: data encryption, access control, authentication, audit logging, network security, application security.”

Bad answer: “We’re HIPAA compliant.” Without specifics, this means nothing. Ask for the BAA. Ask for the security architecture document. If they can’t produce either, walk away.

D. Question 4: Can you show me a real cost breakdown from a similar project?

Why it matters: “It depends” is the worst answer to a cost question. A good partner should be able to show you a breakdown from a comparable project with percentages by phase. See our full EHR cost guide for reference ranges.

Good answer: “Here’s an anonymized breakdown: 15-20% discovery, 40-50% development, 15-25% integrations, 10-15% testing, 5-10% deployment. For a project similar to yours, we’d estimate $X-$Y with these assumptions.”

Bad answer: “$200K-$2M depending on requirements.” A range that wide means they haven’t scoped enough projects to give you a useful estimate.

E. Question 5: What’s your team structure?

Why it matters: The team model directly impacts cost and quality. You need to know: who architects, who builds, who reviews, who manages.

Good answer: “US-based architect and project manager. Offshore engineering team with healthcare domain training. Code reviews by senior engineers. Dedicated QA. Blended rate: $75-$150/hour.”

Bad answer: “We’ll assign a team based on availability.” This means you get whoever isn’t on another project. No dedicated healthcare expertise.

F. Question 6: How do you handle ONC certification?

Why it matters: If your provider customers need certified EHR technology, your platform needs ONC certification. The partner should know the two paths: self-certify (expensive, 12-18 months) or build on a certified platform (faster, cheaper).

Good answer: “We typically build on ONC-certified platforms like Medplum (CHPL #11745) so the platform carries the certification. If you need self-certification, we can guide you through the ONC-ATL/ACB process, but it adds $200K+ and 12-18 months.”

Bad answer: “What’s ONC?” Immediately disqualifying.

G. Question 7: What happens after launch?

Why it matters: Custom EHR isn’t a project. It’s a product. It needs maintenance, security patches, compliance updates, feature iterations, and support.

Good answer: “We offer ongoing support with defined SLAs. Maintenance typically runs 15-25% of build cost annually. We handle security patching, compliance updates (USCDI version changes, HIPAA rule updates), and feature development. Here’s our support tier structure.”

Bad answer: “We hand off the code and you maintain it.” Unless you have an internal team ready to take over, this is a ticking time bomb.

H. Question 8: Can you integrate with our existing systems?

Why it matters: Your custom EHR will need to exchange data with labs, pharmacies, billing systems, and possibly Epic/Cerner/athena.

Good answer: “We have experience with HL7 v2 message processing, FHIR R4 APIs, SMART on FHIR for EHR-embedded apps, e-prescribing via Surescripts, and lab integrations. Here’s a technical mapping guide we published.”

Bad answer: “We can build any integration.” Ask for specifics. Which protocols? Which EHR systems? Which lab vendors?

I. Question 9: What’s your testing and compliance validation process?

Why it matters: Clinical software has higher testing requirements than standard applications. You need: unit testing, integration testing, clinical workflow testing with real users, HIPAA security testing, and penetration testing.

Good answer: “Dedicated QA team separate from development. Clinical workflow testing with real clinician users before go-live. Annual penetration testing by a third-party firm. Automated dependency scanning for vulnerabilities. We follow the 15-day critical CVE remediation standard.”

Bad answer: “Our developers test their own code.” No independent QA = no safety net.

J. Question 10: Do you have accelerators or pre-built components?

Why it matters: Pre-built components reduce build time and cost. A healthcare-focused partner should have reusable frameworks for common patterns.

Good answer: “Yes. Our accelerators cover approximately 30-40% of standard engineering: HIPAA-compliant data handling (PHISecure), FHIR client with EHR adapters (HealthConnect CoPilot), healthcare MVP framework (Launchpad), and AI clinical documentation (AI Medical Summary). This reduces a typical 6-month build to 3-4 months.”

Bad answer: “We build everything from scratch for maximum customization.” Building from scratch when reusable components exist means you’re paying for solved problems.

Evaluating partners right now? Schedule an architecture review – we’ll answer all 10 questions with specifics for your use case.

III. What Are the Red Flags in Custom EHR Proposals?

Five red flags that should end the conversation – or at minimum trigger deeper due diligence.

A. No named case studies

“100+ healthcare projects” with zero specifics. If they can’t show you anonymized metrics from a real build (documentation time reduced by X%, migration of Y databases, Z% clinical outcome improvement), they either haven’t done it or the results weren’t worth sharing. Every credible healthcare partner has at least 2-3 projects they can discuss in detail.

B. No HIPAA BAA offered

If the vendor handles PHI during development (and they will – test data, staging environments, integration testing), a BAA is legally required. A vendor who doesn’t proactively offer a BAA either doesn’t understand HIPAA or is avoiding the liability. Both are disqualifying.

C. Fixed price without a discovery phase

A fixed-price proposal for a custom EHR before a discovery phase means the vendor is either padding the price (to absorb unknowns) or underestimating (and will hit you with change orders later). The honest approach: paid discovery ($15K-$50K, 2-4 weeks) that produces a detailed scope, architecture document, and realistic estimate. Then fixed or T&M for the build.

The pattern we see: A vendor quotes $150K fixed. Three months in, they’ve burned the budget on 60% of features. Change orders add $100K. Final cost: $250K. A discovery-first approach would have scoped it at $200K-$230K from the start with no surprises.

D. No healthcare domain experts on the team

Ask: “Who on your team has healthcare-specific experience? What certifications or domain training do they have?” If the answer is “our developers are quick learners,” you’re funding their healthcare education on your budget. Look for: FHIR SMEs, HL7 specialists, clinical workflow analysts, HIPAA compliance leads.

E. No mention of FHIR or interoperability standards.

In 2026, any custom EHR development partner who doesn’t lead with FHIR R4, USCDI v3, and interoperability standards is building a silo. Your clinical platform will need to exchange data with other systems from day one. If FHIR isn’t in the proposal, the vendor isn’t building for healthcare in 2026.

IV. What Does a Good Evaluation Look Like?

Here’s what we’d show you if you asked us the 10 questions above. Not as a sales pitch – as a reference for what “good” looks like so you can compare other vendors.

A. Proof (anonymized, real projects)

• Country-scale national health records system: $131K, FHIR-native, ONC-aligned data models
• Healthcare platform cloud migration: 30TB, 180 databases, 30-40% cost reduction, zero downtime
• Custom clinical module inside major EHR: 15% outcome improvement, 76% fewer coding denials
• Functional medicine platform: 70% documentation time reduction, 90-day deployment
• Pediatric care platform: 45% scheduling friction reduction, 70%+ family mobile adoption

B. Platform expertise

• Medplum: FHIR-native builds, Bot framework, subscriptions
• Oystehr: FHIR R5, usage-based, serverless
• Canvas: Python SDK, plugin architecture
• Epic SMART on FHIR: custom modules inside existing EHR
• Healthie: wellness and telehealth platforms

C. Custom Workflows (30-40% engineering coverage)

• PHISecure: HIPAA-compliant data handling
• HealthConnect CoPilot: FHIR client + EHR adapters
• AI Medical Summary: clinical documentation AI
• Launchpad: healthcare MVP framework

D. Team structure

• US-based architecture + project management
• Offshore engineering with healthcare domain training
• Dedicated QA separate from development
• FHIR SMEs, HL7 specialists, clinical workflow analysts

E. When We’re NOT the Right Fit

Honest answer – we tell buyers this proactively:

• If you need a 40-hospital Epic implementation, that’s an Epic consulting engagement, not a custom build. We build specialty modules inside Epic, not enterprise Epic rollouts.
• If your budget is under $30K, we can’t build a quality clinical platform for that. We’d recommend starting with Medplum’s open-source tools and building in-house, then coming to us when you need to scale.
• If you need a non-healthcare application, our workflows, compliance expertise, and domain knowledge are healthcare-specific. A fintech or e-commerce app isn’t our strength.
• If you want a body shop, we sell outcomes, not hours. If you need 10 developers at $40/hour with no architecture guidance, there are cheaper options.

The best partner tells you when they’re not the right fit. That saves you time, money, and the kind of $400K mistake that brought the Series B CTO to us in the first place.