DicomFlow

The system shall provide a multi-tenant platform architecture with strict data isolation for independent organizations. The system shall support global user registration for roles including Doctor, Patient, and Technician. The system shall allow a global user to be associated with multiple tenants. The system shall maintain a global Master Patient Index (MPI) to ensure patient uniqueness across the platform. The system shall provide tenant-scoped management of medical imaging studies, including scheduling and status tracking. The system shall support DICOM image ingestion, storage, and retrieval. The system shall enforce physical segregation of DICOM data per tenant. The system shall support the ingestion and parsing of HL7 ORU messages for radiology reports. The system shall provide secure, role-based sharing of studies with internal and external users. The system shall expose a FHIR R4 compliant API for external system interoperability. The system shall provide a web-based user interface with role-specific dashboards. The system shall include a basic DICOM viewer in its web interface. The system shall not generate radiology reports; it shall only consume them via HL7. The system shall not provide advanced radiological image manipulation and diagnostic tools beyond a basic viewer. The system shall not include billing, insurance, or financial management workflows. The system shall not provide direct integration with specific DICOM modality hardware.

The system shall be a standalone, cloud-native web application. The system shall operate as a modern Picture Archiving and Communication System (PACS). The system shall integrate with existing hospital infrastructure by acting as an HL7 listener. The system shall provide modern interoperability through a FHIR API. The system shall be built on a hybrid microservices architecture.

The system shall define a 'Super Administrator' role responsible for platform-level administration. A Super Administrator shall manage the tenant lifecycle, including activation and suspension. A Super Administrator shall oversee system health. A Super Administrator shall be able to perform sensitive data management tasks, such as merging duplicate patient records. The system shall define an 'Organization Administrator' role responsible for managing their organization's tenant instance. An Organization Administrator shall manage user associations for their tenant. An Organization Administrator shall manage tenant-specific settings. An Organization Administrator shall have full access to all data within their own organization. The system shall define a 'Doctor' role for clinical users. A Doctor shall be able to be associated with multiple organizations. A Doctor shall be required to switch contexts to view data from each associated organization. A Doctor shall have read-only access to clinical data. The system shall define a 'Technician' role for operational users. A Technician shall be able to schedule studies. A Technician shall be able to manage patient check-ins. A Technician shall be able to update study statuses. A Technician shall be able to upload DICOM images. A Technician shall be able to be associated with multiple organizations. The system shall define a 'Patient' role for end-users. A Patient shall only be able to view studies that have been explicitly shared with them via a secure link. A Patient shall not have access to organizational study lists or other platform features. The system shall define an 'External System' user class for non-human users. An External System shall interact with the platform programmatically via the FHIR API using OAuth 2.0 credentials. An External System's access shall be strictly scoped to a single tenant.

The system shall be deployed on the Microsoft Azure cloud platform. Compute services shall be containerized using Docker. Compute services shall be orchestrated via Azure Kubernetes Service (AKS). Azure SQL Database shall be used for relational data. Azure Cache for Redis shall be used for caching. Azure Blob Storage shall be used for DICOM file storage. The web application shall be accessible via modern web browsers, including Chrome, Firefox, Edge, and Safari. The web application shall be accessible on standard desktop and laptop computers.

The backend shall be implemented using the ASP.NET Core 8 framework. The system shall use a hybrid data model with a shared database for global entities (Users, MPI). The system shall use a 'Database per Tenant' model for all tenant-specific data. The external API shall comply with the FHIR R4 specification. The system architecture and all features shall be designed to facilitate organizational compliance with HIPAA and GDPR. The system shall use a centralized identity provider implementing OAuth 2.0 and OpenID Connect. The centralized identity provider shall be IdentityServer6.

The system design shall assume Microsoft Azure is the exclusive cloud provider. The system shall assume that external systems (HIS/RIS) are capable of sending well-formed HL7 ORU messages. The system shall assume that end-users will have a stable, modern internet connection. The project shall procure all necessary commercial licenses for third-party software, including IdentityServer6.

The system shall allow a prospective organization to submit a registration request for the platform. The system shall create a new tenant in a 'Pending' state upon registration submission. The system shall send an email notification to the Super Administrator group to alert them of a new registration request. <<$Addition>> A Super Administrator shall be able to review pending organization registrations. <<$Addition>> A Super Administrator shall have the ability to 'Activate' a pending tenant. <<$Addition>> A Super Administrator shall have the ability to 'Reject' a pending registration with a reason. <<$Addition>> The system shall notify the organization's contact person of the registration decision via email. <<$Addition>> Upon activation, the system shall change the organization's status to 'Active'. <<$Addition>> Upon activation, the system shall provision the organization's dedicated database. <<$Addition>> Upon rejection, the system shall change the organization's status to 'Rejected'. <<$Addition>> A Super Administrator shall have the ability to suspend an existing tenant. <<$Addition>> A Super Administrator shall have the ability to deactivate an existing tenant. <<$Addition>> When a tenant is suspended, its users shall be prevented from logging in. <<$Addition>> When a tenant is suspended, its data shall be preserved. <<$Addition>> When a tenant is deactivated, its data shall be marked for archival and eventual deletion according to data retention policies. The system shall allow individuals (Doctors, Patients, Technicians) to register a global account, independent of an organization. The registration process shall capture the user's intended role. A user's global account shall not be associated with any organization by default. <<$Addition>> The system shall support a workflow for verifying the credentials of users registering as a 'Doctor' or 'Technician'. <<$Addition>> A user account registered with the role 'Doctor' or 'Technician' shall be placed in an 'Unverified' state. <<$Addition>> A Super Administrator shall be able to view a list of unverified professionals. <<$Addition>> A Super Administrator shall be able to mark an unverified professional as 'Verified'. <<$Addition>> An unverified user shall not be able to be invited to join an organization. An Organization Administrator shall be able to search for globally registered Doctors and Technicians by name or email. An Organization Administrator shall be able to send an invitation to a 'Verified' user to join their organization. <<$Change>> The system shall send an invitation to a user via a system notification and/or email. <<$Change>> A user shall be able to 'Accept' or 'Decline' an invitation. <<$Change>> Invitations shall have a configurable expiration period. <<$Change>> An invitation shall become invalid after its expiration period. <<$Change>> Upon accepting an invitation, the system shall create an active `UserOrganizationAssociation` record. <<$Change>> If an invitation is declined or expires, its record shall be marked as 'Declined' or 'Expired'. System access shall be strictly controlled by user roles within a specific context. A Super Admin shall have access to all system-level features, tenant management, and platform-wide data. An Organization Admin shall have full create, read, update, and delete (CRUD) access within their own organization's context. A Doctor shall have read-only access to studies within their associated organizations. A Technician shall be able to create/schedule studies and upload images within their associated organizations. A Patient shall have access only to studies explicitly shared with them. <<$Addition>> An Organization Administrator shall be able to remove a Doctor or Technician's association from their organization. <<$Addition>> Upon removal, a user shall immediately lose all access to that organization's data and context. <<$Addition>> A user's global account shall remain active after being disassociated from an organization. <<$Addition>> A user's active session for an organization context shall be immediately invalidated upon disassociation. <<$Addition>> A disassociated user shall no longer be able to select that organization as their active context upon next login.

<<$Resolution>> The system shall maintain a Master Patient Index (MPI) to ensure every patient has a single, globally unique record. <<$Resolution>> The MPI shall be the single source of truth for patient identity. <<$Resolution>> All studies, regardless of the tenant, shall link to a patient record in the global MPI. <<$Change>> When creating a new patient, the system shall first perform a search against the global MPI. <<$Change>> The MPI search shall use a combination of Name, Date of Birth, and a government-issued ID Number. <<$Change>> The system shall present potential matches to the user to prevent the creation of duplicate patients. <<$Change>> The set of fields used for patient matching shall be configurable per tenant. <<$Change>> The system shall use a probabilistic matching algorithm for MPI searches. <<$Change>> A user shall be able to select an existing patient from the search results. <<$Change>> A user shall be able to confirm that no matches are correct and proceed to create a new MPI record. The 'Schedule Study' workflow shall begin with a mandatory patient search and selection step. A study shall not be created without being linked to a valid record from the global MPI. <<$Addition>> The system shall provide a secure interface for a Super Administrator or an authorized Organization Administrator to merge potential duplicate patient records. <<$Addition>> The merge process shall consolidate all associated studies and data under a single, surviving patient record. <<$Addition>> The merge process shall create a clear audit trail of the merge event. <<$Addition>> The subsumed patient record shall be marked as 'Merged' and shall no longer be searchable after a merge. <<$Addition>> A detailed audit log entry shall be created for each merge, recording the pre-merge and post-merge state and the administrator who performed the action.

<<$Resolution>> All data entities, except for the global MPI and global user accounts, shall be strictly scoped by an `OrganizationId`. <<$Resolution>> A user's query shall never return data from a tenant they are not actively authenticated into. Every database query for tenant-specific data shall include a `WHERE OrganizationId = @CurrentOrganizationId` clause, enforced by the data access layer. DICOM images shall be stored in a cloud storage container that is physically segregated by `OrganizationId`. When a new tenant is activated, a dedicated Azure Blob Storage container shall be created for them. All DICOM uploads for a tenant shall be routed exclusively to their dedicated container. The application logic shall prevent any possibility of cross-container access. When a user associated with multiple organizations logs in, they shall be required to select an organization context to act within. If a user is associated with more than one active organization, they shall be presented with a list of those organizations upon login. The selected `OrganizationId` shall be included in the user's JWT token. The selected `OrganizationId` shall be used for all subsequent API requests during that session. The UI shall clearly display the currently active organization context at all times. <<$Addition>> If a user is associated with only one organization, the system shall automatically select that context upon login. A Doctor or Technician shall only be able to view and interact with studies belonging to the currently selected organization context. The user interface shall provide a mechanism for users to switch their active organization context without logging out. Switching context shall issue a new JWT with the new `OrganizationId`. Switching context shall refresh the application state to reflect the new context.

<<$Addition>> Each study shall have a status that tracks its progress through the workflow. <<$Addition>> The minimum set of study statuses shall be: `Scheduled`, `In Progress`, `Completed`, `Cancelled`. <<$Addition>> When a new study is created, its initial status shall be 'Scheduled'. <<$Addition>> The study list UI shall allow filtering and sorting by status. <<$Addition>> The system shall enforce logical status transitions. <<$Addition>> A Technician or Organization Admin shall be able to change a study's status from 'Scheduled' to 'In Progress'. <<$Addition>> A Technician or Organization Admin shall be able to change a study's status from 'In Progress' to 'Completed'. <<$Addition>> An Organization Admin shall be able to change a study's status to 'Cancelled' from any other state. <<$Addition>> All status changes shall be audit logged with the user, timestamp, and previous/new status.

Sharing shall be initiated by an authorized user (Organization Admin or Technician) within an organization context. From a study's detail view, an authorized user shall have a 'Share' option. The system shall generate a unique, secure, and time-limited URL for a shared study. The generated URL shall contain a cryptographically secure, random, and unguessable token. The token shall be associated with a single study. <<$Change>> All shared links shall have a configurable expiration date/time. <<$Change>> Shared links shall become invalid after their expiration. <<$Change>> The user who initiated the share or an Organization Admin shall have the ability to manually revoke the link at any time. <<$Change>> Revoking a link shall immediately disable access. <<$Change>> Accessing an expired or revoked link shall result in an 'Access Denied' or 'Link Invalid' message. <<$Change>> For unauthenticated users, accessing a shared link shall require verification of identity by providing a second piece of information (e.g., Patient's Date of Birth). For authenticated users, the system shall grant access to a shared link if they are the intended recipient or a member of the sharing organization. Authorized internal users of the same organization shall be able to access the study directly through the application, provided they are in the correct organization context. A patient's studies shall not be automatically shared with all doctors or technicians associated with an organization. Access to a study shall be granted only if the user's role permits it within their active tenant context, or if they are the recipient of an explicit share. <<$Addition>> Every action related to sharing shall be recorded in the audit log. <<$Addition>> The sharing audit log shall include the creation of a share link, successful access, failed access attempt, and revocation. <<$Addition>> The sharing audit log shall record the user who performed the action, the recipient (if known), the timestamp, and the associated study. <<$Addition>> The audit log for a successful share access shall include the source IP address.

The system shall expose a FHIR R4 compliant REST API endpoint. The API's CapabilityStatement shall be accessible and accurately reflect the supported resources and operations. The API shall support `GET` operations for key FHIR resources. <<$Change>> The API shall support searching for resources using a core set of search parameters as defined by the FHIR standard. The API shall support `GET [baseUrl]/Patient/[id]`. The API shall support searching for Patients via `identifier`, `name`, and `birthdate` parameters. The API shall support `GET [baseUrl]/ImagingStudy/[id]`. The API shall support searching for ImagingStudy via `patient`, `accession`, and `started` parameters. The API shall support `GET [baseUrl]/DiagnosticReport/[id]`. The API shall support searching for DiagnosticReport via `patient` and `study` parameters. The API shall support `GET [baseUrl]/Binary/[id]` to allow download of DICOM files. API access shall be secured using the OAuth 2.0 Client Credentials grant flow. The Identity Service shall expose a token endpoint for the Client Credentials flow. Each external system client shall be registered with a unique `client_id` and `client_secret`. API requests without a valid JWT Bearer token shall be rejected with a `401 Unauthorized` status. Data returned via the FHIR API shall be strictly scoped to the caller's tenant. Each API client registered in the system shall be associated with exactly one `OrganizationId`. When a client authenticates, the issued JWT shall contain an `organization_id` claim. All data queries performed by the FHIR service shall use the `organization_id` from the token to scope the results.

The user interface shall be clean, modern, and intuitive. The user interface shall minimize the number of clicks required to complete common tasks. The web application shall be responsive and functional on screen resolutions from 1366x768 to 1920x1080 and higher. The UI shall adhere to Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards. The system shall provide a Login Screen with fields for email and password, a 'Forgot Password' link, and a 'Register' link. The system shall provide an Organization Selector screen, displayed post-login for users with multiple associations. The system shall provide a Dashboard/Study List that is filterable, sortable, and searchable. The Study List shall display Patient Name, Accession Number, Description, Status, and Scheduled Time. The system shall provide a Study Viewer with a basic DICOM viewer. The DICOM viewer shall include tools for windowing, panning, zooming, and scrolling through series. The Study Viewer shall display study and patient metadata. The system shall provide separate administration panels for Organization Admins and Super Admins.

The system shall support integration with external EHR/RIS via the FHIR R4 API. The system shall listen for incoming HL7 ORU messages on a designated TCP/IP port to ingest radiology reports. The backend shall utilize the `Hl7.Fhir.R4` library for FHIR resource handling. The backend shall utilize a suitable MLLP library for HL7 communication.

All communication between the client web browser and the backend servers shall use HTTPS over TCP/IP. All data exchanged between client and server shall be formatted as JSON. <<$Addition>> The system shall use SignalR for real-time notifications to the client, such as updates to study status. All data in transit shall be encrypted using TLS 1.2 or higher.

The main study list UI shall load in under 2 seconds. The Largest Contentful Paint (LCP) for key pages shall be under 2.5 seconds. The P95 latency for all interactive API calls shall be under 250ms. The FHIR API shall respond to GET requests in under 1 second for single-resource queries. The system shall support a 100MB study upload/download in under 30 seconds on a standard 30 Mbps broadband connection.

All databases shall utilize Azure SQL's Point-in-Time Restore (PITR) capabilities. The PITR configuration shall have a 35-day retention period. The system shall use geo-replication to maintain read-only replicas of all databases and storage accounts in a paired Azure region. The system shall be deployed across multiple Azure Availability Zones to ensure high availability. The system shall support automatic failover in case of a single datacenter failure.

All user and system access shall be authenticated via the central Identity Service (IdentityServer6) using OAuth 2.0 and OpenID Connect protocols. Authorization shall be enforced at the API gateway and within each service based on roles and tenant context claims present in the user's JWT. All data stored in Azure SQL shall be encrypted at rest using AES-256 via Transparent Data Encryption. All data stored in Azure Blob Storage shall be encrypted at rest using AES-256 via Storage Service Encryption. All network communication shall be encrypted using TLS 1.2 or higher. All application secrets, connection strings, and certificates shall be stored in Azure Key Vault. Services shall access secrets from Azure Key Vault at runtime using Azure Managed Identities. <<$Change>> The system shall maintain comprehensive audit logs that track all events involving PHI. <<$Change>> Auditable events shall include user login/logout, patient record creation/view/update, study view, data export, and all sharing activities. Audit logs shall capture the user, user role, organization context, timestamp, source IP address, and the specific data record accessed. Audit logs shall be stored in a secure, tamper-evident manner within Azure Log Analytics Workspace.

The system shall target 99.9% uptime, excluding planned maintenance. Planned maintenance windows shall be scheduled during off-peak hours. Tenants shall be notified of planned maintenance at least 48 hours in advance. All backend services shall be stateless and designed to be scaled horizontally. The system shall use the AKS Horizontal Pod Autoscaler to automatically scale services based on load. The system shall be designed to support up to 10,000 concurrent users across all tenants. The architecture shall support petabyte-scale growth in DICOM data storage. All code shall adhere to defined coding standards. All code shall be analyzed for quality and security vulnerabilities using static analysis tools as part of the CI/CD pipeline. A minimum of 80% unit test code coverage shall be required for all backend services. All cloud infrastructure shall be defined and managed using Terraform.

The system shall employ a Hybrid Microservices Architecture deployed on Microsoft Azure. Services shall be containerized and orchestrated with AKS for scalability and resilience. Communication shall be routed through an API Gateway. Asynchronous tasks shall be managed via a message bus.

The frontend framework shall be React 18 with TypeScript. The frontend state management library shall be Redux Toolkit. The backend framework shall be ASP.NET Core 8 (LTS). The authentication service shall be IdentityServer6. The database technology shall be Azure SQL Database with Elastic Pools. The caching technology shall be Azure Cache for Redis. The file storage technology shall be Azure Blob Storage (Premium Tier). <<$Addition>> The system shall use Azure AI Search for probabilistic patient matching. The cloud provider shall be Microsoft Azure. The container orchestration platform shall be Azure Kubernetes Service (AKS). The CI/CD platform shall be Azure DevOps Pipelines. The Infrastructure as Code tool shall be Terraform. The monitoring suite shall be Azure Monitor, including Application Insights and Log Analytics.

The system shall provide Organization Admins with basic operational dashboards. Operational dashboards shall include the number of studies per day/week/month. Operational dashboards shall include study status distribution. Operational dashboards shall include user activity summaries. Super Admins and authorized Organization Admins shall be able to query the audit log. Super Admins and authorized Organization Admins shall be able to export the audit log for specific date ranges, users, or patients.

All application and system logs shall be structured and forwarded to a central Azure Log Analytics Workspace. Key performance indicators (KPIs) shall be collected via Application Insights. Collected KPIs shall include API request rates, latency, error rates, and CPU/memory utilization for all services. Application Insights shall be configured to trace requests across service boundaries. Alerts shall be configured in Azure Monitor to automatically notify the operations team of critical issues. An alert shall be triggered if P95 API latency exceeds 500ms for 5 minutes. An alert shall be triggered if the HTTP 5xx error rate exceeds 1% on any service. An alert shall be triggered if CPU or memory utilization exceeds 85% on any node or database. An alert shall be triggered for high-severity alerts from Microsoft Defender for Cloud.

DicomFlow: Multi-Tenant Medical Imaging Platform Version: 2.0 Date: October 26, 2023 Author: [Your Name/Team] Project: "DicomFlow" 1. Introduction 1.1 Purpose This document describes the functional and non-functional requirements for "DicomFlow," a multi-tenant, cloud-based software system for managing medical imaging workflows. The system will handle user and organization registration, patient and study management, DICOM image storage with strict data isolation, HL7 report ingestion, secure sharing, and provide a FHIR API for interoperability. 1.2 Scope DicomFlow will be a web-based application built on the .NET stack. It serves multiple independent organizations (tenants) from a single instance. The system manages the entire workflow from user registration to secure sharing and external data access. The generation of radiology reports within external Hospital Information Systems (HIS) or Radiology Information Systems (RIS) is out of scope; the system will only consume HL7 ORU messages. 1.3 Definitions, Acronyms, and Abbreviations DICOM: Digital Imaging and Communications in Medicine. HL7: Health Level Seven International. FHIR: Fast Healthcare Interoperability Resources. HL7 ORU: Observation Result Unsolicited message. Study: A collection of DICOM images and associated data from a single imaging session. Tenant: An independent organization (e.g., a hospital or radiology center) using the system. PII/PHI: Personally Identifiable Information / Protected Health Information. 2. Overall Description 2.1 Product Perspective DicomFlow is a standalone web application that integrates with existing hospital infrastructure and provides modern API access. It acts as a cloud-native PACS, HL7 listener, and FHIR server. 2.2 Product Functions (High-Level) Multi-Tenant Management & User Registration: Isolate data and configuration for each organization. Support global user registrations (Doctor, Patient, Technician) with associations to multiple tenants. Patient & Study Workflow: Ensure patient uniqueness, schedule studies, and track status. DICOM Image Handling with Strict Isolation: Receive and store images in tenant-specific and user-specific cloud containers. HL7 Report Processing: Receive and parse HL7 ORU messages. Secure, Role-Based Sharing: Control access based on user roles and tenant context. FHIR API: Provide a standards-based API for external system integration. Web-based UI: Provide role-specific dashboards and a basic DICOM viewer. 2.3 User Classes and Characteristics Super Administrator: Manages the platform backend, oversees all tenants. Organization Administrator: Manages their organization's users, settings, and studies. Doctor: Can be associated with multiple organizations. Views studies from organizations they are associated with. Technician: Can be associated with multiple organizations. Uploads/scans and manages studies within their organizations. Patient: Registered globally. Can view studies shared with them directly. Cannot access organization-specific study lists. External System: Accesses data via the FHIR API using OAuth2 credentials. 2.4 Design and Implementation Constraints Technology Stack: Backend must be implemented using the .NET 6/8 framework. Multi-tenancy: Data must be logically separated by OrganizationId. Physical storage must also be isolated. FHIR Standard: The API must comply with FHIR R4. 3. System Features 3.1 User Registration & Management (FR-UR) FR-UR-01: Organization Registration: A prospective organization shall be able to register for the platform. This creates a new tenant in a "Pending" state, awaiting activation by a Super Admin. FR-UR-02: Global User Registration: Individuals (Doctors, Patients, Technicians) shall be able to register on the platform independently of an organization. FR-UR-03: User Association: An Organization Administrator shall be able to search for globally registered Doctors and Technicians and invite them to join their organization. Accepting an invitation creates an association. FR-UR-04: Role-Based Access Control (RBAC): Super Admin: Access to all system-level features and data. Organization Admin: Full access within their organization. Doctor: Read-only access to studies within their associated organizations. Technician: Can create studies and upload images within their associated organizations. Patient: Access only to studies explicitly shared with them via a link. 3.2 Patient Registration & Uniqueness (FR-PU) FR-PU-01: The system shall allow creating a new patient record, which is globally unique. FR-PU-02: The system shall enforce patient uniqueness based on a combination of Name, Date of Birth, and a government-issued ID Number (configurable per tenant). The system shall prevent the creation of duplicate patients. FR-PU-03: When scheduling a study, the user must first search for and select an existing unique patient or create a new one if no match is found. 3.3 Multi-Tenancy & Data Isolation (FR-DI) FR-DI-01: All database entities (patients, studies, users) must be scoped by an OrganizationId. FR-DI-02: DICOM images must be stored in a cloud storage container that is physically segregated by OrganizationId (e.g., tenant-{org-id}/dicom/). FR-DI-03: When a user logs in, they must select an organization context from their list of associated organizations. All their actions and data views are then scoped to that selected organization. FR-DI-04: A Doctor or Technician can only view and interact with studies belonging to the currently selected organization context. They cannot see studies from other organizations they are associated with unless they explicitly switch context. 3.4 Secure Sharing & Access Control (FR-SA) - UPDATED FR-SA-01: Sharing shall be initiated by an authorized user (Organization Admin or Technician) within an organization context. FR-SA-02: The system shall generate a unique, secure URL for the shared study. FR-SA-03: Access to the shared link shall be restricted to: The intended Referring Physician (if they are a registered Doctor, they can access it via their account; if not, via the link). The Patient (via the link only; they do not see the organization's study list). Authorized internal users (Doctors, Technicians, Admins) of the same organization that created the share, only when they are in the correct organization context. FR-SA-04: A patient's studies cannot be automatically shared with all doctors or technicians associated with an organization. Access must be explicitly granted per study via the sharing mechanism. 3.5 FHIR Data Connectivity (FR-FHIR) FR-FHIR-01: The system shall expose a FHIR R4 compliant REST API endpoint. FR-FHIR-02: The API shall support GET operations for key FHIR resources, including: Patient - Retrieve patient details. ImagingStudy - Retrieve study metadata and series information. DiagnosticReport - Retrieve the attached radiology report. Binary - To allow access to the actual DICOM files (as a download). FR-FHIR-03: API access shall be secured using OAuth 2.0 Client Credentials grant flow, suitable for system-to-system integration. FR-FHIR-04: Data returned via the FHIR API shall be strictly scoped to the caller's tenant based on the OAuth2 client's OrganizationId. 4. Non-Functional Requirements 4.1 Performance Requirements The study list UI should load in under 2 seconds. The FHIR API should respond to GET requests in under 1 second for single-resource queries. 4.2 Security & Compliance Requirements - ENHANCED NF-SEC-01: All data must be encrypted in transit (TLS 1.2+) and at rest (AES-256). NF-SEC-02: The system must be designed to facilitate compliance with HIPAA/GDPR. This includes: Strict tenant data isolation as a core architectural principle. Comprehensive audit logs tracking every access to patient data (who, what, when, from which organization context). <<$Change>>The system's architecture and features must support the organizational and legal requirements for HIPAA/GDPR compliance.<<$/Change>> Enhancement Justification: The original statement "A formal Business Associate Agreement (BAA) with the cloud provider" is a legal and contractual obligation of the organization, not a software requirement that the system itself can implement. The revised statement clarifies that the *software* must *support* the organizational efforts to comply with HIPAA/GDPR by providing the necessary architectural principles and features, without dictating external legal agreements. This makes it a valid non-functional requirement for the software. NF-SEC-03: Patient uniqueness logic must be robust to prevent accidental PHI leakage between tenants. NF-SEC-04: The authentication and authorization system must be robust, using industry-standard libraries (e.g., IdentityServer) to manage complex user-organization relationships. 4.3 Reliability & Availability The system shall target 99.9% uptime. 4.4 Usability The process of switching between organization contexts for multi-associated users must be intuitive and clear. 5. Technical Specifications & Architecture Hints Backend: ASP.NET Core Web API. Authentication & Authorization: Implement <<$Change>>IdentityServer6<<$/Change>> or use ASP.NET Core Identity with custom policies to handle the complex multi-tenant, multi-role model. JWT tokens should include the user's associated OrganizationIds and the currently selected OrganizationId. <<$Addition>> Enhancement Justification: IdentityServer6 is the latest stable version of IdentityServer, offering continued support, security updates, and performance improvements over IdentityServer4. Updating to the latest version ensures the authentication and authorization framework remains robust and secure without altering the core functionality or architectural approach described. <<$/Addition>> Multi-tenancy Data Isolation: Use the "Database per Tenant" or "Schema per Tenant" model for strong isolation, with a shared database for global user accounts. A middleware should always validate that the user's request is scoped to a tenant they are associated with. Cloud Storage: Use Azure Blob Storage with separate containers per tenant (e.g., dicomflow-tenant-org123). Generate SAS tokens for secure, time-bound download links. FHIR API: Use the .NET FHIR Server for Azure or the Hl7.Fhir.R4 library to implement the FHIR endpoints. Ensure all endpoints correctly scope data to the OrganizationId from the OAuth2 client. Patient Uniqueness: Implement a probabilistic matching algorithm (e.g., based on Levenshtein distance for names) in addition to exact ID matching, with manual admin override for potential duplicates.

DicomFlow is a multi-tenant, cloud-based medical imaging platform built on the .NET stack. It aims to manage medical imaging workflows, including user and organization registration, patient and study management, DICOM image storage, HL7 report ingestion, secure sharing, and FHIR API interoperability. Key functionalities include: * **Multi-Tenant Management & User Registration:** Supports independent organizations (tenants) with data and configuration isolation. Allows global user registration (Doctors, Patients, Technicians) and association with multiple tenants. Organization Administrators manage users within their tenant. * **Patient & Study Workflow:** Ensures globally unique patient records based on Name, Date of Birth, and configurable ID. Facilitates study scheduling, tracking, and association with unique patients. * **DICOM Image Handling:** Stores DICOM images in physically segregated cloud storage containers per tenant, ensuring strict data isolation. * **HL7 Report Processing:** Consumes and parses HL7 ORU messages for radiology reports. * **Secure, Role-Based Sharing:** Implements granular access control based on user roles (Super Admin, Organization Admin, Doctor, Technician, Patient). Sharing of studies generates unique, secure URLs with restricted access for referring physicians, patients, and authorized internal users within the correct organizational context. * **FHIR API Connectivity:** Exposes a FHIR R4 compliant REST API for external system integration, supporting GET operations for Patient, ImagingStudy, DiagnosticReport, and Binary resources. API access is secured via OAuth 2.0 Client Credentials, with data strictly scoped to the caller's tenant. * **Web-based UI:** Provides role-specific dashboards and a basic DICOM viewer. **Non-Functional Requirements:** * **Performance:** UI loads in <2 seconds, FHIR API responses in <1 second. * **Security & Compliance:** All data encrypted in transit (TLS 1.2+) and at rest (AES-256). Designed to facilitate HIPAA/GDPR compliance through strict tenant data isolation, comprehensive audit logs, and robust patient uniqueness logic. Authentication and authorization use industry-standard libraries (e.g., IdentityServer6). * **Reliability & Availability:** Targets 99.9% uptime. * **Usability:** Intuitive process for switching between organization contexts for multi-associated users. **Technical Specifications:** Backend uses ASP.NET Core Web API. Authentication and authorization leverage IdentityServer6 or ASP.NET Core Identity. Multi-tenancy uses Database/Schema per Tenant model. Cloud storage utilizes Azure Blob Storage with tenant-specific containers and SAS tokens. FHIR API implementation uses .NET FHIR Server for Azure or Hl7.Fhir.R4 library. Patient uniqueness includes probabilistic matching.