MRI Workflow — POC

Three-portal workflow · Detailed process overview

Proof of concept · Functional flow

MRI study intake → assignment → doctor analysis → report return

This POC explains the end-to-end process and core data relationships in one vertically scrollable workflow. There is no AI analysis in this design: the doctor reviews the MRI, uses the imaging tools, and prepares the report. Superadmin coordinates the workflow and receives the completed report.

Superadmin PortalIncoming studies, doctor/hospital management, assignment, report tracking.
Hospital PortalHospital-scoped visibility of assigned studies, responsible doctor and status.
Doctor PortalDICOM viewer, manual analysis, measurements, annotations and report authoring.

1. Detailed MRI study workflow

Follow the arrows downward. Each step describes the actor, action, resulting record and next destination.

01

MRI Machine / Imaging System

MRI scan is acquired and stored as a DICOM study containing series and image instances.

Output: DICOM StudyIdentifiers: Study / Series / SOP Instance UID
Secure transfer / API
02

MRI Cloud / Vendor API / PACS

Source system makes new study metadata and image objects available through its supported API, DICOMweb or DICOM gateway.

Vendor-specific integrationTLS / approved credentials
New study event or scheduled sync
03

Backend Ingestion & Validation

Fetch metadata, validate completeness, prevent duplicates, log failures and register the study.

FastAPI integration serviceImport status + audit event
Save metadata and image references
04

Database + DICOM Storage

PostgreSQL stores workflow metadata; Orthanc/PACS or compatible object storage stores original DICOM files.

Study status: UnassignedOriginal image geometry preserved
Study appears in Superadmin queue
05

Superadmin Portal — Review & Assign

Superadmin reviews incoming study and assigns it to one hospital and one doctor.

  • Manage hospitals and doctor accounts.
  • Check study readiness, priority and assignment destination.
  • Create an assignment record with assigned-by user, timestamp and status.
  • Preserve assignment history if a case is reassigned.
Creates: StudyAssignmentStatus: Assigned
Shared assignment record drives scoped portal views
One study record · two role-authorized viewsNo duplicate MRI study is created for each portal. Backend permissions determine what each user can see.

Hospital Portal

Shows studies assigned to this hospital, assigned doctor, current status and permitted report access.

Doctor Portal

Shows only studies assigned to the signed-in doctor, with actions available for that assignment.

Doctor opens assigned study
06

Doctor Portal — Open MRI Viewer

Doctor opens the original study in OHIF / Cornerstone3D for manual review.

  • Zoom, pan, scroll, magnifier, window/level, rotate and flip.
  • Axial, sagittal and coronal views, crosshairs and synchronized viewports where supported.
  • Calibrated distance, angle, ROI area/perimeter, annotations and measurements.
DICOMweb image retrievalNo AI analysis
Save manual measurements and selected regions
07

Annotations, Measurements & ROI Workspace

Doctor can select an area, preserve its spatial context and open it in a separate analysis tab/window.

  • Save measurement values, units, coordinates, image references, author and timestamp.
  • 2D crop extracts the selected region from the current slice.
  • 3D ROI extracts across slices while preserving voxel spacing and orientation.
  • Derived images and annotations remain linked to the original study.
Annotation / Measurement / Artifact records
Doctor writes and finalizes the report
08

Doctor Portal — Report Generation

Doctor authors the clinical findings and conclusion based on manual image review.

  • Enter findings, impression, technique and relevant measurements.
  • Attach key images if required.
  • Save drafts; finalize and submit a versioned report attributed to the doctor.
Report status: SubmittedPDF export can be generated by backend
Report status update and notification
09

Superadmin Receives Report

Submitted report returns to Superadmin's dashboard, linked to the original study and assignment.

  • Track report receipt and case completion.
  • Review operational completeness and request an amendment if needed.
  • Do not silently overwrite a signed report; amendments create a new version.
  • Hospital portal reflects report availability according to permissions.
Status: Report Submitted / ClosedAudit trail retained
Secure retention and audit
10

Archive & Audit

Retain original images, authorized derived artifacts, report versions and activity history under the agreed policy.

Backups and restore testsRetention / privacy policy

2. Database relationships

Entity relationship diagram showing the main tables, primary/foreign keys and how records connect.

1:N = One-to-many
1:N1:0..11:N 1:N1:N1:N 1:N1:N1:N 1:N1:N1:N 1:N1:N1:N 1:N1:N Usersuser_idemail (unique)password_hashrole, status Hospitalshospital_idnameexternal_codestatus Doctorsdoctor_iduser_idlicense_refdisplay_name, specialty SourceSystemssource_idsource_typeendpoint_reflast_sync_at HospitalUsershospital_user_idhospital_iduser_id, access_level Patientspatient_idsource_patient_refdemographics* StudyAssignmentsassignment_idstudy_id, hospital_iddoctor_id, assigned_bystatus, assigned_at ImagingStudiesstudy_idpatient_id, source_idStudyInstanceUIDstudy_date, modality, status Seriesseries_idstudy_idSeriesInstanceUID, description DicomInstancesinstance_idseries_idSOPInstanceUID, object_uri Annotationsannotation_idstudy_id, doctor_idseries / instance referencetool_type, geometry_json Reports / ReportVersionsreport_id / version_idstudy_id, doctor_id, assignment_idfindings, impression, versionstatus, signed_at AnalysisArtifactsartifact_idstudy_id / report_id?artifact_type, object_urimetadata_json AuditEventsaudit_idactor_user_idaction, resource, timestamprequest_id, result *Patient fields are policy-dependent. Image pixel data stays in DICOM/PACS or object storage; relational tables keep metadata and references.

This is a conceptual ER model. Final constraints and indexes should be confirmed during database design. Every hospital/doctor data request must be authorized by the backend.

3. Portal responsibilities

Separate the operational role from clinical interpretation.

Superadmin portal

  • Manage hospital organisations and doctor accounts.
  • View imported studies and ingestion errors.
  • Assign/reassign studies to a hospital and doctor.
  • Monitor assignment status and turnaround time.
  • Receive submitted reports and track completion.
  • Request operational correction/amendment without changing a doctor's signed findings.
  • Review audit trail and manage access policies.

Hospital portal

  • View studies assigned to that hospital.
  • See assigned doctor, priority and current status.
  • Monitor pending and completed reports.
  • Access reports only when hospital policy grants permission.
  • Request reassignment or correction through an auditable workflow.
  • Never see other hospitals' data by default.

Doctor portal

  • View assigned worklist.
  • Open original DICOM study in OHIF/Cornerstone3D.
  • Use zoom, pan, window/level, MPR, calibrated measurements and annotations.
  • Save 2D crops / 3D ROIs as linked artifacts and open them for further review.
  • Write, save, sign and submit a report.
  • Amend a report using a new version and preserved history.

Why there is no AI module

  • Image interpretation is performed by the doctor.
  • The viewer is an image visualization and measurement tool, not automatically an AI diagnostic system.
  • Python backend may still be used for API integration, DICOM processing, data validation, report PDF generation and storage workflows.
  • AI/ML inference, automated diagnosis and AI-generated findings are explicitly out of scope for this POC.

4. MRI/API integration checklist

These items must be confirmed before connecting the actual source system.

QuestionWhy it mattersImplementation implication
Which vendor/cloud system provides the API?Endpoints, payloads and authentication differ by vendor.Create a vendor-specific ingestion adapter.
Does it provide DICOMweb or only metadata?Study metadata alone is not enough to display original images.Need image retrieval endpoint or PACS/gateway integration.
How is a new study detected?Webhook, polling and DICOM push have different reliability characteristics.Implement retries, idempotency and reconciliation.
How are image objects accessed?Large MRI studies can contain many instances.Use secure streaming/on-demand retrieval; avoid passing image bytes through the browser unnecessarily.
What identifiers are stable?Prevents duplicate studies and mismatched patient records.Map source IDs and DICOM UIDs with a defined namespace.
What are privacy and retention rules?Medical images contain sensitive information.Define access, audit, encryption, backups, retention and deletion policy.

5. Statuses, exceptions and recovery

A robust workflow defines what happens when normal processing fails.

StageExample statusesAction on failure / exception
ImportDetected → Importing → Imported / FailedLog error, retry safely, reconcile source and local record to avoid duplicates.
AssignmentUnassigned → Assigned → Reassigned / CancelledPreserve history and reason; notify old/new assignee when applicable.
Clinical workAssigned → In Progress → Draft SavedPersist draft and annotations; allow authorized resumption.
ReportDraft → Submitted → Amendment Requested → Amended / FinalKeep versions; never silently replace a finalized report.
Study lifecycleAwaiting Import → Ready → Assigned → Report Submitted → ClosedDo not mark ready until required images/metadata are available.
NotificationsPending → Sent / FailedRetry asynchronously; notification failure must not lose the assignment/report.

6. Viewer customization reference

Conceptual HTML mockup showing the kind of workspace to customize using OHIF Viewer and Cornerstone3D. This is a UI reference, not an actual running viewer.

MRI WORKSPACE
Study: DEMO-2026-001 · Brain MRI · De-identified sample
Doctor workspace · Reference UI
AXIAL · T2Slice 12 / 24
SAGITTAL · T1Slice 16 / 32
CORONAL · T2Slice 14 / 28
3D VOLUMEVolume rendering preview
Concept UI reference · not a functional viewerTo be implemented using OHIF / Cornerstone3D extensions

OHIF Viewer

Can provide an existing medical-imaging application shell and workflow UI that can be extended for your portal.

Official OHIF documentation ↗

Cornerstone3D

Rendering and imaging toolkit for DICOM viewports, measurements, annotations and custom viewer tools.

Official Cornerstone3D documentation ↗

7. Implementation notes

Technology recommendations for the actual product; the POC itself is a static HTML document.

Application stack

React + TypeScriptFastAPIPostgreSQLOrthanc / PACSDICOMweb

  • Three portal experiences can be separate route groups in one React app or separately deployed apps.
  • Backend enforces role-based access on every endpoint.
  • Use PostgreSQL for workflow metadata and object/PACS storage for image data.
  • Use OHIF/Cornerstone3D for viewer rendering and measurement tools; advanced features may need extensions.

Production safety checklist

  • HTTPS/TLS, secure session management and server-side RBAC.
  • Hospital tenant isolation and doctor-assignment checks on image/report APIs.
  • Encrypt storage and backups; protect API secrets.
  • Audit study access, exports, assignments, annotations and report changes.
  • Validate measurement calibration, DICOM geometry and report versioning.
  • Use only synthetic/de-identified records in the public demo.

POC scope boundary

This file illustrates the workflow and data relationships only. It does not connect to an MRI vendor, store real records, authenticate users, display actual DICOM images or generate a clinical report. No AI analysis is included. Before production, the vendor API contract, database schema, clinical workflow, legal/privacy obligations and validation plan must be confirmed with the client.