What each standard addresses
For non-experts, interoperability means deciding how your product fits into systems that already exist. Some products can succeed as standalone tools early, while others need deep EMR/EHR integration from the beginning. The right strategy depends on your target workflow, customer expectations, and deployment timeline. Use the table as a map, not a substitute for a concrete interface plan with your customers’ IT and clinical stakeholders.
| Standard | Common role | Founder concern |
|---|---|---|
| HL7 v2 | Legacy hospital event and order messaging (ADT, ORU, etc.) | High site-to-site variability; often mediated by an interface engine |
| FHIR | Modern HTTP/API-oriented exchange of clinical resources | Which resources, which implementation guides, which partner profile |
| DICOM | Medical imaging objects, metadata, storage, and network transfer | PACS/RIS workflow, bandwidth, long-term archive sizing |
What this page helps you decide
This page helps learners understand integration before promising it. HL7, FHIR, DICOM, IHE profiles, interface engines, and EHR workflows solve different problems and create different maintenance obligations.
Use it before telling a customer the product integrates with their systems. Integration is a workflow, data, security, testing, and support commitment, not only an API feature.
HL7 v2 versus FHIR in practice
HL7 v2 messages are still common in hospitals: pipe-delimited records that carry orders, results, and demographic events. “Standard” does not mean uniform. Local conventions (Z-segments, custom tables) and aging documentation mean two “HL7” feeds can behave quite differently. Your team should plan for mapping work, test environments, and clarification cycles with each site.
FHIR (Fast Healthcare Interoperability Resources) wraps clinical concepts (patients, observations, diagnostic reports) in REST-style resources. That makes modern app integration easier in principle, but you still must answer which implementation guide applies (for example, US Core, national profiles, or payer-specific rules), whether SMART on FHIR is in scope for app launch inside an EHR, and how you handle authentication and consent. FHIR reduces some friction; it does not remove governance or security review.
DICOM and imaging workflows
DICOM is the lingua franca of imaging: acquisition modalities, structured reports, and storage semantics (PACS, VNA) depend on it. If your product touches images or derived measurements, you need a clear story for transfer syntax, routing, priors retrieval, and who owns long-term retention. Imaging integrations often stress networks and storage harder than text-only clinical workflows, so performance and latency targets belong in the same conversation as clinical requirements.
Profiles, IHE, and the interface engine
Standards gain teeth through profiles and testing: IHE (Integrating the Healthcare Enterprise) publishes integration profiles that mix HL7, DICOM, and FHIR in real-world scenarios. An interface engine (also called an integration engine) sits between systems to translate, route, filter, and retry messages. Many “integration problems” are really configuration, monitoring, and ownership problems around that middle layer. When scoping work, ask who operates the engine, how errors surface, and what uptime is guaranteed for your path.
Integration brief before build
Before promising integration, write down the exact system, standard, message or resource type, owner, test environment, authentication method, expected volume, error handling, and support contact. “We integrate with the EHR” is not a requirement. It is the start of a discovery conversation.
Worksheet
Use the integration brief worksheet before estimating build effort or making customer commitments.
Standalone vs integrated
A standalone product can be faster to deploy and easier to control. An integrated product can improve user adoption by fitting existing workflows but usually requires more implementation effort. Many teams use a phased strategy: start standalone with clear value, then integrate where it drives measurable adoption gains. Pair this page with Health Canada and ecosystem strategy when regulatory classification and data location also depend on integration depth.
Pitfalls that catch teams
- Treating “supports FHIR” as sufficient without naming resources, operations, and the exact implementation guide.
- Underestimating site-specific HL7 v2 variance and the time to build and run message validation in test.
- Ignoring imaging transfer and storage costs until pilot scale.
- Missing a clear support model for the interface engine path (alerts, retries, dead-letter queues).
- Confusing product-market pilots with production interoperability obligations for security, consent, and audit logging.
Standards and learning links
Use these as neutral references for vocabulary and scope. Your customer’s IT policies, national profiles, and contractual testing gates still drive what “done” means.
- HL7 International — home for HL7 v2, FHIR, and related product family documentation.
- HL7 — FHIR specification — technical source for resources and REST interaction patterns (version your implementation to a specific release for production).
- DICOM standard — official hub for medical imaging interoperability.
- IHE — integration profiles that combine standards into implementable scenarios.
- IMDRF — technical document library — includes Software as a Medical Device (SaMD) working group materials for harmonized terminology; pair with Canadian strategy and counsel for jurisdiction-specific rules.
Practical next step
Write an integration brief that names source systems, target systems, data fields, timing, errors, owners, test environment, and support process.
- Template or worksheet: integration brief worksheet.
- Glossary terms: FHIR implementation guide, interface engine, DICOM.
- Pathway links: Architecture patterns, Operations.