The platform
Archive, workflow, governance.
Behind the viewer sits a full archive: a standards-compliant DICOM node, a searchable study index, order and reporting workflow, and the access controls a hospital needs before a single patient image is stored.
- DICOM SCP
- DICOMweb
- MWL & MPPS
- HL7 v2
- RBAC + audit
- OpenAPI
How it moves
From the order to the read, in one flow
The order leaves your RIS, the modality picks it up from the worklist, images land in the archive automatically, and the study is one click away from the clinician who ordered it.
RIS / EHR
Order placedPatient & accessionModalities
CT · MRI · X-ray · USQuery worklist, send imagesqPACS Core
DICOM SCP · MWL · MPPSDICOMweb · REST · HL7 v2Clinicians
One-click launch from RISPatient image galleryWhat it does
Connectivity, worklist, reporting, governance
DICOM & connectivity
- C-STORE — receive and archive
- C-ECHO — verification
- C-FIND — study, series and image level
- Query / retrieve — C-FIND, C-MOVE, C-GET
- Modality Worklist (MWL)
- MPPS — N-CREATE / N-SET procedure step status
- DICOMweb QIDO-RS, WADO-RS, STOW-RS
- Modality configuration — AE title, IP, port, routing
- Calling-AE allow-list — optional enforcement
- Transfer syntax support — compressed and uncompressed
Patient & study workflow
- Patient search — name, ID, identifiers
- Study search — accession, modality, date, description
- Study worklist with filters and statuses
- Patient → study → series → instance hierarchy
- Prior studies and current-vs-prior comparison
- Study status — unread, in progress, reported, verified
- Study assignment to radiologists
- Patient image gallery — tool-less patient view
- Non-DICOM document store
Reporting
- Report editor alongside the images
- Report templates — by modality / body part
- Draft, finalise and sign
- Controlled addendum workflow
- Critical finding flag
- Report history and versions
- RIS / HIS / EMR integration — orders, demographics, results
Security & audit
- Role-based access control — view, report, export, admin
- Authentication and optional SSO
- Session timeout
- Patient context protection
- Study access audit
- Export / download audit
- Annotation audit trail
- Anonymisation — for approved secondary use
- Single-use launch tokens — short-lived, scoped
Integration
Built to integrate, without lock-in
Orders push straight into the modality worklist and clinicians launch a study from inside your RIS/EHR in one click — with native MediCubes integration, single-use launch tokens and a documented API for everything else.
Integration interfaces
- DICOM: C-STORE, C-ECHO, C-FIND, MWL, MPPS
- DICOMweb: QIDO-RS, WADO-RS, STOW-RS
- REST: order push and cancellation
- REST: launch-token mint and exchange — server-to-server
- HL7 v2: ORM and ADT in, ORU out — MLLP or HTTP
- Per-application client credentials and scope
- OpenAPI specification
- Native MediCubes RIS/EHR integration
Administration without a specialist
- Register modalities and test connectivity from the browser
- Create users and assign roles in seconds
- Enable or disable a device without restarting services
- Standard files and database — back up with your own tools
HL7 v2
Speak the language your
hospital already speaks.
Most hospital information systems talk HL7 v2, not REST. qPACS now does both — and the choice is made per registered application, so one site can run a REST integration and an HL7 feed side by side without either knowing about the other.
| Direction | Message | What it does |
|---|---|---|
| In | ORM^O01 · OMG^O19 · OMI^O23 | Creates or updates a scheduled procedure step, served straight to modalities over MWL. ORC-1 cancel controls drop it off the worklist again. |
| In | ADT A01 · A04 · A05 · A08 · A28 · A31 | Upserts patient demographics. A40 merges the MRG-1 patient into the PID patient. Other triggers are accepted as no-ops. |
| Out | ORU^R01 — study available | Sent as soon as a case's first images are archived, to each HL7 application that asks for it. |
| Out | ORU^R01 — results | Sent when a report is finalised, carrying the report back to the ordering system. |
Two transports, one router
- MLLP over TCP — port 2575, framed and persistent
- HL7 over HTTP — POST /api/hl7, raw ER7 in and out
- The same handlers and sender trust behind both
- Every message answered with an ACK — AA, AR or AE
- Either transport can be turned off in configuration
Trust and mapping
- Senders matched on MSH-3 and MSH-4 — application and facility
- Optional source-IP allow-list per application
- Accession from OBR-18 — falling back to ORC-2 / OBR-2
- Modality, procedure, scheduled time and referrer mapped from OBR
- Patient identity, name, DOB and sex mapped from PID
Licensed capability. The inbound MLLP listener starts, and HL7 applications can be created, only when the licence carries the hl7 feature. Without it qPACS runs REST integration exactly as before. MLLP is plaintext by design — keep it on the modality VLAN rather than exposing it publicly.
Modalities
Connect the equipment you already own
qPACS is designed to receive and archive objects from DICOM-conformant modalities across vendors. Devices are registered by AE title with an optional allow-list — adding a scanner is a configuration change, not a service call.
Your data
Your images, in a format you
can still read in ten years.
Every study is stored as standard DICOM Part-10 on your own disk, SAN or NAS, indexed in PostgreSQL — readable by any DICOM tool, with no proprietary container in the way.
- No cloud dependency and no per-study fees
- Back up the database and the object store with your own tools
- Migrate out with standard DICOM tooling, whenever you choose
- One database, one storage path, one machine to secure
PostgreSQL index
patients · studies · orders · audit
Object storage
DICOM Part-10 on disk, SAN or NAS
Request a demo
See it read your studies.
The fastest way to evaluate qPACS is to point a modality at it. We install a full working system, connect it to your equipment and walk your team through a live read — on your images, on your network.
- 01Connect a modality
- 02Send a study
- 03Read it in the browser