Ask one question before any feature demo: how, specifically, will this tool exchange data with the systems we already run? The answer separates a tool that will be adopted from one that will quietly become a second place staff have to type the same information. Integration is not a footnote on the requirements list. In health tech it is usually the decisive criterion, because a tool that cannot read from and write back to the record of truth creates double entry, and double entry kills adoption.
Start here: integration decides the outcome
Most buyers evaluate features first and integration last, then discover the integration is a paid professional-services engagement, a one-way nightly file drop, or nothing at all. Reverse the order. Establish what data has to move, in which direction, and how fast — then judge features among the tools that can actually do it.
Write down, before you talk to anyone:
- Which systems must exchange data (EHR, practice management, billing, labs, imaging, scheduling, patient communications).
- What data has to move: demographics, appointments, problem lists, medications, results, notes, charges, eligibility.
- Which direction: read-only into the new tool, write-back into the system of record, or bidirectional.
- How fast: real time, near real time, or a batch that runs overnight.
- Who owns the data and how you get it back out if you leave.
The four levels of integration
Vendors use the word integration for very different things. These four levels are a practical way to categorize what you are being offered.
| Level | What it means | Typical cost and effort | Best for |
|---|---|---|---|
| 1. Manual export/import | CSV or PDF files exported from one system and loaded into another, on a human schedule | Low up front, ongoing staff time forever | Low-volume, non-clinical data; short-term stopgaps |
| 2. Scheduled file transfer | Automated batch files on a defined interval, often via SFTP | Modest build, low ongoing effort | Reporting, billing extracts, roster syncs |
| 3. Interface or API connection | A messaging interface or an API that moves defined data on demand or on events | Higher build; may require an interface engine or vendor services | Clinical data flows, near-real-time sync |
| 4. Native or certified integration | The vendor maintains a pre-built, supported connection to your specific platform | Lowest ongoing effort; may carry a marketplace or licensing fee | Anything in the daily clinical workflow |
Standards worth knowing
You do not need to be an integration engineer, but you should recognize the vocabulary well enough to tell a real answer from a vague one.
- HL7 v2 — the long-established messaging format behind a great deal of hospital data exchange. Widely supported, message-based, and typically implemented through an interface engine.
- FHIR — a modern, API-based standard from HL7 for exchanging discrete health data. It is the direction of travel for app-style integrations and is central to federal interoperability policy.
- C-CDA — a document standard used for summary-of-care exchange between organizations.
- USCDI — the United States Core Data for Interoperability, a federally maintained set of data classes and elements that certified health IT is expected to support. It is a useful yardstick for asking what data a tool can actually exchange, because it is specified publicly rather than by a vendor.
Federal information blocking rules also matter to buyers, not just to developers: they support your ability to access, exchange, and use your own electronic health information. HealthIT.gov is the authoritative place to read what those rules cover before you accept a vendor's claim that your data cannot be released.
Questions to ask every vendor
- Which specific systems and versions do you integrate with today? Not the product family — the version we are on.
- Which integration level is that? File drop, interface, API, or native?
- Is it read-only or bidirectional? If a clinician acts in your tool, does the system of record know?
- What standards do you support? Ask for the standard by name, and which data classes are covered.
- Who has this running in production right now? Ask for a reference on your platform, at roughly your size.
- Who builds it, and how long does it take? Get a stated timeline in the contract, not in a slide.
- What does it cost — once and annually? Interface builds, marketplace fees, and per-message charges all exist.
- What happens when our EHR upgrades? Who maintains the connection, and is that maintenance included?
- How do we export all of our data if we leave? In what format, on what timeline, at what cost?
- Do you sign a business associate agreement? If PHI moves through the vendor, this is non-negotiable.
Who builds it, and who pays
Integration work is real engineering, and someone pays for it — the vendor, your EHR provider, an interface consultant, your own IT staff, or you, in cash. The failure pattern is a three-way standoff in which the new vendor says the EHR must open an interface, the EHR vendor treats it as a billable project, and nobody owns the timeline. Resolve this before signing. Name the responsible party in writing, attach a date, and tie a portion of payment to a working connection rather than to signature.
Test it before you sign
A demo shows the integration working in the vendor's environment. That tells you little about yours. Where possible, structure a proof of concept that moves real (or realistically shaped) data between your actual systems, with your actual configuration, and have the people who will use it daily do the testing. Confirm that records match on both sides, that updates propagate in the direction you expect, that failures are visible rather than silent, and that PHI is protected in transit and at rest throughout. If a vendor will not support a scoped test, treat that as information.
Red flags
- We integrate with everything. Nobody integrates with everything. This means we will build something, eventually, for a fee.
- Integration is on the roadmap. Buy what exists, not what is planned.
- No named production reference on your platform. The first customer on a new connection pays in time.
- Vague answers about data export. If getting your data out is undefined, your switching cost is unbounded.
- Reluctance to sign a BAA while handling PHI. Full stop.
- Screen scraping or credential sharing presented as an integration. It is brittle, and it raises access-control questions you do not want.
The takeaway
Define the data flows before you shop. Make every vendor name the integration level, the standards, the systems, and a live reference. Get the build owner, timeline, and total cost in the contract. Test with your own data. And confirm your exit path — how your data comes back out — before you let a tool become the place your information lives.
Common questions
What is the difference between an integration and an interface?
Integration is the general goal of making systems work together. An interface is one technical means of doing it — a defined channel that passes messages between two systems. A vendor can claim integration while offering only a scheduled file transfer, so ask which mechanism is actually on offer.
Is FHIR support enough to guarantee a tool will connect to my EHR?
No. FHIR is a standard, not a guarantee of a working connection. What matters is which FHIR resources and data elements both sides support, whether the EHR exposes them to third parties, and whether write-back is permitted. Ask for a live production reference on your platform.
Should I pay extra for a native integration?
Often yes. A pre-built, vendor-maintained connection usually costs less over the life of the contract than a custom interface you must maintain yourself, especially across platform upgrades. Compare the total cost over the contract term, not just the setup fee.
Does a vendor need a business associate agreement to integrate with our EHR?
If the vendor creates, receives, maintains, or transmits protected health information on your behalf, a business associate agreement is generally required. Confirm it before any real data moves.