## Introduction

# Introduction

This document defines the functional, business, and technical requirements, as well as the current limitations, for the order management and CSV import features of the system. The requirements and constraints outlined herein are derived exclusively from the current system architecture, operational needs, and stakeholder feedback as documented in the provided source material.

The primary business driver for these requirements is to significantly improve operational efficiency for corporate customers, who have expressed a strong need to import large volumes of orders (ranging from 100 to 10,000) via CSV files, rather than entering orders individually through the REST API or administrative interface. The existing order management system only supports single-order creation, which has been identified as a major bottleneck for high-volume clients. The proposed CSV import functionality is intended to address this gap and support the business process improvements required by these stakeholders [KB-155b5f4a-d232-4166-bb96-ba158f86ceb1], [KB-1603dccf-0e13-426d-a4c3-527af9e69c16], [KB-161f44bf-9450-491f-b894-1fd70c185060].

The scope of this document includes:

- Functional requirements for order creation, listing, and status management
- Constraints and limitations of the current system, including lack of batch or bulk order creation, absence of CSV/file-based import, and one-to-one payment processing per order
- Data model and interface requirements for order and payment services
- Identified technical and architectural limitations that impact the feasibility and performance of bulk operations
- Business rules and acceptance criteria for CSV import and order management

The document also highlights the architectural changes required to support CSV import and batch processing, as well as the impact of these changes on the Order Service, Payment Service, and Notification Service [KB-110bd1b1-0680-48fd-9bf9-6a5929dbbdec].

This requirements specification is intended for system architects, developers, QA engineers, and business stakeholders involved in the design, implementation, and validation of the order management and CSV import features. All requirements and constraints are traceable to the source documentation and reflect the current state of the system as well as the desired enhancements.

For details on the current system limitations, refer to the summary table below:

| ID      | Limitation                                                                                                          | Impact Area          | Severity   |
|---------|---------------------------------------------------------------------------------------------------------------------|----------------------|------------|
| LIM-001 | Order creation is single-entry only. No bulk or batch order creation capability exists. Orders can only be created one at a time via the REST API.         | Order Service        | High       |
| LIM-002 | No CSV/file-based order import functionality. There is no endpoint or mechanism to upload and process order data from files (CSV, Excel, etc.).            | Order Service        | High       |
| LIM-003 | Payment processing handles one transaction at a time. No batch payment API exists. Each order requires an individual payment API call.                     | Payment Service      | High       |
| LIM-004 | Notifications are sent individually per order. No bulk notification capability exists. Each notification requires a separate API call.                      | Notification Service | Medium     |
| LIM-005 | Cross-service calls are sequential. Order creation flow (Order → Payment → Notification) executes sequentially. No parallel processing of payment and notification. | All Services         | Medium     |
| LIM-006 | No progress tracking for batch operations. The system has no mechanism to track progress of multi-item operations because no batch operations exist.        | All Services         | Medium     |

[KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0f930ddc-3571-41a3-9aac-3588586dee43], [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6], [KB-150eb89c-77b0-415b-a547-3ed0502eec24]

This document is ISO-29148 compliant and will serve as the authoritative reference for all future development and validation activities related to order management and CSV import enhancements.

## Getting Started

# 1. Getting Started

## 1.1 Purpose

This section provides an overview of the current system capabilities and limitations for order management and related services. It is intended to guide users, administrators, and integrators in understanding the baseline functionality, constraints, and operational context prior to system use or migration. All information below is based strictly on the current system documentation and requirements.  
[KB-146a6a29-932f-485d-96d6-6a92ee610336]

---

## 1.2 System Overview

The order management system is a web-based application with a React single-page application (SPA) frontend, connecting to three backend microservices via REST API. All inter-service communication is synchronous REST over HTTP. There is no message broker, event bus, or asynchronous communication channel.  
[KB-050d0be4-11bc-4945-80c9-1f59d3187e45]

### Key Features

- Single order creation via REST API or management UI.
- Search and filter orders by customer name/email (client-side).
- Order detail view aggregates data from all three services in parallel (order, payment, notification).
- No bulk or batch order creation capability.
- No CSV/file-based order import functionality.
- Payment and notification processing are strictly one-to-one per order.
- No real-time dashboard updates; polling-based only.
- System supports only Japanese language; no internationalization (i18n) framework.
[KB-16181d30-2dd3-421e-bab0-939cd85255d2]  
[KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]  
[KB-146a6a29-932f-485d-96d6-6a92ee610336]  
[KB-017cfb36-bd85-4935-a73e-91861c478baa]

---

## 1.3 Critical System Limitations

The following table summarizes the main limitations of the current system:

| ID      | Limitation                                                                                                   | Impact Area          | Severity   |
|---------|--------------------------------------------------------------------------------------------------------------|----------------------|------------|
| LIM-001 | Order creation is single-entry only. No bulk or batch order creation capability exists.                      | Order Service        | High       |
| LIM-002 | No CSV/file-based order import functionality. No endpoint or mechanism to upload and process order data.     | Order Service        | High       |
| LIM-003 | Payment processing handles one transaction at a time. No batch payment API exists.                           | Payment Service      | High       |
| LIM-004 | Notifications are sent individually per order. No bulk notification capability exists.                       | Notification Service | Medium     |
| LIM-005 | Cross-service calls are sequential. No parallel processing of payment and notification.                      | All Services         | Medium     |
| LIM-006 | No progress tracking for batch operations. No mechanism to track progress of multi-item operations.          | All Services         | Medium     |
[KB-146a6a29-932f-485d-96d6-6a92ee610336]  
[KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]  
[KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

#### Additional Notes

- There is no UI for bulk order import (no CSV upload, drag-and-drop, or batch creation form).
- The dashboard aggregates statistics only on the client side; no backend list-all endpoints.
- Real-time updates are not supported; only polling is available.
- The system is single-language (Japanese).
[KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]  
[KB-017cfb36-bd85-4935-a73e-91861c478baa]

---

## 1.4 Order Creation Flow

Order creation is performed one order at a time via the REST API or the management UI. The process is strictly sequential:

1. Order is created (Order Service).
2. Payment is processed (Payment Service).
3. Notification is sent (Notification Service).

Each step must complete before the next begins. There is no parallel or batch processing capability.  
[KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf]  
[KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]  
[KB-150eb89c-77b0-415b-a547-3ed0502eec24]

---

## 1.5 API and Data Model Constraints

- All order, payment, and notification APIs operate on a single resource per request.
- Maximum payment amount per transaction is 1,000,000 JPY.
- There is no support for batch or group operations at the API or schema level (e.g., no batch_id, bulk_import_group, or csv_source fields).
- Each payment is strictly 1:1 with an order (enforced by unique constraint).
[KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2]  
[KB-0f930ddc-66b7-46ea-a319-5b56de9277d1]  
[KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6]

---

## 1.6 Performance Considerations

- High-volume order processing (e.g., 10,000 orders) requires 10,000 individual API calls.
- Notification service is rate-limited to 10 requests per second; sending 10,000 notifications requires at least 1,000 seconds (~17 minutes).
- Order creation latency is the sum of order save, payment, and notification times due to sequential processing.
[KB-150eb89c-77b0-415b-a547-3ed0502eec24]  
[KB-06c5403a-d177-4525-b247-1d7ae37a86b8]

---

## 1.7 User Interface

- The order management UI displays a disabled CSV Import button labeled “CSVインポート（未実装）” and a banner indicating CSV import is not available.
- All order search and filtering is performed client-side.
- Order detail views aggregate data from all three backend services in parallel for a single order.
[KB-16181d30-2dd3-421e-bab0-939cd85255d2]

---

## 1.8 Getting Help

For questions regarding system limitations, feature requests, or integration support, contact the system architecture team at architecture@dentalcarepro.com.  
[KB-02bc6ee3-521e-4ebf-b934-b7e08bd16081]

---

## 1.9 Summary

The current system is designed for single-order processing only. Bulk or batch operations, including CSV import, are not supported. All integrations and user workflows must operate within these constraints. Any requirements for bulk processing or import will require significant architectural changes across multiple services.  
[KB-146a6a29-932f-485d-96d6-6a92ee610336]

## Build and Test

# 6. Build and Test

## 6.1 Build Process

The system is built using a microservices architecture, with each service (Order Service, Payment Service, Notification Service) deployed as a Spring Boot application. The deployment targets ECS Fargate clusters, and the data layer is implemented on PostgreSQL 16 (AWS RDS). The build pipeline includes the following steps:

- Source code compilation and packaging for each service
- Database schema migrations executed via Flyway
- Container image build and push to the registry
- Automated deployment to ECS Fargate clusters
- Integration with AWS KMS for encryption key management
- Configuration of TLS 1.3 for all service-to-service and client-to-service communications

**Build Artifacts:**
- Spring Boot JARs for API and supporting services
- Docker container images for each service
- Flyway migration scripts for schema management

**References:**  
[KB-0e90d327-2678-405f-b35a-294b5435dc66]  
[KB-17a58f06-2387-412d-bf37-2f4d751e1d7e]  
[KB-1a54c453-d6ee-488f-bbdc-311c467a9661]  
[KB-116f84fb-2eec-4493-9762-414a92624981]

---

## 6.2 Test Strategy

Testing is conducted at multiple levels to ensure functional correctness, security, performance, and compliance with regulatory requirements.

### 6.2.1 Unit and Integration Testing

- **Unit tests**: All business logic and data access layers are covered, with a minimum of 80% line coverage required.
- **Integration tests**: Run against a PostgreSQL test instance, verifying end-to-end flows for order creation, payment processing, and notification delivery.
- **Security tests**: Authentication, authorization, and input validation are tested, including OAuth2/Azure AD integration, CSRF protection, and rate limiting.

**References:**  
[KB-0a1640fc-f63e-4c6b-8191-220e34d8af3f]  
[KB-0910e88e-c115-4412-a137-d96b5c1a2082]  
[KB-0667f620-e2f7-4030-8e28-f56315efb7d0]

### 6.2.2 System and Acceptance Testing

- **System test cases** cover all functional requirements, including order lifecycle, payment, and notification flows.
- **User Acceptance Testing (UAT)** is performed by end users (front desk, billing staff, clinicians) in a staged rollout, with acceptance criteria defined per module.

|   Phase | Module               | UAT Participants                     | Duration   | Status   |
|---------|----------------------|--------------------------------------|------------|----------|
|       1 | Patient Registration | Front desk staff (3), Office mgr (1) | 1 week     | Complete |
|       1 | Scheduling           | Front desk (3), Dentists (2)         | 1 week     | Complete |
|       2 | Insurance / Billing  | Billing staff (4), Office mgr (1)    | 2 weeks    | Planned  |
|       3 | Clinical Notes       | Dentists (4), Hygienists (3)         | 2 weeks    | Planned  |
|       4 | Imaging / Labs / Rx  | Dentists (4), Hygienists (3)         | 1 week     | Planned  |
|       5 | Reports / Admin      | Office mgr (2), IT                   | 1 week     | Planned  |

**Reference:**  
[KB-169a3eb6-41b7-4fce-a195-bdee1db5c1dd]

### 6.2.3 Migration and Data Integrity Testing

- **Parallel run**: Both legacy and new systems are operated in parallel for a minimum of two weeks. Key metrics (patient registrations, appointments, financial totals, claims, payments, clinical notes, logins) are compared with strict tolerances.
- **Data migration**: Record counts and checksums are validated post-migration. Financial balances are reconciled to within $0.01. MRN uniqueness and foreign key integrity are verified.

| Comparison Test                 | Tolerance   | Alert Level         |
|---------------------------------|-------------|---------------------|
| New patient registrations match | 0           | Critical            |
| Appointment count matches       | 0           | Critical            |
| Daily financial totals match    | $0.01       | Critical            |
| Claims submitted match          | 0           | High                |
| Payments posted match           | $0.01       | Critical            |
| Clinical note count matches     | 0           | High                |
| User login count comparison     | ±5%         | Low (expected diff) |

**References:**  
[KB-092b662f-1233-4421-8d2b-ae9705639cfc]  
[KB-0368630b-7eb5-445e-aa3b-de044dd2e57a]  
[KB-05e90e5d-09da-4f67-85af-8f2be11cd2ce]

### 6.2.4 Performance Testing

- **API response times** are measured to meet or exceed SLA targets:
  - p50: <200ms
  - p95: <500ms
  - p99: <1,000ms
- **Page load times**: <2 seconds initial, <1 second subsequent
- **Concurrent users**: 500+ supported
- **Database query time**: <100ms average

| Metric                      | Target                    | Measurement              |
|-----------------------------|---------------------------|--------------------------|
| API response time (p50)     | < 200ms                   | Application metrics      |
| API response time (p95)     | < 500ms                   | Application metrics      |
| API response time (p99)     | < 1,000ms                 | Application metrics      |
| Page load time (initial)    | < 2 seconds               | Lighthouse measurement   |
| Page load time (subsequent) | < 1 second                | Client-side metrics      |
| System availability         | 99.9% (8.77 hrs/year max) | Uptime monitoring        |
| Concurrent users            | 500+ simultaneous         | Load testing             |
| Database query time (avg)   | < 100ms                   | RDS Performance Insights |

**Reference:**  
[KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

### 6.2.5 Security and Compliance Testing

- **Security tests** include authentication, authorization, input validation, and output encoding.
- **PHI audit logging** is verified for all access and modification events.
- **Error handling** is validated to ensure no PHI, stack traces, or internal details are exposed in production error responses.
- **De-identification** is enforced in all test and development environments.

**References:**  
[KB-0a1640fc-f63e-4c6b-8191-220e34d8af3f]  
[KB-03f9d790-a1e6-46b9-8aeb-0fc45505be6a]  
[KB-10300d8a-a98a-4726-9be3-3957c2fe7bf4]

---

## 6.3 Rollback and Recovery Testing

- **Rollback plans** are documented and tested, including blue/green deployment rollback, database backup restoration, and full migration rollback in staging.
- **Test schedule:** Blue/green and backup restoration are tested monthly; full migration rollback is tested quarterly.

| Test                              | Frequency     | Last Test   | Next Test   | Result   |
|-----------------------------------|---------------|-------------|-------------|----------|
| Blue/green deployment rollback    | Monthly       | 2025-07-15  | 2025-08-15  | Pass     |
| Database backup restoration       | Monthly       | 2025-07-15  | 2025-08-15  | Pass     |
| Full migration rollback (staging) | Quarterly     | 2025-06-01  | 2025-09-01  | Pass     |
| Service-level rollback            | Monthly       | 2025-07-15  | 2025-08-15  | Pass     |

**References:**  
[KB-0e7db777-ce75-42c0-aac9-256614f5e8a4]  
[KB-04c5b64b-0ba0-40cd-864f-395e17b12504]  
[KB-190fe16f-a70b-4fa5-869a-fcb047547798]

---

## 6.4 Accessibility and Usability Testing

- **Accessibility:** The React UI is tested for WCAG 2.1 AA compliance.
- **Usability:** User acceptance and workflow validation are performed by representative end users.

**Reference:**  
[KB-0a1640fc-f63e-4c6b-8191-220e34d8af3f]

---

## 6.5 Known Gaps and Limitations

- **No bulk or batch order creation:** All orders must be created individually via REST API. CSV/file-based import is not supported.  
  [KB-146a6a29-932f-485d-96d6-6a92ee610336]
- **No batch payment or notification APIs:** Payment and notification processing are strictly one-to-one per order, with no aggregation or parallelization.  
  [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]
- **No progress tracking for batch operations:** The system does not provide progress bars or status tracking for multi-item operations.  
  [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]
- **No client CSV import UI:** The UI disables CSV import features and displays a warning that the feature is not implemented.  
  [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

---

## 6.6 Test Completion Criteria

- All unit, integration, and system tests must pass.
- UAT sign-off is required for each module.
- Data migration and parallel run must show zero or within-tolerance discrepancies.
- Security and compliance tests must be passed, with no critical findings outstanding.
- Rollback and recovery procedures must be validated in staging.

---

**End of Build and Test Section**

## Contribute

[GAP: Missing data for Contribute]