You asked the hospital a simple question: can your system send us lab results when they're ready? The integration analyst on the call says "sure, we're HL7." Everyone nods. You write down yes and move to the next agenda item.

That sentence was not a yes. It was a category. Telling you a hospital "uses HL7" is close to telling you a company "uses English": true, friendly, and hiding every detail that decides whether your product connects in six weeks or nine months. HL7 covers three largely unrelated technical standards, dozens of message types, and a stack of ownership questions nobody in that room raised. Here's what the phrase actually conceals, roughly in the order it comes back to bite you.

"HL7" Names a Family of Standards, Not a Format

Health Level Seven International is a standards body, not a file type. It has published several standards over nearly four decades, and at least three of them are running in production hospitals right now.

• HL7 v2 is the old workhorse: plain-text messages made of segments and fields separated by pipe characters, usually pushed over a raw TCP socket. A patient identification segment looks like `PID|1||100428^^^MRN||DOE^JANE||19750214|F`. Position matters, most fields are optional, and the standard lets each site add custom "Z-segments," so no two v2 implementations are quite the same.
• HL7 FHIR is the modern one: a REST API returning JSON resources with names like Patient, Observation, and Encounter. You request data instead of receiving a firehose.
• C-CDA is a document standard: an XML clinical document such as a discharge summary or care-summary snapshot. It carries a point-in-time picture of a patient, not a stream of events.

When someone says "we're HL7" without qualifying it, they almost always mean v2. ASTP/ONC's 2023 national survey of health information exchanges found 96% of HIEs receiving HL7 v2 ADT messages, while only a small share routinely used FHIR APIs to move data. The pipe-delimited standard from 1989 is still what most clinical traffic rides on.

This matters to you commercially, not just technically. If your engineering team built a FHIR client because that's what the modern documentation covers, and the hospital's answer is a v2 feed over a VPN tunnel, you don't have an integration. You have a parser to write, a socket listener to host, and a message-acknowledgement flow to get right before anyone sees a single lab result.

There's a second-order consequence founders miss when they're modeling growth. Because v2 tolerates local customization, the interface you build for your first hospital is partly specific to that hospital. Segment usage, code sets for lab identifiers, how a facility encodes departments and units, whether a field arrives populated at all: those vary by site and by the vendor version underneath. Your second hospital reuses your parser, your infrastructure, and your operational knowledge, which is real savings. It does not reuse your field mapping. Budget the second integration at a discount, not at zero, and be careful about promising an investor a per-customer onboarding cost that assumes otherwise.So the first question in that meeting is narrower than "do you support HL7." It's: for this specific data flow, which standard, and which version of it?

Which Message Types, Flowing Which Way

A v2 interface isn't one connection to "the hospital." It's one connection per data flow, per message type, per direction. Hospitals think in message types, and once you learn the vocabulary the meeting gets dramatically more productive.

• ADT (Admit, Discharge, Transfer) carries patient demographics and movement events. It's the feed almost everything else depends on, because it tells your system who the patient is and where they are.
• ORU carries observation results: lab values, imaging report text, device readings.
• ORM and OML carry orders going the other way, into the lab or radiology system.
• SIU carries scheduling events, which is what you want if your product cares about appointments.
• DFT carries charges and billing detail.
• MDM carries documents and notes.

Each of those is a separate build on the hospital's side, and each one gets its own testing cycle. A product that needs demographics plus results plus appointment changes is asking for three interfaces, not one, and the hospital's analyst is mentally pricing it that way even if nobody says so out loud. Published scopes for HL7 integration services are typically broken out per interface and per message type for the same reason, which makes them a reasonable yardstick for checking whether your internal estimate counts the same units of work the hospital counts.

Direction is the other half of the question, and it's where founders get the biggest surprise. Reading data out of a hospital system is a technical project. Writing data back into the chart is a clinical governance project. A result your app pushes into a patient's record becomes part of the legal medical record, so it pulls in the informatics team, sometimes a physician committee, and a validation cycle with real clinicians clicking through real screens. Teams that assumed write-back was symmetric with read tend to lose a quarter to that discovery.

Two more details worth nailing down before you leave: whether the feed is real-time or batched, and whether you get history. Most interfaces are go-forward only. If your product's value depends on twelve months of prior results, that's a separate extract with its own approval.

Then get specific about triggers and volume. An ADT feed isn't one event; it's a set of them, and the hospital chooses which ones to send you. A01 is an admission, A03 a discharge, A08 a demographic update, A11 a cancelled admission. Products that never subscribed to cancellations end up with patients who were never actually admitted sitting in their dashboard, and the fix is another change request. Volume shapes your architecture too: a busy hospital's ADT stream carries far more traffic than the slice your product cares about, most of it routine updates, and you need somewhere to land it before you filter. Ask which trigger events they'll send, at what expected daily volume, and whether the messages arrive as a live stream or a nightly file.

Somebody Owns the Interface Engine, and It Probably Isn't You

Between the hospital's EHR and the outside world sits an interface engine: middleware that receives messages, transforms them, and routes them. The common names are Rhapsody, Cloverleaf, Corepoint, InterSystems, NextGen Connect, and Epic's own Bridges module. Every hospital has one, and it's the actual location of your integration.

That's a budget question disguised as an architecture question. Someone at the hospital has to build the channel, map your fields, stand up the test connection, and support it afterward. That someone is usually one of two or three interface analysts covering the entire organization, and their year is already allocated. Ask directly who will build it, whether that person's hours are funded for this project, and whether the funding sits with IT or with the clinical department that wants your product.

The EHR vendor may also have a hand out. Interface licensing, per-connection fees, and app-program listings are all real line items depending on the vendor and the connection type, and they're rarely mentioned in the first conversation. If you're planning a FHIR app for a large EHR, being listed in that vendor's app program is often the practical path to production access, which adds a review process running in parallel with the hospital's own.

Connectivity and support ownership deserve their own five minutes. A v2 feed typically travels over a site-to-site VPN or a dedicated tunnel, which means a network request, a firewall rule, and an IP address exchange before a single test message moves. Then decide, out loud, who notices when the feed stops. Interfaces fail quietly: the socket drops, the hospital's engine queues messages, and your product keeps showing yesterday's data while looking perfectly healthy. Somebody has to monitor the connection, someone has to be reachable when it breaks at 2am, and the answer is often "both of us, differently." Agree on who watches what, and how you'll reach each other outside business hours, before go-live rather than after the first outage. None of this shows up in "we use HL7." All of it shows up in your timeline.

"We Have an API" Has a Narrower Meaning Than You Think

The regulatory picture genuinely improved, and it's worth knowing exactly how far the improvement goes.

The 21st Century Cures Act update to health IT certification required certified developers to deliver FHIR-based standardized API technology to their customers by December 31, 2022, and more than 95% of them met that deadline. Since ASTP/ONC's hospital adoption data puts certified EHR use above 99% of non-federal acute care hospitals as of 2024, the practical effect is that nearly any hospital you talk to has a standards-based FHIR API available.

What that API guarantees is specific: read access, through FHIR, to the data elements in the United States Core Data for Interoperability, for a single patient and for populations of patients. USCDI Version 3 lists 94 data elements across 19 data classes, covering things like problems, medications, allergies, lab results, demographics, and immunizations.Ninety-four elements sounds generous until you compare it to what your product needs. The certified API does not promise you:

• The ability to write anything back.
• Data elements outside USCDI, including most custom flowsheet rows, department-specific fields, and anything your clinical champion described as "the field our nurses actually use."
• Push notifications when something happens. Event-driven awareness is still typically an ADT feed, not an API poll.
• Bulk historical extracts on your schedule.
• Automatic permission. Your app still needs registration, credentials, and the hospital's own approval to connect to their endpoint.

One distinction inside FHIR trips up more product plans than any other: who authorizes the access. A patient-facing app gets its data because the patient logs in with their portal credentials and grants your app permission, one patient at a time. A system-to-system integration, where your platform pulls data for a whole panel of patients without anyone tapping "allow," is a different authorization model, a different registration path, and a different conversation with the hospital. Founders regularly demo the first, cite it as proof the integration works, and then discover their actual business model needs the second. Say which one you need in plain words, early, because the two get approved by different people on different timelines.

So "we have an API" and "you can build your product on our API" are different statements. Ask which USCDI version their system is certified against, and then ask specifically about the two or three fields your product cannot function without. That second question resolves more risk than an hour of general discussion.

The Timeline Belongs to Their Change Process

The most expensive misunderstanding in that meeting is not technical. It's the assumption that the hospital's enthusiasm translates into the hospital's calendar. Your integration has to pass through a process built to keep clinical systems from breaking:

1. Intake and prioritization. Your project joins a queue behind revenue-cycle work, an upgrade, and a compliance deadline. Enthusiasm from a department head does not reorder that queue; a governance committee does.
2. Security and privacy review. Questionnaires, penetration-test evidence, a signed business associate agreement, and a decision about how you'll connect.
3. Non-production environment access. Test systems are shared, sometimes refreshed on a schedule you don't control, and occasionally unavailable because a bigger project has them.
4. Build and interface testing. Their analyst builds the channel, you exchange messages, and you discover the field mapping problems that only appear with real data shapes.
5. Patient identity reconciliation. Their medical record number is not your patient ID. Deciding how the two match, and what happens when they don't, is its own conversation.
6. Change control and go-live. Production changes happen in defined windows, and many organizations freeze changes around upgrades, holidays, and year-end.

Nobody in the room is lying when they can't give you a date. The date isn't theirs to give. What you can get is the name of the process, the cadence of the committee that approves it, and the next date that committee meets. Those three facts let you build a plan; "they seemed really excited" does not.

Plan around it rather than fighting it. Sequence your first integration for the narrowest useful data flow, get it into production, and expand from a working connection. A live read-only ADT feed is worth more to your roadmap than a perfect bidirectional design still waiting for its first review.

What to Ask Before the Meeting Ends

Take these questions in with you. They're deliberately blunt, and every experienced integration analyst will respect them.

1. Which standard for this flow: v2, FHIR, or C-CDA? Which version?
2. Which message types, and in which direction?
3. Is this read-only, or does anything write back into the chart?
4. Which interface engine, and who builds and supports the channel?
5. Are that person's hours funded for this project, and by which budget?
6. Does the EHR vendor charge a fee or require an app-program listing for this connection?
7. Which USCDI version is your system certified against, and are these specific fields included?
8. Do we get historical data, or go-forward only?
9. What's the approval path, and when does that committee next meet?
10. Who owns patient matching between your medical record number and our identifiers?

Write the answers down. Six months later, when someone asks why the integration slipped, that page will tell you which assumption broke.

The Short Version

"We use HL7" is the start of a scoping conversation, not the end of one. Three things to carry out of the room: pin the standard and version to the specific data flow, find out who builds the interface and whether their time is paid for, and get the name and cadence of the committee that approves production changes. Then scope your first connection as narrowly as it can be while still being useful. One working feed beats a complete design nobody has approved.