MedScanMedScan
TECHNOLOGYBUILT IN-HOUSE

The imaging engine behind MedScan

Most mobile DICOM viewers are thin wrappers around decades-old C libraries. MedScan is not. We build the imaging stack ourselves — from the codec that decodes the bytes to the Metal pipeline that puts them on glass — because a dental imaging platform is only as good as the engine underneath it.

Metal GPU pipeline

RENDER

Every pixel MedScan draws goes through a Metal rendering pipeline built for medical imaging: 16-bit windowing done on the GPU, not baked into textures; zoom and pan at native display refresh; 3D volume rendering with bone and soft-tissue transfer functions running on the same silicon that powers the iPad Pro. A 2,000-slice CT volume scrolls like a photo album.

Pure-Swift DICOM codecs

CODEC

We wrote our own decoders for the DICOM codec line — JPEG Lossless, JPEG-LS, baseline JPEG, RLE — in pure Swift, alongside JPEG 2000 support. In-house codecs mean no opaque C dependency deciding what opens and what fails: when a study renders wrong, we can fix the decoder, not file a bug upstream. Each decoder is validated byte-exact against the reference implementations (DCMTK, CharLS) across our corpus of real-world studies.

Anatomy-aware reformat engines

MPR / CPR

The MPR engine reconstructs axial, coronal, and sagittal planes with synchronized crosshairs and correct anisotropic spacing. On top of it sits the dental engine: a curved-planar reformat (CPR) that follows the arch spline you draw, producing the panoramic view and serial cross-sections perpendicular to the curve — the geometry implant planning actually needs. The same reformat core drives PET/CT fusion, blending co-registered series with adjustable opacity.

A real PACS client

DICOMWEB

MedScan speaks standard DICOMweb: QIDO-RS for search, WADO-RS for retrieval, with Basic auth and OAuth 2.0. We test against Orthanc and dcm4chee, and stick to the standard so any compliant archive works. Studies download into the on-device library and are fully usable offline; edited annotations and measurements can be exported back as DICOM.

On-device by architecture

PRIVACY

Privacy is not a policy layer — it is the shape of the system. Decoding, rendering, reformatting, and measurement all execute on the device. There is no MedScan cloud, no account system, and no pathway by which PHI leaves the iPad: the app has nothing to upload to. This is also why it works identically in a basement reading room, on a plane, or in a clinic with no IT department.

The AI research direction

AI R&D

The next layer of the platform is AI-assisted dental analysis: pathology highlighting on CBCT and panoramic views, automatic tooth detection and charting, and structured reporting. Our constraint is the same one that shapes the rest of the stack — models must run on-device, on Apple silicon, with the clinician confirming every finding. These capabilities are in active development and are not part of the shipping product today.

ENGINEERING PRINCIPLES
  • Own the stack: if it decodes, reformats, or renders, we wrote it.
  • Validate against references: byte-exact parity with DCMTK and CharLS, not "looks right".
  • On-device is non-negotiable: no PHI leaves the iPad, ever.
  • Standards over lock-in: DICOM in, DICOM out, DICOMweb in between.

ENGINE · READY

See the engine at work

Download on the App Store