Article · Clinical workflows

DICOM in the patient chart vs a separate viewer: why imaging architecture matters

·7 min read·Oralstack team

Most dental clinics still keep imaging on a separate desktop app — Romexis, Dolphin, the sensor manufacturer's native software, or a folder on the front desk PC named with the patient's last visit date. That feels normal because it's the way dental imaging has worked for two decades. It also costs 3–5 minutes per visit hunting for the right radiograph, and a meaningful percentage of treatment planning errors that come from not having the chart and the image visible at the same time.

This article is for the clinic owner or clinical lead deciding how seriously to take in-chart imaging when evaluating PMS options. The short version: this is the single most consequential clinical workflow decision in a PMS migration.

The two architectures

Stripped to essentials, dental imaging is built on one of two models.

Parallel-folder (legacy)

The patient's images live in a separate system from the patient's chart. Often a folder on a local PC, sometimes a dedicated PACS server, sometimes the sensor vendor's native software. Capture happens in that system; viewing happens in that system; the chart in the PMS knows the image exists only as a reference (or sometimes not at all).

This is how Plato + Romexis works in most Singapore clinics today. It's how Dentrix + Dexis works. It's the default because the PMS and the imaging vendor were built by different companies that never integrated deeply.

In-record (modern)

Images live against the visit in the patient record. The chart UI renders them inline alongside conditions, notes, and treatment plan. Sensor capture writes directly to the active visit. There's one audit log that covers chart events and image events together.

This is what “DICOM in the chart” actually means — not that DICOM is supported (most systems support DICOM at the protocol level), but that the architecture treats imaging as a first-class part of the patient record, not a parallel attachment.

What “in the chart” means in practice

Four characteristics distinguish a real in-record imaging workflow from one that just has DICOM support:

  • The DICOM file attaches to the visit, not a date-stamped folder. When you open the visit a year later, the radiographs are right there.
  • The chart UI renders the image inlinenext to the tooth-level conditions and treatment plan. You don't alt-tab to a separate window.
  • Sensor capture writes to the active visitin real time. Not “import later” or “dragged into the chart afterwards.”
  • One audit log covers both chart and image events — view, annotate, replace, delete. Important for PDPA and for any audit trail.

Why this matters operationally

The case for in-record imaging is usually argued in clinical-quality terms (better treatment planning, fewer missed lesions). Those are real, but the operational case is concrete and easier to measure.

Time saved per visit

A typical workflow pause when imaging lives in a parallel system: open patient record in PMS, alt-tab to imaging app, search by patient ID, find the most recent radiograph, alt-tab back, mentally cross-reference. 3–5 minutes per visit, conservatively. For a 3-chair clinic doing 24 visits a day, that's 1–2 hours a day just on image hunting.

Treatment planning quality

When the chart and the image are visible on the same screen, clinicians catch things they otherwise miss — caries adjacent to a condition already being treated, an unrelated finding that gets a watch annotation. When you have to alt-tab, the cross-reference sometimes doesn't happen. Hard to quantify, but every clinical lead has stories.

Audit + chain-of-custody

For PDPA-relevant clinics, image events are patient-data events. A unified audit log makes “who viewed this radiograph?” a one-query answer. A parallel imaging system requires combining logs across two systems, which often means in practice you can't answer the question at all.

Sensor capture latency

With sensor-bridge integration to the PMS, capture-to-display is well under 5 seconds. With a parallel imaging app that has to be manually pointed at the right patient, the same flow is 30–60 seconds and includes a manual confirmation step where the image could end up under the wrong patient. Misfiled radiographs are a real failure mode.

Three things to look for

If you're evaluating a PMS for in-record imaging, three checks separate the real implementations from the marketing:

  • Sensor-bridge supportfor the brands you actually use — Carestream, Dexis, Sopro, Schick, Planmeca. Generic “DICOM-compatible” isn't the same as a working sensor bridge. Ask for a demo of capture flow with your specific sensor model.
  • DICOM C-STORE / C-FINDfor legacy interop. You'll still want to receive images from external referrers (orthodontists, oral surgeons, PACS) and send images to viewers like OHIF for second opinions. C-STORE/C-FIND is the standard protocol for this; if a system can't speak it, it can't interop.
  • In-chart annotation tools that write back to the visit — pan, zoom, rotate, ruler, pen. Annotations that vanish when you close the image, or that don't write to the visit record, are a tell that the imaging is bolted on rather than integrated.

What to do next

Audit your current imaging hunt time. The honest answer for most clinics is “I don't know — let me time it for a day.” That's the right experiment. If it's under 30 seconds per visit, your current setup is probably fine. If it's 3+ minutes, the case for in-record imaging is already paying back.

See the Oralstack imaging workflow for the in-record implementation, or the integrations page for current sensor-bridge coverage.

See how Oralstack handles this in production.

A 30-minute demo walks the front desk and a clinician through every workflow on a sample dataset that mirrors a typical Singapore clinic.