1) Fastest path: Mendix + OHIF (via DICOMweb)
When to choose: You want a full-featured viewer quickly, with minimal custom code.
Reference architecture
DICOM store/PACS: Orthanc, dcm4chee, or a managed DICOMweb service (AWS HealthImaging, Azure HDI DICOM, GCP Healthcare).
Viewer: OHIF 3.x configured for your DICOMweb endpoints (QIDO-RS, WADO-RS/URI, STOW-RS if you’ll upload).
Mendix: Owns auth, search, and launch logic. It passes UIDs to OHIF.
How it looks from Mendix
Persist only metadata in Mendix (Study/Series/Instance entities) + the three UIDs: StudyInstanceUID
, SeriesInstanceUID
, SOPInstanceUID
.
Use a “Open Viewer” button that builds a URL for OHIF, e.g.https://ohif-host/viewer?StudyInstanceUIDs=<uid>
(You can also pass Series/SOP for deep linking.)
Embed OHIF either:
In an iframe (simple, keeps upgrade path clean), or
Open in a new tab (best performance, fewer CSP headaches).
OHIF config (typical)
// app-config.js (OHIF 3.x style) window.config = { servers: [ { id: "dicomweb", type: "dicomweb", name: "Orthanc", wadoUriRoot: "https://pacs.example/wado", qidoRoot: "https://pacs.example/dicom-web", wadoRoot: "https://pacs.example/dicom-web", qidoSupportsIncludeField: true, supportsFuzzyMatching: true, imageRendering: "wadors", thumbnailRendering: "wadors", enableStudyLazyLoad: true } ] };
Pros
Full toolset out of the box (MPR, measurements, hanging protocols, multi-frame playback).
OHIF already handles most multi-frame edge cases.
Cons
Viewer branding/custom UX is limited unless you fork/extend OHIF.
You host/operate a DICOMweb-capable backend (Orthanc/dcm4chee or cloud).
2) Deep integration: Mendix Pluggable Widget with Cornerstone (2D/3D)
When to choose: You want the viewer inside a Mendix page with custom events, ACL-driven tool visibility, or tight UI coupling.
Approach
Build a pluggable widget that:
Accepts Study/Series/SOP UIDs as props.
Uses Cornerstone 3D + dicomweb-client to fetch frames over WADO-RS.
Renders a <div>
canvas with cornerstone’s rendering pipeline.
Use Mendix microflows/nanoflows for search + selection; the widget just renders what it’s told.
Pros
Pixel-perfect Mendix UX, react to page context, show/hide tools by role.
Smaller runtime surface than full OHIF if you need only basic tools.
Cons
More engineering time (tooling, measurements, cine, layout, codecs).
You’ll re-implement features OHIF already ships.
3) Hybrid: OHIF in iframe + light Mendix widget helpers
When to choose: You want OHIF’s power but also extra Mendix-side UX (sticky patient banner, action buttons that command the viewer, etc.).
Keep OHIF in an iframe.
Add a Mendix widget to exchange messages via postMessage
(e.g., tell OHIF to load a new series, start/stop cine, jump to frame).
Minimal custom code with a “native-ish” feel.
Storage & metadata model (recommended)
In Mendix, create lightweight entities and don’t store the raw DICOM in Mendix unless you must.
Entities
Patient
(ID, Name, DOB…) – optional if needed
Study
(StudyInstanceUID
, StudyDate
, AccessionNumber
, Description
, PatientName
)
Series
(SeriesInstanceUID
, Modality
, BodyPart
, Description
)
Instance
(SOPInstanceUID
, NumberOfFrames
, TransferSyntaxUID
, ContentDateTime
)
Sync flow
Query PACS via QIDO-RS (search) from Mendix “Call REST”.
Map JSON → entities (one microflow per level is fine).
Show a grid of studies/series; store the UIDs for launch.
Don’t copy pixel data to Mendix; fetch via WADO-RS directly from viewer.
Upload (optional)
If users upload DICOMs in Mendix, immediately forward to PACS using STOW-RS (multipart/related; Content-Type: application/dicom
).
On success, re-QIDO to refresh metadata; link to created Study/Series.