## Introduction

# 1. Introduction

This document provides a comprehensive overview of the current system limitations and requirements for order management, payment processing, and notification services within the DentalCare Pro ecosystem. The focus is on the constraints and operational boundaries of the existing architecture, particularly regarding bulk order import, batch processing, and cross-service integrations.

The current system is designed to process orders, payments, and notifications on a per-transaction basis. There is no capability for bulk or batch operations such as CSV file import, batch payment processing, or bulk notification delivery. All inter-service communications are handled via synchronous REST API calls, with each request limited to a single order or notification. This architecture imposes significant performance and scalability constraints, especially when handling large volumes of orders (e.g., 10,000 orders require 10,000 individual API calls) [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-150eb89c-77b0-415b-a547-3ed0502eec24].

The documentation outlines the following key aspects:

- **System Limitations:** Detailed constraints on order creation, payment processing, notification delivery, and the absence of bulk/batch features.
- **Functional and Interface Requirements:** Specifications for REST API endpoints, data models, and operational workflows.
- **Performance and Reliability Considerations:** Impact of sequential processing, rate limits, and lack of parallelization on system throughput and user experience.
- **Security and Compliance:** Requirements for secure error handling, data protection, and regulatory adherence.

This document serves as a foundational reference for stakeholders, architects, and developers involved in system maintenance, enhancement, or migration planning. All requirements and limitations described herein are based strictly on the current system state as documented in the knowledge base, and any future feature development (such as bulk import or batch processing) will require significant architectural changes across multiple services [KB-146a6a29-932f-485d-96d6-6a92ee610336].

## Getting Started

# 2. Getting Started

## 2.1 System Access and User Interface

The order management system provides a web-based interface for users to manage orders. The frontend is a React single-page application (SPA) that connects to three backend microservices via REST API. All inter-service communication is synchronous REST over HTTP, with no support for asynchronous messaging or event-driven patterns. The system supports search and filtering of orders by customer name and email, status filtering, and sortable order tables. Order details can be viewed by fetching data in parallel from all three backend services (Order, Payment, Notification) for a given order ID. [KB-050d0be4-11bc-4945-80e4-1f59d3187e45], [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

## 2.2 Order Creation

Order creation is performed one order at a time. There is no bulk or batch order creation capability. Each order must be entered individually via the REST API or the management interface. The system does not provide endpoints or mechanisms for uploading and processing order data from files (such as CSV or Excel). [KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]

### Order Creation Workflow

| Step | Action                                             |
|------|----------------------------------------------------|
| 1    | Enter customer information (name, email)           |
| 2    | Enter order details (item name, quantity, unit price) |
| 3    | System calculates total order amount automatically |
| 4    | Submit order for processing                        |

- Each order triggers a payment process and a notification process, both executed sequentially. [KB-033639ab-c6f8-4f72-a373-bf76d05dd6cf], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

## 2.3 Payment and Notification Processing

- Payment processing is handled one transaction at a time. There is no batch payment API; each order requires an individual payment API call. [KB-10744011-e9ca-48b5-ac6d-4f9f3627b7e6], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c]
- Notifications (such as order confirmation emails) are sent individually per order. No bulk notification capability exists. [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a], [KB-06c5403a-d177-4525-b247-1d7ae37a86b8]

## 2.4 System Limitations

The following limitations are critical for all users and integrators:

| Limitation ID | Description                                                                                      | Impact Area     | Severity |
|---------------|--------------------------------------------------------------------------------------------------|-----------------|----------|
| LIM-001       | Order creation is single-entry only. No bulk/batch order creation capability exists.             | Order Service   | High     |
| LIM-002       | No CSV/file-based order import functionality.                                                    | 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    | 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.                                                       | All Services    | Medium   |

[KB-146a6a29-932f-485d-96d6-6a92ee610336], [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f], [KB-05b70fbd-4026-4ac9-b1e2-e21dabe7da5c], [KB-0a7d4d64-4d48-4214-94eb-2f3f278ec66a]

## 2.5 CSV Import Functionality

**CSV import and bulk order creation are not available.** The UI displays a disabled CSV Import button labeled “CSVインポート（未実装）” and an amber warning banner indicating CSV import is not available. [KB-16181d30-2dd3-421e-bab0-939cd85255d2]

## 2.6 Getting Help

For questions about system access, limitations, or workflow, contact your system administrator or refer to the internal user guide.

---

**Note:** Any features requiring bulk operations, CSV import, or batch processing are not supported in the current system. Architectural changes across multiple services would be required to support such capabilities. [KB-146a6a29-932f-485d-96d6-6a92ee610336]

## Build and Test

# 6. Build and Test

## 6.1 Build Process

### 6.1.1 Source Code Management

- All source code is maintained in a version-controlled repository.
- Code changes are subject to peer review and must pass automated CI checks before merging.  
[GAP: Missing data for Build and Test]

### 6.1.2 Technology Stack

| Component            | Technology                      | Version      | End of Life                   |
|----------------------|---------------------------------|--------------|-------------------------------|
| Programming Language | Visual Basic 6.0 (legacy)       | SP6          | 2008 (extended support ended) |
| Programming Language | Java (Spring Boot migration)    | [GAP: Missing version] | [GAP: Missing data]          |
| Runtime              | VB6 Runtime (MSVBVM60.dll)      | 6.0 SP6      | Included in Windows           |
| UI Framework         | VB6 WinForms                    | 6.0          | N/A                           |
| Data Access          | ADO (ActiveX Data Objects)      | 2.x          | [GAP: Missing data]           |
| ORM/Data Access      | Spring Data JPA + Hibernate     | 6.4          | [GAP: Missing data]           |
| Database             | SQL Server 2012 + MS Access     | [legacy]     | EOL                           |
| Database             | PostgreSQL 16 (AWS RDS)         | [target]     | Supported                     |
| Authentication       | Custom (MD5 hash, legacy)       | [legacy]     | Deprecated                    |
| Authentication       | Spring Security 6.x + OAuth 2.0 | [target]     | Supported                     |
| Reporting            | Crystal Reports XI (legacy)     | [legacy]     | [GAP: Missing data]           |
| Reporting            | JasperReports (target)          | [target]     | Supported                     |
| Audit Logging        | PostgreSQL, CloudWatch, Elasticsearch | [target] | Supported                     |

[KB-03d0d4be-6781-4fc5-af90-de8b326616c0]  
[KB-17a58f06-2387-412d-bf37-2f4d751e1d7e]  
[KB-1a54c453-d6ee-488f-bbdc-311c467a9661]

### 6.1.3 Build Automation

- Spring Boot modules are built using standard Maven/Gradle pipelines.
- Automated builds include static analysis, dependency scanning (OWASP Dependency-Check), and unit test execution.
- Docker images are built for deployment to ECS Fargate clusters.
- API documentation is auto-generated and published as part of the build pipeline.
[GAP: Missing data for Build and Test]

## 6.2 Test Strategy

### 6.2.1 Test Coverage and Types

- **Unit Testing:** All business logic modules must achieve ≥80% line coverage.  
- **Integration Testing:** All service interfaces (REST APIs, database, external services) are covered by integration tests.
- **Security Testing:** Authentication, authorization, and input validation are tested per migration requirements.
- **Performance Testing:** System must meet or exceed legacy baseline for key metrics (see below).
- **Accessibility Testing:** React UI must comply with WCAG 2.1 AA.
- **Code Review:** All code is reviewed by a senior developer and subject to security review.
[KB-0a1640fc-d3df-49c8-9862-d52514894afd]

### 6.2.2 Performance Requirements

| Metric                       | Legacy Baseline   | Target   | Measurement Method      |
|------------------------------|-------------------|----------|------------------------|
| Patient search response time | 2.0s              | 1.0s     | Application metrics    |
| API response time (p50)      | [GAP]             | <200ms   | Application metrics    |
| API response time (p95)      | [GAP]             | <500ms   | Application metrics    |
| API response time (p99)      | [GAP]             | <1,000ms | Application metrics    |
| Page load time (initial)     | [GAP]             | <2s      | Lighthouse             |
| Page load time (subsequent)  | [GAP]             | <1s      | Client-side metrics    |
| System availability          | [GAP]             | 99.9%    | Uptime monitoring      |
| Concurrent users             | [GAP]             | 500+     | Load testing           |
| Database query time (avg)    | [GAP]             | <100ms   | RDS Performance Insights|
| API throughput               | [GAP]             | >1,000/min| Load testing           |

[KB-05e90e5d-09da-4f67-85af-8f2be11cd2ce]  
[KB-0d9e59c7-0414-46c2-b302-2f4cbc1e9e88]

### 6.2.3 Acceptance and User Testing

- **User Acceptance Testing (UAT):** Conducted in phases by module and user group.
- **Parallel Run:** Minimum 2 weeks, with comparison reports for data and transaction parity.
- **Post-Migration Hypercare:** 2 weeks of enhanced support following go-live.
- **Staff Training:** All affected user groups receive training prior to cutover.

|   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), Admin (1)            | 1 week     | Planned  |

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

### 6.2.4 Data Integrity and Parallel Run Testing

- **Data Migration Verification:** Record count and checksum validation between legacy and new systems.
- **Parallel Run:** Both systems audited simultaneously; comparison tests for all critical data types.
- **Acceptance Criteria:** All comparison tests must meet defined tolerances (see below).

| 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) |

[KB-092b662f-2b03-418b-8931-ae9705639cfc]

### 6.2.5 Security and Compliance Testing

- **Audit Logging:** PHI access, modification, and export events are logged and verified for completeness.
- **Access Control:** Parity check between legacy and new system permissions; no privilege escalation allowed.
- **Incident Response:** Security incident procedures are documented and tested.
- **De-identification:** All test/dev environments use de-identified data per Safe Harbor requirements.
- **Encryption:** Verified at rest (DB, file, field-level) and in transit (TLS 1.3).
[KB-052c37cd-e1b9-4e3f-8d87-e4cff20e9718]  
[KB-1554a441-9086-4371-85f6-cb4d7472ee1b]  
[KB-116f84fb-2eec-4493-9762-414a92624981]

### 6.2.6 Rollback and Disaster Recovery Testing

| 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     |

[KB-0e7db777-ce75-42c0-aac9-256614f5e8a4]  
[KB-04c5b64b-0ba0-40cd-864f-395e17b12504]

## 6.3 Traceability to Requirements

- All build and test activities are mapped to functional, performance, security, and compliance requirements as specified in the migration plan and referenced requirement documents.
- Any gaps or deviations are documented and tracked for remediation prior to production release.

[GAP: Missing data for Build and Test]

## Contribute

# Contribute

## System Limitations Impacting Contribution

The current system architecture imposes several critical limitations that directly affect the ability to contribute new features or enhancements related to order management, payment processing, and notification workflows:

| 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     |

*Source: [KB-146a6a29-932f-485d-96d6-6a92ee610336]*

## Data Model and API Constraints

- The orders table does **not** contain a `batch_id`, `csv_source`, or `bulk_import_group` column. There is no mechanism to associate orders with a batch import or track their origin from a file import.  
  *Source: [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8]*

- The payment table enforces a **1:1 relationship** between order and payment (`order_id` is UNIQUE), preventing any form of batch or grouped payment processing. Each payment is strictly associated with a single order.  
  *Source: [KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2]*

- The Payment Service API only supports processing one payment per request. There is no batch payment endpoint, and the maximum amount per transaction is 1,000,000 JPY.  
  *Source: [KB-186b33d7-f985-455b-8117-0cd019912510]*

- The Notification Service API only allows sending one notification per API call, with a rate limit of 10 notifications per second.  
  *Source: [KB-05a9aed3-6a71-4ac9-9bfec293268b]*

## UI and Workflow Limitations

- The frontend management interface does **not** provide any UI for bulk order import (no CSV upload, no drag-and-drop, no batch creation form).  
  *Source: [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]*

- The order management UI displays a disabled CSV Import button with a label indicating "CSV Import (Not Implemented)" and shows an amber warning banner stating that CSV import is unavailable.  
  *Source: [KB-16181d30-2dd3-421e-bab0-939cd85255d2]*

## Technical and Performance Implications

- Processing large order volumes (e.g., 10,000 orders) requires 10,000 individual API calls due to the lack of batch endpoints. This results in extremely slow bulk operations.  
  *Source: [KB-150eb89c-77b0-415b-a547-3ed0502eec24]*

- All cross-service calls (Order → Payment → Notification) are executed sequentially, not in parallel, further increasing latency for bulk operations.  
  *Source: [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]*

- There is no retry or circuit breaker mechanism for failed cross-service calls. Failures are logged, but not retried, increasing the risk of partial failures in multi-step operations.  
  *Source: [KB-150eb89c-77b0-415b-a547-3ed0502eec24]*

## Summary

Due to the above architectural and functional constraints, contributions that require batch or bulk processing (such as CSV import, batch payments, or bulk notifications) cannot be implemented without significant architectural changes across multiple services. All current contributions must conform to the single-entry, single-transaction, and single-notification model enforced by both the backend and frontend systems.

**Any proposed enhancements or contributions that require batch capabilities must first address these systemic limitations at the architectural level.**  
*For further details, see referenced knowledge base entries.*

---

**References:**  
- [KB-146a6a29-932f-485d-96d6-6a92ee610336]  
- [KB-0f930ddc-1f3a-4014-a015-49fe1808f8d8]  
- [KB-11739ab0-b209-41e4-b73e-7d7e0c4338b2]  
- [KB-186b33d7-f985-455b-8117-0cd019912510]  
- [KB-05a9aed3-6a71-4c74-ac19-6bfec293268b]  
- [KB-0a36efdc-f63e-4c6b-8191-220e34d8af3f]  
- [KB-16181d30-2dd3-421e-bab0-939cd85255d2]  
- [KB-150eb89c-77b0-415b-a547-3ed0502eec24]