clqms-be/USER_STORIES.md

1608 lines
47 KiB
Markdown
Raw Normal View History

# CLQMS User Stories
> Clinical Laboratory Quality Management System - User Stories
>
> Version: 1.0
> Last Updated: 2026-01-28
---
## How to Read These Stories
Each user story follows this format:
**Story ID**: [Module]-[Number]
**Priority**: P0 (Must-have) | P1 (Should-have) | P2 (Nice-to-have) | P3 (Future)
```
As a [actor/role],
I want [feature/action],
So that [benefit/value].
```
**Acceptance Criteria:**
- [ ] Criteria 1
- [ ] Criteria 2
---
## Table of Contents
1. [Master Data Management (P0)](#1-master-data-management-p0)
2. [Order Management (P0)](#2-order-management-p0)
3. [Specimen Management (P0)](#3-specimen-management-p0)
4. [Result Management (P0)](#4-result-management-p0)
5. [Patient Visit (P1)](#5-patient-visit-p1)
6. [Instrument Integration (P1)](#6-instrument-integration-p1)
7. [Quality Control (P2)](#7-quality-control-p2)
8. [Calibration (P2)](#8-calibration-p2)
9. [Audit Trail (P2)](#9-audit-trail-p2)
10. [Inventory & Billing (P3)](#10--inventory--billing-p3)
---
## 1. Master Data Management (P0)
> **Note**: All master data stories are P0 because they are foundational prerequisites for all transactional workflows.
### VS-001: Manage Value Set Definitions
**Priority**: P0
As a **system administrator**,
I want **to manage value set definitions**,
So that **I can define and maintain lookup value categories used throughout the system**.
**Acceptance Criteria:**
- [ ] Create new value set definition with name, description, and metadata
- [ ] Update existing value set definition
- [ ] Delete value set definition (soft delete)
- [ ] List all value set definitions with pagination
- [ ] Retrieve single value set definition by ID
- [ ] Value set definitions include: name, description, category, active status
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/valuesetdef`
---
### VS-002: Manage Value Set Values
**Priority**: P0
As a **system administrator**,
I want **to manage individual values within value sets**,
So that **I can maintain the lookup options available for dropdown selections**.
**Acceptance Criteria:**
- [ ] Create new value set value with key, label, and sort order
- [ ] Update existing value set value
- [ ] Delete value set value (soft delete)
- [ ] List all values for a specific value set definition
- [ ] Filter values by active/inactive status
- [ ] Values can be marked as default
- [ ] Sort order controls display sequence in dropdowns
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/valueset`
---
### VS-003: Use JSON-Based Static Lookups
**Priority**: P0
As a **developer**,
I want **to access static lookup values from JSON files**,
So that **I can quickly load commonly-used reference data without database queries**.
**Acceptance Criteria:**
- [ ] ValueSet library provides `get($key)` method returning dropdown options
- [ ] ValueSet library provides `getRaw($key)` method returning raw JSON data
- [ ] ValueSet library provides `getLabel($key, $value)` to get text label
- [ ] ValueSet library provides `transformLabels($records, $mappings)` for batch label conversion
- [ ] JSON files stored in `app/Libraries/Data/*.json`
- [ ] Lookup results cached for performance (>95% cache hit rate)
- [ ] Cache can be cleared via `ValueSet::clearCache()`
- [ ] Common lookups include: sex, marital_status, race, ethnic, order_status, specimen_type, result_type
---
### VS-004: Refresh Value Set Cache
**Priority**: P0
As a **system administrator**,
I want **to refresh the value set cache after making changes**,
So that **the system immediately reflects updated lookup values**.
**Acceptance Criteria:**
- [ ] API endpoint: POST `/api/valueset/refresh`
- [ ] Cache refresh requires authentication
- [ ] Cache refresh returns success status
- [ ] All ValueSet library calls return fresh data after refresh
---
### TD-001: Manage Test Site Definitions
**Priority**: P0
As a **lab manager**,
I want **to define which tests are available at each laboratory site**,
So that **orders can only include tests appropriate for the testing location**.
**Acceptance Criteria:**
- [ ] Create test definition for a site
- [ ] Update test site definition
- [ ] Delete test site definition
- [ ] List all tests available at a specific site
- [ ] Filter tests by discipline, department, or specimen type
- [ ] Mark tests as active/inactive per site
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/testdefsite`
---
### TD-002: Manage Technical Test Specifications
**Priority**: P0
As a **lab technical specialist**,
I want **to define technical specifications for each test**,
So that **the system knows how to process, validate, and report test results**.
**Acceptance Criteria:**
- [ ] Define specimen type requirements
- [ ] Define container requirements
- [ ] Define result type (numeric, text, valueset, range)
- [ ] Define expected units of measure
- [ ] Define decimal precision
- [ ] Define result format options
- [ ] Link to reference range definitions
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/testdeftech`
---
### TD-003: Define Calculated Test Formulas
**Priority**: P0
As a **lab technical specialist**,
I want **to create formulas for calculated tests**,
So that **the system can automatically compute derived values from other test results**.
**Acceptance Criteria:**
- [ ] Create formula for calculated test
- [ ] Formula language supports basic arithmetic (+, -, *, /)
- [ ] Formula can reference other test results by TestID
- [ ] Formula can include constants and parentheses
- [ ] Formula validation catches circular references
- [ ] Formula calculation triggered when all dependencies are available
- [ ] Calculated results flagged as "CALC" type
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/testdefcal`
---
### TD-004: Manage Test Groups and Panels
**Priority**: P0
As a **lab manager**,
I want **to group individual tests into panels and profiles**,
So that **clinicians can order commonly-related tests as a single group**.
**Acceptance Criteria:**
- [ ] Create test group with name and description
- [ ] Add multiple tests to a group
- [ ] Remove tests from a group
- [ ] Mark group as type "GROUP" (panel) or "TITLE" (section header)
- [ ] Groups can include other groups (nested panels)
- [ ] Ordering a group automatically orders all component tests
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/testdefgrp`
---
### TD-005: Map Instruments to Tests
**Priority**: P0
As a **lab technical specialist**,
I want **to map laboratory instruments to specific tests**,
So that **instrument results can be correctly matched to patient tests**.
**Acceptance Criteria:**
- [ ] Create instrument-to-test mapping
- [ ] Define instrument test code (from analyzer)
- [ ] Define corresponding CLQMS TestID
- [ ] Define result transformation rules (if needed)
- [ ] Specify unit conversions (if needed)
- [ ] One instrument test can map to multiple CLQMS tests
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/testmap`
---
### TD-006: Auto-Select Calculated Test Parameters
**Priority**: P0
As a **laboratory information system**,
I want **to automatically add parameters required for calculated tests**,
So that **all necessary data is collected when calculated tests are ordered**.
**Acceptance Criteria:**
- [ ] System analyzes formulas for all calculated tests in order
- [ ] System identifies parameter dependencies
- [ ] System automatically adds missing parameters to order
- [ ] User notified of auto-added parameters
- [ ] Parameters cannot be removed if required by calculated test
- [ ] Dependency chain is recursive (parameters may have their own dependencies)
---
### RR-001: Manage Numeric Reference Ranges
**Priority**: P0
As a **lab technical specialist**,
I want **to define numeric reference ranges with age and sex criteria**,
So that **the system can automatically flag abnormal test results**.
**Acceptance Criteria:**
- [ ] Create reference range for a test
- [ ] Define minimum and maximum normal values
- [ ] Define age range (birth to death)
- [ ] Define sex criteria (male, female, both)
- [ ] Define race/ethnicity criteria (optional)
- [ ] System auto-flags results outside range as "abnormal"
- [ ] System finds matching range based on patient demographics
- [ ] Supports critical value thresholds
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/refnum`
---
### RR-002: Manage Threshold Reference Ranges
**Priority**: P0
As a **lab technical specialist**,
I want **to define critical value thresholds**,
So that **the system can generate urgent alerts for dangerous results**.
**Acceptance Criteria:**
- [ ] Create threshold range for a test
- [ ] Define critical low and critical high values
- [ ] Define panic values requiring immediate notification
- [ ] Threshold overrides standard reference range
- [ ] System flags threshold results as "critical"
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/refthold`
---
### RR-003: Manage Text Reference Ranges
**Priority**: P0
As a **lab technical specialist**,
I want **to define acceptable text values for qualitative tests**,
So that **the system can validate text-based results**.
**Acceptance Criteria:**
- [ ] Create text reference range for a test
- [ ] Define list of acceptable text values
- [ ] Define default/normal value
- [ ] Define abnormal values
- [ ] System validates entered text against acceptable values
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/reftxt`
---
### RR-004: Manage Value Set Reference Ranges
**Priority**: P0
As a **lab technical specialist**,
I want **to define reference ranges based on value set codes**,
So that **dropdown-based results can be validated**.
**Acceptance Criteria:**
- [ ] Create value set reference range
- [ ] Link to specific value set definition
- [ ] Mark which values are normal vs abnormal
- [ ] Define default normal value
- [ ] System flags non-default values as abnormal (optional)
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/refvset`
---
### ORG-001: Manage Accounts
**Priority**: P0
As a **system administrator**,
I want **to manage laboratory accounts**,
So that **the system can track orders and results by customer organization**.
**Acceptance Criteria:**
- [ ] Create account with name, code, and contact information
- [ ] Update account details
- [ ] Soft delete account
- [ ] List all accounts with pagination
- [ ] Assign sites to accounts
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/account`
---
### ORG-002: Manage Sites
**Priority**: P0
As a **system administrator**,
I want **to manage laboratory sites**,
So that **multi-location laboratories can track data by physical location**.
**Acceptance Criteria:**
- [ ] Create site with name, type, and location
- [ ] Define site type (hospital, clinic, reference lab, etc.)
- [ ] Link site to parent account
- [ ] Define site address and contact
- [ ] Update and soft delete sites
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/site`
---
### ORG-003: Manage Locations
**Priority**: P0
As a **system administrator**,
I want **to manage physical locations within sites**,
So that **specimens and orders can be tracked to specific areas**.
**Acceptance Criteria:**
- [ ] Create location within a site
- [ ] Define location type (phlebotomy, reception, lab, storage, etc.)
- [ ] Define location hierarchy (building, floor, room)
- [ ] Update and soft delete locations
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/location`
---
### ORG-004: Manage Disciplines
**Priority**: P0
As a **lab manager**,
I want **to manage laboratory disciplines**,
So that **tests can be organized by clinical discipline**.
**Acceptance Criteria:**
- [ ] Create discipline (e.g., Chemistry, Hematology, Microbiology)
- [ ] Define discipline code and description
- [ ] Link departments to disciplines
- [ ] Update and soft delete disciplines
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/discipline`
---
### ORG-005: Manage Departments
**Priority**: P0
As a **lab manager**,
I want **to manage laboratory departments**,
So that **tests and staff can be organized by sub-discipline**.
**Acceptance Criteria:**
- [ ] Create department within a discipline
- [ ] Define department code and description
- [ ] Link department to parent discipline
- [ ] Update and soft delete departments
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/department`
---
### ORG-006: Manage Workstations
**Priority**: P0
As a **lab manager**,
I want **to manage laboratory workstations**,
So that **orders and results can be tracked to specific instruments or work areas**.
**Acceptance Criteria:**
- [ ] Create workstation with name and type
- [ ] Link workstation to department
- [ ] Define workstation as manual or automated
- [ ] Link automated workstations to instruments
- [ ] Update and soft delete workstations
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/workstation`
---
### SPEC-001: Manage Container Definitions
**Priority**: P0
As a **lab technical specialist**,
I want **to define specimen container types**,
So that **the system can track appropriate containers for each specimen type**.
**Acceptance Criteria:**
- [ ] Create container definition
- [ ] Define container class (tube, cup, slide, etc.)
- [ ] Define container size
- [ ] Define cap color
- [ ] Define additive requirements
- [ ] Define minimum and maximum volumes
- [ ] Update and soft delete containers
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/containerdef`
---
### SPEC-002: Manage Specimen Types
**Priority**: P0
As a **lab technical specialist**,
I want **to define specimen types**,
So that **orders can specify the required biological material**.
**Acceptance Criteria:**
- [ ] Create specimen type (Blood, Urine, Tissue, etc.)
- [ ] Define specimen type code
- [ ] Link to appropriate container types
- [ ] Define collection methods
- [ ] Define storage requirements
- [ ] Update and soft delete specimen types
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/specimentype`
---
### SPEC-003: Manage Collection Methods
**Priority**: P0
As a **lab technical specialist**,
I want **to define specimen collection methods**,
So that **phlebotomy procedures can be standardized**.
**Acceptance Criteria:**
- [ ] Create collection method (Venipuncture, Catheter, etc.)
- [ ] Define method code and description
- [ ] Link to appropriate specimen types
- [ ] Update and soft delete collection methods
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/collectionmethod`
---
### SPEC-004: Manage Container Classes and Sizes
**Priority**: P0
As a **lab technical specialist**,
I want **to define container classes and sizes**,
So that **specimen containers can be consistently categorized**.
**Acceptance Criteria:**
- [ ] Container classes: tube, cup, vial, slide, bag, etc.
- [ ] Container sizes with volume capacity
- [ ] Size units (mL, L, etc.)
- [ ] Link sizes to container classes
- [ ] Manage cap color options
- [ ] API endpoints: GET/POST/PATCH/DELETE for container class and size lookup tables
---
## 2. Order Management (P0)
### ORD-001: Create Laboratory Order
**Priority**: P0
As a **ordering provider or clinical staff**,
I want **to create a laboratory order for a patient**,
So that **the laboratory can perform requested tests**.
**Acceptance Criteria:**
- [ ] Create order via POST `/api/ordertest`
- [ ] Order requires patient identification (InternalPID)
- [ ] Order requires priority (Stat/Routine/ASAP)
- [ ] Order requires ordering provider identification
- [ ] System generates unique OrderID in format: LLYYMMDDXXXXX
- LL: Lab location code
- YYMMDD: Date
- XXXXX: Sequential number
- [ ] Order includes one or more tests
- [ ] Initial order status is "ORD" (ordered)
- [ ] Order date/time recorded in UTC
- [ ] Response includes: OrderID, InternalPID, OrderStatus, list of tests
---
### ORD-002: Update Order Details
**Priority**: P0
As a **laboratory staff**,
I want **to modify order details before verification**,
So that **the order can be corrected if information was entered incorrectly**.
**Acceptance Criteria:**
- [ ] Update order via PATCH `/api/ordertest/:id`
- [ ] Can update priority
- [ ] Can update ordering provider
- [ ] Can add tests to order
- [ ] Can remove tests from order (before specimen collection)
- [ ] Updates prevented if order is verified
- [ ] Update timestamp recorded in UTC
---
### ORD-003: Delete Order
**Priority**: P0
As a **laboratory staff**,
I want **to cancel an order**,
So that **tests are not performed on cancelled orders**.
**Acceptance Criteria:**
- [ ] Delete order via DELETE `/api/ordertest/:id`
- [ ] Delete is soft delete (DelDate set, not actual deletion)
- [ ] Deleted orders not displayed in standard queries
- [ ] Delete prevented if specimens have been collected
- [ ] Delete reason must be recorded
- [ ] Deleted orders can be retrieved with include_deleted flag
---
### ORD-004: Track Order Status
**Priority**: P0
As a **laboratory staff and clinician**,
I want **to track order status through the testing workflow**,
So that **I know the current state of the order**.
**Acceptance Criteria:**
- [ ] Order status workflow: ORD → SCH → ANA → VER → REV → REP
- ORD: Ordered
- SCH: Scheduled
- ANA: Analyzing
- VER: Technical verification complete
- REV: Clinical review complete
- REP: Reported (final)
- [ ] Status can be updated via PATCH `/api/ordertest/:id/status`
- [ ] Status update requires authentication
- [ ] Status change recorded with user ID and timestamp
- [ ] Status history tracked via audit trail
- [ ] Current status included in all order responses
---
### ORD-005: Assign Order Priority
**Priority**: P0
As a **ordering provider or lab staff**,
I want **to mark orders as urgent**,
So that **critical tests are performed first**.
**Acceptance Criteria:**
- [ ] Priority options: Stat (S), Routine (R), ASAP (A)
- [ ] Stat orders appear at top of worklists
- [ ] Priority can be updated before specimen collection
- [ ] Priority displayed on all order views
- [ ] Default priority is Routine
---
### ORD-006: Attach Documents to Order
**Priority**: P0
As a **clinical staff**,
I want **to attach documents or images to an order**,
So that **relevant clinical information is available to laboratory staff**.
**Acceptance Criteria:**
- [ ] Upload attachments via POST `/api/ordertest/:id/attachments`
- [ ] Supported file types: PDF, images (PNG, JPG), documents
- [ ] File size limits enforced
- [ ] Attachments linked to ordercom/orderatt tables
- [ ] Attachment metadata includes: filename, type, size, uploader, timestamp
- [ ] Attachments can be retrieved via GET `/api/ordertest/:id/attachments`
---
### ORD-007: Map Multiple Tests to Order
**Priority**: P0
As a **ordering provider**,
I want **to include multiple tests in a single order**,
So that **related tests are performed on the same specimen**.
**Acceptance Criteria:**
- [ ] Order can include multiple tests
- [ ] Tests can be individual tests or panels
- [ ] Panels expand to component tests
- [ ] Orderitem table links OrderID to TestID
- [ ] All tests in order initially have same status
- [ ] Individual test status can be tracked independently
---
### ORD-008: Auto-Select Calculated Test Parameters
**Priority**: P0
As a **laboratory information system**,
I want **to automatically add required parameters for calculated tests**,
So that **all necessary data is collected**.
**Acceptance Criteria:**
- [ ] System detects calculated tests in order
- [ ] System analyzes formulas for calculated tests
- [ ] System adds missing parameters to order
- [ ] User notified of auto-added parameters
- [ ] Parameters cannot be removed if required
- [ ] Dependency tracking is recursive
---
### ORD-009: Identify Ordering Provider
**Priority**: P0
As a **laboratory system**,
I want **to track which provider ordered each test**,
So that **results can be sent back and questions can be directed appropriately**.
**Acceptance Criteria:**
- [ ] Order requires ordering provider identification
- [ ] Provider can be identified by ID or name
- [ ] Provider contact information stored
- [ ] Provider included in result reports
- [ ] Results can be filtered by ordering provider
---
### ORD-010: Track Order Date/Time in UTC
**Priority**: P0
As a **laboratory system**,
I want **to normalize all timestamps to UTC**,
So that **times are consistent across multiple time zones**.
**Acceptance Criteria:**
- [ ] Order date stored in UTC in database
- [ ] Order dates returned as UTC ISO 8601 format in API
- [ ] Input dates automatically converted to UTC
- [ ] Timezone information preserved in metadata
- [ ] Display can show local time based on user preference
---
## 3. Specimen Management (P0)
### SPM-001: Create Specimen from Order
**Priority**: P0
As a **phlebotomist or lab staff**,
I want **to create a specimen record for an order**,
So that **the specimen can be tracked through the laboratory workflow**.
**Acceptance Criteria:**
- [ ] Create specimen via POST `/api/specimen`
- [ ] Specimen requires OrderID
- [ ] Specimen requires SpecimenType
- [ ] System generates unique SpecimenID = OrderID + SpecimenTypeCode(3) + ContainerCode(1)
- [ ] Specimen linked to order
- [ ] Initial specimen status is "COLLECTED"
- [ ] Collection date/time recorded in UTC
---
### SPM-002: Mark Specimen as Collected
**Priority**: P0
As a **phlebotomist**,
I want **to record specimen collection**,
So that **the laboratory knows the specimen is ready for processing**.
**Acceptance Criteria:**
- [ ] Update specimen status to "COLLECTED"
- [ ] Record collection date/time
- [ ] Record collector ID
- [ ] Record collection location
- [ ] Record collection method (venipuncture, catheter, etc.)
- [ ] Collection activity logged to specmenactivity table
---
### SPM-003: Track Specimen In-Transit
**Priority**: P0
As a **courier or lab staff**,
I want **to mark specimen as in-transit**,
So that **the specimen location is known during transport**.
**Acceptance Criteria:**
- [ ] Update specimen status to "IN_TRANSIT"
- [ ] Record dispatch date/time
- [ ] Record courier/staff ID
- [ ] Record destination location
- [ ] Expected arrival time can be recorded
- [ ] Transit activity logged to specmenactivity table
---
### SPM-004: Receive or Reject Specimen
**Priority**: P0
As a **laboratory reception staff**,
I want **to receive specimens and verify acceptability**,
So that **unacceptable specimens are not processed**.
**Acceptance Criteria:**
- [ ] Update specimen status to "RECEIVED" or "REJECTED"
- [ ] Record reception date/time
- [ ] Record receiver ID
- [ ] If rejected, record rejection reason
- [ ] Rejection reasons: insufficient quantity, hemolysis, clotting, wrong container, etc.
- [ ] Rejected specimens cannot proceed to analysis
- [ ] Reception activity logged to specmenactivity table
---
### SPM-005: Prepare Specimen for Analysis
**Priority**: P0
As a **lab technician**,
I want **to record specimen preparation steps**,
So that **the specimen processing history is documented**.
**Acceptance Criteria:**
- [ ] Update specimen status to "PREPARATION"
- [ ] Preparation types: centrifuge, aliquot, pretreatment, stain, etc.
- [ ] Record preparation date/time
- [ ] Record technician ID
- [ ] Preparation activity logged to specmenactivity table
- [ ] Multiple preparation steps can be recorded
---
### SPM-006: Store Specimen
**Priority**: P0
As a **lab technician**,
I want **to record specimen storage location**,
So that **the specimen can be retrieved if needed**.
**Acceptance Criteria:**
- [ ] Update specimen status to "STORED"
- [ ] Record storage date/time
- [ ] Record storage location (freezer, refrigerator, room)
- [ ] Record technician ID
- [ ] Storage activity logged to specmenactivity table
- [ ] Storage conditions (temperature) can be recorded
---
### SPM-007: Dispatch Specimen for Referral
**Priority**: P0
As a **lab staff**,
I want **to dispatch specimen to reference laboratory**,
So that **tests not performed in-house can be completed**.
**Acceptance Criteria:**
- [ ] Update specimen status to "DISPATCHED"
- [ ] Record dispatch date/time
- [ ] Record destination (reference lab)
- [ ] Record courier/tracking information
- [ ] Dispatch activity logged to specmenactivity table
- [ ] Dispatched specimens can be tracked
---
### SPM-008: Track Specimen Condition
**Priority**: P0
As a **lab staff**,
I want **to flag specimen condition issues**,
So that **result quality issues can be identified**.
**Acceptance Criteria:**
- [ ] Condition flags can be recorded: HEM (hemolysis), ITC (insufficient), LIP (lipemic)
- [ ] Multiple conditions can be flagged
- [ ] Conditions can be recorded at any stage
- [ ] Conditions displayed on specimen and result views
- [ ] Conditions included in result reports
- [ ] Critical conditions prevent analysis
---
### SPM-009: Log Specimen Activity
**Priority**: P0
As a **laboratory system**,
I want **to maintain complete audit trail for specimen**,
So that **all specimen handling is documented**.
**Acceptance Criteria:**
- [ ] All status changes logged to specmenactivity table
- [ ] Activity record includes: SID, activity type, timestamp, user ID
- [ ] Activity history can be retrieved via GET `/api/specimen/:id/activity`
- [ ] Activity history displayed chronologically
- [ ] Activity cannot be deleted or modified
---
### SPM-010: Link Tests to Specimens
**Priority**: P0
As a **laboratory system**,
I want **to map tests to specific specimens**,
So that **results can be linked to the correct biological material**.
**Acceptance Criteria:**
- [ ] Tests from order can be assigned to specimen(s)
- [ ] One order can have multiple specimens
- [ ] Tests can be split across multiple specimens
- [ ] Test-to-specimen mapping stored in specimen table
- [ ] Results reference the specimen ID
- [ ] Result reports show specimen information for each test
---
## 4. Result Management (P0)
### RES-001: Enter Numeric Results
**Priority**: P0
As a **lab technician or instrument**,
I want **to enter numeric test results**,
So that **quantitative measurements are recorded**.
**Acceptance Criteria:**
- [ ] Create result via POST `/api/patresult`
- [ ] Result type: numeric
- [ ] Requires OrderID, TestID, ResultValue, ResultUnit
- [ ] ResultValue must be valid number
- [ ] ResultUnit must match test definition
- [ ] Decimal precision enforced
- [ ] Initial status is "ENTRY"
- [ ] UTC timestamp recorded
---
### RES-002: Enter Text Results
**Priority**: P0
As a **lab technician or pathologist**,
I want **to enter text-based results**,
So that **qualitative or descriptive findings can be recorded**.
**Acceptance Criteria:**
- [ ] Create result via POST `/api/patresult`
- [ ] Result type: text
- [ ] Requires OrderID, TestID, ResultValue (text)
- [ ] Text can be free-form or coded
- [ ] Text length limits enforced
- [ ] Initial status is "ENTRY"
- [ ] UTC timestamp recorded
---
### RES-003: Enter Value Set Results
**Priority**: P0
As a **lab technician**,
I want **to select results from dropdown options**,
So that **coded results ensure consistency**.
**Acceptance Criteria:**
- [ ] Create result via POST `/api/patresult`
- [ ] Result type: valueset
- [ ] Dropdown populated from linked value set
- [ ] Requires OrderID, TestID, ResultValue (code)
- [ ] Code must be valid value from value set
- [ ] Initial status is "ENTRY"
- [ ] UTC timestamp recorded
---
### RES-004: Enter Range Results
**Priority**: P0
As a **lab technician**,
I want **to enter range-based results**,
So that **measurements with min/max can be recorded**.
**Acceptance Criteria:**
- [ ] Create result via POST `/api/patresult`
- [ ] Result type: range
- [ ] Requires OrderID, TestID, ResultMin, ResultMax, ResultUnit
- [ ] Both min and max must be valid numbers
- [ ] ResultUnit must match test definition
- [ ] Initial status is "ENTRY"
- [ ] UTC timestamp recorded
---
### RES-005: Validate Against Reference Ranges
**Priority**: P0
As a **laboratory system**,
I want **to automatically flag results outside reference ranges**,
So that **abnormal results are highlighted for review**.
**Acceptance Criteria:**
- [ ] System retrieves reference range for test based on patient age/sex
- [ ] Numeric results compared to min/max
- [ ] Text results compared to acceptable values
- [ ] Value set results compared to normal/abnormal flags
- [ ] Results outside range flagged as "abnormal"
- [ ] Flag displayed on result entry and review screens
- [ ] Flag included in result reports
---
### RES-006: Flag Critical Values
**Priority**: P0
As a **laboratory system**,
I want **to identify critical values**,
So that **urgent results are immediately brought to attention**.
**Acceptance Criteria:**
- [ ] Critical values defined in threshold reference ranges
- [ ] Results exceeding critical thresholds flagged as "critical"
- [ ] Critical flag visually prominent in UI
- [ ] Critical results require acknowledgment
- [ ] Critical results require notification to ordering provider
- [ ] Critical notification logged
---
### RES-007: Technical Verification
**Priority**: P0
As a **lab technician or technologist**,
I want **to verify results for technical accuracy**,
So that **results are validated before clinical review**.
**Acceptance Criteria:**
- [ ] Update result status to "VER" via PATCH `/api/patresult/:id/status`
- [ ] Verification requires authenticated user
- [ ] Verifier ID recorded
- [ ] Verification timestamp recorded in UTC
- [ ] Verification requires review of reference range flags
- [ ] Verification requires review of critical values
- [ ] Bulk verification allowed for multiple results
- [ ] Verification can be reversed before clinical review
---
### RES-008: Clinical Review
**Priority**: P0
As a **pathologist or clinical reviewer**,
I want **to review results for clinical interpretation**,
So that **results are validated before reporting**.
**Acceptance Criteria:**
- [ ] Update result status to "REV" via PATCH `/api/patresult/:id/status`
- [ ] Review requires authenticated user with clinical role
- [ ] Reviewer ID recorded
- [ ] Review timestamp recorded in UTC
- [ ] Review can add clinical comments
- [ ] Review can override reference range flags with justification
- [ ] Bulk review allowed for multiple results
- [ ] Review can be reversed before reporting
---
### RES-009: Report Final Results
**Priority**: P0
As a **laboratory staff**,
I want **to finalize results for reporting**,
So that **results can be sent to clinicians**.
**Acceptance Criteria:**
- [ ] Update result status to "REP" via PATCH `/api/patresult/:id/status`
- [ ] Finalization requires clinical review complete
- [ ] Finalization timestamp recorded in UTC
- [ ] Finalizer ID recorded
- [ ] Finalized results cannot be modified (only addendum)
- [ ] Finalized results trigger report generation
- [ ] Finalized results sent to ordering provider
- [ ] Bulk finalization allowed for multiple results
---
### RES-010: Track Result Reruns
**Priority**: P0
As a **lab technician**,
I want **to record result reruns**,
So that **quality issues and repeated measurements are documented**.
**Acceptance Criteria:**
- [ ] Rerun count tracked via AspCnt field
- [ ] Rerun reason can be recorded
- [ ] Rerun timestamp recorded
- [ ] All reruns preserved (no overwriting)
- [ ] Final result selected from reruns
- [ ] Rerun history displayed with result
- [ ] Rerun cannot occur after result verification
---
### RES-011: Add Result Comments
**Priority**: P0
As a **lab technician or pathologist**,
I want **to add comments to results**,
So that **additional context and notes are preserved**.
**Acceptance Criteria:**
- [ ] Add comment via POST `/api/patresult/:id/comments`
- [ ] Comment requires text and user ID
- [ ] Comment timestamp recorded in UTC
- [ ] Comment type flag: technical, clinical, administrative
- [ ] Comments displayed with result
- [ ] Comments included in result reports
- [ ] Comments cannot be deleted (only appended)
---
### RES-012: Manage Result Details
**Priority**: P0
As a **lab technician**,
I want **to add multiple detail parameters to a result**,
So that **complex multi-part results can be recorded**.
**Acceptance Criteria:**
- [ ] Add detail via POST `/api/patresult/:id/details`
- [ ] Detail requires ParameterID and Value
- [ ] Multiple details can be added to one result
- [ ] Details can be numeric, text, or coded
- [ ] Details linked to patresultdetail table
- [ ] Details displayed with main result
- [ ] Details included in result reports
---
## 5. Patient Visit (P1)
### VIS-001: Create Patient Visit
**Priority**: P1
As a **admission or registration staff**,
I want **to create a patient visit record**,
So that **orders and results can be linked to an encounter**.
**Acceptance Criteria:**
- [ ] Create visit via POST `/api/patvisit`
- [ ] Visit requires patient identification (InternalPID)
- [ ] Visit type: inpatient, outpatient, emergency
- [ ] Visit number generated
- [ ] Admission date/time recorded in UTC
- [ ] Discharge date/time nullable (open until discharged)
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/patvisit`
---
### VIS-002: Link Orders to Visit
**Priority**: P1
As a **laboratory or clinical staff**,
I want **to associate orders with a patient visit**,
So that **laboratory work is organized by encounter**.
**Acceptance Criteria:**
- [ ] Orders can be linked to visit during creation
- [ ] Orders can be updated to link to visit
- [ ] Visit ID included in order record
- [ ] Orders can be queried by visit
- [ ] Visit details displayed with orders
---
### VIS-003: Track ADT Events
**Priority**: P1
As a **hospital staff**,
I want **to record patient admission, discharge, and transfer**,
So that **patient location is known throughout the stay**.
**Acceptance Criteria:**
- [ ] Record admission event
- [ ] Record discharge event
- [ ] Record transfer event
- [ ] Each event requires timestamp (UTC) and location
- [ ] ADT events logged to patvisit table
- [ ] Current location always available
- [ ] ADT history queryable
---
### VIS-004: Link Diagnosis to Visit
**Priority**: P1
As a **clinical staff**,
I want **to record patient diagnoses**,
So that **laboratory results can be correlated with clinical conditions**.
**Acceptance Criteria:**
- [ ] Add diagnosis via POST `/api/patvisit/:id/diagnosis`
- [ ] Diagnosis requires ICD code or text
- [ ] Diagnosis type: admission, principal, secondary
- [ ] Multiple diagnoses can be added
- [ ] Diagnoses stored in patdiag table
- [ ] Diagnoses displayed with visit
---
### VIS-005: Track Insurance Information
**Priority**: P1
As a **registration or billing staff**,
I want **to record patient insurance**,
So that **billing information is available**.
**Acceptance Criteria:**
- [ ] Add insurance via POST `/api/patvisit/:id/insurance`
- [ ] Insurance requires: company, policy number, group number
- [ ] Insurance type: primary, secondary, tertiary
- [ ] Multiple insurance policies can be added
- [ ] Insurance stored in patinsurance table
- [ ] Insurance displayed with visit
---
## 6. Instrument Integration (P1)
### EDGE-001: Receive Instrument Results
**Priority**: P1
As a **laboratory instrument via tiny-edge**,
I want **to send results to CLQMS**,
So that **results are automatically recorded in the system**.
**Acceptance Criteria:**
- [ ] Receive results via POST `/api/edge/results`
- [ ] Request includes: instrument ID, sample ID, results array
- [ ] Each result includes: test code, value, unit, timestamp
- [ ] Raw results stored in edgeres table
- [ ] Results queued for processing
- [ ] Acknowledgment returned to instrument
- [ ] Authentication required (API key or JWT)
---
### EDGE-002: Store Raw Edge Results
**Priority**: P1
As a **laboratory system**,
I want **to preserve raw instrument results**,
So that **original data is available for troubleshooting and audit**.
**Acceptance Criteria:**
- [ ] Raw results stored in edgeres table
- [ ] Raw data includes: instrument, sample, test code, value, unit, flags
- [ ] Raw data is immutable (no updates or deletes)
- [ ] Raw data linked to processed result
- [ ] Raw data queryable for troubleshooting
---
### EDGE-003: Log Instrument Status
**Priority**: P1
As a **laboratory instrument**,
I want **to send status updates**,
So that **instrument health is monitored**.
**Acceptance Criteria:**
- [ ] Send status via POST `/api/edge/status`
- [ ] Status includes: instrument ID, status code, message, timestamp
- [ ] Status stored in edgestatus table
- [ ] Status types: ready, busy, error, maintenance, offline
- [ ] Status history queryable
- [ ] Alerts triggered for error status
---
### EDGE-004: Acknowledge Order Delivery
**Priority**: P1
As a **laboratory instrument**,
I want **to acknowledge order receipt**,
So that **the system knows the order was received**.
**Acceptance Criteria:**
- [ ] Acknowledge via POST `/api/edge/orders/:id/ack`
- [ ] Acknowledgment includes: order ID, instrument ID, timestamp
- [ ] Acknowledgment stored in edgeack table
- [ ] Order marked as "acknowledged" in system
- [ ] Missing acknowledgments flagged
---
### EDGE-005: Fetch Pending Orders
**Priority**: P1
As a **laboratory instrument via tiny-edge**,
I want **to retrieve pending orders**,
So that **the instrument knows which samples to process**.
**Acceptance Criteria:**
- [ ] Fetch orders via GET `/api/edge/orders`
- [ ] Can filter by instrument ID
- [ ] Can filter by specimen status
- [ ] Response includes: OrderID, SampleID, tests, priority
- [ ] Only orders not yet acknowledged returned
- [ ] Orders marked as "sent" after retrieval
---
### EDGE-006: Acknowledge Order Delivery
**Priority**: P1
As a **laboratory instrument**,
I want **to confirm order receipt**,
So that **the system can track order delivery**.
**Acceptance Criteria:**
- [ ] Acknowledge via POST `/api/edge/orders/:id/ack`
- [ ] Acknowledgment requires instrument ID
- [ ] Acknowledgment timestamp recorded
- [ ] Acknowledgment stored in edgeack table
- [ ] Failed acknowledgments retried
---
### EDGE-007: Process Edge Results to Patient Results
**Priority**: P1
As a **laboratory system**,
I want **to automatically process raw edge results into patient results**,
So that **instrument results become part of the patient record**.
**Acceptance Criteria:**
- [ ] System polls edgeres table for unprocessed results
- [ ] Test code mapped to TestID via testmap
- [ ] Sample ID mapped to OrderID/SpecimenID
- [ ] Result value and unit converted if needed
- [ ] Reference range validation performed
- [ ] Result created in patresult table with status "ENTRY"
- [ ] Raw result marked as processed
- [ ] Processing errors logged
---
## 7. Quality Control (P2)
### QC-001: Enter QC Results
**Priority**: P2
As a **lab technician**,
I want **to enter quality control results**,
So that **instrument performance is monitored**.
**Acceptance Criteria:**
- [ ] Create QC result via POST `/api/qcresult`
- [ ] QC result requires: instrument, lot number, level, test, value
- [ ] QC results stored in calres table
- [ ] QC result timestamp recorded in UTC
- [ ] QC result linked to QC material lot
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/qcresult`
---
### QC-002: Prepare Levey-Jennings Data
**Priority**: P2
As a **lab manager or quality officer**,
I want **to retrieve Levey-Jennings chart data**,
So that **QC trends can be visualized**.
**Acceptance Criteria:**
- [ ] Get QC data via GET `/api/qcresult/levey-jennings`
- [ ] Requires instrument, test, lot, level, date range
- [ ] Returns: mean, SD, values, timestamps
- [ ] Data formatted for charting libraries
- [ ] Includes control limits (±2SD, ±3SD)
---
### QC-003: Validate QC Results
**Priority**: P2
As a **laboratory system**,
I want **to automatically validate QC results**,
So that **out-of-control QC is flagged**.
**Acceptance Criteria:**
- [ ] System applies Westgard rules (or 2SD rule)
- [ ] Rules: 1:2s warning, 1:3s rejection, 2:2s rejection, etc.
- [ ] Out-of-control QC flagged
- [ ] Flagged QC prevents patient result release
- [ ] QC override requires justification
---
### QC-004: Calculate Sigma Metrics
**Priority**: P2
As a **lab manager or quality officer**,
I want **to calculate sigma metrics**,
So that **method performance can be evaluated**.
**Acceptance Criteria:**
- [ ] Calculate via GET `/api/qcresult/sigma`
- [ ] Requires: test, total allowable error (TEa), CV, bias
- [ ] Formula: Sigma = (TEa - bias) / CV
- [ ] Returns sigma value and quality ranking
- [ ] Rankings: world class (>6), excellent (5), good (4), marginal (3), poor (<3)
---
### QC-005: Query QC History
**Priority**: P2
As a **lab manager or quality officer**,
I want **to review QC history**,
So that **long-term trends can be analyzed**.
**Acceptance Criteria:**
- [ ] Query via GET `/api/qcresult/history`
- [ ] Can filter by instrument, test, lot, date range
- [ ] Returns all QC results with timestamps
- [ ] Includes calculated statistics (mean, SD, CV)
- [ ] Results downloadable as CSV
---
## 8. Calibration (P2)
### CAL-001: Enter Calibration Results
**Priority**: P2
As a **lab technician**,
I want **to record calibration results**,
So that **instrument calibration is documented**.
**Acceptance Criteria:**
- [ ] Create calibration via POST `/api/calibration`
- [ ] Calibration requires: instrument, test, calibrator, factor, result
- [ ] Calibration stored in calres table
- [ ] Calibration timestamp recorded in UTC
- [ ] Calibration type: initial, periodic, after maintenance
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/calibration`
---
### CAL-002: Query Calibration History
**Priority**: P2
As a **lab manager or quality officer**,
I want **to review calibration history**,
So that **instrument performance over time is documented**.
**Acceptance Criteria:**
- [ ] Query via GET `/api/calibration/history`
- [ ] Can filter by instrument, test, date range
- [ ] Returns all calibrations with factors and results
- [ ] Includes calibration type and technician
- [ ] Results downloadable as CSV
---
### CAL-003: Validate Calibration
**Priority**: P2
As a **laboratory system**,
I want **to validate calibration results**,
So that **out-of-spec calibration is flagged**.
**Acceptance Criteria:**
- [ ] Calibration result compared to acceptable range
- [ ] Out-of-spec calibration flagged
- [ ] Flagged calibration prevents patient testing
- [ ] Calibration override requires justification
- [ ] Calibration failure triggers maintenance request
---
## 9. Audit Trail (P2)
### AUD-001: Automatic Audit Logging
**Priority**: P2
As a **laboratory system**,
I want **to automatically log all data changes**,
So that **complete audit trail is maintained**.
**Acceptance Criteria:**
- [ ] Middleware intercepts all create/update/delete operations
- [ ] Audit record includes: table, record ID, action, user, timestamp
- [ ] Before and after values captured
- [ ] IP address and user agent logged
- [ ] Audit records stored in audit table
- [ ] Audit records are immutable
---
### AUD-002: Track What/Who/When
**Priority**: P2
As a **compliance officer or auditor**,
I want **to see complete change history**,
So that **data provenance is documented**.
**Acceptance Criteria:**
- [ ] Query via GET `/api/audit`
- [ ] Can filter by table, record, user, date range, action
- [ ] Returns: action, table, record, user, timestamp, before, after
- [ ] Results sorted chronologically
- [ ] Supports pagination
---
### AUD-003: Log Security Events
**Priority**: P2
As a **laboratory system**,
I want **to log authentication and authorization events**,
So that **security incidents can be investigated**.
**Acceptance Criteria:**
- [ ] Login attempts logged (success and failure)
- [ ] Logout events logged
- [ ] Failed authorization attempts logged
- [ ] Password changes logged
- [ ] Permission changes logged
- [ ] Events include: user, IP, timestamp, result
---
### AUD-004: Query Audit Logs
**Priority**: P2
As a **compliance officer or auditor**,
I want **to search audit logs**,
So that **specific events can be investigated**.
**Acceptance Criteria:**
- [ ] Query via GET `/api/audit/search`
- [ ] Search parameters: table, record, user, action, date range, keyword
- [ ] Returns matching audit records
- [ ] Results sorted by relevance or chronology
- [ ] Supports export to CSV/JSON
---
## 10. Inventory & Billing (P3)
### INV-001: Manage Counters
**Priority**: P3
As a **system administrator**,
I want **to manage system counters**,
So that **sequential IDs can be generated**.
**Acceptance Criteria:**
- [ ] Create counter via POST `/api/counter`
- [ ] Counter requires: name, prefix, current value
- [ ] Counter can be incremented
- [ ] Counter can be reset
- [ ] Counters used for OrderID, SpecimenID, ResultID generation
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/counter`
---
### INV-002: Manage Product Catalog
**Priority**: P3
As a **inventory manager**,
I want **to maintain product catalog**,
So that **reagents and consumables are tracked**.
**Acceptance Criteria:**
- [ ] Create product via POST `/api/product`
- [ ] Product requires: name, code, category, unit
- [ ] Product includes: manufacturer, catalog number
- [ ] Products can be marked as active/inactive
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/product`
---
### INV-003: Track Reagent Lots
**Priority**: P3
As a **inventory manager**,
I want **to track reagent lot numbers and expiration**,
So that **QC can be linked to specific lots**.
**Acceptance Criteria:**
- [ ] Create lot via POST `/api/reagentlot`
- [ ] Lot requires: product, lot number, expiration date
- [ ] Lot includes: received date, quantity, location
- [ ] Lots can be marked as open/closed
- [ ] Expired lots flagged
- [ ] API endpoints: GET/POST/PATCH/DELETE `/api/reagentlot`
---
### INV-004: Track Consumable Usage
**Priority**: P3
As a **lab technician**,
I want **to record consumable usage**,
So that **inventory is accurate**.
**Acceptance Criteria:**
- [ ] Create usage record via POST `/api/consumableusage`
- [ ] Usage requires: product, quantity, test or order
- [ ] Usage timestamp recorded
- [ ] Usage linked to user ID
- [ ] Usage updates inventory quantity
- [ ] Low inventory alerts triggered
---
### INV-005: Export Billing Data
**Priority**: P3
As a **billing staff**,
I want **to export completed orders for billing**,
So that **charges can be generated**.
**Acceptance Criteria:**
- [ ] Export via GET `/api/billing/export`
- [ ] Can filter by date range, account, order status
- [ ] Export includes: OrderID, PatientID, tests, dates
- [ ] Export format: CSV, JSON, or HL7
- [ ] Billing codes included (CPT, LOINC)
- [ ] Export marks orders as "billed"
---
### INV-006: Select Service Class
**Priority**: P3
As a **ordering provider**,
I want **to select service class for billing**,
So that **appropriate pricing is applied**.
**Acceptance Criteria:**
- [ ] Service class options: routine, urgent, stat, research, etc.
- [ ] Service class selected during order creation
- [ ] Service class affects billing tier
- [ ] Service class included in billing export
- [ ] Service class can be updated before billing
---
## Summary Statistics
**Total User Stories**: 103
**By Priority:**
- P0 (Must-have): 75
- P1 (Should-have): 10
- P2 (Nice-to-have): 13
- P3 (Future): 5
**By Module:**
- Master Data: 28 stories
- Order Management: 10 stories
- Specimen Management: 10 stories
- Result Management: 12 stories
- Patient Visit: 5 stories
- Instrument Integration: 7 stories
- Quality Control: 5 stories
- Calibration: 3 stories
- Audit Trail: 4 stories
- Inventory & Billing: 6 stories
---
## User Story Mapping
### MVP Sprint 1: Foundation (Weeks 1-4)
- All Master Data stories (28 stories)
### MVP Sprint 2: Orders & Specimens (Weeks 5-8)
- Order Management stories (10 stories)
- Specimen Management stories (10 stories)
### MVP Sprint 3: Results (Weeks 9-12)
- Result Management stories (12 stories)
### MVP Sprint 4: Integration (Weeks 13-16)
- Patient Visit stories (5 stories)
- Instrument Integration stories (7 stories)
### Post-MVP: Enhancement (Weeks 17+)
- Quality Control stories (5 stories)
- Calibration stories (3 stories)
- Audit Trail stories (4 stories)
- Inventory & Billing stories (6 stories)
---
**Document Status**: Draft for Review
**Last Updated**: 2026-01-28
**Next Review**: Prior to Sprint 1 kickoff