03. Core Screens

Application bootstrap & routing

App.tsx owns routing and navigation. It defines all application routes, establishes global initialization, and acts as the entry point that binds high-level views together. Individual views do not register themselves globally; they are activated exclusively through route transitions defined here.

Patients

Main file located in src/components/patients/PatientList.tsx Route: /patients

PatientList is the top-level management screen and the entry point into all patient-scoped workflows. It's the highest boundary below global routing and is only responsible for patient-level concerns.

This view owns the lifecycle of operations that do not require session context:

• Creation, deletion, archiving, searching and filtering of patients
• Selection and presentation of patients

It owns mutations, and reads from the patients table. It may also read derived patient metadata strictly to support list rendering and patient-level actions.

PatientList does not:

• Manage session data
• Images, analysis or reports
• Perform aggregation across sessions or images
• Mantain cross-patient or cross-view state.
• Coordinate downstream workflows.

States in this view is limited to:

• UI state (filters, dialogs, loading states)
• Interaction state (selection, confirmations)

Persistent data is handled directly through the database layer. No shared stores are owned by this view.

Selecting a patient transitions control to the PatientDetails view via navigation. No patient context is stored globally.

PatientList acts as a boundary between global navigation and patient-scoped workflows. Logic related to sessions, images, or analysis should not be introduced here.

Patient Details

Main file located in src/components/patients/PatientDetails Route: /patients/:patientId

PatientDetails is the patient-scoped coordination screen responsible for managing sessions belonging to a single patient. It represents the transition point from patient-level management to session-level workflows.

This screen owns the lifecycle of sessions for a specific patient, including:

• Creation, deletion, duplication of sessions
• Editing of session metadata
• Selection and presentation of sessions

It owns mutation to the session and patient tables. Specifically, it reads related patient metadata as needed to support these actions.

PatientDetails does not:

• Manage images, detections, segmentations, or reports
• Perform analysis or AI-related operations
• Aggregate data across sessions
• Persist or coordinate cross-session state

State in this view is limited to:

• UI and interaction state (dialogs, selections, expanded views)

Persistent session data is managed directly through the database. Patient context is derived exclusively from route parameters.

PatientDetails uses route-based navigation to transition into SessionView. It does not pass session data via props or shared stores.

This view represents the final boundary before session-specific data processing occurs. It coordinates navigation and session management.

Sessions

Main file located in src/components/upload/SessionView.tsx Route: /patients/:patientId/sessions/:sessionId

SessionView is the primary orchestration screen for session-scoped workflows. It is the point where patient context transitions into image-level processing, analysis and reporting.

This view owns the lifecycle of session images and reports. It coordinates:

• Image upload and deletion
• AI Processing
• Analysis visualization
• Report generation and visualization
• Session export

It owns mutations to the image, detection, segmentation and report tables. It reads from the session table.

SessionView does not:

• Implement AI models or inference logic
• Perform image-level annotation ending
• Manage patient-level data
• Coordinate cross-session workflows

As mentioned earlier, this view acts as an orchestration layer, it delegates work to specialized subsystems:

• Image upload and validation
• AI Inference services
• Analysis and visualization components
• Export utilities
• Report generators

It does not contain domain logic for these systems, it invokes them based on user interaction and session state.

The screen is organized into three primary tabs: images, analysis, and reports. Tab selection is persisted via a shared patient store to maintain navigation continuity within the session context.

SessionView mantains:

• UI and interaction state (loading, progress, dialogs)
• Transient orchestration state (process progress, refresh keys)

Persistent session data is handled through the database. No cross-session or cross-patient state is owned.

SessionView is route-driven and depends on the routing parameters for context. It serves as the entry point image-level workflows, routing into ImageGallery.

Navigation between session-level and image-level views is performed exclusively throughout route transitions.

Image Editor

Main file located in src/components/canvas/ImageAnalyzer Route: /patients/:patientId/sessions/:sessionId/images/:imageId

Image analyzer is the primary image-level analysis and annotation screen. it's accessed via /patients/:patientId/sessions/:sessionId/images/:imageId

This view owns all image-scoped interaction, including:

• Visualization of AI annotations, and manual annotations
• Corrections, measurements
• Contribution making
• Re-running AI detections

It owns mutations for the detection, measurement and pendingContribution tables. It reads from the image and session tables.

It operates strictly within the context of a single image, it doesn't manage session-level or patient-level lifecycles.

This view acts as a coordination layer between multiple subsystems:

• Canvas rendering and interaction
• AI analysis utilites
• Manual annotation tools
• Image processing utilities
• Contribution and dataset curation workflows

ImageAnalyzer also does not implement AI models or inference logic itself, it does however execute analysis functions and post-processing analysis. Analytical computations are delegated to specialized analysis modules. It's only responsible for invoking these modules, aggregating their outpots, and presenting results visually.

State management within ImageAnalyzer is divided into:

• Local UI state (active tools, panels, dialogs)
• Shared canvas state (selection, undo/redo history)
• Persisted image state (detections, annotations, measurements)

Undo and redo functionality is implemented at image level, and only affects persisted detection and annotation records for the active image. It is not global and it's not cross-image.

Navigation within ImageAnalyzer is image-scoped. Users move between images in the same session, using route-based navigation. It's also the home of the advanced editor mode, which is an UI mode within the same navigation route.

Finally, it does not mutate session metadata, patient data, or cross-image aggregates.

Reports

Main file located in src/components/reports/GlobalReportsList Route: /reports

GlobalReportsList is the application-wide reporting screen. It provides a general view of all reports generated across all sessions and patients, independent of navigation context. It's a global management screen.

This view owns:

• Listing generated reports
• Filtering of reports (date, single sessions, combinated sessions, report status)
• Search of reports (notes, metadata)
• Viewing, downloading and finalizing preliminary reports

It also reads from the reports, session and patients data for display. It does not create reports, or mutate image, detection or segmentation data.

All persistence is handled via IndexedDB (Dexie). No server-side persistence is involved.

There are no global shared states in this view, only local states, limited to:

• Filtering and search UI state
• Modal visiblity state
• Temporary report selection state

This view does not:

• Generate reports from scratch
• Perform AI inference
• Manage patient or session lifecycles
• Coordinate cross-session analytics

Configuration

Main file located in src/components/settings/Settings Route: /settings

The Settings view is the global configuration interface for the application. It allows the user to modify appearance, processing, AI model configuration, reporting preferences, debugging options, PWA behavior, and application metadata.

This view does not manage domain data (patients, sessions, images, reports). Instead, it mutates global configuration state stored in useConfigStore, which is consumed by multiple subsystems across the app.

Settings acts exclusively as a configuration editor. It does not execute workflows, perform inference, or own persisted domain entities.

This view is responsible for:

• Editing global appearance and localization settings
• Configuring AI model sources (local vs API)
• Defining processing and analysis parameters
• Managing debug and maintenance utilities
• Exposing application metadata and update mechanisms
• Stating current version
• Cache clearing

Settings delegates all persistent state to the configuration store and does not directly interact with patient or session data, except for maintenance utilities (e.g. cleanup of invalid annotations).

Contributions

Main file located src/components/contribution/ContributeMenu Route: /contribute

ContributeMenu is the central coordination screen for dataset and knowledge contributions. It allows users to review, curate, and submit locally modified data back to the project's central infrastructure (models, guidelines, conclusions).

This view represents the boundary between local, offline-first usage and external contribution APIs

It owns the cycle of pending contributions, including:

• Reviewing locally modified images and annotations
• Reviewing modified clinical guidelines
• Reviewing modified diagnostic conclusions
• Marking modified images in bulk for contribution
• Submitting contributions to the remote contribution API
• Tracking submission progress and success/failure states
• Collecting qualitive user feedback

The system supports multiple contribution categories, all coordinated here:

• Image contributions
• • Images with manual detections, segmentations, measurements, or classifications
• • Bundles original image data with all associated annotations
• • Converts painted pixel annotations into segmentation masks before submission
• • Guideline contributions
• • Modified or newly created clinical guidelines
• • Submitted as structured JSON metadata
• Conclusion contributions
• • Modified image-level classifications or diagnostic conclusions
• • Submitted independently from image data

Each contribution is tracked locally via the pendingContributions table with a status lifecycle (pending -> submitted).

It owns mutations to pendingContribution table. It reads from the image, detection, segmentation, measurement, imageClassification and session tables.

All contributions states are persisted locally until successfully submitted.

States are limited to local, through:

• UI interaction state
• Submission state
• Temporary selection state

This view is strictly a curation and submission layer, not an editing or analysis tool.

It is the only place where local data crosses the boundary into external systems, making it a critical trust, privacy and data integrity boundary.

Academy

Main file located in src/components/academy/AcademyView Route: /academy

AcademyView is the educational and reference hub of the application. It provides clinical context, protocol explanations, detected class definitions, and supporting documentation for how DIRD works. This view is informational by design and does not participate in patient, session, or image workflows.

It's a companion to the diagnostic workflow, providing explanations for how the system interprets and uses AI detections, for example.

States of this view include UI states, such as:

• Active clinical protocol tab
• Educational structure and presentation
• Links to external guides and internal documentation assets

Changes to this view only affect user understanding, not application behaviour.