DICOM Integration in Ophthalmology
What to Look for in an Image Management System
Overview
If you are evaluating an image management system for an ophthalmology practice, DICOM will come up early and often. Every vendor will tell you they support it. That is precisely why it is a weak place to stop your evaluation. DICOM support is a starting question, not a finishing one, and the gap between “supports DICOM” and “integrates cleanly into your workflow” is where most of the real differences between systems live.
This guide explains what DICOM is, how it interacts with an EHR, how image management differs from a traditional PACS, what DICOM does and does not solve, and the specific questions worth asking before you choose a system. It is written to be useful to an ophthalmologist or practice executive while holding up for an IT or clinical systems leader.
What is DICOM in ophthalmology?
DICOM, which stands for Digital Imaging and Communications in Medicine, is the recognized standard for the format and exchange of medical images and their associated data. It was opened to all medical specialties in the 1990s and is maintained by the Medical Imaging Technology Alliance, a division of the National Electrical Manufacturers Association.1 In ophthalmology, the American Academy of Ophthalmology has helped define agreed-upon imaging definitions and has urged both imaging device and image-archive manufacturers to implement DICOM, because standardized formats are what make images shareable and comparable across systems.2
DICOM matters because it establishes a common language for images and the data embedded in them, including patient demographics and technical details.3 Without a shared format, images become silos that are difficult to move between systems or practices.
How DICOM works with an EHR
At a practical level, DICOM is not only a file format. It also defines services that let systems coordinate imaging. The most important of these for everyday workflow is the modality worklist.
A modality worklist lets patient and order information flow from the practice’s systems to the imaging device, so the technician does not re-key the patient’s name and details at the instrument. The IHE Eye Care technical framework, which is built on DICOM and HL7, describes several real-world models for how this is arranged. In one, the EHR itself supports the DICOM modality worklist and integrates with a separate image archive. In another, the EHR supports the worklist and also handles image storage and display without a separate archive. In a third, the EHR speaks only HL7 and relies on the image archive to provide the worklist.4 These are defined, standards-based arrangements, not custom one-off interfaces.
The AAO’s IHE Eye Care guidance is explicit about what good integration achieves: it removes the need to enter patient information at the instrument, eliminates searching for mismatched studies between the record and the archive, and makes images immediately available for viewing.5
PACS vs image management vs EHR-integrated imaging
These terms are often used loosely, and the differences matter when you evaluate systems.
| Approach | What it is | Where images live | Typical workflow effect |
|---|---|---|---|
| PACS (Picture Archiving and Communication System) | A centralized image archive and display system, historically from radiology | In a dedicated archive, viewed in a separate PACS application | Reliable storage, but the physician often works in a system separate from the EHR |
| Standalone image management | Software that stores and displays images, sometimes device- or vendor-specific | In a dedicated system, separate from the record | Consolidates images but can still sit outside the clinical workflow |
| EHR-integrated imaging | Imaging brought into the patient record itself | Accessible within the EHR; no separate archive required in some models | Physician reviews and documents in one place, reducing system-switching |
The IHE Eye Care models make clear that a practice can operate with a PACS or, in other models, with the EHR handling storage and display directly.4 Neither is inherently wrong. What matters is whether the resulting workflow keeps the physician in one place or forces them into a separate application during the encounter.
What DICOM does not solve
This is the section most vendor content skips, and it is the most important one for a buyer.
DICOM support does not guarantee that two systems will work together cleanly, because compliance with the standard is voluntary and is interpreted inconsistently. A Verana Health analysis of imaging files from two manufacturers, both identified as DICOM compliant, found that while most metadata could be matched to synonymous terms, 43 tags could not be reconciled between the two vendors.3 That is a concrete illustration of a general truth: two systems can each legitimately claim DICOM support and still fail to integrate without additional work.
Adoption is also incomplete. Despite decades of effort, and even after the FDA formally recognized the DICOM standard for ocular imaging devices in April 2022, full and consistent implementation across ophthalmic devices remains a work in progress, which is why the AAO, NEI, FDA, and ONC continue to push for it.6 The AAO’s guidance to practices is to ask manufacturers directly about their DICOM conformance rather than assume it.6
The lesson for evaluation is simple. Do not ask only whether a system supports DICOM. Ask how it handles the messy reality of multiple vendors, inconsistent conformance, and legacy equipment.
The role of IHE Eye Care
DICOM defines the image and its services. IHE Eye Care defines how the systems in an eye care practice should use those services together. The IHE Eye Care domain was formed in 2005 and is sponsored by the American Academy of Ophthalmology, with a mission to help practice systems communicate patient information efficiently.7 When a vendor supports IHE Eye Care profiles, it is committing to a defined, testable way of interoperating rather than to a private integration you cannot evaluate.
IHE also gives buyers a tool. Vendors document which IHE actors and profiles they support in an IHE Integration Statement, and the AAO’s own buyer guidance encourages practices to ask for these and to expect products to support one or more IHE Eye Care profiles.8 Asking for an integration statement is a fast way to separate systems that conform to shared standards from those that rely on custom interfaces.
What to look for in an ophthalmology image management system
Use these criteria, which follow from the workflow realities above rather than from any single product’s feature list.
- DICOM and legacy support. Does the system handle both current DICOM devices and older or non-DICOM imaging you already own?
- Cross-vendor connectivity. Can it bring in images from the mix of device brands you actually run, without a separate integration project per device?
- Modality worklist. Does it pass patient and order data to devices so technicians do not re-key at the instrument?4
- Images in the clinical workflow. Can the physician review and document imaging inside the patient record rather than in a separate application?
- Prior-study access and comparison. How easily can historical studies be retrieved and compared to assess progression?
- Multi-location access. Are images reliably available across every site, without cumbersome remote-access workarounds?
- Deployment flexibility. Does it support the deployment model your infrastructure and security posture require?
- Standards conformance evidence. Will the vendor provide an IHE Integration Statement documenting the profiles and actors it supports?8
Questions to Ask During an Image Management Demo
Bring this list to any vendor demonstration. Each question is technically defensible and maps to a real workflow need.
- Which of our current diagnostic devices have you already integrated with?
- How do you support legacy or non-DICOM devices we still use?
- Does your implementation use a DICOM modality worklist so demographics are not re-entered at the device?
- Where exactly does the physician access the image, inside the patient record or in a separate viewer?
- How are prior studies retrieved and compared against the current study?
- How does image access work across our locations, and does it require a VPN or remote desktop?
- What happens operationally when we add a new device or a new modality?
- Which IHE Eye Care profiles and actors do you support?
- Can you provide your IHE Integration Statement?
Common integration mistakes
- Stopping at “DICOM supported.” As the metadata evidence shows, that phrase does not guarantee two systems will interoperate cleanly.3
- Overlooking legacy and multi-vendor equipment. A solution that only handles new, single-vendor DICOM leaves real gaps in most practices.
- Accepting custom interfaces without standards conformance. Private integrations are harder to maintain and evaluate than standards-based ones; ask for the IHE Integration Statement.8
- Treating the physician’s application-switching as unavoidable. Whether imaging appears in the record or in a separate viewer is a design choice, and it directly affects encounter workflow.5
How Optivate addresses these criteria
Measured against the criteria above, Optivate is built specifically for ophthalmology and supports both DICOM and legacy imaging across device vendors without per-device integration fees. It brings images into the patient record so physicians review and document in one place, provides historical progression comparison, and delivers access across locations without VPNs or remote desktops, with cloud, on-premise, and hybrid deployment options.9 Optivate’s imaging heritage is rooted in the ophthalmic interoperability work coordinated through the AAO-sponsored IHE Eye Care framework, and the company publishes an integration statement documenting how its systems conform to those profiles.9 It has also been named Best in KLAS for Ophthalmology, a recognition of the broader platform rather than a category award specific to image management.9
To see these capabilities in detail, explore Optivate’s image management for ophthalmology or request a demonstration. For the broader strategic case, the guide on how to end the diagnostic workflow bottleneck covers assessment and economics, and if you want the operational context behind all of this, see how disconnected imaging quietly slows an ophthalmology practice. The full path from capture to chart is also shown in Optivate Image Management: From Device to Chart in One Connected Workflow.
Frequently asked questions
DICOM (Digital Imaging and Communications in Medicine) is the recognized standard for the format and exchange of medical images and their embedded data. In ophthalmology, the AAO has helped define standardized imaging definitions and urges device and archive manufacturers to implement DICOM so images are shareable across systems.2
Beyond a file format, DICOM defines services such as the modality worklist, which passes patient and order data from the practice’s systems to the imaging device so it is not re-keyed at the instrument. IHE Eye Care defines standards-based models for how the EHR, image archive, and devices coordinate.4
A PACS is a centralized image archive and viewer, historically from radiology, in which images are typically viewed in a separate application. EHR-integrated image management brings images into the patient record itself, so the physician reviews and documents in one place rather than switching systems.4
Yes. Using DICOM services and IHE Eye Care profiles, patient and order data can flow to devices and images can flow back into the record, with defined real-world models for practices that use a PACS and for those that do not.4
Look for DICOM and legacy support, cross-vendor connectivity, modality worklist, images available inside the clinical workflow, easy prior-study comparison, reliable multi-location access, deployment flexibility, and a vendor willing to provide an IHE Integration Statement.8
It does not guarantee clean integration between systems, because compliance is voluntary and interpreted inconsistently. Two DICOM-compliant vendors can still have irreconcilable metadata differences, so DICOM support alone does not equal workflow integration.3
Sources / References
1. American Academy of Ophthalmology. Image Sharing: Making Interoperability a Reality. EyeNet Magazine. 2025. https://www.aao.org/eyenet/article/imaging-interoperability-DICOM
2. American Academy of Ophthalmology. Recommendations for Standardization of Images in Ophthalmology. Ophthalmology. 2021. https://www.aaojournal.org/article/S0161-6420(21)00164-0/fulltext
3. Verana Health. Importance of Adopting Imaging Standards in Ophthalmology. 2023. https://veranahealth.com/importance-of-adopting-imaging-standards-in-ophthalmology/
4. IHE International. Unified Eye Care Workflow. IHE Wiki. https://wiki.ihe.net/index.php/Unified_Eye_Care_Workflow
5. American Academy of Ophthalmology / IHE Eye Care. IHE Eye Care User’s Handbook. 2013. https://www.aao.org/assets/769d375b-389c-42fd-95a9-6cdcdd82f98b/635194232551870000/ihe-eye-care-users-handbook-2013-final-pdf
6. Goetz KE, Reed AA, Chiang MF, et al. Accelerating Care: A Roadmap to Interoperable Ophthalmic Imaging Standards in the United States. Ophthalmology. 2023. https://www.aaojournal.org/article/S0161-6420(23)00713-3/fulltext
7. IHE International. Eye Care. IHE Domains. https://www.ihe.net/ihe_domains/eye_care/
8. American Academy of Ophthalmology. Buying an Integrated Electronic Health Record (IHE Overview). https://www.aao.org/assets/0c3f06df-00b3-483e-98ce-4844702fde9f/635194232506930000/aao-ihe-overview-final-pdf
9. Optivate. Image Management. 2026. https://www.optivatehealth.com/image-management/
Keep reading