sumazou Terminal — DICOM Conformance Statement

0. Scope

The product implements no DICOM network services. It is a Media Storage Application that acts solely as a File-Set Reader (FSR) for interchange media (CD/DVD). The PS3.2 "Network AE Specification" sections are therefore not applicable, and the "Media Interchange AE Specification" is the core of this document.

1. Conformance overview

1.1 Network services

Not applicable. No DIMSE services (C-STORE / C-FIND / C-MOVE / C-GET / C-ECHO), no DICOMweb (WADO-RS / QIDO-RS / STOW-RS), no WADO-URI, no JPIP. Production terminals run fully offline (no hospital LAN, no internet).

The communication between the terminal and the patient's smartphone is a proprietary protocol unrelated to DICOM and is not a DICOM Application Entity.

1.2 Media interchange

2. Implementation model

2.1 Application data flow

 [Patient inserts a DVD/CD]
        │
        ▼
 ┌────────────────────────────────────────────────────────────────┐
 │ sumazou terminal (Media Import AE = File-Set Reader)           │
 │  1. Read the medium (read-only)                                │
 │  2. Identify the DICOM Part 10 files on it                     │
 │  3. Group them into study / series / instance                  │
 │  4. Copy each original file unmodified into a transfer package │
 │     and render a preview image for image objects               │
 │  5. Transfer the package to the patient's smartphone           │
 │  6. Delete all temporary data                                  │
 └────────────────────────────────────────────────────────────────┘
        │
        ▼
 [Patient's smartphone] (receives, stores, displays)

2.2 Application Entity

The product has exactly one AE and no AE Title (no network presence).

2.3 Sequencing

One session handles one medium and transfers to exactly one smartphone, paired via a confirmation code. If the patient cancels or removes the disc during reading, processing stops and the temporary data is deleted.

3. Media Interchange AE specification

3.1 Role

File-Set Reader (FSR) only.

3.2 Requirements on the medium

The DICOMDIR is used as the marker of a DICOM medium; grouping into studies, series and instances is derived from the files themselves, so a medium remains readable even when its DICOMDIR records are incomplete.

3.3 SOP Classes

Inclusion in the transfer package does not depend on the SOP Class: every DICOM file on the medium is transferred unmodified, including private SOP Classes.

There is no restriction on Modality (0008,0060).

3.4 Transfer Syntaxes

Header parsing (grouping and inclusion in the package) works for every standard transfer syntax. The table below states whether a preview image can be rendered from the pixel data. "Verified" means confirmed with test media on a production terminal.

Files in a transfer syntax marked "No" are still transferred unmodified. No transfer-syntax conversion (transcoding) is performed.

3.5 Character sets

Specific Character Set (0008,0005) is honoured for all repertoires defined in PS3.3, including the combinations common on Japanese media:

For Patient's Name (0010,0010) the ideographic (kanji) component is used for display on the smartphone when present, otherwise the alphabetic component. Patient identifiers are never shown on the terminal screen (§5).

3.6 Attributes used

Missing Instance Number / Series Number are ordered as 0; a missing Study Date is treated as empty.

3.7 Limits

Media exceeding any of the following are rejected as a whole.

These limits are fixed and cannot be changed at the installation site.

4. Preview images (format conversion)

Preview images are a format-conversion output for viewing and storing on a smartphone. Diagnostic image quality and grayscale fidelity are not guaranteed.

5. Security and privacy behaviour

• Media are read read-only; software on the medium is never executed.
• Patient's Name, Patient ID and Patient's Birth Date never appear on the terminal screen or in terminal logs. Patient ID and Birth Date are not written to the transfer package.
• UIDs inside the original DICOM files are unchanged. The package metadata carries them only in hashed form.
• All temporary data of a session (the medium image and the package) is deleted when the transfer completes, on any error, and at every start-up.
• Media containing more than one patient are transferred normally; the smartphone lists studies by patient name.

6. Terminal output (outside the DICOM standard — reference information)

• Every original DICOM file is transferred to the smartphone byte-for-byte unmodified: no transfer-syntax conversion, no attribute addition / removal / de-identification, no regeneration of the Part 10 header. A per-file SHA-256 accompanies the package so the smartphone can verify integrity.
• The smartphone app does not interpret DICOM. The patient can export the original files as-is to other apps or storage (this is not media creation, i.e. not an FSC).

7. Verification

The transfer-syntax, character-set and non-image behaviour in this document is verified by an automated regression suite that runs on every software change, and by reading a coverage disc (CD-R with one series per transfer syntax, photometric interpretation and edge case) on a production terminal.

8. Not supported

• All DICOM network services (DIMSE, DICOMweb, WADO, JPIP)
• Media creation or update (FSC / FSU); DICOMDIR generation or update
• Media-level security (PS3.15 Media Security) or media protected with Encapsulated CMS
• Transfer-syntax conversion, attribute editing / de-identification, Part 10 header regeneration
• Previews of frames other than the first; decoding of video transfer syntaxes
• Rendering of Overlay / Curve / Presentation State / Structured Display
• Measurement, annotation, WW/WL manipulation, MPR, 3D and similar image processing (deliberately not implemented: the product is not a medical device)
• Semantic interpretation of private attributes and private SOP Classes (transferred as opaque bytes)

9. Extensions / specialisations / privatisations

None. No private SOP Classes, private transfer syntaxes or private attributes are defined.

10. Configuration

No site-configurable settings affect DICOM reading.