Dolphin Imaging Integration: Orthodontic IT Guide

A useful integration map begins with the clinical workflow rather than a software inventory. Orthodontic staff may create or update a patient in a practice-management system, acquire photographs or radiographs, review 2D or 3D records, perform treatment-planning tasks, share records with another system, and return to the administrative workflow. Every transition between those steps can depend on a configured integration, patient-matching rule, workstation component, network path, local device, cloud service, or user account.

Dolphin's current product information spans imaging, management, cloud, and web-based offerings. Patterson also describes Dolphin Imaging and Management as specialty software with 2D/3D imaging, practice-management, mobile/cloud options, and third-party connections. That breadth is why the phrase 'Dolphin integration' is too vague for a deployment plan: document the exact products, modules, devices, locations, and third-party workflows the practice expects to use.

Traditional Dolphin environments can involve locally installed software, local workstations, imaging devices, practice servers or data locations, and site-specific network dependencies. Dolphin Cloud Subscription is currently described by Dolphin as a hosted option that removes the need for a local Dolphin server and includes automatic backup of the hosted Dolphin environment. Dolphin Blue is a browser-based platform hosted in Microsoft cloud infrastructure and combines web-based practice and imaging capabilities.

Those options do not eliminate every local responsibility. Even with a hosted or browser-based platform, the practice still owns reliable workstations, monitors, browsers or required local components, imaging hardware, account lifecycle, local network quality, internet access, endpoint security, printing, and other applications that remain outside the hosted Dolphin service. Architecture should be confirmed before deciding which servers, backups, or local components can actually be retired.

Use current vendor documentation for the exact product before buying hardware. Dolphin's public Minimum System Requirements PDF currently available from its website is marked revision 07/24. That document can be useful for understanding the published workstation, server, display, and accessory expectations, but its revision date is also a reminder not to present an old requirement sheet as a new 2026 product version.

Before an upgrade or refresh, confirm the latest requirements with Dolphin support or the current vendor documentation and compare them with the practice's actual computers. Record operating-system edition, processor, memory, graphics capability, storage, monitor arrangement, acquisition-device connections, and any local components used by imaging or practice-management integrations. A workstation can meet a generic office standard and still be a poor fit for image-heavy orthodontic workflows.

The answer depends on architecture. A local imaging workflow may be sensitive to LAN performance between acquisition workstations and data storage. A hosted or browser-based workflow shifts more importance to internet reliability, DNS, firewall policy, Wi-Fi quality, and the path between the office and the cloud service. Multi-office organizations also need consistent network standards so one location does not become the exception that generates recurring support problems.

Dolphin publishes a specific recommendation for Dolphin Blue: its public page recommends, for best performance, at least 50 Mbps download and 5 Mbps upload and an emergency internet source. Treat that as product-specific vendor guidance for Blue, not a universal bandwidth rule for every Dolphin product. Test the actual workflow over the office's primary and backup internet paths instead of relying on a speed-test result alone.

Patient identity is one of the highest-impact integration points. If demographics are entered differently between the practice-management platform and imaging environment, staff can create duplicate patients, attach images to the wrong record, or spend time manually reconciling information. The go-live plan should define which system is the source of truth for patient creation and which fields are exchanged or synchronized.

Test with representative records before production. Verify new-patient creation, updates to names and contact details, unique identifiers, inactive or transferred patients, and any workflow that launches Dolphin from another application. The test should confirm what staff see when records do not match and which team owns correction. A technically successful connection is not enough if the patient identity workflow is ambiguous.

Inventory every acquisition source: intraoral cameras, digital radiography, panoramic or cephalometric systems, CBCT, photography, scanners, and imported external records. Confirm which workstation talks to each device, which software or driver is required, where the resulting files are stored, and how the record becomes available to the clinicians who need it.

For 3D workflows, test realistic file sizes and treatment-planning tasks rather than one small sample. Verify image opening time, manipulation performance, display behavior, import/export, and what happens when the network is under normal office load. Device compatibility should be confirmed against the current Dolphin and hardware-vendor documentation; do not assume a device is supported because an older office or an older Dolphin release used the same brand.

Dolphin and Patterson both describe connections with third-party dental-specialty solutions, but a broad integration statement is not proof that a specific feature, version, country, device, or workflow is supported today. Older public integration brochures can remain indexed for years, so integration counts from an old PDF should not be used as a current 2026 compatibility claim.

For each dependency, record the vendor, product, version, direction of data flow, authentication method, local bridge or service if any, and the business process that fails when the integration is unavailable. Obtain current confirmation from the relevant vendors for critical workflows. Then test the exact action the staff performs: launch, synchronize, import, export, send, receive, or attach—not merely whether two products appear on a compatibility list.

Start by separating vendor-hosted data from everything still owned by the practice. A cloud subscription may include backup for the hosted Dolphin environment, but the office can still have local photographs, exports, documents, device software, configuration data, network settings, and other systems that require independent protection. A backup inventory should identify each data set and the party responsible for restoring it.

Recovery testing should prove more than file availability. Choose a representative restore scenario and document how the practice would regain access to Dolphin, imaging records, related applications, credentials, and network services. If recovery depends on vendor support, record the support path and account ownership. For local data, verify that backups are isolated from ordinary user access and that the practice can restore the data into a usable workflow.

A dental or orthodontic practice should include Dolphin systems, endpoints, cloud services, vendors, integrations, and data flows in its broader HIPAA security risk analysis. The software platform itself does not make a practice HIPAA compliant. User accounts, access changes, workstation security, encryption, logging, backups, incident procedures, and vendor relationships all remain part of the operating environment.

Define ownership explicitly. Dolphin support should own product-specific defects and supported configuration questions. The practice's IT provider can own the surrounding network, endpoints, identity, security tooling, backups outside the vendor service, and cross-vendor troubleshooting. When an issue crosses boundaries, one party should coordinate the incident so staff are not forced to act as the technical dispatcher between multiple vendors.

Run an end-to-end rehearsal with a test or approved training record. Create or synchronize the patient, acquire representative images, confirm they appear under the correct patient, open them from the clinical workstation, use the required treatment-planning or presentation workflow, test any external handoff, and confirm the record remains available after logout and from the roles that need it.

Then test the failure paths: secondary internet if applicable, a workstation restart, a user who lacks permission, a temporary integration outage, and the support escalation process. Document the result, the vendor contacts, the current requirements used, and any exception that still needs remediation. A repeatable go-live checklist is more valuable than a one-time successful installation.