DICOM Conformance Statement

DICOM Conformance Statement — DDSALLY

This statement follows the structure of DICOM PS3.2 so it can be compared with other vendors' statements, and is written so a dental office or an integrating vendor can tell in a few minutes what DDSALLY will accept, what it keeps, and what it gives back. Everything in it describes the code as deployed; where DDSALLY falls short of a capability a reader might expect, the gap is stated rather than left out (section 7).

AllyVue is not FDA-cleared. AllyVue Cloud and AllyVue Web are available to providers for viewing; the full AllyVue is in use by selected testers. Nothing in this statement is a claim of diagnostic performance.

1. Overview

DDSALLY is a web service plus an optional agent installed in the office. The web service implements no classic DIMSE network services (no C-STORE, C-FIND, C-MOVE); it receives DICOM instances over HTTPS using the DICOMweb STOW-RS service, by file upload from a browser, and from the DDSALLY Agent, which sends STOW-RS on the office's behalf. The DDSALLY Agent for Windows is a Storage SCP and Verification SCP (section 3.7): a modality or imaging program can send a study to it by C-STORE as if to a PACS, and the agent forwards the instances unchanged over STOW-RS. The agent also watches an export folder, which remains the default. It stores the received files unchanged, displays them in a browser, answers QIDO-RS searches and WADO-RS retrieves over the same HTTPS API, and can export the original files as DICOM media and a Structured Report of the measurements made in the viewer.

Table 1-1. Network services

Table 1-2. Objects created by DDSALLY

2. Implementation model

2.1 Application data flow

 Acquisition PC                    DDSALLY API (AWS)                     Browser
 ┌──────────────────┐   STOW-RS    ┌──────────────────────┐   HTTPS    ┌────────────────┐
 │ Imaging software │  (HTTPS,     │ Ingest AE            │  (JSON,    │ AllyVue Cloud  │
 │  exports DICOM   │   ingest     │  parse header only   │   signed   │  (server MPR)  │
 │        ↓         │   key)       │  store bytes as-is   │   URLs)    │ AllyVue Web    │
 │ DDSALLY Agent    │ ──────────▶  │  group by Study UID  │ ◀────────▶ │  (WebGL 2)     │
 └──────────────────┘              │ Storage (S3, KMS)    │            │ Download of    │
                                   │ SR Creator AE        │            │  original files│
 Browser upload ─────────────────▶ │ (TID 1500 on demand) │            └────────────────┘
 (presigned S3 PUT, then finalize) └──────────────────────┘

Three logical Application Entities (AEs) exist, all inside one service:

2.2 Functional definition of each AE

Ingest AE. On a STOW-RS request it splits the multipart/related body, parses each application/dicom part up to but not including Pixel Data, requires Study Instance UID and SOP Instance UID, and writes the part's exact bytes to encrypted object storage under a key derived from the SOP Instance UID. A resent instance overwrites itself, which is how duplicates are collapsed. The response is a DICOM JSON dataset per PS3.18 10.5 listing referenced and failed instances. On a browser upload the same header extraction runs after the upload completes; a file is treated as DICOM if its media type is application/dicom, its extension is .dcm/.dicom, or bytes 128–131 are DICM (so renamed files such as Carestream .rvg are recognised). A ZIP archive is probed for DICOM entries and treated as a series.

Viewer AE. Decodes pixel data from the stored originals, applies Rescale Slope/Intercept, and renders. For large volumes it writes two derived display caches: a gzipped signed 16-bit volume with JSON geometry (not DICOM), and a reduced-resolution DICOM display copy for memory-limited devices (section 3.9). Both are regenerated from the original and are never offered as exchange objects.

Agent Storage AE. (In the DDSALLY Agent, not the web service.) When the office turns the DICOM receiver on, the agent listens on a configurable port under a configurable AE title, accepts associations proposing any Storage SOP Class in any transfer syntax, and writes each received instance to disk exactly as received, with the negotiated File Meta Information, as <SOPInstanceUID>.dcm in a folder per Study Instance UID. A study is considered complete when no instance has arrived for a configurable quiet period (default 30 s) and no association is still storing into it; it is then sent to the Ingest AE over STOW-RS by the same path as an exported folder. A resent SOP Instance replaces the file of the same name.

SR Creator AE. On request, builds a Comprehensive SR conforming to TID 1500 Measurement Report with one TID 1501 group per numeric measurement (length, angle, area, volume), each with the measuring tool, the value with units, an optional SCOORD3D of the points, and the user's note. The SR references the source study's Study Instance UID and Frame of Reference UID when known. Observer context names the signing clinician and the software.

2.3 Sequencing of real-world activities

An office configures the DDSALLY Agent once (sign in, choose the export folder, optionally turn on the DICOM receiver and point the scanner at it). Its imaging software exports a study to that folder or sends it by C-STORE; the agent waits until the study has been quiet, then sends the study's files in STOW-RS requests of at most 256 MB each, retrying up to five times. The study appears in the office's Images inbox, where it can be viewed, attached to a referral, forwarded to another office, or downloaded.

3. AE specifications

3.1 Ingest AE — STOW-RS provider

3.2 Viewer AE — what can be displayed

3.3 SR Creator AE

3.4 Query/Retrieve AE — QIDO-RS and WADO-RS provider

3.5 Download of originals

GET /files/{id}/download-url returns a short-lived signed URL to the exact bytes received. For a study received over STOW-RS, the download is a ZIP of the instance files (one .dcm per SOP Instance UID). The URL is issued only after the malware scan has cleared the file.

3.6 Export as DICOM media (File-set)

GET /files/{id}/dicom-export and GET /practices/me/incoming-studies/{id}/dicom-export return the same study as a DICOM File-set per PS3.10 and PS3.12: a DICOMDIR at the root and the instances beneath it as PTxxxxxx/STxxxxxx/SExxxxxx/IMxxxxxx (8-character names, no extension), in a ZIP. This is the layout an imaging program's "import from CD/folder" reads. The File-set is built from the stored originals on first request and cached; the response is {status: converting} until it is ready, then a short-lived URL. Instances are written with their original transfer syntax and content; pixel data is never decoded; no attribute is added to or removed from an instance. DDSALLY writes only the DICOMDIR. Directory records carry empty or defaulted values where an instance omits a record key (Study ID, Study Time, Series Number, Instance Number), as PS3.3 F.5 allows. IMAGE, SR DOCUMENT and ENCAP DOC record types are produced according to SOP Class; other instances get IMAGE records. Non-DICOM content of the source (a bundled vendor viewer, for example) is not included. A README.txt is placed beside DICOMDIR for the person opening the ZIP. The same gates apply as to the ordinary download.

3.7 Agent Storage AE — C-STORE and C-ECHO provider

Where. The DDSALLY Agent for Windows, inside the office network. Off by default; turned on in the agent window (More → DICOM receiver).

Association policy. Accepts any calling AE title; the called AE title must match the configured one (default DDSALLY, up to 16 characters). Default port 11112. One association at a time per sender is not required; several may be open. Maximum PDU size is unlimited (offered as 0). Timeouts: ACSE 60 s, DIMSE 120 s, network 120 s. No user identity negotiation, no TLS on the DICOM port — the receiver is intended for a private office LAN, and the installer's firewall rule allows it on Private and Domain network profiles only.

Presentation contexts accepted. Every Storage SOP Class defined in PS3.4 Annex B as known to pynetdicom at build time (including CT, Digital Intra-Oral X-Ray for Presentation and for Processing, Digital X-Ray, Secondary Capture, Encapsulated PDF, Comprehensive SR and the enhanced CT/MR families), each with every transfer syntax pynetdicom lists: Implicit and Explicit VR Little Endian, Explicit VR Big Endian, Deflated, all JPEG, JPEG-LS, JPEG 2000, RLE and HTJ2K families. The receiver transcodes nothing: an instance is stored in the transfer syntax it was sent in. Verification (1.2.840.10008.1.1) is accepted so the sender's "test connection" works.

Response behaviour. C-STORE returns Success (0000) once the file is written; C000 (cannot understand) when the dataset carries no Study Instance UID or SOP Instance UID; A700 (refused, out of resources) when the file cannot be written. C-ECHO returns Success.

What happens next. The study folder is handed to the upload path described in 2.3 and 3.1. Instance bytes are not modified between receipt and STOW-RS; the File Meta Information written to disk is the one negotiated on the association.

3.8 Segmentation Creator AE (SEG_EXPORT_V1)

3.9 Derived display copies (LITE_UIDS_V1)

The reduced-resolution display copy built for memory-limited devices (internally the "lite volume") is a set of derived CT images: Image Type DERIVED\SECONDARY, Derivation Description naming the in-plane block-average factor and slice stride, Derivation Code DCM 113085 Spatial resampling, Source Image Sequence naming the original instance, Related Series Sequence naming the original series, Series Description suffixed "(DDSALLY display copy)", Series Number = original + 800. Each derived instance has its own SOP Instance UID and each derived series its own Series Instance UID, both derived deterministically from the original's under the 2.25 arc (the same original always yields the same derived UID, so a rebuilt copy is the same object, never a second one). Study Instance UID and Frame of Reference UID are the original's, so geometry measured on the display copy places on the original. The copy is a display cache behind authenticated viewer URLs and is not offered for download or exchange.

3.10 Single-file export (MULTIFRAME_EXPORT_V1)

On request (?format=multiframe on the export endpoints), the study's largest consistent volume series is re-encoded as ONE Enhanced CT Image instance: every slice a frame, position order, Explicit VR Little Endian, pixel values unchanged (compressed sources are decompressed, never resampled or rescaled). Geometry is carried in the shared (Pixel Measures, Plane Orientation, Pixel Value Transformation, CT Image Frame Type) and per-frame (Plane Position, Frame Content with In-Stack Position) functional groups, with a dimension organisation over in-stack position. It is a derived object: Image Type DERIVED\PRIMARY\VOLUME\NONE, Derivation Code DCM 113040 Multi-frame conversion, a Source Image Sequence naming every source slice, and SOP/Series Instance UIDs issued deterministically under the DDSALLY root (a rebuilt export is the same object). Study and Frame of Reference UIDs are the source's. Scout views, secondary captures, reports and other series are not included — the DICOMDIR export (3.5) remains the export of everything — and a source with no two aligned slices, or more than 2048, is refused with a stated reason. Enhanced CT is the current multi-frame encoding; software limited to classic single-frame CT should use the DICOMDIR export.

3.11 Cropped volume export (VOI_EXPORT_V1)

On request from the viewer's VOI box (POST /files/{id}/crop and POST /practices/me/incoming-studies/{id}/crop), the part of the study's volume inside a box stated in patient (LPS) millimetres is written as a NEW study beside the source: one classic CT Image instance per slice (also when the source is a single Enhanced CT instance — each frame becomes one instance), Explicit VR Little Endian, pixel values, Rescale Intercept/Slope, Pixel Spacing and slice spacing unchanged; the box is snapped outward to whole voxels, never resampled. Image Position (Patient) is moved to the box corner and Image Orientation (Patient) kept, so the cropped slices place on the original in the same frame of reference. It is a derived object: Image Type DERIVED\SECONDARY, Derivation Description "Cropped by AllyVue on <date> to a volume of interest <size> mm (patient x/y/z extents); pixel values and spacing unchanged; derived from the original study", a Source Image Sequence naming the source instance with purpose DCM 121322 Source image for image processing operation, Series Description = source + " cropped by AllyVue <date>", Series Number = source + 900, Content Date/Time = when it was built. SOP and Series Instance UIDs are issued deterministically under the DDSALLY root from the source UIDs, the box and the date (the same box on the same day is the same object). Patient, study-level attributes and Frame of Reference UID are copied from the source. Filed on a referral, the crop keeps the source's Study Instance UID (it is one more series of that study); filed in a practice's imaging inbox, where studies are keyed by Study Instance UID, it is given a derived Study Instance UID with a Referenced Study Sequence naming the source study and the Study Description suffixed "(cropped)". The crop is taken from the stored study, never from a reduced-resolution display copy (3.9), so it is at the acquisition's full resolution whatever device requested it; the box is set by typed millimetre extents per patient axis or by handles, and moved as a whole, in the viewer. Pixel data is written uncompressed (Explicit VR Little Endian): a source stored with a lossless transfer syntax is reproduced exactly; a source stored with a lossy transfer syntax is written from its decoded pixels, which are what every conforming viewer displays, and the crop cannot restore what that compression discarded. A box thinner than 1 mm, or lying wholly outside the volume, is refused with a stated reason. The crop is an ordinary study afterwards: it can be viewed, sent, exported by 3.5/3.10, and is subject to the same retention and audit (the access log records the source and the box). It is a cropping of the image data, not a de-identification: the patient attributes travel with it.

3.12 De-identified copy (DEID_EXPORT_V1)

On request (GET /files/{id}/deid-export, GET /practices/me/incoming-studies/{id}/deid-export), every instance of a study is rewritten under DICOM PS3.15 Annex E, Basic Application Level Confidentiality Profile, with the Clean Descriptors (113105), Retain Longitudinal Temporal Information with Modified Dates (113107), Retain Device Identity (113109) and Retain Patient Characteristics (113110) options, and says so in De-identification Method and De-identification Method Code Sequence; Patient Identity Removed is YES. Patient's Name becomes DEIDENTIFIED and Patient ID a token derived from the exporting practice and the patient (the same patient exported twice by the same practice gets the same token, so serial studies can be paired; the token cannot be reversed without the practice's identifier); the birth date is removed and Patient's Age computed from it when absent (ages over 89 collapse to 090Y); sex is kept. Every DA and DT value in the study is shifted by one offset of one to two years, the same for every instance and stable for the patient within the practice, so intervals are preserved; TM values are kept. Manufacturer, model and software version are kept; institution, station, device serial, every person name other than the patient's placeholder, accession, study ID, request and comment attributes, and all private attributes are removed; Referring Physician's Name is present and empty. Study and Series Description are kept unless they contain the patient's name or ID. Every instance-level UID (Study, Series, SOP, Frame of Reference, and references to them in sequences) is replaced by one derived from the original and a per-export secret, consistent within the export. Pixel data is written as the source's, decoded to Explicit VR Little Endian where the source was compressed, and is NOT examined: burned-in text survives, Burned In Annotation is left as the source states it, and the zip's README says so. The copy is a download, not a stored object; it is not filed on the referral and the audit log records who downloaded it.

3.13 Presentation state export (GSPS_EXPORT_V1)

On request from the viewer (POST /files/{id}/measurements/gsps), a Grayscale Softcopy Presentation State is created with: a Softcopy VOI LUT holding the window the clinician was reading with (centre/width on the rescaled scale); the Modality LUT copied from the referenced images; a Displayed Area Selection of the whole image, scale to fit; one Graphic Layer, ALLYVUE; and, for every measurement whose points all lie within half the slice spacing of one acquired image, a Graphic Annotation on that image in PIXEL units (PS3.3 C.10.5: the top-left corner of the top-left pixel is 0\0, so a voxel centre sits at +0.5) -- POLYLINE for lengths, paths and polygons, two POLYLINEs for a bidirectional, ELLIPSE for an ellipse, POINT for a probe -- with the value the viewer showed, and the clinician's note, as a Text Object anchored at the first point. The whole series the drawings sit in is referenced, so the window applies throughout. A measurement on a reformatted plane (coronal, sagittal, oblique, panoramic, TMJ) has no acquired image to live on and is not carried; the response names each one left out. Image geometry comes from the instance index (classic images and enhanced multi-frame per-frame positions). The object is stored with the study under the DDSALLY root, listed in the viewer's work history, and downloadable; it is not pushed anywhere. It is a record of what was displayed and drawn, not a measurement object: the numbers in it are text, and the SR (3.3) remains the coded export.

3.14 Encapsulated PDF (ENCAP_PDF_V1)

On request (GET /reports/{id}/encapsulated-pdf), a signed report's PDF is wrapped unchanged (Encapsulated Document, padded to even length) in an Encapsulated PDF Storage instance: Modality DOC, Conversion Type WSD, MIME type application/pdf, Document Title the report's kind, Burned In Annotation YES (the PDF shows the patient's name), Verification Flag VERIFIED with the signing date and time as Content Date and Time, Series Number 995. When the referral carries a DICOM study the instance takes that study's Patient and Study Instance UID, so an importing PACS files it with the images; otherwise it carries its own derived Study Instance UID and the response says it will not join a study. SOP and Series Instance UIDs are derived deterministically from the PDF file, so the same report yields the same instance. Built once and cached beside the PDF; either practice on the referral may fetch it; the download is logged against the PDF.

4. Communication profiles

All traffic between the office and DDSALLY is HTTPS (TLS 1.2+) to api.ddsally.com. The DICOM Upper Layer over TCP is supported only by the DDSALLY Agent's Storage AE (section 3.7), on the office LAN. STOW-RS follows PS3.18 section 10.5; DICOM JSON responses follow PS3.18 Annex F.

5. Extensions, specialisations and privatisations

None. DDSALLY adds no private attributes, private SOP Classes or private transfer syntaxes to any object. The SR contains no private content items.

6. Configuration

7. Known limitations against ANSI/ADA 1114 and common expectations

These are stated so an integrator is not surprised, and because the ADA's 2026 comments to ONC single out exactly these points.

7.1 Retrieval is DICOMweb only, and needs a user's token

QIDO-RS and WADO-RS are provided (section 3.4); C-FIND/C-MOVE are not. A viewer or PMS integration authenticates with a practice API key of the DICOMweb scope (read-only, revocable) or with a user's bearer token.

7.2 Structured findings: what is and is not exported

Measurements, traced canals, planned implants (SR, 3.3), server-side volumetry regions (SEG, 3.8), the display state with measurements on acquired slices (GSPS, 3.13) and signed reports (Encapsulated PDF, 3.14) export. Three-dimensional cephalometric landmarks (CEPH3D_V1) are kept in the work history and copied as text; they are not yet an SR. Not yet: the browser-side contour-interpolated lesion volume (the mask is computed in the browser and only its contours are saved), the 3D trim recipe, TMJ axes and the arch curve. Reduced-resolution display copies now carry their own UIDs (3.9); copies built before LITE_UIDS_V1 keep the original UIDs until they are rebuilt.

7.3 Ingest check is advisory, and 1114 is still a draft

Since 2026-10-13 every received header is checked against the clauses of ANSI/ADA 1114 (AIP review draft, October 2025) that name attributes, and the result is shown on the study card as a "Metadata" chip listing what the modality did not write (patient identity and acquisition date, patient orientation, device identification, exposure factors, laterality and anatomic region for intraoral images, pixel size and slice thickness for CBCT, lossy compression, legacy one-file-per-slice CT, Secondary Capture). The standard is written in clinical terms; the mapping from each clause to DICOM attributes is DDSALLY's own and is kept in app/services/dicom_conformance.py. Nothing is rejected on these grounds: an instance with a Study and SOP Instance UID is stored whatever else it lacks, because the office cannot fix what its unit wrote. For browser uploads the check runs on the header slices probed at upload (up to 25 archive entries), so a large study's count reflects a sample.

7.4 Inbound DIMSE is in the Agent, not the service

A modality can send by C-STORE to the DDSALLY Agent on the office LAN (section 3.7), but not to DDSALLY over the internet: the web service accepts STOW-RS only, and the agent's receiver is unencrypted DICOM intended for a private network. Storage Commitment (N-ACTION) is not provided; the C-STORE success status means the file is on the agent's disk, and the agent's window and log show whether it reached DDSALLY.

7.5 Media

DICOMDIR is written on export (section 3.5) but not read on import: a DICOMDIR inside an uploaded ZIP is ignored and the instances are indexed from their own headers. Physical media are not read or written.

7.6 Registered UID root

Since 2026-10-15 DDSALLY issues UIDs under its IANA Private Enterprise Number arc 1.3.6.1.4.1.67226. Objects issued before then carry the UUID-derived root 2.25.266749473930415871265813823636100784599 (PS3.5 B.2) and keep those UIDs; derived display copies keep deriving theirs from that root so that a regenerated copy is the same object.

8. Security

9. Character sets

Specific Character Set is honoured as present in received files; no transcoding. Objects DDSALLY writes use ISO_IR 192.

10. Codes and controlled terminology

The measurement SR uses DICOM Controlled Terminology (DCM), SNOMED CT (SCT) and UCUM codes from the standard's context groups; no private codes.

Revision history. 2.2 (2026-11-01): sections 3.12 de-identified copy (DEID_EXPORT_V1), 3.13 presentation state (GSPS_EXPORT_V1), 3.14 Encapsulated PDF (ENCAP_PDF_V1); Table 1-2 and 7.2 extended. 2.1 (2026-10-31): 3.11, source resolution, transfer syntax and box placement stated. 2.0 (2026-10-31): section 3.11, cropped volume export as a new study (VOI_EXPORT_V1, VOI_EXPORT_INBOX_V1); Table 1-2 extended. 1.9 (2026-10-21): WADO-RS frames, rendered, thumbnail and bulkdata resources (DICOMWEB_READ_V2, section 3.4); Pixel Data referenced by BulkDataURI in metadata; practice API keys with a DICOMweb scope (API_KEY_SCOPE_V1, 3.4 and 7.1). 1.8 (2026-10-16): registered UID root (IANA PEN 67226, section 3.3 and 7.6); MR and non-volume series display and stack geometry checks (section 3.2). 1.7 (2026-10-14): section 3.10, single-file Enhanced CT export (MULTIFRAME_EXPORT_V1); Table 1-2 extended. 1.6 (2026-10-14): section 3.8, Segmentation objects are also consumed (SEG_IMPORT_V1) and produced from browser-side masks (SEG_UPLOAD_V1). 1.5 (2026-10-13): section 3.8, Segmentation objects for volumetry (SEG_EXPORT_V1); 3.3 extended to canals and planned implants (SR_FINDINGS_V2); 3.9, derived UIDs for reduced-resolution display copies (LITE_UIDS_V1); Table 1-2 and 7.2 rewritten. 1.4 (2026-10-13): section 3.7, Storage SCP and Verification SCP in the DDSALLY Agent (AGENT_CSTORE_V1); 1.1, 2.2, 2.3, 4, 6, 7.1 and 7.4 updated. 1.3 (2026-10-13): section 3.4, QIDO-RS and WADO-RS provider (DICOMWEB_READ_V1); 7.1 rewritten. 1.2 (2026-10-13): section 3.5, export as a DICOM File-set with DICOMDIR (DICOM_EXPORT_V1); 7.5 updated. 1.1 (2026-10-13): section 7.3, advisory ingest check against ANSI/ADA 1114 (DICOM_1114_V1). 1.0 (2026-10-13): first publication. Reflects DDSALLY API with DICOM_UIDS_V1 (fixed Implementation Class UID), INGEST_1 (STOW-RS), MEASUREMENT_SR_V1, and AllyVue Cloud / AllyVue Web as of this date.