Data processing agreement

This page is the reference text. Where any other page on this site appears to say something different, this one governs.

1. Roles

The dental practice is the controller of its patient data. SCMDSD LLC, operating DentalClinicsAIHub, acts as a processor for the limited purpose of transmitting a radiograph to the platform the practice has selected and returning that platform's response. The selected platform acts as a further processor under its own terms with the practice.

2. Categories of data processed

Dental radiographic images transmitted by the practice, and whatever identifiers the practice chooses to leave inside those files. We do not require patient identifiers. On entry, identifying fields in the DICOM header are removed, private tags are removed and unique identifiers are replaced by random ones, and every change is reported back to the practice. An image that declares burned-in annotation is refused. Text burned into the pixels without that declaration cannot be detected, so the practice remains responsible for not sending it.

3. Retention period

Zero (0) seconds after the response is returned. Images are held in process memory for the duration of a single request and released when it closes. No image is written to disk, to a database, to a cache, or to a backup at any point. There is no archive, therefore no restoration, no export and no deletion request to process.

4. What is retained

Nothing is retained per analysis. Billing is per practice location and per month, so no record of individual analyses is needed, and none is kept: no timestamp, no count, no request identifier. What is retained is the practice account and the SHA-256 hash of its access token, for the duration of the commercial relationship and the period required by accounting law thereafter.

5. Purpose limitation

Images are processed for transmission only. They are not used to train, evaluate or improve any model, ours or a third party's. They are not analysed, indexed, catalogued or reviewed by our staff. No secondary use of any kind is made of them.

6. Sub-processors

The platform selected by the practice for each analysis, and our infrastructure provider for hosting. We publish the current list and give notice before adding a sub-processor that would receive image data. Vendors are never added to a practice's account without that practice selecting them.

7. International transfers

A radiograph travels to wherever the selected platform operates. That destination is a property of the practice's own selection, and it is stated on each platform page. Where the practice requires a specific jurisdiction, it should select accordingly.

8. Security measures

TLS in transit on every exchange. Each practice location holds its own access token; only its SHA-256 hash is stored, and the operator can revoke it individually at any time. Revocation by the practice itself, from an account page, is planned. The service account can only read the list of valid token hashes and cannot write anywhere. Restricted and logged access to production infrastructure; operator logs record actions, never image content. Measures relating to data at rest are not applicable, there being no data at rest.

9. Incidents

We notify the practice without undue delay of any breach affecting its account data or its credentials. A breach exposing patient images from our infrastructure is not a scenario we can have, since those images are not held; a compromise of credentials permitting fraudulent transmission is, and it is the scenario our notification obligation covers.

10. Audit

The practice may request evidence that the architecture matches this text: configuration, code paths handling image data, and infrastructure access records. We prefer this to a certification badge, because it is the thing the badge would be standing in for.

11. Termination

There is no notice period and no minimum term. On termination there is nothing to return and nothing to erase, because nothing was kept. Billing records are retained as set out in clause 4.

Annex — stateless architecture

Image data exists in this system only as a buffer in the memory of the process handling an individual HTTP request. It is forwarded to the selected platform within that same request and the buffer is released when the request terminates. There is no queue, no temporary file, no object store and no cache layer holding image content. This property is what clause 3 describes; it is enforced by the design of the service, not by an operational policy.

SCMDSD LLC, 1603 Capitol Avenue, Cheyenne, WY 82001, United States.