Questions to Ask Health IT Vendors
For whoever has to choose an electronic health record or another clinical system, or decide whether to renew one: a practice manager, a physician owner, a hospital IT lead. The questions follow the order the decision usually takes: whether the product fits your work, what is on the vendor's roadmap and how much of it is committed, compliance and data exchange, then go-live, support, cost and getting your records out again. Certification, privacy and prescribing rules differ by country and often by state, so on those points check the vendor's answer against what your own regulator or lawyer says applies to you.
The questions
Each question, and why to ask it
Fit
Which organizations of our size and specialty run this system today, and can we call two of them?
Why ask it
A system built for a 300-bed hospital behaves differently in a four-provider clinic, and the other way round. Take references who went live in the last two years, and put two things to them: what still needs a workaround, and what they would do differently.
Can you run the demo on our most common visit, from check-in through to a paid claim?
Why ask it
A scripted demo shows the screens that look best. Hand the vendor a real scenario a week ahead, such as a follow-up visit with a lab order, a refill and a copay, and watch where the presenter has to leave the product or skip a step.
Is everything you just showed us in use at a customer today, or is some of it still on the roadmap?
Why ask it
Demo environments often run a newer build than customers have, with features that are finished on screen and unreleased in practice. For anything you liked, get the version it ships in and the name of a site using it with real patients. Whatever cannot pass that test is a roadmap item, and should be scored as one.
Which parts of what you showed are in the base product, and which are add-on modules or another company's software?
Why ask it
Patient portals, telehealth, billing and analytics are often separate line items, or partner products with their own contract and login. Go back through the demo screen by screen and mark each one as included, extra or third party before you compare quotes.
How many screens and clicks does it take to document a routine visit and sign the note?
Why ask it
Have one of your clinicians do it, not the salesperson, with a timer running. A minute or two added to each visit is multiplied by every provider and every working day, and charting speed is one of the first things your clinicians will judge the system on.
Which templates, order sets and forms for our specialty come built, and who keeps them current?
Why ask it
'We support your specialty' can mean a finished library or an empty template builder. Open the actual content for three conditions you treat every week, and find out whether updating it later is your work, theirs or a paid service.
Is the system hosted by you or installed on our own servers, and what hardware and internet connection does it need?
Why ask it
With a hosted product the vendor looks after servers, backups and upgrades, and your clinic depends on its internet line. With an installed one, those jobs and their costs are yours. Either way, get the supported browsers, devices, printers, scanners and card readers in writing, and check the list against what is already on your desks.
What do patients see when they book, message us, read a result, fill in a form or pay a bill?
Why ask it
Log in as a test patient on a phone during the demo. If booking a visit or opening a result is awkward there, your front desk will keep taking the calls the portal was supposed to remove.
What reports can our own staff build without paying you for each one?
Why ask it
Quality measures, payer reports and a plain list of patients overdue for a visit all depend on getting data back out. Have someone on your team build one report in the demo environment. If it needs the vendor's analysts, add that to the price.
What kind of practice or hospital is this product a poor fit for?
Why ask it
A vendor that knows its product can name where it struggles, for example a specialty it has little content for or a size it was never designed around. If the reply is that it suits everyone, lean harder on your reference calls.
Roadmap
What is on your product roadmap for the next two years, and can we have it in writing?
Why ask it
A roadmap shown on a slide and not left behind is hard to hold anyone to. Offer to sign a confidentiality agreement for the document, and note how much of it is new capability and how much is catching up on things you assumed were already there.
Which roadmap items are committed with a release date, and which are only planned?
Why ask it
Listen for the vendor's own vocabulary: funded, in development, scheduled, exploring. Anything you need in order to go live belongs in the first group with a quarter attached, and anything in the last group should count for nothing when you score the product.
If a feature we are buying on the strength of the roadmap is late, what do we get?
Why ask it
The possible answers are a fee credit, a right to end the contract or nothing at all. Whatever is said in the room, only what is written into the agreement outlasts a change of account manager, so have the feature and its date named there.
How did last year's roadmap turn out: what shipped on time, what slipped and what was dropped?
Why ask it
Past delivery is the best check you have on a future promise. Compare the reply with the published release notes, and find out from a reference customer whether the features promised to them at signing ever arrived.
Who decides what goes on the roadmap, and how do customers get a say?
Why ask it
Some vendors run a user group or a voting board for requests, and some build mainly for their largest accounts. Have them name the last released feature that began as a customer request, and how long it took to arrive. A small practice should also find out how much a small practice's vote weighs.
How do you keep the product current with regulatory and payer changes, and is that work inside our fee?
Why ask it
Reporting rules, code sets and certification requirements keep changing, and the vendor has to ship each update before its deadline. Find out how close to the deadline the last required update reached customers, and whether a mandated change has ever been billed as an upgrade.
How often do you release upgrades, and can we test one before it reaches our clinicians?
Why ask it
Find out whether updates go to every customer at once or on a schedule you agree, and whether you get a test environment that mirrors your own configuration. A medication screen that changes unannounced on a Monday morning is a risk to patients, not only an irritation.
Is this the platform you are investing in for the long term, or is a successor product coming?
Why ask it
Vendors that have bought several products often steer development money to one and leave the others on maintenance. If a migration is coming, the three things to pin down are when, whether it is inside your price, and whether your data and custom content move with you.
What AI features are live or planned, and how can a clinician check what they produce?
Why ask it
For drafted notes, suggested codes or message replies, the points to cover are what the tool was tested on, whether a person must review the output before it enters the record, and whether patient data leaves the vendor's environment to make it work. Who answers for output that is signed unchanged is a question for your malpractice insurer and compliance lead, not for the vendor.
Compliance
Which certifications does the exact version we would run hold, and where can we check the listing ourselves?
Why ask it
Certification attaches to a product version and a set of criteria, so an older or differently packaged edition may not carry it. In the United States the federal health IT office, ONC, keeps a public, searchable list of certified products, and other countries have their own schemes, so look the product up yourself. If a program you report to requires certified technology, ask that program which criteria count.
Will you sign a HIPAA business associate agreement, and can we read your standard one before the contract?
Why ask it
In the United States this is the agreement that sets out how a vendor handling patient information must protect it. Elsewhere, the equivalent is the data processing agreement that privacy law calls for where you practice. Have your own lawyer or compliance lead read it, with an eye on breach notice, subcontractors and what happens to the data at the end.
Where is our patient data stored, and does any of it leave the country?
Why ask it
Get the hosting provider, the region, where the backups sit and where the support staff who can reach the data are based. Some funders, insurers and privacy laws restrict where health records may be held, so check what binds you before you hear the answer, not after.
Who at your company can open patient records, and how is each access recorded?
Why ask it
Support and engineering staff sometimes need to see a live chart to fix a fault. A careful vendor grants that access per ticket, for a limited time, and can hand you the log. 'Our team is trained' is a different and weaker answer.
How are sign-in, user roles and emergency access to a restricted chart set up?
Why ask it
Look for two-factor sign-in, roles you can tailor so a biller does not see clinical notes, and an emergency override that records who used it and why. The screen where an administrator edits a role is the one to watch, because that is where you learn how fine the controls really are.
What audit trail shows who viewed or changed a chart, and can we run it ourselves?
Why ask it
Sooner or later a patient or a manager asks who looked at a record. Check that the log covers viewing as well as editing, how far back it goes, and whether pulling it is a button for your privacy officer or a support ticket with a wait.
When did an outside firm last assess your security, and can we read the summary?
Why ask it
Ask for the document itself, such as a SOC 2 report, a HITRUST letter or a penetration test summary, and note its date and scope. A report that covers the corporate office but not the hosted product you are buying tells you little.
If a breach touched our patients' records, how quickly would you tell us and what would you do?
Why ask it
The duty to tell patients and regulators usually sits with the provider, and the deadlines differ by place, so the vendor's notice period has to fit inside yours. Find out whether they have had an incident and how customers heard about it, then get the notice period written into the agreement.
How do you use our patients' data for your own purposes, including de-identified data and training AI models?
Why ask it
Some vendors license de-identified data to others or use customer records to build their own products. Find the clause that allows it, ask whether you can opt out, and decide whether you could explain the arrangement to a patient who asked.
Data exchange
Which of our lab, imaging, pharmacy, billing and clearinghouse systems do you already have live interfaces with?
Why ask it
Name each system and version you run and get a yes, a no or a 'we could build it' for every one. An interface already running at another customer may take weeks. A new one can take months and arrive with its own invoice.
What does each interface cost to build, and what does it cost every year after that?
Why ask it
Interface fees are a common reason a quote grows after signing. Get a setup price and an annual maintenance price per connection, and check whether the lab or the other vendor will charge on their side as well.
Which standards does the product support, and which FHIR resources can customers read and write today?
Why ask it
Most vendors will say HL7 version 2, C-CDA and FHIR. The useful detail is which data types are exposed, whether writing back is allowed or only reading, and whether the documentation is public. Get the link and pass it to whoever does your integrations.
Do you charge us or outside developers for access to the API?
Why ask it
A product can have a modern API and still price it so that nobody connects. Per-call fees, app review charges and revenue-share terms all count, because the scheduling or reminder tool you want to plug in next year will meet them.
How would we exchange records with the hospitals and practices around us?
Why ask it
Find out which regional exchanges and national networks the vendor is connected to, then check whether your main referral partners are on the same ones. During the demo, watch an outside record arrive in a chart, since a document clinicians have to hunt for is rarely read.
How can patients get their records electronically, including through an app they choose?
Why ask it
Rules on patient access, and on blocking the flow of health information, vary by country and carry penalties in some, so ask your compliance lead what you owe patients where you practice. Then have the vendor show the whole path: the request, the release and what your staff do in between.
How does electronic prescribing work, including controlled substances and the prescription monitoring check?
Why ask it
Whether controlled drugs can or must be prescribed electronically, and whether a monitoring database has to be checked first, depends on where you practice. Check that both are built into the prescribing screen, what identity proofing each prescriber goes through, and whether either is charged per provider.
Which public health registries and reporting programs can the system send to from our location?
Why ask it
Immunization registries, lab reporting and quality programs are run locally, so a connection that works in one state or region may not exist in yours. The proof is a customer near you who is submitting today, so get a name and call.
When outside data arrives, how does the system match it to the right patient and handle duplicates?
Why ask it
A result filed to the wrong chart is a safety problem as well as a privacy one. Find out what happens to a message that does not match cleanly, who works that queue, and how two charts for one person are merged and, if the merge was wrong, separated again.
Go-live and support
What is the timeline from signing to go-live, and how many hours will our own staff need to put in?
Why ask it
Have the plan laid out week by week with your tasks marked: building templates, checking converted charts, sitting through training. Buyers tend to underestimate their own side, so check with a reference how many staff hours it really took them.
Who converts our existing charts, what arrives as usable data and what arrives as scanned pages?
Why ask it
Medications, allergies, problems and immunizations should land as structured entries the new system can check and alert on. Agree in advance how a sample of converted charts will be compared with the old system, and who signs off before the old one goes read-only.
How much training does each role get, and what is there for people we hire later?
Why ask it
A front-desk clerk, a nurse, a physician and a biller need different sessions, ideally on your own configuration and close enough to go-live that it sticks. Staff turnover means you will need it again, so find out whether later training is included or billed per session.
Who will be on site on go-live day and through the first weeks?
Why ask it
Get names, the number of people per location and how long they stay. Ask too how far they suggest thinning the appointment schedule at first, and be skeptical of a vendor who says there is no need.
How many hours of unplanned downtime did customers have in the past twelve months?
Why ask it
An uptime percentage in a contract is a promise, and the incident history is the record. Get the dates, the causes and how customers were kept informed, and check whether scheduled maintenance is left out of the promised figure and how often it has run into working hours.
When the system is down, what do we work from, and how does the paper get back into the chart?
Why ask it
You need a read-only copy or printed snapshot of schedules, medication lists and allergies that works without the main system, and an agreed way to enter afterwards what was done on paper. Run a downtime drill before go-live, since the first real outage is a bad time to look for the forms.
How often is our data backed up, and how long would it take you to restore us after a ransomware attack on your hosting?
Why ask it
Two figures matter: how much recent charting could be lost, and how many hours or days would pass before you could open a chart again. A vendor that has rehearsed a full restore can give both and say when the last test was. If the reply is only that backups run nightly, nobody has timed the restore.
What are your support hours, and how fast do you respond when a problem stops patient care?
Why ask it
Find out how the vendor ranks severity and what counts as the top level. A clinic that cannot prescribe or see results should be there. Check whether the first person who answers can fix things or only log a ticket, and ring the support line yourself before you sign.
How do we report a patient-safety concern about the software, and what happens to it?
Why ask it
A wrong dose default or a result showing under the wrong patient needs a faster route than an ordinary ticket. A good answer has clinicians reviewing these reports and a way of warning other customers about the same fault. Check too whether the contract limits what you may say publicly about a safety problem.
Cost and exit
What is the total cost over five years, with every module, interface, fee and service listed?
Why ask it
Give every vendor the same five-year grid so the quotes can sit side by side: subscription, implementation, conversion, interfaces, training, hardware and support. Have each one mark which lines are estimates, and say what has most often pushed other customers past their quote.
Which charges scale with providers, visits, claims or a percentage of collections?
Why ask it
Per-provider pricing raises the matter of how part-time clinicians, residents and nurse practitioners are counted. A percentage of collections means the bill grows whenever your revenue does, so work out each model at the size you expect to be in three years.
How much can the price go up at renewal, and is the increase capped in writing?
Why ask it
Once your records are in a system, moving is expensive, and the vendor knows it. Ask for a cap on annual increases through the first term and the first renewal. How readily it is given tells you something about the renewals to come.
How long is the contract, does it renew on its own, and what would leaving early cost?
Why ask it
Note the deadline for stopping an automatic renewal and put it in a shared calendar the day you sign. If you are renewing an existing system, this is the moment to ask for the terms you wished you had the first time.
What happens to our system, our price and our data if your company is sold or closes?
Why ask it
A new owner can retire a product, move it to maintenance only or rewrite the price list. Look for a clause that carries your contract over to a buyer unchanged, and one that guarantees an export of your records if the company stops trading. Your lawyer can say how much either is worth where you are.
If we leave, in what format do we get our records, how complete are they, and what will you charge?
Why ask it
Request a sample export now, on a test patient: discrete data, scanned documents, images, billing history and the audit log. A summary document per patient is not the whole chart, and a per-record fee can make leaving unaffordable, so settle format, price and timescale in the contract.
After the contract ends, how long can we still look up the old records, and at what price?
Why ask it
How long medical and billing records must be kept depends on where you practice and who your patients are, so get your own number from your regulator, insurer or lawyer. Then ask the vendor what read-only access or an archive costs for that many years.
Who owns the patient data, and the templates and reports we build ourselves?
Why ask it
Look for a line in the contract saying the records are yours and the vendor holds them on your behalf. Custom templates and reports are less clear cut, so ask whether those export too or stay behind when you go.
How to run a health IT vendor evaluation
Practical guidance for the conversation itself
Before the first demo
Write down what the system has to do on an ordinary Tuesday
List the ten things your organization does most: the common visit types, a refill request, a referral out, a lab result coming back, a claim going to your biggest payer. Those become the demo script and the scoring sheet. A vendor judged against your Tuesday is much harder to flatter than one judged against its own slide deck.
Give each group of questions to the person who can judge the answer
A clinician should own Fit. Whoever handles privacy should own Compliance. The person who looks after your interfaces, or an outside consultant if you have nobody, should own Data exchange. Go-live and support belongs to the manager who will run the changeover, and Cost and exit to whoever signs. Roadmap is for everyone, because each of them is waiting on something different.
Send the factual questions ahead in writing
Compliance, Data exchange and Cost and exit are mostly questions with documents behind them: a certification listing, a security report, an interface price list, a sample export. Send those a week before the meeting and ask for written replies. Keep the meeting itself for Fit and Roadmap, where watching the product and the people tells you more than a form does.
Treat a renewal as a purchase
If you already run the system, skip most of Fit and go straight to Roadmap and Cost and exit. Ask what has shipped since you signed, what the next term will cost, and what an export would look like today. Bring your own record of outages and slow support tickets, since on those you no longer need the vendor's account. You do not have to intend to leave. Knowing what leaving would take is what gives the renewal conversation two sides.
Reading a roadmap answer
Sort everything into live, committed and planned
Live means a customer is using it today and you can see it in a production system, not a prototype. Committed means it has funding, a team and a release quarter the vendor will put in writing. Planned is everything else. During the meeting, stop the presenter each time a feature comes up and ask which of the three it is.
Score only what is live
When you compare vendors, give points for what exists. A committed item can be noted beside the score if the vendor will name it in the contract. A planned item earns nothing, however good the mock-up looked, because you would be paying this year for something that may never be built.
Check the roadmap against a customer's memory
On each reference call, ask what the vendor told them was coming when they signed, and what actually arrived. Two or three customers who were promised the same missing feature tell you more about the roadmap than the roadmap does.
Decide what you cannot go live without
Before the meeting, mark the two or three capabilities you would refuse to start without. If any of them is on the roadmap and not in the product, your choices are to wait, to have the feature and a date written into the agreement with a remedy, or to pick another system. Hoping is not on the list.
From the meeting to the contract
Keep a running list of promises
Have one person note every commitment made aloud: the interface that is included, the trainer who stays two weeks, the export at no charge. After each meeting, send the list back to the vendor and ask them to confirm it. Before signing, ask for it to be attached to the agreement, because many contracts say that nothing outside the document counts.
Put each document in front of the right reader
The main agreement and the business associate or data processing agreement need a lawyer who has seen health IT contracts before. The security report needs someone who can tell what its scope leaves out. The interface and API terms need whoever will build on them. This page can tell you what to ask for, but not what your own law, payers or regulator require, so ask them.
Settle the exit while the vendor still wants the sale
Export format, export price, how long the vendor will help with a transition and how long you keep read-only access are easy to agree before signing and very hard afterwards. Get the sample export during the evaluation and have a technical person open it. If the file is unreadable now, it will be unreadable on the day you need it.
Find out what changes with where you practice
Certification programs, privacy law, breach deadlines, electronic prescribing rules, registry reporting and record retention all differ between countries and often between states or provinces. Where a note above says to check, the vendor's answer is only half of it. The other half comes from your regulator, your professional body or your own counsel.
Mistakes buyers make
Choosing on the demo
The demo is the product at its best, driven by someone who uses it every day, on data chosen to behave. Ask for a sandbox login and let your slowest and your most skeptical clinician each spend an hour in it alone. Their verdict is closer to what the first month will feel like.
Comparing first-year prices
One quote loads the cost into implementation and another into the monthly fee. A third looks cheapest until interfaces and the percentage of collections are added. Only the five-year total, with your own staff time and the cost of a thinner schedule at go-live included, puts them on the same footing.
Leaving downtime for later
Buyers ask about uptime and forget to ask what happens during the hours that are left. Every hosted system goes down at some point. Whether your clinic keeps seeing patients safely that afternoon depends on a downtime copy and a paper routine that were set up and practiced before go-live.
Letting the owner or the IT lead decide alone
A system picked without the front desk, the nurses and the billers gets worked around by them. They do not need a vote on the contract, but each should see their own part of the product and say what would stop them doing their job in it.