If your organization is evaluating teleophthalmology (hospital, clinic, PHC network, or outreach campaign), the key question is not only “does the AI work?” but also “how does this enter day-to-day operations without duplicating work?”.
Integration often fails for simple reasons: - the result ends up as a standalone PDF, - the image is stored in a separate system, - and the clinical team retypes data into the EHR.
The good news is that you do not need a massive project to do this right. With a phased design and two concrete standards, DICOM/DICOMweb for images and HL7 FHIR for clinical data, you can achieve real and measurable interoperability.
For a complementary framework on safe AI operations (roles, thresholds, traceability), see: /en/blog/human-in-the-loop-ai-in-healthcare/.
Mental model: 3 layers you must solve
Think about integration as three independent layers that can be implemented from lower to higher maturity:
1) Image layer (fundus images)
- Goal: store and retrieve images in a standard and traceable way.
- Typical standard: DICOM (and on the web, DICOMweb).
2) Result layer (findings and report)
- Goal: register the clinical outcome (AI output, classification, severity, recommendation, clinician sign-off) as structured data in the EHR.
- Typical standard: HL7 FHIR (Observation / DiagnosticReport, depending on use case).
3) Workflow layer (orders, queues, referrals, SLA)
- Goal: make the study part of the care process (request, status, turnaround, notifications).
- Typical standard: FHIR (for example ServiceRequest/Task in many ecosystems), or equivalent local HIS integrations.
In retina programs, it is usually best to start with result + image link and mature workflow later.
DICOM and DICOMweb in 2 minutes (why they matter in retina)
DICOM is the classical standard for medical imaging. For fundus integration, the practical goal is: - to keep images with identifiers (patient, study, date, device), - to make them queryable by clinical systems, - and to enable audit trails of access.
DICOMweb adds a modern REST approach to query, retrieve, and store images over the web. In practice, it makes integration with web viewers, portals, and distributed systems far easier.
HL7 FHIR: where results live (and how to avoid the “standalone PDF”)
FHIR does not replace your images: it structures clinical data and reporting.
A common scalable approach:
- FHIR Observation for structured outputs (for example: “DR risk,” “gradable/ungradable image,” “recommendation: refer”).
- FHIR DiagnosticReport to bundle findings, interpretation, sign-off, attachments, and references to images/studies.
This enables real clinical search inside the EHR: - “show patients with positive findings in the last 6 months” - “list pending reviews” - “audit turnaround times”
4 integration patterns that work (from simple to mature)
Pattern 1: “Result in EHR + secure viewer link”
Ideal to start (fast, low risk). - Store structured result in the EHR plus a secure link to image/study in a viewer. - Benefit: avoid duplicate storage and gain clinical traceability.
When to use: hospitals and clinics that already have a viewer/repository (PACS/VNA), or those minimizing initial change.
Pattern 2: “Signed PDF + minimum structured data”
If your ecosystem still depends on PDFs, improve without breaking current flow: - keep the signed PDF (legal/audit), - and also store 3 to 6 structured fields (classification, eye, gradability, recommendation, priority, date).
Key point: PDF should not be the only source of truth.
Pattern 3: “Full DICOM + FHIR report”
A more mature design: - image in DICOM (or DICOMweb), - report and findings in FHIR, - stable linkage between both.
Benefit: standards-based interoperability, ideal for network scaling across sites.
Pattern 4: “End-to-end integrated workflow”
Most powerful, but not first step: - order -> capture -> AI -> review -> report -> referral -> follow-up, - all with controlled states and SLA timing, integrated with the HIS.
Benefit: automation reduces bottlenecks and avoids the “eternal pilot.”
Procurement / IT checklist: 12 questions that save months
Use this directly in demos or RFPs:
1) Identifiers: how do you handle MPI / patient ID? What about duplicates?
2) Data export: can I export structured outcomes (not only PDFs)?
3) Standards: do you support DICOM/DICOMweb, HL7 FHIR, or equivalent documented APIs?
4) Versioning: is model/algorithm version logged per result?
5) Traceability: who viewed, who validated, who signed?
6) Permissions: role-based access (capture, review, audit, admin)
7) Image quality: do you capture gradability and rejection reasons?
8) EHR integration: do you have real EHR/HIS integrations? What is typical IT effort?
9) Notifications: can alerts be triggered for “high-risk case” or “report pending”?
10) SLA and metrics: do you provide turnaround dashboards (capture -> result -> report)?
11) Security: encryption, backups, access controls, logs, retention
12) Portability: if I change vendor, can I take my data and images with me?
How this applies in Retinar (concrete example)
Retinar was designed for Argentina and LATAM, where reality often includes: - heterogeneous camera fleets, - limited specialist availability, - and EHR/HIS systems with varying maturity.
In practice, Retinar supports phased integration:
- Initial phase (fast): structured outcomes + secure study link, avoiding manual re-entry.
- Scale phase: API integrations and connectors with institutional systems (EHR/HIS), while preserving traceability and auditability.
- Network operations: decentralized capture (PHC/campaigns), AI-based prioritization, and professional review where it adds value.
The goal is not “putting images in a system.” The goal is making data actionable inside care workflows, with metrics and follow-up.
Closing: interoperability is what makes programs sustainable
In teleophthalmology, the biggest value appears when: - results are searchable, - referral is measurable, - and teams stop copy/pasting between systems.
If integration means only “upload an image” or “attach a PDF,” friction appears within weeks. If you solve image, result, and workflow in phases, the program scales.
CTA: let us review your scenario and propose a phased integration
Do you want Retinar integrated with your EHR/HIS without an endless project?
Contact us for a technical + clinical demo (30 to 45 minutes) to:
- map your current workflow,
- review your equipment,
- define a roadmap (minimum viable -> network scale).
Web form: https://retinar.com.ar