Ultrasound USB DICOMDIR Viewer No Study: Four Layers

An "ultrasound USB DICOMDIR viewer no study" ticket arrives dressed as a hardware story: files on the drive, nothing in the list.

Four layers sit between those two facts — media, naming, index, receiver — and the order you test them decides whether the next test still has evidence to work with.

The temptation is to skip straight to the import button, because that is where the failure shows. That button is also the first step that can change the thing you are about to measure.

Write-block the drive before anyone double-clicks it

The first hour belongs to capture, not repair. An import can drop a lock file, rewrite a directory, or leave a partially written index on media the application is allowed to write.

Capture in this order, and stop if a step contradicts the last one:

1. Photograph the drive label, the port, and the export-completion message on the console screen.
2. Dump the full tree with sizes and timestamps to a text file, not a screenshot.
3. Hash the tree and put the hash in the ticket before anything opens it.
4. Copy the whole tree to working storage and confirm the copy hash matches.
5. Import only from the copy. Keep the original untouched until the ticket closes.

If step 4 reports read errors or the drive disconnects mid-copy, you have a media-layer answer and the viewer is not the question yet.

Four layers, one symptom, four owners

Most of the wasted money in this fault lives between two departments: imaging reports "the viewer is broken", IT reports "the files are there". This table is the instrument that ends that exchange.

Layer	What the listing shows	The non-destructive test	Who signs
Media	Files present; copy stalls, retries, or slows near the end	Copy twice, compare hashes	Clinical engineering
Naming	Random-looking names, no extension, one folder per series	Ask the exporter what it writes; never rename to test	Export procedure owner
Index	No directory file, an empty one, or references to paths that are not there	Indexed import from the copy, then compare referenced list to actual tree	PACS / viewer owner
Receiver	The same copy opens on another application	Import the copy on a second viewer before touching the console	PACS / viewer owner with IT

Read it top to bottom. Each row is cheaper than the one below it, and the bottom row is the only one where a purchase might follow.

What a file listing can never prove

A drive that reports hundreds of files and gigabytes of data has told you almost nothing about the examination.

DICOM puts one directory file with the reserved identifier DICOMDIR in every File-set, and a File-set without it does not conform (PS3.10 §8.1 and §8.6, reviewed 2026-11-06).

The directory may also be left empty where an environment does not need it, so an empty one is not automatic corruption (PS3.10 §8.6, reviewed 2026-11-06).

For the ultrasound media profile the directory has to carry patient, study, series and image records and reference the objects that profile defines.

The profile's note puts that directory file in the media root (PS3.11 §C.3.3, reviewed 2026-11-06).

Names carry no meaning. A File ID holds one to eight components of one to eight characters, and the standard attaches no semantics to either (PS3.10 §8.2, reviewed 2026-11-06).

So a missing .dcm suffix proves nothing, and renaming a file is cosmetic, not conversion. A viewer that resolves the directory and a viewer that scans loose files are answering two different questions.

Read the second-workstation test as a matrix

"The other computer opens it" is quoted far more often than it is understood, because it arrives without the action that produced it. Ask for the action, then place the result here.

What the second viewer did	What it eliminates	What stays open
Listed the study from the directory file	Index intact, objects readable	First viewer's version, licence, import mode or policy
Showed nothing until a folder scan	The index, not the objects	Whether the index was ever written, and by which export
Showed stills but no clips	Media and index	Object-class or codec support on the first viewer
Showed nothing, either route	Receiver layer	Media read integrity — go back to the hash

The third row is the one that gets misread as a storage problem. Still images and cine loops are separate objects and can need separate support.

Export habits that outlive the operator who set them

Export mode is rarely a decision anyone made this week. It is a preset that survived logout.

Three habits produce most of these tickets.

The first is a multimedia export that writes viewable images rather than a DICOM file-set. It looks correct in a file manager and can never satisfy an indexed import.

The second is a partial copy: someone drags the image folder and leaves the directory behind, or copies the directory and leaves the images.

The third is merging.

Two exports on one drive is a merge whether or not anyone called it that.

Whether a second write replaces the index, appends, or collides on names is a property of that console's software, not something the standard fixes — ask what was done rather than assuming a dialog appeared.

Our rule for site work: no renaming, no reorganisation, no "just the study folder" — until the ticket records that the original was already broken.

Do the arithmetic before anyone calls it recovered

Completeness is a count, not an impression. Four lines, all obtainable on site:

expected_objects = stills_planned + cine_planned + reports_planned
readable_objects = objects that import AND display
coverage         = readable_objects / expected_objects
frames_seen      = sum of frames in every multiframe object

A fictitious example: 180 stills, 6 cine loops and 1 measurement report were selected at export. The import shows 180 stills and 6 cine loops. Coverage is 186/187, or 0.9947.

That reads as finished and is not. The report is a different object with a different decoder, and a directory rebuild will never add it back.

The stop rule is simple: coverage below 1.0 keeps the ticket open with the missing object named by class. A percentage is not an acceptance criterion, and disk usage is not a count.

When the console, not the file-set, is the fault

Some evidence does justify opening the machine. Four observations, and no others in this list, are enough to escalate from media to hardware:

• A known-good drive is not enumerated at all on that port.
• The same drive exports normally from a second console of the same model.
• Export aborts mid-write with a scanner fault code, on more than one drive.
• The fault follows the port, not the drive.

An empty study list appears nowhere in those four observations. Index and receiver faults do not damage boards, and a new board does not repair a directory.

A transducer fault reads differently: element dropout, banding, failed articulation, a leak test that will not hold. None of those empties a viewer's list, and re-exporting will not clear any of them.

We repair transducers and supply parts, so we have a commercial interest in this distinction and still insist on it.

Our catalogue does carry console-side items such as a GE USB hub distribution board (GE KTZ301908_3, reviewed 2026-11-06). A part existing is not a diagnosis.

Scope sits at probe repair and ultrasound parts. The published process is a free 24-hour evaluation, OEM-standard restoration, and an ultra-long warranty on every repair (repair process, reviewed 2026-11-06).

Two checklists before anyone escalates

Imaging department:

• Export mode recorded as DICOM media, not multimedia or print-to-file.
• Export-completion message photographed before the drive is removed.
• Drive handed over with no files renamed, moved or deleted.
• Expected contents listed in words: stills, cine, reports, measurements.
• The operator who exported named, with the time and the console used.

IT and clinical engineering:

• Tree listing and hash stored with the ticket.
• Copy verified against the original hash.
• Directory file present, empty, or absent — recorded as one of the three.
• Import action named: indexed, folder scan, or drag-and-drop.
• Second viewer tested on the copy, with product and version noted.

What an actionable service request contains

If the checks end at hardware, send five things: exact model and software version, the export mode and its completion message, the directory file's status, the failing object classes, and the hash of the original tree.

Leave patient identifiers out. A filename, a screenshot and a directory listing can all carry them, and an empty list does not make a drive anonymous.

State plainly what was observed and what is suspected. A port or board labelled defective because a viewer listed nothing is how a media ticket becomes an invoice.

Sources and verification notes

• DICOM PS3.10 §8.1, File-set and the single DICOMDIR — reviewed 2026-11-06.
• DICOM PS3.10 §8.2, File IDs, components and absence of semantics — reviewed 2026-11-06.
• DICOM PS3.10 §8.6, reserved DICOMDIR file ID and optionally empty content — reviewed 2026-11-06.
• DICOM PS3.11 §C.3.3, STD-US directory records and media-root guidance — reviewed 2026-11-06.
• GEPROBE repair process — reviewed 2026-11-06.
• GEPROBE ultrasound parts catalogue — reviewed 2026-11-06.

Object counts, drive sizes, ports and model examples above are fictitious illustrations of the method. No patient data is included.

Whether a specific console writes a directory file, and what its merge behaviour is, must be confirmed against that system's own documentation. We did not test any exporter for this article.