EHR Vendors to Consider

Which EHR vendors should you consider?

The EHR vendors to consider are those that serve your care setting and specialty, hold current ONC certification for the criteria you need, support modern standards such as FHIR R4 and SMART App Launch, and can show reference sites like yours. Start from those filters rather than brand names, then cut to three to five vendors for detailed evaluation.

A vendor that is ideal for a 500-bed hospital can be a poor fit for a ten-clinician specialty group, and the reverse is equally true. Fit with your setting matters more than any general ranking.

How do you build an EHR vendor longlist?

Build the longlist by care setting and specialty first, then add constraints such as hosting model, budget range and required modules. Ten to fifteen candidates is a reasonable longlist before screening.

• Care setting: Ambulatory, inpatient, emergency, post-acute, behavioral health or home health, or a mix.
• Specialty: Specialty content, templates and devices, for example ophthalmology imaging or orthopedic implant tracking.
• Scale: Number of clinicians, sites and patient volume, now and in five years.
• Modules: Practice management, revenue cycle, patient portal, telehealth, lab, pharmacy or imaging.
• Hosting: Vendor-hosted cloud, private cloud or on-premises, and any data residency requirements.
• Existing systems: Systems you must keep, such as a lab system or data warehouse, and how each vendor connects to them.

Peers in the same specialty and size band are the best source of names. Ask what they chose, what they considered and rejected, and why.

How do you check certification on ONC's CHPL?

Search ONC's Certified Health IT Product List for each vendor's product and version, and read the full listing rather than relying on a certification logo. CHPL lists products that were tested by an ONC-Authorized Testing Laboratory and certified by an ONC-Authorized Certification Body.

• Exact version: Confirm the version you would buy is the one listed, not an older or newer release.
• Criteria covered: Check which certification criteria the listing includes, and whether any you need are missing.
• Relied-upon software: Note any third-party components the listing depends on, which you may also need to license.
• Corrective actions: CHPL publishes corrective action plans; ask the vendor to explain any open or recent ones.
• Real World Testing: Read the vendor's Real World Testing plans and results, also linked from CHPL.
• CMS EHR Certification ID: ONC's Health IT Playbook notes that CHPL is used to generate the CMS EHR Certification ID used in CMS programs.

Screen the longlist against CHPL before any demos. A vendor that lacks a criterion you need, or whose listed version is well behind its current release, can be set aside early, saving weeks of evaluation time for both sides.

Which interoperability standards should a vendor support?

A vendor should support the API standards ONC adopts at 45 CFR 170.215, which include HL7 FHIR R4.0.1, US Core 6.1.0, SMART App Launch 2.0.0 and the Bulk Data Access specification, along with the HL7 v2 messaging most organizations still run.

• FHIR R4 with US Core: For patient and population data access by apps and partners.
• SMART App Launch: So third-party and in-house apps can launch inside the EHR with the user's context.
• Bulk Data: For exporting data on whole patient populations to analytics and quality programs.
• HL7 v2: For admissions, orders, results and scheduling feeds with labs, imaging and other systems.
• Documents: C-CDA documents for transitions of care and record requests.
• Network participation: Connections to health information exchanges and national networks your partners use.

What should you ask about APIs and integration?

Ask how you will actually use the vendor's APIs and interfaces, what they cost and who builds them. Standards support on paper does not mean a vendor makes integration easy or affordable.

• Access: Is there a developer sandbox, and how long does it take to get production credentials?
• Coverage: Which FHIR resources support write as well as read, and which data is only available through proprietary APIs?
• Fees: Are there charges per interface, per API call, per app or per connected organization?
• Interface builds: Who builds HL7 v2 interfaces, at what price, and with what lead time?
• App marketplace: Is there an app program, and what does listing or connecting an app require?
• Events: Can the EHR push notifications, for example through FHIR Subscriptions, or must partners poll?

The best test is a small proof of concept. Give your developers or an integration partner sandbox access for two weeks and ask them to read a patient's problems and medications, write back a document and launch a simple app. How that goes predicts the next five years better than any slide.

How should you run EHR demos?

Run demos from your own scripts, built from real workflows, and score every vendor against the same scenarios. A vendor's standard demo shows its strengths; your script shows how it handles your day.

• 1. Write scenarios: Pick ten to fifteen common and difficult workflows, such as a new patient visit, a referral with records, a result needing follow-up and a denied claim.
• 2. Share in advance: Send scenarios two weeks ahead, with sample patient data, so vendors can configure.
• 3. Invite users: Have clinicians, front desk, billing and IT staff each score the scenarios that affect them.
• 4. Count clicks and screens: Time key tasks and note where users would need workarounds.
• 5. Ask for the build: Ask whether each part shown is standard, configured for the demo, or still in development.

What should reference calls cover?

Reference calls should be with organizations of your size and specialty, ideally ones you find yourself, and should cover implementation, support and integration as much as the software.

• Implementation: Was go-live on time and budget, and what would they do differently?
• Support: How fast are tickets resolved, and how are urgent issues escalated?
• Upgrades: How disruptive are upgrades, and how much testing falls on the customer?
• Integration: How long did interfaces and API projects take, and what did they cost?
• Price changes: How have renewal prices changed compared with the original contract?
• Hindsight: Knowing what they know now, would they choose the same vendor again?

Ask to speak with an IT lead as well as a clinical sponsor. Clinicians describe daily use, while IT staff describe upgrades, outages and integration, and the two views together give a far more honest picture.

How do you compare total cost of ownership?

Compare total cost over five to seven years, not the first-year quote. Licence or subscription fees are often a minority of the total once implementation, interfaces, hosting, staff and productivity loss at go-live are counted.

• Subscription or licence: Per provider, per user, per encounter or a percentage of collections, and annual increases.
• Implementation: Vendor services, third-party consultants and internal staff time.
• Interfaces and APIs: One-time build fees and recurring charges for each connection.
• Data migration: Extracting, mapping and loading data from the current system, and archiving what is not migrated.
• Hardware and hosting: Devices, scanners, signature pads and any on-premises infrastructure.
• Productivity dip: Reduced schedules around go-live and the training time behind it.

Put every vendor's costs in the same model, with the same assumptions about growth, staff time and interfaces, and ask each vendor to confirm the lines that come from their quote. Differences that looked large in the first quote often shrink, or reverse, once the full picture is laid out.

Which contract terms protect you?

The contract terms that protect you most cover your data, your costs and your ability to leave. Negotiate them before signing, while your bargaining position is strongest.

• Data export: Full export of all data in standard and documented formats, at any time and at termination, at a fixed or no cost.
• Price protection: Caps on annual increases and on fees for new interfaces or users.
• Service levels: Uptime commitments, response times and credits when they are missed.
• Business associate agreement: HIPAA obligations, breach notification timelines and subcontractor terms.
• Transition assistance: Help moving to another system at the end of the contract, with defined rates.
• Roadmap commitments: Written commitments for features you were promised during selection.

Contract talks also expose red flags, the signals that a vendor will be harder to work with after signing than before. Treat any one of them as a reason to dig further before you commit.

• Vague API pricing: Fees for integration that are only quoted after signing.
• Export reluctance: Unclear answers about how you would get your data out.
• Demo-only features: Capabilities shown in demos that are not in the version listed on CHPL.
• Hand-picked references only: No willingness to let you contact other customers directly.
• Open corrective actions: Unresolved certification issues the vendor cannot explain clearly.

None of these rules a vendor out on its own. A vague answer can reflect a sales team that does not know the detail, and a direct follow-up to the vendor's technical staff often resolves it. What matters is whether the vendor puts the answer in writing.

How Agnotic can help

Agnotic Technologies helps clients assess shortlisted EHR vendors on the technical questions that decide integration cost: API coverage, FHIR and HL7 v2 support, sandbox access and data export. Agnotic can test vendor APIs hands-on before the contract is signed.

Once a vendor is chosen, Agnotic plans and builds the interfaces, data migration and analytics feeds the new EHR needs, so the go-live includes the connections the organization depends on.

Sources

• ONC: Certified Health IT Product List (CHPL)
• ONC Health IT Playbook: Certified Health IT
• 45 CFR 170.215: Application Programming Interface Standards