The Questions to Ask an EHR Vendor Before You Sign

Every demo looks good. The demo is built to look good. What you're watching is the handful of screens the vendor has spent two years polishing, driven by someone who has clicked that exact path several hundred times and knows where it breaks.

What you don't see in a demo is the export file, the support queue at 6am on a Sunday, the change request that sits untouched for a year, or the invoice line that shows up in month seven. Those are the things that decide whether this was a good purchase, and none of them are on screen.

So here's the list. Ask these before you sign. Get the answers in writing, and put the ones that matter into the contract itself. A vendor who's comfortable with that is telling you something. A vendor who isn't is also telling you something.

Who owns the data, and how do I actually get it out?

Every vendor says you own your data. Saying it costs them nothing. The real question is mechanical: in what format, how often, at what cost, and do I have to ask permission first?

Ask for a sample export before you sign. Not a description of one, an actual file. Then look at it. Does the note text come out as readable text, or as fragments with the labels stripped off? Are signatures, timestamps and the name of the person who signed still attached? Do scanned documents come with it, or only the database rows that point at them? Are audit logs included?

Also ask whether you can pull an export yourself, on demand, without opening a ticket. That's the difference between owning your data and being allowed to request it.

A bad answer sounds like: "You own all your data, and we can generate an export for you whenever you need one." Every word of that is technically true and it still means a professional services fee and a wait.

What happens the day the contract ends?

Nobody wants to talk about the breakup while signing the paperwork. Do it anyway, because the leverage is all on your side right now and none of it will be later.

Ask: how many days of read access do we keep after termination? How long before you delete our data, and can we ask you to delete it sooner? Who pays for the final export? What happens if we're in a billing dispute at the time - do we still get our records? If you're acquired or you shut down, what's the process?

Your records retention obligation outlives the contract. How long you have to keep what varies by state and by program type, and your licensing body is the authority on that, not the vendor. Their deletion schedule doesn't change your obligation, so make sure the two don't collide.

A bad answer sounds like: "That's never come up, none of our customers have left." Or "our team would work with you on that at the time."

Single tenant or multi tenant? Just say which.

Multi tenant means every customer's records live in one shared database, separated by software logic. Single tenant means you get your own instance. Multi tenant isn't automatically unsafe and it's common, but it changes how far a mistake travels and it changes what "restore from backup" means. If another customer's bad data import forces a restore, whose records move?

Ask where the deployment physically sits. Ask who at the vendor can see production data, and under what circumstances. Ask whether PHI access is logged at the record level with a name attached, so you can answer the question "who opened this chart" without calling anyone.

Kordera runs single tenant per agency with audit-logged PHI access, encryption in transit and at rest, and passkey login. The details are on the compliance page if you want to compare them line by line against what you're being offered elsewhere.

A bad answer sounds like: "bank-level encryption" and "enterprise-grade security" with no answer to the actual question. If the person selling to you can't say which architecture it is without checking, ask for someone who can.

Will you sign a BAA, and can I read it now?

Any vendor handling PHI has to sign one. Getting a yes is the floor, not the finish line. What's in it is the part that matters.

Ask for the BAA during evaluation, not at signing. Look at the breach notification window: a defined number of days is a commitment, "without unreasonable delay" is not. Ask for the list of subcontractors who will touch PHI, because there almost always are some - hosting, SMS, e-fax, analytics, email. Ask what happens to your data in their hands and whether they're bound by the same terms.

A bad answer sounds like: "Absolutely, legal will send that over with the signature packet." That's how you end up reading it at the moment you have the least leverage you will ever have.

Where does support sit, who answers, and what hours?

A residential program runs 24 hours. Software problems don't wait for business hours. If the med pass screen won't load at 6am on a Sunday, "we respond within one business day" means Monday.

Ask whether support is in-house or outsourced. Ask what time zone and what hours, in local time, written down. Ask what the after-hours path is for something that stops documentation or medication administration, and whether that path is a phone number or a form. Ask whether the person answering knows what a med pass, a witness signature or an elopement is, or whether they're reading from a script and will escalate to someone who does.

Then ask for the escalation path by role, and what happens if the first tier can't fix it.

A bad answer sounds like: "We offer 24/7 support." Make them define it. A monitored inbox, a pager that only fires for total outages, and a human being on the phone are three very different things sold with the same three characters. Also worth noticing: whether real support is a paid tier.

What does implementation actually involve, and who does the work?

The honest answer is that some of it is on you. Nobody outside your building knows what's on your med sheet, how your level system works, which units run which schedule, or what your incident categories are. A vendor can't invent that. The question is how much of the building they do and how much lands on your program director at 9pm.

Ask, specifically:

• Who enters historical data, and how far back does it go?
• Who builds the forms and assessments, you or us?
• How many hours a week of my staff's time does this take, and for how long?
• Who trains, in what format, and is training included or an add-on?
• What does "go live" mean here - one unit, or the whole facility on one day?
• What's the fallback if something isn't working on day one?

A bad answer sounds like: a speed claim with no task list behind it. Ask for a written implementation plan with a named owner next to every step. If they won't put owners next to steps, the owner is you.

Who configures it to the way your program actually runs?

The forms that ship in the box came out of somebody else's program. Your state's paperwork, your accreditor's documentation requirements, your incident categories and your behavior system are yours. Ask whether configuration is something you do yourself in the interface, something the vendor does for you as part of the price, or something that requires a developer and a quote.

Then ask the follow-up that gets skipped: when the state changes a form, who updates it, how fast, and does it cost anything? That happens on someone else's schedule, not yours.

While you're there, ask what the system was built for. A platform designed around 15-minute billable outpatient visits handles a 24-hour milieu badly, and the signs are easy to spot once you look: no shift structure, no bed board, no witness signature on a med pass, nowhere to log an elopement, incident reports handled as a generic note type. This is the whole reason software built for residential programs looks different from a repurposed clinic system, and it's why configuration to your program's forms and workflow is worth pinning down before you sign rather than after.

A bad answer sounds like: "It's fully customizable." Fully customizable by whom, on what timeline, at what price.

How do change requests work after go live?

You will find something in month three. Everyone does. What matters is what happens next.

Ask where a request goes, who decides, and whether you hear back either way. Ask whether there's a visible queue or you're shouting into a mailbox. Ask what the cost model is: included, hourly, or "roadmap". Ask how many of the last year's releases came from customer requests, and ask for a specific example of one.

Ask who you'd be talking to. In a small company that's often the person who wrote the code. In a large one it's a product manager weighing your 60-bed program against a thousand other accounts, which is a rational thing for them to do and a bad thing for you.

A bad answer sounds like: "We'll add it to the roadmap." That's a polite no with a calendar attached. The other bad answer is when every change, however small, requires a statement of work and a quote before anyone will even discuss whether it's a good idea.

Pricing: what's flat, and what moves?

Ask for the complete list of everything that can produce a charge. Not the monthly number, the list. It usually includes some of these:

• Per user, per bed, per resident, or per active chart
• Per claim, per clearinghouse transaction, or a percentage of collections
• Implementation and data migration
• Training, including retraining after turnover
• Support tiers
• Interfaces to labs, pharmacy, or state reporting
• Each custom form or report
• Document storage above some limit
• Annual increases, and whether there's a cap on them

Per-claim and percentage-of-collections pricing deserves its own question, because it means your software bill rises with your billing volume. You pay more in the months you're busiest, and you can't forecast it cleanly. Kordera uses one flat per-agency price with no per-claim fees, which is a deliberate choice for exactly that reason.

Two more pricing questions worth asking out loud: what does this cost in year three, and what happens to the bill if census drops?

A bad answer sounds like: one monthly figure followed by "plus the standard fees for the usual things."

Two questions that tell you more than the rest

First: who built this, and have they ever run a program? Not sold to one, run one. Someone who has stood in a med room at shift change makes different decisions about where the witness signature goes. Ask any vendor the same question and listen to how quickly they can answer it.

Second: can I talk to a customer who's been live for more than a year, without you on the call? The reference itself matters less than the reaction. Hesitation is information.

None of this makes a purchase safe. It just moves the unpleasant surprises from month seven to the week before signing, which is the only week you can still do anything about them.

Print the list. Ask every vendor the same questions in the same order, including us, and write down what they say. The differences will be obvious on paper in a way they never are in a demo. If you'd like to run this list against Kordera with someone who can answer all of it in one sitting, you can set up a walkthrough.