EHR Integration with FHIR and HL7

Which standard fits which data flow

Startups often hear that FHIR replaced HL7 and plan everything around one API. In real hospital environments the standards coexist, and each one is good at a different job. Tepia starts by listing every data flow your product needs, then assigns a standard to each.

Most products end up with two or three of these. A remote monitoring startup, for example, might read problem lists through FHIR, listen to ADT feeds for hospital admissions, and write readings back as Observations.

What healthcare startups underestimate

The code is rarely the slow part. Access is. Tepia plans for these realities before a single endpoint is called.

• Vendor developer programs. Epic, Oracle Health and athenahealth each run their own developer and marketplace programs with registration steps, review and sandbox environments. Plan for that work in your first months.
• Site by site activation. Being listed with a vendor does not connect you to a hospital. Each health system’s IT and security teams approve your app, assign scopes and sometimes configure custom fields.
• Security questionnaires. Expect long questionnaires about encryption, access control, incident response and SOC 2 aligned practices. Tepia helps you answer them from real architecture documents, not marketing copy.
• Sandbox versus production data. Sandbox patients are tidy. Production charts have duplicate records, free text medications and lab codes that never appear in test data.
• On premises interfaces. HL7 v2 feeds often come from an interface engine behind the hospital firewall, reached over a VPN that someone has to provision and monitor.

None of this is a reason to avoid integration, but it changes your launch plan. Tepia sequences the first live site as its own milestone, separate from feature development, so a slow approval does not stall engineering.

Reading, writing and listening to the chart

Tepia designs EHR integration around three verbs, because each one has different technical and governance answers.

Reading

FHIR R4 reads cover most needs: demographics, problems, medications, allergies, labs and vitals. Tepia caches only what your product needs, records every access in an audit log, and maps codes to LOINC, SNOMED CT, RxNorm and ICD-10 so data from different EHRs lines up.

Writing

Writing back is where vendors are most cautious. Common options are a DocumentReference containing a PDF or note, an Observation for device readings, an HL7 v2 ORU or MDM message through the interface engine, or a task in a clinician’s inbox. Tepia confirms during Discovery which of these each target site will actually accept.

Listening

Polling FHIR endpoints for changes is slow and burns rate limits. For real time triggers such as an admission, discharge or final lab result, Tepia prefers HL7 v2 ADT and ORU feeds or FHIR Subscriptions where the EHR supports them, routed through a queue so no message is lost during a deploy.

All three run on HIPAA aware infrastructure in AWS, Azure or GCP with encryption in transit and at rest. See our API development and integration work for the general patterns behind this.

How Tepia approaches EHR integration

Tepia applies its six phase process to integration projects with a US based project manager coordinating your team, the vendor and each health system’s IT contacts.

1. Discovery: an inventory of every data flow, the target EHRs and versions, and the vendor programs you need to join. Deliverables are an Investigation Summary with a data flow map, an Interview Summary from clinical and IT stakeholders, and User Stories such as a care manager seeing yesterday’s discharges at 8 a.m.
2. Design: interface specifications, field mappings, a terminology plan and, for clinician facing apps, wireframes of the SMART on FHIR launch experience inside the EHR frame.
3. Development and Testing: an Alpha against vendor sandboxes and a Beta against one live site, with test plans for message replay, malformed segments, duplicate patients and downtime recovery.
4. Training: sessions for your support team on reading interface logs and resolving match exceptions.
5. Launch: production credentials, VPN setup where needed, historical data backfill and a monitored cutover.
6. Support: alerting on interface failures, quick response when a site upgrades its EHR, and new site onboarding.

Discovery typically takes 1 to 3 months, development and QA 2 to 6 months, and launch around a month per first site. Read more on how Tepia works.

Direct connection, interface engine, or integration platform

There are three common architectures, and Tepia recommends based on how many sites and standards you will touch.

• Direct FHIR connection: best when you serve one EHR vendor and mostly read data. It is the simplest to own and debug.
• Interface engine: an engine such as Mirth Connect fits when HL7 v2 feeds dominate, or when you run integration for a hospital that already operates one.
• Integration platform: commercial platforms such as Redox normalize many EHRs behind one API, which can shorten time to the first several sites. Tepia builds on top of them when the site count justifies it.

Whichever you choose, keep your own canonical data model so switching later does not mean rewriting the product. Tepia’s systems integration services follow that rule across industries, and our patient portal development work shows it applied to a patient facing product. If you are planning a first hospital integration, talk to Tepia before you sign a pilot agreement.

Frequently asked questions