What integration experience really means in healthcare technology

Integration experience is one of the most common phrases in healthcare technology hiring, and one of the least precise. A resume can list HL7, FHIR, claims, eligibility, and a handful of EHR names without telling you whether the person has actually carried an interface through a live deployment.

The difference matters. Integration work is where product promises meet someone else's system, someone else's data, and someone else's release schedule.

Ask about a specific interface

Start with one interface and stay with it. Which system sent the data? What did the message look like on day one? What was missing, duplicated, or formatted in a way nobody expected? Who owned the mapping, and who had to approve a change?

People who have done the work answer in details. They mention a field that behaved differently than the spec, a vendor contact who took a week to respond, or a test environment that never matched production. People who have only been nearby stay at the level of standards and architecture.

Look for the unglamorous parts

• How they handled patient matching when identifiers disagreed across systems.
• What they did when a partner system went down during a pilot.
• How they tested against real data without exposing it.
• Where they pushed back on a timeline because a dependency was outside their control.
• What they changed in the product after the first live integration, not just in the interface.

These questions are not traps. They are the normal texture of the job. A candidate who has lived through them will usually welcome the conversation, because it is more interesting than reciting a list of standards.

The compliance context is part of the skill

Healthcare integration also means working inside review cycles, security requirements, and contractual limits on what can be shared. Strong engineers do not treat that as paperwork standing between them and the code. They plan for it, ask early, and keep the people who own the risk informed.

That habit is hard to teach in the first month and easy to notice in an interview. Ask how they found out a change needed review, and what they did with that information.

What to listen for

You are listening for ownership, not vocabulary. Did they build it, debug it, explain it to a partner, and stay through the first month of production? If the answer is yes, the standards on the resume are a useful shorthand. If the answer is no, the standards are just a list.