Software Design Specification: System Context
Document Type: System-Level (Tier 1) Status: Draft Last Updated: 2026-01-25
1. Purpose
This document defines the system boundaries of PCR.AI, identifying what is inside the system scope versus external, the actors that interact with the system, and the integration points with external systems.
As a Tier 1 document, this provides synthesis and context. It does not satisfy individual requirements directly.
2. System Boundaries
2.1 What PCR.AI Is
PCR.AI is a cloud-based SaaS platform that automates PCR analysis, quality control, and result classification for clinical diagnostic laboratories.
In Scope:
| Capability | Description |
|---|---|
| Run file import | Automated (S3 monitored folder) and manual (web upload) |
| Data normalization | Convert thermocycler-specific formats to standard JSON |
| Rules-based classification | Apply configurable rules to classify results |
| Westgard QC | Statistical quality control for control samples |
| Review and amendment | Interactive error resolution with audit trail |
| LIMS export | Export classified results to external systems |
| User management | Role-based access control, authentication, MFA |
| Multi-site operation | Site-scoped data isolation and access |
| Audit logging | Immutable record of all significant actions |
| Configuration management | Kit, rule, control, and system configuration |
2.2 What PCR.AI Is Not
Out of Scope:
| Exclusion | Rationale |
|---|---|
| PCR instrument operation | Thermocyclers are external; PCR.AI processes their output files |
| Sample preparation | Physical laboratory operations precede PCR.AI |
| Patient identity management | No PII/PHI stored; all data anonymized before analysis |
| LIMS functionality | PCR.AI exports to LIMS; it does not replace LIMS |
| Result interpretation | Clinical decisions remain with laboratory personnel |
3. System Context Diagram
This diagram illustrates the high-level system context. It does not specify all implementation details.
4. External Actors
4.1 Human Actors
| Actor | Role | Primary Interactions |
|---|---|---|
| Junior Scientist | Basic user | View runs, review results, apply resolutions |
| Senior Scientist | Advanced user | All Junior actions plus reanalysis, comments |
| Manager | Oversight | All Senior actions plus trends, reports, QC review |
| Client Admin | Site administrator | User management, configuration, all operational features |
| Super Admin | System administrator | All Client Admin actions plus cross-client access, system configuration |
4.2 External Systems
| System | Integration Type | Data Flow |
|---|---|---|
| Thermocyclers | File-based (S3) | Inbound: Run files (.sds, .pcrd, .eds, .ixo) |
| LIMS/LIS | File-based (S3) | Outbound: Classified results (CSV, Excel, custom) |
| Corporate IdP | SAML 2.0 / OIDC | Bidirectional: Authentication federation |
5. Integration Points
5.1 Amazon S3 (File Storage)
Purpose: Primary storage for run files and exports.
| Folder | Direction | Trigger |
|---|---|---|
toPcrai/ | Inbound | S3 event triggers SQS for automated import |
Processing/ | Internal | Temporary during import |
Problem_Files/ | Internal | Failed imports with error logs |
LIMS_Reports/ | Outbound | Export destination for LIMS integration |
archive/ | Internal | Successfully processed files |
Integration Pattern: Event-driven via S3 notifications to SQS, processed by Lambda.
5.2 AWS Cognito (Authentication)
Purpose: User identity management, authentication, and federation.
| Capability | Implementation |
|---|---|
| Native login | ADMIN_USER_PASSWORD_AUTH flow |
| Federated login | SAML 2.0 / OpenID Connect |
| MFA | Software TOTP |
| Session management | GlobalSignOut for single-device enforcement |
| Custom attributes | custom:UserGroup, custom:VisibleSites |
Integration Pattern: Direct API calls from Laravel via AWS SDK.
5.3 Pusher (Real-time Communication)
Purpose: WebSocket-based real-time notifications and progress updates.
| Channel Type | Use Case |
|---|---|
| Public | Run import progress, export status |
| Private | User-specific notifications, comment mentions |
Integration Pattern: Laravel Broadcasting driver with Pusher backend.
5.4 Amazon SES / SendGrid (Email)
Purpose: Transactional email delivery.
| Email Type | Trigger |
|---|---|
| Account notifications | User creation, password reset |
| Comment mentions | @-tag in comments |
| Alert notifications | Threshold violations |
| Export links | Audit data export |
Integration Pattern: Laravel Mail driver; SendGrid primary, SES fallback.
5.5 Amazon SQS (Message Queue)
Purpose: Decouple asynchronous processing from synchronous requests.
| Queue | Purpose |
|---|---|
| Import queue | Run file processing from S3 events |
| Export queue | Background export generation |
Integration Pattern: Laravel Queue driver with SQS backend.
6. Deployment Context
6.1 Environment Topology
| Environment | Purpose | Database |
|---|---|---|
| Development | Feature development | Aurora Serverless v2 (dev cluster) |
| QA | Testing and validation | Aurora Serverless v2 (QA cluster) |
| Production | Live client use | Aurora Serverless v2 (production cluster) |
6.2 Multi-Tenancy Model
PCR.AI uses single-codebase, multi-deployment tenancy:
- Each client has their own AWS account resources (S3, Cognito)
- All clients share the same application codebase
- Data isolation via site-scoped access control
- Configuration isolation via client-specific settings
6.3 Data Privacy
| Property | Value |
|---|---|
| PII Storage | None - all data anonymized before analysis |
| PHI Storage | None - no protected health information stored |
| Data Residency | Configurable per client (AWS region selection) |
7. User Roles at System Boundary
7.1 Role Hierarchy
7.2 Boundary Permissions
| Capability | Junior | Senior | Manager | Client Admin | Super Admin |
|---|---|---|---|---|---|
| View assigned site data | Yes | Yes | Yes | Yes | Yes |
| View all client sites | No | No | Yes | Yes | Yes |
| Manage users | No | No | No | Yes | Yes |
| Manage configuration | No | No | No | Yes | Yes |
| Cross-client access | No | No | No | No | Yes |
| System administration | No | No | No | No | Yes |
8. Related Documents
| Document | Relationship |
|---|---|
| SDS: Architecture Overview | Component decomposition within system boundary |
| SDS: Security Architecture | Authentication and authorization design |
| SDD: Architecture | Legacy architecture documentation |
| SDD: Security | Legacy security documentation |