Interoperability in EHR is how one electronic health record talks to another: a pipe, a shared structure, and shared meaning. It is not a vendor pick-list and not the definition of an EHR.
If you meant healthcare interoperability solutions (Redox / Mirth / Cloverleaf / Epic Bridges) → healthcare interoperability solutions. If you meant EMR vs EHR → what is the difference between EMR and EHR. If you meant pros and cons of adopting an EHR → pros and cons of EHR. If you meant healthcare APIs → API for healthcare. If you meant HIPAA transfer → HIPAA-compliant data transfer.
PYCAD builds custom web DICOM viewers and imaging AI — a connector / imaging stack, not an EHR or an HIE.
Three levels
The usual frame is three levels. Foundational is a pipe. Structural is a shared envelope. Semantic is shared meaning. Most “we integrated” projects stop at the first two.
| Level | What it is | In practice |
|---|---|---|
| Foundational | A secure pipe from system A to system B | The file arrives. The receiving system may not be able to open it. |
| Structural | The same envelope on both sides | Fields land in the right slots: date, ID, order type. |
| Semantic | Both sides mean the same thing | “Systolic” and a LOINC code are the same concept in both charts. |
Semantic is the goal. Without it you have a fax with extra steps.
The languages: HL7, DICOM, FHIR
HL7 (especially v2) is the grammar most hospitals already speak: ADT, orders, results. Reliable, verbose, still moving the majority of clinical traffic.
DICOM is non-negotiable for imaging. A CT is not a JPEG. The standard carries the pixels plus the patient, the study, and the acquisition. An EHR that cannot speak DICOM parks the study in PACS and leaves a text report in the chart. For how PACS actually attaches, see PACS integration.
FHIR is the web dialect. Resources (Patient, Observation, ImagingStudy) over HTTPS, not a whole ADT dump. The 21st Century Cures Act pushed certified EHRs to expose FHIR APIs for patient and app access. A cloud store for those payloads is a separate job — Google Cloud Healthcare API.
Three architectures
| Path | What you build | Fails when |
|---|---|---|
| Point-to-point | A custom interface for each pair of systems | The fifth connection. Spaghetti, one owner per wire. |
| Integration engine | One hub that translates and routes | The hub is down. Everything waits. |
| APIs | On-demand reads and writes (usually FHIR) | Auth, rate limits, and “which resource is the source of truth” are not designed. |
P2P is fine for two systems. An engine is the hospital default. APIs are how a new app asks for one allergy list without a nightly file. Most shops run an engine and a FHIR layer. The vendor names for those engines live on the interop-solutions page, not here.
Imaging and AI inside the record
Text interop is the easy half. Studies are large, DICOM-shaped, and usually sit in PACS. The clinician then lives in two windows: the chart and the viewer. That is the gap this page actually owns.
A web DICOM viewer inside the chart is the fix: window/level, measurements, prior comparison, without a second login. Once the pixels are in the same session as the labs and meds, AI has something to work on — triage (flag a likely bleed), quantitative follow-up (volume change), not a model that never sees the chart. PYCAD builds those viewers. It does not replace the EHR.
Security as the floor
An open pipe is a breach. Minimum:
- Auth — OAuth 2.0 / SMART on FHIR for apps. Least privilege, not a shared service account.
- Encryption — TLS in transit, AES-256 at rest. The five minutes on the landing folder count.
- Audit — who read, who wrote, which resource. If you cannot show it, it did not happen.
How to move the copy is HIPAA-compliant data transfer. This page is how the systems talk once the copy is allowed to move.
Three-phase roadmap
- Name the job. Faster referrals, fewer repeat labs, imaging in the chart — pick one. A committee with no target buys an engine and stares at it.
- Audit the stack. What already speaks HL7. What is a fax. What is PACS-only. Retire what will never grow a FHIR resource.
- Pilot, then widen. One high-value, low-complexity flow first. A “big bang” cutover is how you get a weekend of downtime and a rolled-back interface.
FAQ
Interoperability vs integration?
Integration is one custom wire. Interoperability is a shared language so the next system does not need a new wire. You will still write interfaces. The point is not to write a new one for every pair.
FHIR vs HL7 v2?
v2 moves whole messages (ADT, ORM, ORU). FHIR lets you ask for one resource. Hospitals will run both for years. Do not rip out v2 because a slide said “API-first.”
Where do we start?
Clinicians, IT, and admin in one room. One pain (referrals, duplicate labs, imaging out of the chart). Then the audit. Then a pilot. Software is step four.
PYCAD implements viewers and imaging AI on top of DICOM / FHIR / PACS. It is not an EHR and not an HIE. Case studies.