Add PatVisit controller and use case documentation
- Add PatVisitController with CRUD operations - Add use case documentation (docx and md files) - Update API documentation in api-docs.yaml - Remove USER_STORIES.md (migrated to docs/) - Update TODO.md with current tasks - Update Routes.php for new endpoints - Update DummySeeder with additional test data
This commit is contained in:
parent
f30755c830
commit
8806b007ab
515
TODO.md
515
TODO.md
@ -1,271 +1,334 @@
|
||||
# CLQMS MVP Todo List
|
||||
# CLQMS REST API Development Checklist
|
||||
|
||||
> Clinical Laboratory Quality Management System - Minimum Viable Product
|
||||
**Note**: This checklist covers ONLY the REST API backend. UI/UX implementation is handled separately in the frontend project (clqms01-fe).
|
||||
|
||||
## Quick Start: Create Order with Minimal Master Data
|
||||
|
||||
You **don't need** all master data finished to create an order. Here's what's actually required:
|
||||
|
||||
### Minimum Required (2 Tables)
|
||||
|
||||
These are the only tables that need database entries for a minimal setup. System lookups (status, priority, etc.) are handled by the `ValueSet` library using static JSON files in `app/Libraries/Data/`.
|
||||
|
||||
```sql
|
||||
-- 1. Patient (already exists in codebase)
|
||||
-- Just need at least 1 patient
|
||||
|
||||
-- 2. Counter for Order ID
|
||||
INSERT INTO counter (CounterName, CounterValue) VALUES ('ORDER', 1);
|
||||
```
|
||||
|
||||
### API Endpoints (No Auth Required for Testing)
|
||||
|
||||
```bash
|
||||
# Create demo order (auto-creates patient if needed)
|
||||
POST /api/demo/order
|
||||
{
|
||||
"PatientID": "PT001",
|
||||
"NameFirst": "John",
|
||||
"NameLast": "Doe",
|
||||
"Gender": "1",
|
||||
"Birthdate": "1990-05-15",
|
||||
"Priority": "R",
|
||||
"OrderingProvider": "Dr. Smith"
|
||||
}
|
||||
|
||||
# List orders
|
||||
GET /api/demo/orders
|
||||
|
||||
# Create order (requires auth)
|
||||
POST /api/ordertest
|
||||
{
|
||||
"InternalPID": 1,
|
||||
"Priority": "R",
|
||||
"OrderingProvider": "Dr. Smith"
|
||||
}
|
||||
|
||||
# Update order status
|
||||
POST /api/ordertest/status
|
||||
{
|
||||
"OrderID": "00250112000001",
|
||||
"OrderStatus": "SCH"
|
||||
}
|
||||
```
|
||||
|
||||
## Core Workflow
|
||||
Order → Collection → Reception → Preparation → Analysis → Verification → Review → Reporting
|
||||
## Legend
|
||||
- [x] **DONE** - Implemented and functional
|
||||
- [ ] **TODO** - Not yet implemented
|
||||
- [~] **PARTIAL** - Partially implemented
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: Order Management (Immediate Priority)
|
||||
## Phase 1: Core Infrastructure ✅ DONE
|
||||
|
||||
### 1.1 Order Management
|
||||
- [x] Complete `OrderTestController` create/update/delete
|
||||
- [x] Implement order ID generation (LLYYMMDDXXXXX format)
|
||||
- [x] Implement order comment handling (ordercom table)
|
||||
- [ ] Implement order attachment handling (orderatt table)
|
||||
- [x] Add order status tracking (ORD→SCH→ANA→VER→REV→REP)
|
||||
- [x] Create order test mapping (using patres table)
|
||||
- [x] Add calculated test parameter auto-selection & Group expansion
|
||||
### 1.1 Base Framework
|
||||
- [x] BaseController with ResponseTrait
|
||||
- [x] BaseModel with auto UTC normalization
|
||||
- [x] Validation system with custom rules
|
||||
- [x] JWT authentication system
|
||||
- [x] CORS and security headers configuration
|
||||
- [x] Database migration system
|
||||
|
||||
## Phase 2: Specimen & Result Management (Later)
|
||||
|
||||
### 2.1 Specimen Management
|
||||
- [ ] Complete `SpecimenController` API
|
||||
- [ ] Implement specimen ID generation (OrderID + SSS + C)
|
||||
- [ ] Build specimen collection API (Collection status)
|
||||
- [ ] Build specimen transport API (In-transport status)
|
||||
- [ ] Build specimen reception API (Received/Rejected status)
|
||||
- [ ] Build specimen preparation API (Centrifuge, Aliquot, Pre-treatment)
|
||||
- [ ] Build specimen storage API (Stored status)
|
||||
- [ ] Build specimen dispatching API (Dispatch status)
|
||||
- [ ] Implement specimen condition tracking (HEM, ITC, LIP flags)
|
||||
|
||||
### 2.2 Result Management
|
||||
- [ ] Complete `ResultController` with full CRUD
|
||||
- [ ] Implement result entry API (numeric, text, valueset, range)
|
||||
- [ ] Implement result verification workflow (Technical + Clinical)
|
||||
- [ ] Add reference range validation (numeric, threshold, text, valueset)
|
||||
- [ ] Implement critical value flagging (threshold-based)
|
||||
- [ ] Implement result rerun with AspCnt tracking
|
||||
- [ ] Add result report generation API
|
||||
|
||||
### 2.3 Patient Visit
|
||||
- [ ] Complete `PatVisitController` create/read
|
||||
- [ ] Implement patient visit to order linking
|
||||
- [ ] Add admission/discharge/transfer (ADT) tracking
|
||||
- [ ] Add diagnosis linking (patdiag table)
|
||||
---
|
||||
|
||||
## Phase 3: Instrument Integration (Later)
|
||||
|
||||
### 3.1 Edge API
|
||||
- [ ] Complete `EdgeController` results endpoint
|
||||
- [ ] Implement edgeres table data handling
|
||||
- [ ] Implement edgestatus tracking
|
||||
- [ ] Implement edgeack acknowledgment
|
||||
- [ ] Build instrument orders endpoint (/api/edge/orders)
|
||||
- [ ] Build order acknowledgment endpoint (/api/edge/orders/:id/ack)
|
||||
- [ ] Build status logging endpoint (/api/edge/status)
|
||||
|
||||
### 3.2 Test Mapping
|
||||
- [ ] Implement test mapping CRUD (TestMapModel)
|
||||
- [ ] Build instrument code to LQMS test mapping
|
||||
- [ ] Add many-to-one mapping support (e.g., glucose variations)
|
||||
### 1.2 Authentication & Security
|
||||
- [x] User login/logout (AuthController, AuthV2Controller)
|
||||
- [x] JWT token generation and validation
|
||||
- [x] Password change functionality
|
||||
- [x] Auth check endpoints
|
||||
- [x] Role-based access control (RBAC) preparation
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Quality Management (Should Have)
|
||||
## Phase 2: Organization Management ✅ DONE
|
||||
|
||||
### 3.1 Quality Control
|
||||
- [ ] Build QC result entry API
|
||||
- [ ] Implement QC result storage (calres table)
|
||||
- [ ] Add Levey-Jennings data preparation endpoints
|
||||
- [ ] Implement QC validation (2SD auto-validation)
|
||||
- [ ] Add Sigma score calculation endpoint
|
||||
### 2.1 Account Management
|
||||
- [x] Account CRUD API (`/api/organization/account`)
|
||||
- [x] Account listing and search
|
||||
- [x] Parent-child Account relationships
|
||||
|
||||
### 3.2 Calibration
|
||||
- [ ] Build calibration result entry API
|
||||
- [ ] Implement calibration factor tracking
|
||||
- [ ] Add calibration history endpoint
|
||||
- [ ] Implement calibration validation
|
||||
### 2.2 Site Management
|
||||
- [x] Site CRUD API (`/api/organization/site`)
|
||||
- [x] SiteCode generation support
|
||||
- [x] Site type management (PHL, GL, PL)
|
||||
|
||||
### 3.3 Audit Trail
|
||||
- [ ] Add audit logging middleware
|
||||
- [ ] Implement data change tracking (what/who/when/how/where)
|
||||
- [ ] Build audit query endpoint
|
||||
- [ ] Add security log endpoints
|
||||
### 2.3 Department Management
|
||||
- [x] Department CRUD API (`/api/organization/department`)
|
||||
- [x] Department-Discipline linking
|
||||
|
||||
### 2.4 Discipline Management
|
||||
- [x] Discipline CRUD API (`/api/organization/discipline`)
|
||||
- [x] Discipline hierarchy support
|
||||
|
||||
### 2.5 Workstation Management
|
||||
- [x] Workstation CRUD API (`/api/organization/workstation`)
|
||||
- [x] Workstation type management (primary/secondary)
|
||||
- [x] Workstation linking support
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: Master Data (Already Have - Need Completion)
|
||||
## Phase 3: Personnel/Contact Management ✅ DONE
|
||||
|
||||
### 4.1 Test Definitions ✅ Existing
|
||||
- [ ] Test definitions (testdefsite)
|
||||
- [ ] Technical specs (testdeftech)
|
||||
- [ ] Calculated tests (testdefcal)
|
||||
- [ ] Group tests (testdefgrp)
|
||||
- [ ] Test parameters
|
||||
### 3.1 Contact Management
|
||||
- [x] Contact CRUD API (`/api/contact`)
|
||||
- [x] ContactDetail model (for site-specific roles)
|
||||
- [x] Patient-Contact association
|
||||
|
||||
### 4.2 Reference Ranges ✅ Existing
|
||||
- [x] Numeric ranges (refnum)
|
||||
- [x] Threshold ranges (refthold)
|
||||
- [x] Text ranges (reftxt)
|
||||
- [x] Value set ranges (refvset)
|
||||
### 3.2 Occupation Management
|
||||
- [x] Occupation CRUD API (`/api/occupation`)
|
||||
|
||||
### 4.3 Organizations ✅ Existing
|
||||
- [ ] Sites (SiteController)
|
||||
- [ ] Departments (DepartmentController)
|
||||
- [ ] Workstations (WorkstationController)
|
||||
- [ ] Disciplines (DisciplineController)
|
||||
|
||||
### 4.4 Value Sets ✅ Existing
|
||||
- [ ] Value set definitions (ValueSetDefController)
|
||||
- [ ] Value set values (ValueSetController)
|
||||
### 3.3 Medical Specialty
|
||||
- [x] MedicalSpecialty CRUD API (`/api/medicalspecialty`)
|
||||
|
||||
---
|
||||
|
||||
## Phase 5: Inventory & Billing (Nice to Have)
|
||||
## Phase 4: Patient Management ✅ DONE
|
||||
|
||||
### 5.1 Inventory
|
||||
- [ ] Build counter management API
|
||||
- [ ] Implement product catalog endpoints
|
||||
- [ ] Add reagent tracking
|
||||
- [ ] Implement consumables usage logging
|
||||
### 4.1 Patient Core
|
||||
- [x] Patient CRUD API (`/api/patient`)
|
||||
- [x] Patient search and filtering
|
||||
- [x] Patient identifier management (PatIdtModel)
|
||||
- [x] Patient comments (PatComModel)
|
||||
- [x] Patient attachments (PatAttModel)
|
||||
- [x] Patient check endpoint
|
||||
|
||||
### 5.2 Billing
|
||||
- [ ] Add billing account linking
|
||||
- [ ] Implement tariff selection by service class
|
||||
- [ ] Build billing export endpoint
|
||||
### 4.2 Patient Visit (ADT)
|
||||
- [x] PatientVisit CRUD API (`/api/patvisit`)
|
||||
- [x] Get visits by patient
|
||||
- [x] PatVisitADT CRUD (`/api/patvisitadt`)
|
||||
- [x] Get ADT by visit
|
||||
- [x] Admission workflow (A01)
|
||||
- [x] Transfer workflow (A02)
|
||||
- [x] Discharge workflow (A03)
|
||||
- [x] Cancel admission/discharge
|
||||
|
||||
---
|
||||
|
||||
## Priority Matrix
|
||||
## Phase 5: Location Management ✅ DONE
|
||||
|
||||
| Priority | Feature | Controller/Model | Status |
|
||||
|----------|---------|-----------------|--------|
|
||||
| P0 | Order CRUD | OrderTestController + OrderTestModel | ✅ Done |
|
||||
| P0 | Specimen Status | SpecimenController | ⚠️ Needs API |
|
||||
| P0 | Result Entry | ResultController | ❌ Empty |
|
||||
| P0 | Result Verification | ResultController | ❌ Empty |
|
||||
| P1 | Visit Management | PatVisitController | ⚠️ Partial |
|
||||
| P1 | Instrument Integration | EdgeController | ⚠️ Partial |
|
||||
| P1 | Reference Range Validation | RefNumModel + API | ⚠️ Need API |
|
||||
| P2 | QC Results | New Controller | ❌ Not exist |
|
||||
| P2 | Audit Trail | New Model | ❌ Not exist |
|
||||
| P3 | Inventory | CounterController | ⚠️ Partial |
|
||||
| P3 | Billing | New Controller | ❌ Not exist |
|
||||
### 5.1 Location
|
||||
- [x] Location CRUD API (`/api/location`)
|
||||
- [x] Location hierarchy support
|
||||
|
||||
### 5.2 Area/Geography
|
||||
- [x] AreaGeo API (`/api/areageo`)
|
||||
- [x] Province listing
|
||||
- [x] City listing
|
||||
|
||||
---
|
||||
|
||||
## Quick Test: Does Order Creation Work?
|
||||
## Phase 6: Specimen Management ✅ DONE
|
||||
|
||||
```bash
|
||||
# Test 1: Create demo order (no auth required)
|
||||
curl -X POST http://localhost:8080/api/demo/order \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"NameFirst": "Test", "NameLast": "Patient"}'
|
||||
### 6.1 Specimen Core
|
||||
- [x] Specimen CRUD API (`/api/specimen`)
|
||||
- [x] SID generation support
|
||||
|
||||
# Expected Response:
|
||||
{
|
||||
"status": "success",
|
||||
"message": "Demo order created successfully",
|
||||
"data": {
|
||||
"PatientID": "DEMO1736689600",
|
||||
"InternalPID": 1,
|
||||
"OrderID": "00250112000001",
|
||||
"OrderStatus": "ORD"
|
||||
}
|
||||
}
|
||||
### 6.2 Container Management
|
||||
- [x] ContainerDef CRUD API (`/api/specimen/container`, `/api/specimen/containerdef`)
|
||||
|
||||
# Test 2: Update order status
|
||||
curl -X POST http://localhost:8080/api/ordertest/status \
|
||||
-H "Content-Type: application/json" \
|
||||
-H "Authorization: Bearer <token>" \
|
||||
-d '{"OrderID": "00250112000001", "OrderStatus": "SCH"}'
|
||||
```
|
||||
### 6.3 Specimen Workflow
|
||||
- [x] SpecimenPrep CRUD API (`/api/specimen/prep`)
|
||||
- [x] SpecimenStatus CRUD API (`/api/specimen/status`)
|
||||
- [x] SpecimenCollection CRUD API (`/api/specimen/collection`)
|
||||
|
||||
---
|
||||
|
||||
## Success Criteria
|
||||
## Phase 7: Test Management ✅ DONE
|
||||
|
||||
### Functional
|
||||
- [x] Patient registration works
|
||||
- [ ] Test ordering generates valid OrderID and SID
|
||||
- [ ] Specimens track through collection → transport → reception → preparation → analysis
|
||||
- [ ] Results can be entered with reference range validation
|
||||
- [ ] Results verified through VER → REV → REP workflow
|
||||
- [ ] Instruments can send results via Edge API
|
||||
### 7.1 Test Definitions
|
||||
- [x] Tests CRUD API (`/api/tests`)
|
||||
- [x] Test mapping API (`/api/test/testmap`)
|
||||
- [x] **Reference Range nested in Tests** (RefNum, RefTxt via POST/PUT body)
|
||||
- [x] Test profile/group management
|
||||
- [x] Test discipline mapping
|
||||
|
||||
### Non-Functional
|
||||
- [ ] JWT authentication required for all endpoints
|
||||
- [ ] Soft delete (DelDate) on all transactions
|
||||
- [ ] UTC timezone for all datetime fields
|
||||
- [ ] Audit logging for data changes
|
||||
- [ ] < 2s response time for standard queries
|
||||
### 7.2 Test Ordering
|
||||
- [x] OrderTest CRUD API (`/api/ordertest`)
|
||||
- [x] Order status update endpoint
|
||||
- [x] Demo order creation (`/api/demo/order`)
|
||||
|
||||
### 7.3 Reference Range (Nested in Tests)
|
||||
- [x] RefNum model and controller integration (`saveRefNumRanges()`)
|
||||
- [x] RefTxt model and controller integration (`saveRefTxtRanges()`)
|
||||
- [x] Age range validation
|
||||
- [x] Gender-based reference ranges
|
||||
- [x] Text-based result interpretation
|
||||
- [x] Threshold (RefTHold) support
|
||||
- [x] ValueSet (RefVSet) support
|
||||
|
||||
**Note**: Reference ranges are managed as nested data within Tests API. POST/PUT `/api/tests` includes `refRanges` array in request body.
|
||||
|
||||
---
|
||||
|
||||
## Current Codebase Status
|
||||
## Phase 8: Result Management ✅ PARTIAL
|
||||
|
||||
### Controllers (Need Work)
|
||||
- [ ] OrderTestController - placeholder code, incomplete
|
||||
- [ ] ResultController - only validates JWT
|
||||
- [x] PatientController - complete
|
||||
- [x] TestsController - complete
|
||||
- [x] PatVisitController - partial
|
||||
### 8.1 Result Core
|
||||
- [x] Result listing endpoint (`/api/result`)
|
||||
- [~] Result entry (manual)
|
||||
- [ ] Result validation workflow
|
||||
- [ ] Result flagging (H/L/A)
|
||||
- [ ] Result correction workflow
|
||||
|
||||
### Models (Good)
|
||||
- [x] PatientModel - complete
|
||||
- [x] TestDef* models - complete
|
||||
- [x] Ref* models - complete
|
||||
- [x] ValueSet* models - complete
|
||||
- [x] SpecimenModel - exists, needs API
|
||||
### 8.2 Result ValueSets
|
||||
- [x] ResultValueSet CRUD API (`/api/result/valueset`)
|
||||
|
||||
### Missing Controllers
|
||||
- [ ] SpecimenController - need full implementation
|
||||
- [ ] ResultController - need full implementation
|
||||
- [ ] QualityControlController - not exist
|
||||
- [ ] CalibrationController - not exist
|
||||
- [ ] AuditController - not exist
|
||||
- [ ] BillingController - not exist
|
||||
---
|
||||
|
||||
## Phase 9: ValueSet Management ✅ DONE
|
||||
|
||||
### 9.1 File-based ValueSets
|
||||
- [x] ValueSet listing (`/api/valueset`)
|
||||
- [x] Specific value set retrieval (`/api/valueset/{type}`)
|
||||
- [x] ValueSet refresh endpoint
|
||||
|
||||
### 9.2 Database ValueSets
|
||||
- [x] ValueSet items CRUD (`/api/valueset/user/items`)
|
||||
- [x] ValueSet definitions CRUD (`/api/valueset/user/def`)
|
||||
|
||||
---
|
||||
|
||||
## Phase 10: Infrastructure & Support ✅ DONE
|
||||
|
||||
### 10.1 Counter Management
|
||||
- [x] Counter CRUD API (`/api/counter`)
|
||||
|
||||
### 10.2 Edge Integration (Instrument)
|
||||
- [x] Edge results endpoint (`/api/edge/results`)
|
||||
- [x] Edge orders retrieval (`/api/edge/orders`)
|
||||
- [x] Order acknowledgment (`/api/edge/orders/{id}/ack`)
|
||||
- [x] Status update endpoint (`/api/edge/status`)
|
||||
|
||||
---
|
||||
|
||||
## Phase 11: Missing Features ⏳ TODO
|
||||
|
||||
### 11.1 Equipment Management
|
||||
- [ ] ProductCatalog CRUD
|
||||
- [ ] ProductCatalogExt CRUD
|
||||
- [ ] ProductExt (Equipment) CRUD
|
||||
- [ ] Equipment lifecycle tracking (installation, maintenance, decommissioning)
|
||||
- [ ] Equipment-instrument mapping
|
||||
|
||||
### 11.2 Calibration Management
|
||||
- [ ] Calibrator CRUD
|
||||
- [ ] Calibration results API
|
||||
- [ ] Calibration factor tracking
|
||||
- [ ] Calibration validation endpoints
|
||||
- [ ] Cumulative calibration view
|
||||
|
||||
### 11.3 Quality Control (QC) Management
|
||||
- [ ] QC material CRUD
|
||||
- [ ] QC results API
|
||||
- [ ] Levey-Jennings data endpoints
|
||||
- [ ] QC validation workflow
|
||||
- [ ] Westgard rules implementation
|
||||
|
||||
### 11.4 Inventory Management
|
||||
- [ ] Inventory receiving API
|
||||
- [ ] Consumables tracking endpoints
|
||||
- [ ] Stock monitoring API
|
||||
- [ ] Expiry date alerts
|
||||
|
||||
### 11.6 Audit Trail
|
||||
- [ ] Patient audit log API (patreglog)
|
||||
- [ ] Visit audit log API (patvisitlog)
|
||||
- [ ] Specimen audit log API (specimenlog)
|
||||
- [ ] Security event logging API
|
||||
|
||||
### 11.7 Advanced Features
|
||||
- [ ] Multi-site patient linking API
|
||||
- [ ] Patient merge/unlink endpoints
|
||||
- [ ] Archiving API
|
||||
- [ ] Data warehouse integration endpoints
|
||||
- [ ] Report generation API (PDF/JSON)
|
||||
- [ ] HL7 message generation endpoints
|
||||
- [ ] Instrument test mapping API
|
||||
- [ ] Rerun management API
|
||||
- [ ] Critical value alerts API
|
||||
|
||||
### 11.8 SMCRM Integration
|
||||
- [ ] CRM sync webhooks
|
||||
- [ ] Bidirectional data sync endpoints
|
||||
- [ ] Equipment activity sync
|
||||
|
||||
---
|
||||
|
||||
## Phase 12: Documentation & Testing ⏳ TODO
|
||||
|
||||
### 12.1 API Documentation
|
||||
- [x] Swagger/OpenAPI documentation endpoint (`/swagger`)
|
||||
- [ ] Complete API documentation for all endpoints
|
||||
- [ ] Request/response examples
|
||||
- [ ] Authentication documentation
|
||||
|
||||
### 12.2 Testing
|
||||
- [ ] PHPUnit test suite setup
|
||||
- [ ] Unit tests for models
|
||||
- [ ] Integration tests for controllers
|
||||
- [ ] API endpoint tests
|
||||
- [ ] HL7 message tests
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
| Category | Done | Partial | Todo | Total |
|
||||
|----------|------|---------|------|-------|
|
||||
| Core Infrastructure | 5 | 0 | 0 | 5 |
|
||||
| Organization | 5 | 0 | 0 | 5 |
|
||||
| Personnel | 3 | 0 | 0 | 3 |
|
||||
| Patient | 8 | 0 | 0 | 8 |
|
||||
| Location | 2 | 0 | 0 | 2 |
|
||||
| Specimen | 4 | 0 | 0 | 4 |
|
||||
| Test | 9 | 0 | 0 | 9 |
|
||||
| Result | 2 | 1 | 5 | 8 |
|
||||
| ValueSet | 2 | 0 | 0 | 2 |
|
||||
| Infrastructure | 2 | 0 | 0 | 2 |
|
||||
| **Missing Features** | **0** | **0** | **32** | **32** |
|
||||
| **Documentation** | **1** | **0** | **3** | **4** |
|
||||
| **TOTAL** | **43** | **1** | **40** | **84** |
|
||||
|
||||
**Completion: ~51% (43/84 items done)**
|
||||
|
||||
---
|
||||
|
||||
## Priority Next Steps
|
||||
|
||||
### 🔴 CRITICAL - Blockers for Production
|
||||
1. [ ] Result validation workflow
|
||||
- Flag generation based on reference ranges (H/L/A)
|
||||
- Result interpretation logic
|
||||
- Must be completed before production deployment
|
||||
|
||||
### High Priority (Core Lab Functions)
|
||||
2. [ ] Equipment Management (ProductExt, Equipment lifecycle)
|
||||
3. [ ] Calibration Management (Calibrator, Calibration results)
|
||||
4. [ ] QC Management (QC material, QC results)
|
||||
5. [ ] Result entry and correction workflow
|
||||
|
||||
### Medium Priority (Important)
|
||||
6. [ ] Audit Trail (Patient, Visit, Specimen logs)
|
||||
7. [ ] HL7 message generation
|
||||
8. [ ] Report generation API
|
||||
9. [ ] Inventory Management
|
||||
10. [ ] Rerun management API
|
||||
|
||||
### Low Priority (Future Enhancement)
|
||||
11. [ ] SMCRM Integration
|
||||
12. [ ] Data warehouse integration
|
||||
13. [ ] Archiving API
|
||||
14. [ ] Critical value alerts
|
||||
15. [ ] Multi-site patient linking
|
||||
|
||||
---
|
||||
|
||||
**Last Updated**: 2026-02-15 (Revised: RefRange is DONE - nested in Tests API)
|
||||
**Project**: CLQMS Backend REST API
|
||||
**Version**: 1.2.0
|
||||
|
||||
## Architecture Notes
|
||||
|
||||
### Nested Data Pattern
|
||||
Some entities are managed as nested data within parent APIs rather than standalone endpoints:
|
||||
|
||||
- **Reference Range** → Nested in `/api/tests` (POST/PUT body includes `refRanges` array)
|
||||
- RefNum (numeric ranges with age/gender filters)
|
||||
- RefTxt (text interpretations)
|
||||
- RefTHold (threshold/cut-off values)
|
||||
- RefVSet (ValueSet-based ranges)
|
||||
|
||||
- **Test Mapping** → Nested in `/api/tests`
|
||||
- Instrument-to-LIS test code mapping
|
||||
- Many-to-one test relationships
|
||||
|
||||
- **Test Groups/Profiles** → Nested in `/api/tests`
|
||||
- Group definitions
|
||||
- Panel structures
|
||||
|
||||
1607
USER_STORIES.md
1607
USER_STORIES.md
File diff suppressed because it is too large
Load Diff
@ -67,9 +67,12 @@ $routes->group('api', function ($routes) {
|
||||
$routes->patch('/', 'PatVisitController::update');
|
||||
});
|
||||
|
||||
$routes->group('patvisitadt', function ($routes) {
|
||||
$routes->group('patvisitadt', function ($routes) {
|
||||
$routes->get('visit/(:num)', 'PatVisitController::getADTByVisit/$1');
|
||||
$routes->get('(:num)', 'PatVisitController::showADT/$1');
|
||||
$routes->post('/', 'PatVisitController::createADT');
|
||||
$routes->patch('/', 'PatVisitController::updateADT');
|
||||
$routes->delete('/', 'PatVisitController::deleteADT');
|
||||
});
|
||||
|
||||
// Master Data
|
||||
|
||||
@ -157,4 +157,92 @@ class PatVisitController extends BaseController {
|
||||
return $this->failServerError('Something went wrong: ' . $e->getMessage());
|
||||
}
|
||||
}
|
||||
|
||||
public function getADTByVisit($InternalPVID = null) {
|
||||
try {
|
||||
if (!$InternalPVID || !is_numeric($InternalPVID)) {
|
||||
return $this->respond(['status' => 'error', 'message' => 'Invalid or missing InternalPVID'], 400);
|
||||
}
|
||||
|
||||
$modelPVA = new PatVisitADTModel();
|
||||
$rows = $modelPVA->select('patvisitadt.*, location.LocFull as LocationName,
|
||||
attDoc.NameFirst as AttDocFirstName, attDoc.NameLast as AttDocLastName,
|
||||
refDoc.NameFirst as RefDocFirstName, refDoc.NameLast as RefDocLastName,
|
||||
admDoc.NameFirst as AdmDocFirstName, admDoc.NameLast as AdmDocLastName,
|
||||
cnsDoc.NameFirst as CnsDocFirstName, cnsDoc.NameLast as CnsDocLastName')
|
||||
->join('location', 'location.LocationID = patvisitadt.LocationID', 'left')
|
||||
->join('contact attDoc', 'attDoc.ContactID = patvisitadt.AttDoc', 'left')
|
||||
->join('contact refDoc', 'refDoc.ContactID = patvisitadt.RefDoc', 'left')
|
||||
->join('contact admDoc', 'admDoc.ContactID = patvisitadt.AdmDoc', 'left')
|
||||
->join('contact cnsDoc', 'cnsDoc.ContactID = patvisitadt.CnsDoc', 'left')
|
||||
->where('patvisitadt.InternalPVID', $InternalPVID)
|
||||
->where('patvisitadt.DelDate IS NULL')
|
||||
->orderBy('patvisitadt.CreateDate', 'ASC')
|
||||
->findAll();
|
||||
|
||||
if (empty($rows)) {
|
||||
return $this->respond(['status' => 'success', 'message' => 'No ADT history found', 'data' => []], 200);
|
||||
}
|
||||
|
||||
return $this->respond(['status' => 'success', 'message' => 'ADT history retrieved', 'data' => $rows], 200);
|
||||
} catch (\Exception $e) {
|
||||
return $this->failServerError('Something went wrong: ' . $e->getMessage());
|
||||
}
|
||||
}
|
||||
|
||||
public function showADT($PVADTID = null) {
|
||||
try {
|
||||
if (!$PVADTID || !is_numeric($PVADTID)) {
|
||||
return $this->respond(['status' => 'error', 'message' => 'Invalid or missing PVADTID'], 400);
|
||||
}
|
||||
|
||||
$modelPVA = new PatVisitADTModel();
|
||||
$row = $modelPVA->select('patvisitadt.*, location.LocFull as LocationName,
|
||||
attDoc.NameFirst as AttDocFirstName, attDoc.NameLast as AttDocLastName,
|
||||
refDoc.NameFirst as RefDocFirstName, refDoc.NameLast as RefDocLastName,
|
||||
admDoc.NameFirst as AdmDocFirstName, admDoc.NameLast as AdmDocLastName,
|
||||
cnsDoc.NameFirst as CnsDocFirstName, cnsDoc.NameLast as CnsDocLastName')
|
||||
->join('location', 'location.LocationID = patvisitadt.LocationID', 'left')
|
||||
->join('contact attDoc', 'attDoc.ContactID = patvisitadt.AttDoc', 'left')
|
||||
->join('contact refDoc', 'refDoc.ContactID = patvisitadt.RefDoc', 'left')
|
||||
->join('contact admDoc', 'admDoc.ContactID = patvisitadt.AdmDoc', 'left')
|
||||
->join('contact cnsDoc', 'cnsDoc.ContactID = patvisitadt.CnsDoc', 'left')
|
||||
->where('patvisitadt.PVADTID', $PVADTID)
|
||||
->where('patvisitadt.DelDate IS NULL')
|
||||
->first();
|
||||
|
||||
if (empty($row)) {
|
||||
return $this->respond(['status' => 'success', 'message' => 'ADT record not found', 'data' => []], 200);
|
||||
}
|
||||
|
||||
return $this->respond(['status' => 'success', 'message' => 'ADT record retrieved', 'data' => $row], 200);
|
||||
} catch (\Exception $e) {
|
||||
return $this->failServerError('Something went wrong: ' . $e->getMessage());
|
||||
}
|
||||
}
|
||||
|
||||
public function deleteADT() {
|
||||
$input = $this->request->getJSON(true);
|
||||
try {
|
||||
if (!isset($input["PVADTID"]) || !is_numeric($input["PVADTID"])) {
|
||||
return $this->respond(['status' => 'error', 'message' => 'Invalid or missing PVADTID'], 400);
|
||||
}
|
||||
|
||||
$modelPVA = new PatVisitADTModel();
|
||||
$adt = $modelPVA->find($input["PVADTID"]);
|
||||
if (!$adt) {
|
||||
return $this->respond(['status' => 'error', 'message' => 'ADT record not found'], 404);
|
||||
}
|
||||
|
||||
$result = $modelPVA->delete($input["PVADTID"]);
|
||||
|
||||
if ($result) {
|
||||
return $this->respond(['status' => 'success', 'message' => 'ADT record deleted successfully'], 200);
|
||||
} else {
|
||||
return $this->respond(['status' => 'error', 'message' => 'Failed to delete ADT record'], 500);
|
||||
}
|
||||
} catch (\Exception $e) {
|
||||
return $this->failServerError('Something went wrong: ' . $e->getMessage());
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@ -9,6 +9,9 @@ class DummySeeder extends Seeder
|
||||
public function run()
|
||||
{
|
||||
$now = date('Y-m-d H:i:s');
|
||||
$yesterday = date('Y-m-d H:i:s', strtotime('-1 day'));
|
||||
$twoDaysAgo = date('Y-m-d H:i:s', strtotime('-2 days'));
|
||||
$threeDaysAgo = date('Y-m-d H:i:s', strtotime('-3 days'));
|
||||
|
||||
// users
|
||||
// Password: 'password' for all users (bcrypt hash)
|
||||
@ -19,24 +22,62 @@ class DummySeeder extends Seeder
|
||||
];
|
||||
$this->db->table('users')->insertBatch($data);
|
||||
|
||||
// patvisit
|
||||
// patvisit - 4 visits for 3 patients
|
||||
// Visit 1: Patient 1 - Discharged (complete history)
|
||||
// Visit 2: Patient 1 - Discharged (complete history)
|
||||
// Visit 3: Patient 2 - Active (no discharge yet)
|
||||
// Visit 4: Patient 3 - Discharged (complete history)
|
||||
$data = [
|
||||
['InternalPVID' => 1, "PVID" => "XLAB0001", "InternalPID" => 1, "EpisodeID" => 1, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 2, "PVID" => "XLAB0002", "InternalPID" => 1, "EpisodeID" => 1, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 1, "PVID" => "DV00001", "InternalPID" => 1, "EpisodeID" => 1, "CreateDate" => "$threeDaysAgo"],
|
||||
['InternalPVID' => 2, "PVID" => "DV00002", "InternalPID" => 1, "EpisodeID" => 1, "CreateDate" => "$twoDaysAgo"],
|
||||
['InternalPVID' => 3, "PVID" => "DV00003", "InternalPID" => 2, "EpisodeID" => 2, "CreateDate" => "$yesterday"],
|
||||
['InternalPVID' => 4, "PVID" => "DV00004", "InternalPID" => 3, "EpisodeID" => 3, "CreateDate" => "$threeDaysAgo"],
|
||||
];
|
||||
$this->db->table('patvisit')->insertBatch($data);
|
||||
|
||||
// patvisitadt
|
||||
// patvisitadt - ADT history for each visit
|
||||
// A04: Register, A01: Admit, A02: Transfer, A03: Discharge
|
||||
$data = [
|
||||
['InternalPVID' => 1, "ADTCode" => "X01", "LocationID" => 1, "AttDoc" => null, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 1, "ADTCode" => "X02", "LocationID" => null, "AttDoc" => 1, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 1, "ADTCode" => "X01", "LocationID" => 2, "AttDoc" => null, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 1, "ADTCode" => "X02", "LocationID" => null, "AttDoc" => 2, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 2, "ADTCode" => "X01", "LocationID" => 1, "AttDoc" => null, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 2, "ADTCode" => "X02", "LocationID" => null, "AttDoc" => 1, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 2, "ADTCode" => "X01", "LocationID" => 2, "AttDoc" => null, "CreateDate" => "$now"],
|
||||
['InternalPVID' => 2, "ADTCode" => "X02", "LocationID" => null, "AttDoc" => 2, "CreateDate" => "$now"],
|
||||
// Visit 1 (InternalPVID=1) - Discharged: ER -> Ward A -> Ward B -> Discharge
|
||||
['InternalPVID' => 1, "ADTCode" => "A04", "LocationID" => 1, "AttDoc" => 1, "RefDoc" => null, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => "$threeDaysAgo", "EndDate" => null],
|
||||
['InternalPVID' => 1, "ADTCode" => "A01", "LocationID" => 1, "AttDoc" => 1, "RefDoc" => null, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => date('Y-m-d H:i:s', strtotime('-2 days +2 hours')), "EndDate" => null],
|
||||
['InternalPVID' => 1, "ADTCode" => "A02", "LocationID" => 2, "AttDoc" => 1, "RefDoc" => 2, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => date('Y-m-d H:i:s', strtotime('-2 days +6 hours')), "EndDate" => null],
|
||||
['InternalPVID' => 1, "ADTCode" => "A02", "LocationID" => 2, "AttDoc" => 2, "RefDoc" => 2, "AdmDoc" => 1, "CnsDoc" => 2, "CreateDate" => date('Y-m-d H:i:s', strtotime('-1 day +8 hours')), "EndDate" => null],
|
||||
['InternalPVID' => 1, "ADTCode" => "A03", "LocationID" => null, "AttDoc" => 2, "RefDoc" => 2, "AdmDoc" => 1, "CnsDoc" => 2, "CreateDate" => date('Y-m-d H:i:s', strtotime('-1 day +12 hours')), "EndDate" => null],
|
||||
|
||||
// Visit 2 (InternalPVID=2) - Discharged: ER -> ICU -> Discharge
|
||||
['InternalPVID' => 2, "ADTCode" => "A04", "LocationID" => 1, "AttDoc" => 1, "RefDoc" => null, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => "$twoDaysAgo", "EndDate" => null],
|
||||
['InternalPVID' => 2, "ADTCode" => "A01", "LocationID" => 1, "AttDoc" => 1, "RefDoc" => null, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => date('Y-m-d H:i:s', strtotime('-1 day +1 hour')), "EndDate" => null],
|
||||
['InternalPVID' => 2, "ADTCode" => "A02", "LocationID" => 2, "AttDoc" => 2, "RefDoc" => 1, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => date('Y-m-d H:i:s', strtotime('-1 day +4 hours')), "EndDate" => null],
|
||||
['InternalPVID' => 2, "ADTCode" => "A03", "LocationID" => null, "AttDoc" => 2, "RefDoc" => 1, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => "$yesterday", "EndDate" => null],
|
||||
|
||||
// Visit 3 (InternalPVID=3) - ACTIVE: ER -> Ward A (no discharge - still admitted)
|
||||
['InternalPVID' => 3, "ADTCode" => "A04", "LocationID" => 1, "AttDoc" => 1, "RefDoc" => null, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => "$yesterday", "EndDate" => null],
|
||||
['InternalPVID' => 3, "ADTCode" => "A01", "LocationID" => 1, "AttDoc" => 1, "RefDoc" => null, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => date('Y-m-d H:i:s', strtotime('-1 day +2 hours')), "EndDate" => null],
|
||||
['InternalPVID' => 3, "ADTCode" => "A02", "LocationID" => 2, "AttDoc" => 2, "RefDoc" => 2, "AdmDoc" => 1, "CnsDoc" => null, "CreateDate" => "$now", "EndDate" => null],
|
||||
// Note: No A03 (discharge) - this visit is still active
|
||||
|
||||
// Visit 4 (InternalPVID=4) - Discharged: Direct admit -> Ward B -> Discharge
|
||||
['InternalPVID' => 4, "ADTCode" => "A04", "LocationID" => 2, "AttDoc" => 2, "RefDoc" => null, "AdmDoc" => 2, "CnsDoc" => null, "CreateDate" => "$threeDaysAgo", "EndDate" => null],
|
||||
['InternalPVID' => 4, "ADTCode" => "A01", "LocationID" => 2, "AttDoc" => 2, "RefDoc" => null, "AdmDoc" => 2, "CnsDoc" => null, "CreateDate" => date('Y-m-d H:i:s', strtotime('-2 days +3 hours')), "EndDate" => null],
|
||||
['InternalPVID' => 4, "ADTCode" => "A02", "LocationID" => 1, "AttDoc" => 1, "RefDoc" => 2, "AdmDoc" => 2, "CnsDoc" => 1, "CreateDate" => date('Y-m-d H:i:s', strtotime('-2 days +12 hours')), "EndDate" => null],
|
||||
['InternalPVID' => 4, "ADTCode" => "A03", "LocationID" => null, "AttDoc" => 1, "RefDoc" => 2, "AdmDoc" => 2, "CnsDoc" => 1, "CreateDate" => date('Y-m-d H:i:s', strtotime('-1 day +6 hours')), "EndDate" => null],
|
||||
];
|
||||
$this->db->table('patvisitadt')->insertBatch($data);
|
||||
|
||||
echo "✅ Dummy ADT data seeded successfully!\n";
|
||||
echo "-------------------------------------------\n";
|
||||
echo "Visits created: 4\n";
|
||||
echo " - Visit 1 (DV00001): Complete ADT history with discharge\n";
|
||||
echo " - Visit 2 (DV00002): Complete ADT history with discharge\n";
|
||||
echo " - Visit 3 (DV00003): ACTIVE (no discharge yet)\n";
|
||||
echo " - Visit 4 (DV00004): Complete ADT history with discharge\n";
|
||||
echo "-------------------------------------------\n";
|
||||
echo "ADT Records: 18 total\n";
|
||||
echo " - A04 (Register): 4 records\n";
|
||||
echo " - A01 (Admit): 4 records\n";
|
||||
echo " - A02 (Transfer): 6 records\n";
|
||||
echo " - A03 (Discharge): 3 records\n";
|
||||
echo "-------------------------------------------\n";
|
||||
}
|
||||
}
|
||||
BIN
docs/Use Case_260214.docx
Normal file
BIN
docs/Use Case_260214.docx
Normal file
Binary file not shown.
5152
docs/prj_clinical laboratory quality management system_3c.md
Normal file
5152
docs/prj_clinical laboratory quality management system_3c.md
Normal file
File diff suppressed because one or more lines are too long
514
docs/use_case_260214.md
Normal file
514
docs/use_case_260214.md
Normal file
@ -0,0 +1,514 @@
|
||||
Here is the converted Markdown format of the Use Case document. I have structured it with headers and lists to make it easily parsable by an AI agent.
|
||||
|
||||
```markdown
|
||||
# Use Case Document
|
||||
|
||||
## Use Case – Authentication
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-01 |
|
||||
| **Use Case Name** | Authentication |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Phlebotomist Lab, Perawat, DSPK/Konsulen, Supervisor Lab, Manajer Lab, Database Administrator, System Administrator |
|
||||
| **Aktor Sekunder** | - |
|
||||
| **Tujuan** | Verifikasi identitas pengguna, yang mencoba mengakses sistem, memastikan bahwa mereka adalah orang yang mereka klaim. Bertindak sebagai mekanisme keamanan primer untuk mencegah akses tidak sah, melindungi data, dan mengurangi risiko seperti pencurian identitas dan pelanggaran keamanan. |
|
||||
| **Prasyarat** | Data pengguna sudah terdefinisi dalam sistem sebagai User atau Contact. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor klik tombol Login.
|
||||
2. System menampilkan login dialog yang terdiri dari User ID dan Password.
|
||||
3. Aktor memasukkan email address sebagai User ID.
|
||||
4. System memeriksa email address di table User, SiteStatus, Contact dan ContactDetail:
|
||||
- Jika Aktor menggunakan email pribadi, maka System menampilkan pilihan sites dimana Aktor memiliki akses. Aktor, kemudian memilih salah satu site.
|
||||
- Jika Aktor menggunakan email site, maka System langsung mengarahkan ke site yang bersangkutan.
|
||||
5. Aktor memasukkan password.
|
||||
6. System memeriksa kebenaran User ID dan password.
|
||||
7. System memeriksa role dan menu apa saja yang bisa diakses Aktor.
|
||||
8. System menampilkan halaman utama dengan menu sesuai role Aktor.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
* **Aktor tidak terdaftar:**
|
||||
* System menampilkan pesan: “Unregistered user, please contact system administrator”.
|
||||
* **Aktor ditemukan tetapi:**
|
||||
* **Disabled:** System menampilkan pesan: “Disabled user, please contact system administrator”.
|
||||
* **Password expired:** System menampilkan pesan: “Your password is expired, please contact system administrator”.
|
||||
* **Password salah:**
|
||||
* System menampilkan pesan: “Invalid login”.
|
||||
* System menghitung jumlah percobaan login password yang gagal dan mencatat dalam Audit log (device dimana login attempt dilakukan, waktu).
|
||||
* System menghentikan proses login untuk User ID tersebut selama x jam dan menampilkan pesan, ”Please try again in x hours or contact system administrator”.
|
||||
|
||||
### Kondisi Akhir
|
||||
* Aktor masuk ke halaman utama dan mendapat akses menu-menu system yang sesuai.
|
||||
* Audit mencatat User ID, waktu, device dimana Aktor melakukan login.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Patient Registration
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-02a |
|
||||
| **Use Case Name** | Patient Registration |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Mencatatkan data demografi pasien baru ke oleh System |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi dalam System.<br>3. Pasien menunjukkan identitas yang sah (kartu identitas, atau rujukan). |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Management – Patient Registration.
|
||||
2. Aktor memasukkan PID.
|
||||
3. System memeriksa apakah PID sudah ada.
|
||||
4. System meminta detail pasien (nama, tanggal lahir, jenis kelamin, informasi kontak, nomor identitas, dst).
|
||||
5. Aktor memasukkan informasi demografis pasien, dengan mandatory data:
|
||||
- patient.NameFirst
|
||||
- patient.Gender
|
||||
- patient.Birthdate
|
||||
6. Jika Aktor memasukkan `patidt.IdentifierType` dan `patidt.Identifier`, maka System memeriksa apakah sudah ada record pasien yang menggunakan Identifier yang sama.
|
||||
7. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A04` (Register), mengkonfirmasi registrasi berhasil dan menampilkan ringkasan pasien.
|
||||
8. Aktor memberikan konfirmasi pendaftaran kepada Pasien (misalnya, slip cetak atau ID digital – barcode, QRIS, dll).
|
||||
|
||||
### Alur Alternatif
|
||||
* **Record pasien sudah ada:**
|
||||
1. Aktor memasukkan PID.
|
||||
2. System mengambil record yang sudah ada dan menampilkan data di halaman Patient Management – Patient Search & Update.
|
||||
3. Aktor memperbarui data jika diperlukan.
|
||||
4. Sistem menyimpan perubahan dan membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A08` (Update patient information).
|
||||
|
||||
### Alur Pengecualian
|
||||
* **Mandatory data tidak ada:**
|
||||
* System menolak menyimpan record.
|
||||
* Aktor diminta untuk melengkapi, setidaknya mandatory data.
|
||||
* **Record pasien tidak ada tetapi ditemukan record yang menggunakan `patidt.IdentifierType` dan `patidt.Identifier` yang sama:**
|
||||
* System menampilkan pesan ’Multiple IDs found”.
|
||||
* System menampilkan records dengan `patidt.IdentifierType` dan `patidt.Identifier` yang sama.
|
||||
* Aktor melakukan review.
|
||||
* Aktor memilih salah satu dari kemungkinan berikut:
|
||||
1. Melanjutkan membuat record pasien baru, mengabaikan record ganda.
|
||||
2. Melanjutkan membuat record pasien baru, kemudian menggabungkan record pasien (lihat UC-02b).
|
||||
3. Membatalkan pendaftaran.
|
||||
|
||||
### Kondisi Akhir
|
||||
* Record pasien dibuat atau diperbarui di System.
|
||||
* PID pasien tersedia untuk test ordering & tracing.
|
||||
* Audit mencatat bahwa record dibuat/diperbarui secara manual, User ID yang mendaftarkan/memperbarui data pasien, device dimana, kapan, dan data apa yang dimasukkan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Patient Link
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-02b |
|
||||
| **Use Case Name** | Patient Link |
|
||||
| **Aktor Utama** | Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Link (menghubungkan) satu atau beberapa record (PID) pasien (source) dengan record pasien lainnya (destination). PatientID destination adalah surviving entity, yang akan digunakan dalam semua aktivitas laboratorium. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi dalam System.<br>3. PID source dan destination telah tercatat dalam System.<br>4. PID source dan destination memiliki `patidt.IdentifierType` dan `patidt.Identifier` yang sama atau nama, alamat dan tanggal lahir yang sama. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Management - Patient Link.
|
||||
2. Aktor mencari PID menggunakan:
|
||||
- `patidt.IdentifierType` dan `patidt.Identifier`
|
||||
- Nama, alamat dan tanggal lahir
|
||||
3. System menampilkan semua PID dengan `patidt.IdentifierType` dan `patidt.Identifier` dan/atau nama, alamat dan tanggal lahir yang sama.
|
||||
4. Aktor memilih dan menentukan satu PID untuk menjadi destination. (Lihat Alur Pengecualian).
|
||||
5. Aktor memilih dan menentukan satu atau lebih, PID yang menjadi source. (Lihat Alur Pengecualian).
|
||||
6. Aktor menghubungkan PID-PID tersebut dengan menekan tombol Link.
|
||||
7. System meminta konfirmasi dari Aktor dengan menampilkan pesan,” Please confirm to link these patient records”. Disertai pilihan “Confirm” dan “Cancel”.
|
||||
8. Aktor mengkonfirmasi Patient Link dengan menekan tombol Confirm.
|
||||
9. System melakukan:
|
||||
- Membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A24` (Link Patient Information).
|
||||
- Mengkonfirmasi Patient Link berhasil.
|
||||
- Menampilkan ringkasan PID yang dihubungkan.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
* **System menemukan bahwa suatu record pasien telah menjadi source, ditandai dengan field `patient.LinkTo` telah terisi dengan PID dari record lain (ditampilkan):**
|
||||
* **Multiple link:**
|
||||
* Aktor memilih dan menunjuk record tersebut sebagai source bagi PID yang berbeda.
|
||||
* System menampilkan peringatan “Multiple link” di samping PID tersebut dan pilihan (check mark) tidak bisa dilakukan.
|
||||
* **Multi-level Link:**
|
||||
* Aktor memilih dan menunjuk record tersebut sebagai destination bagi PID yang berbeda.
|
||||
* System menampilkan peringatan “Multi-level link” di samping PID tersebut dan pilihan (check mark) tidak bisa dilakukan.
|
||||
* Jika semua atau satu-satunya PID mendapat peringatan tersebut maka, proses Patient Link sama sekali tidak bisa dilanjutkan.
|
||||
* Jika ada PID lain yang tidak mendapat peringatan, maka proses Patient Link dilanjutkan atas PID tanpa peringatan.
|
||||
|
||||
### Kondisi Akhir
|
||||
* PID source terhubung dengan PID destination.
|
||||
* Relasi source dengan test order dan lain-lain tidak berubah sebelum dan sesudah proses Patient Link.
|
||||
* Semua test order milik PID source dan destination bisa ditampilkan dalam satu cumulative view/report.
|
||||
* PID destination tersedia untuk test ordering & tracing.
|
||||
* PID source tetap bisa dicari tetapi tidak bisa di-edit maupun digunakan untuk test ordering.
|
||||
* Audit mencatat Patient Link dilakukan secara manual, waktu, User ID yang melakukan Patient Link serta device dimana aktivitas tersebut dilakukan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Patient Unlink
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-02c |
|
||||
| **Use Case Name** | Patient Unlink |
|
||||
| **Aktor Utama** | Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Melepaskan link antara source PID dan destination PID. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi dalam System.<br>3. Pasien sudah pernah registrasi di System, ditandai dengan adanya PID dengan `patidt.IdentifierType` dan `patidt.Identifier` yang sama. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Management – Patient Unlink.
|
||||
2. Aktor mencari record pasien menggunakan PID.
|
||||
3. System menampilkan PID berikut data demografinya dan semua linked PID.
|
||||
4. Aktor uncheck source PID(s) yang hendak dilepaskan dari destination PID.
|
||||
5. Aktor melepas hubungan PID-PID tersebut dengan menekan tombol Unlink.
|
||||
6. System meminta konfirmasi dari Aktor dengan menampilkan pesan,” Please confirm to unlink these patient records”. Disertai pilihan “Confirm” dan “Cancel”.
|
||||
7. Aktor mengkonfirmasi Patient Unink dengan menekan tombol Confirm.
|
||||
8. System melakukan:
|
||||
- Mengosongkan field `patient.LinkTo` dari source PID.
|
||||
- Membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A37` (Unlink Patient Information).
|
||||
- Mengkonfirmasi Patient Unlink berhasil.
|
||||
- Menampilkan ringkasan destination dan source PID yang unlinked.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
-
|
||||
|
||||
### Kondisi Akhir
|
||||
* Source PID aktif kembali, bisa diedit dan tersedia untuk test ordering & tracing.
|
||||
* Unlink source terjadi bisa isi field LinkTo dikosongkan Kembali.
|
||||
* Audit mencatat Patient Unlink dilakukan secara manual, waktu, User ID yang melakukan Patient Unlink dan device dimana aktivitas tersebut dilakukan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Patient Admission
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-03a |
|
||||
| **Use Case Name** | Patient Admission |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Menerima pasien di fasyankes untuk perawatan atau observasi. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Record pasien tersedia di System, ditandai dengan adanya PID. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Visit Management – Patient Admission.
|
||||
2. Aktor memasukkan PID.
|
||||
3. System memeriksa apakah PID ada.
|
||||
4. System menampilkan data demografi pasien dan meminta data-data:
|
||||
- **Mandatory data:** PVID, dokter, location.
|
||||
- **Optional data:** EpisodeID, diagnosis (bisa lebih dari satu), lampiran-lampiran.
|
||||
5. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A01` (Admit), mengkonfirmasi admission berhasil dan menampilkan ringkasan admission.
|
||||
6. Aktor memberikan konfirmasi admission kepada Pasien (misalnya, slip cetak atau ID digital – barcode, QRIS, dll).
|
||||
|
||||
### Alur Alternatif
|
||||
* **PID tidak ada:**
|
||||
1. System menampilkan pesan, “PID does not exist. Proceed to Patient Registration?”.
|
||||
2. Aktor memilih “Yes” dan System membuka halaman Patient Management – Patient Registration.
|
||||
3. Aktor melakukan activity patient registration dilanjutkan patient admission.
|
||||
* **Pembaruan optional data:**
|
||||
1. Aktor membuka halaman Patient Visit Management – Admission Search & Update.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System mengambil record yang sudah ada.
|
||||
4. Aktor memperbarui data jika diperlukan.
|
||||
5. Sistem menyimpan perubahan.
|
||||
|
||||
### Alur Pengecualian
|
||||
* **Mandatory data tidak ada:**
|
||||
* System menolak menyimpan record.
|
||||
* Aktor diminta untuk melengkapi, setidaknya mandatory data.
|
||||
|
||||
### Kondisi Akhir
|
||||
* Kunjungan pasien ke fasyankes tercatat (patvisit records) di System, ditandai dengan adanya PVID dan direlasikan dengan dokter dan ruangan di fasyankes.
|
||||
* Audit mencatat admission/perubahannya dilakukan secara manual, User ID yang melakukan, device dimana, kapan, dan data apa saja yang dimasukkan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Cancel Admission
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-03b |
|
||||
| **Use Case Name** | Cancel Patient Admission |
|
||||
| **Aktor Utama** | Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Membatalkan penerimaan pasien di fasyankes. Pembatalan bisa disebabkan: Data registrasi salah atau tidak lengkap, Cakupan asuransi tidak valid, Pasien menolak rawat inap, Pasien dialihkan, Permintaan rawat inap salah, Kondisi pasien berubah, Permintaan pasien, dll. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Patient Visit Record tersedia di System, ditandai dengan adanya PVID. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Visit Management – Admission Search & Update.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System menampilkan data admission pasien.
|
||||
4. Aktor mengkonfirmasi pembatalan admission ke pihak terkait dan melakukan pembatalan.
|
||||
5. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A11` (Cancel Admit), mengkonfirmasi cancel patient admission berhasil dan menampilkan ringkasan cancel patient admission.
|
||||
6. Aktor memberikan konfirmasi cancel patient admission kepada pihak terkait (misalnya, slip cetak atau ID digital – barcode, QRIS, dll).
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
-
|
||||
|
||||
### Kondisi Akhir
|
||||
* Cancel patient admission tercatat (patvisit records) di System, ditandai dengan record di `patvisitadt` dengan `patvisitadt.Code: A11`.
|
||||
* Audit mencatat cancel patient admission dilakukan secara manual, User ID yang melakukan, device dimana, kapan, dan data apa yang dimasukkan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Change Attending Doctor
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-03c |
|
||||
| **Use Case Name** | Change Attending Doctor |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Mengganti dokter yang bertanggung jawab atas pengobatan pasien (DPJP). |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Patient Visit Record tersedia di System, ditandai dengan adanya PVID dan telah memiliki data Attending Doctor (`patvisitadt.AttDoc`). |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Visit Management – Admission Search & Update.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System menampilkan data admission pasien.
|
||||
4. Aktor mengganti Attending Doctor.
|
||||
5. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A54` (Change Attending Doctor), mengkonfirmasi penggantian dokter berhasil dan menampilkan data admission yang telah diperbarui.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
-
|
||||
|
||||
### Kondisi Akhir
|
||||
* Penggantian Attending Doctor di System sehingga bisa dilakukan pelacakan Attending Doctor sekarang dan sebelumnya.
|
||||
* Audit mencatat User ID yang melakukan perubahan Attending Doctor, device dimana perubahan dilakukan, kapan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Change Consulting Doctor
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-03d |
|
||||
| **Use Case Name** | Change Consulting Doctor |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Mengganti dokter konsulen. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Patient Visit Record tersedia di System, ditandai dengan adanya PVID dan telah memiliki data Consulting Doctor (`patvisitadt.CnsDoc`). |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Visit Management – Admission Search & Update.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System menampilkan data admission pasien.
|
||||
4. Aktor mengganti Consulting Doctor.
|
||||
5. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A61` (Change Consulting Doctor), mengkonfirmasi penggantian dokter berhasil dan menampilkan data admission yang telah diperbarui.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
-
|
||||
|
||||
### Kondisi Akhir
|
||||
* Penggantian Consulting Doctor di System sehingga bisa dilakukan pelacakan Consulting Doctor sekarang dan sebelumnya.
|
||||
* Audit mencatat User ID yang melakukan perubahan Consulting Doctor, device dimana perubahan dilakukan, kapan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Patient Transfer
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-04 |
|
||||
| **Use Case Name** | Patient Transfer |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Memindahkan pasien dari satu lokasi ke lokasi lainnya. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Patient Visit Record tersedia di System, ditandai dengan adanya PVID dan telah memiliki data Location ID (`patvisitadt.LocationID`). |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Visit Management – Transfer.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System menampilkan data admission pasien.
|
||||
4. Aktor mengganti Location ID.
|
||||
5. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A02` (Patient Transfer), mengkonfirmasi perpindahan lokasi berhasil dan menampilkan data admission yang telah diperbarui.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
-
|
||||
|
||||
### Kondisi Akhir
|
||||
* Penggantian Location ID di System sehingga bisa dilakukan pelacakan Location ID sekarang dan sebelumnya.
|
||||
* Audit mencatat User ID yang melakukan perubahan Location ID, device dimana perubahan dilakukan dan kapan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Patient Discharge
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-04a |
|
||||
| **Use Case Name** | Patient Discharge |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Mengakhiri kunjungan pasien. Close billing. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Patient Visit Record tersedia di System, ditandai dengan adanya PVID. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Visit Management – Discharge.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System memeriksa apakah PVID tersebut memiliki test order.
|
||||
4. System memeriksa `orderstatus.OrderStatus` dari test order tsb.
|
||||
5. System menampilkan data admission pasien.
|
||||
6. Aktor mengisikan tanggal discharge.
|
||||
7. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A03` (Discharge), mengkonfirmasi discharge/end visit berhasil dan menampilkan data admission yang telah di-discharge.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
* **Open test order:**
|
||||
* System menolak discharge, jika menemukan `orderstatus.OrderStatus` bernilai ”A” atau “IP” atau “SC” atau “HD”.
|
||||
* Aktor diminta untuk menyelesaikan test order terkait.
|
||||
|
||||
### Kondisi Akhir
|
||||
* Discharge visit di System.
|
||||
* Audit mencatat User ID yang melakukan discharge, device dimana discharge dilakukan dan kapan.
|
||||
* Semua record terkait visit tersebut tidak bisa diedit/update lagi – data-data pada `patvisit`, `patdiag`, `patvisitbill`. Hal-hal berikut tidak bisa dilakukan lagi:
|
||||
- Perpindahan lokasi dan/atau dokter.
|
||||
- Test order.
|
||||
- Billing is closed.
|
||||
* **Cancel discharge:**
|
||||
- Bisa dilakukan atas instruksi dari HIS, misalnya berupa ADT message.
|
||||
- Oleh orang tertentu saja di lab.
|
||||
- Tidak meng-update existing record tetapi men-trigger tambahan `patvisitadt` record dengan Code: A13 (cancel discharge).
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Cancel Discharge
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-04b |
|
||||
| **Use Case Name** | Cancel Patient Discharge |
|
||||
| **Aktor Utama** | Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Membatalkan Patient Discharge. Open billing. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Patient Visit Record tersedia di System, ditandai dengan adanya PVID dan telah discharge. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Patient Visit Management – Cancel Patient Discharge.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System menampilkan data admission pasien.
|
||||
4. Aktor membatalkan discharge dengan menekan tombol Cancel Discharge.
|
||||
5. System membuat record baru di `patvisitadt` dengan `patvisitadt.Code: A13` (Cancel Discharge), mengkonfirmasi cancel discharge berhasil dan menampilkan data admission yang telah dibatalkan discharge-nya.
|
||||
|
||||
### Alur Alternatif
|
||||
-
|
||||
|
||||
### Alur Pengecualian
|
||||
-
|
||||
|
||||
### Kondisi Akhir
|
||||
* Pembatalan discharge di System.
|
||||
* Audit mencatat cancel discharge dilakukan secara manual, User ID yang melakukan, device dimana activity dilakukan dan kapan.
|
||||
* Semua record terkait visit tersebut kembali bisa diedit/update lagi – data-data pada `patvisit`, `patdiag`, `patvisitbill`. Hal-hal berikut bisa dilakukan lagi:
|
||||
- Perpindahan lokasi dan/atau dokter.
|
||||
- Test order.
|
||||
- Billing is re-open.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Test Ordering
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-5a |
|
||||
| **Use Case Name** | Test Ordering |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Membuat test order untuk pasien. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Patient Visit Record tersedia di System, ditandai dengan adanya PVID. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Test Ordering – New Test Order.
|
||||
2. Aktor memasukkan PVID.
|
||||
3. System menampilkan data demografi, daftar PVID pasien berikut daftar OrderID (OID) yang telah dibuat sebelumnya (menghindari test order berlebihan).
|
||||
4. Aktor bisa menambahkan komentar dan/atau lampiran ke test order.
|
||||
5. Aktor memilih test yang diperlukan.
|
||||
6. Aktor bisa memilih mencetak labels segera setelah klik tombol Save, dengan mencentang Print Patient Label, Print Order Label, Print Specimen Label check boxes.
|
||||
7. Aktor menyimpan test order dengan menekan tombol Save.
|
||||
8. System secara otomatis memberi OID.
|
||||
9. System otomatis membuat records di table specimens.
|
||||
10. System, mengkonfirmasi test ordering berhasil dan menampilkan data test order berikut daftar SID.
|
||||
|
||||
### Alur Alternatif
|
||||
* **PVID belum ada:**
|
||||
1. System mengarahkan Aktor ke halaman Patient Visit Management – Patient Admission.
|
||||
2. Aktor melakukan activity patient admission.
|
||||
3. Aktir kembali ke test ordering.
|
||||
* **Test ordering menggunakan PID:**
|
||||
1. Aktor membuka halaman Test Ordering – New Test Order.
|
||||
2. Aktor memasukkan PID.
|
||||
3. System menampilkan daftar PVID yang belum discharge.
|
||||
4. Aktor memilih salah satu PVID dan melanjutkan activity test ordering.
|
||||
* **Future Order:**
|
||||
1. Aktor mengisi Effective Date (`ordertest.EffDate`) untuk menjadwalkan kapan test order mulai dikerjakan.
|
||||
2. Aktor menyimpan test order dengan menekan tombol Save.
|
||||
3. System memberikan OID yang sesuai dengan Effective Date.
|
||||
* **OID sudah ada:**
|
||||
1. Aktor membuka halaman Test Ordering – Test Order Search & Update.
|
||||
2. Aktor memasukan OID.
|
||||
3. System menampilkan data-data test order.
|
||||
4. Aktor melakukan update dan menyimpannya.
|
||||
* **Non patient option** (Not detailed in text).
|
||||
|
||||
### Alur Pengecualian
|
||||
-
|
||||
|
||||
### Kondisi Akhir
|
||||
* Test order terbentuk di System ditandai dengan adanya OID dengan status (`orderstatus.OrderStatus`) ”SC” (In process, scheduled).
|
||||
* SID terbentuk dan specimen label bisa dicetak atau tercetak otomatis.
|
||||
* Audit mencatat test order dilakukan secara manual, User ID yang melakukan, device dimana activity dilakukan dan kapan.
|
||||
|
||||
---
|
||||
|
||||
## Use Case – Update Test Order
|
||||
| **Field** | **Description** |
|
||||
| :--- | :--- |
|
||||
| **Use Case ID** | UC-5b |
|
||||
| **Use Case Name** | Update Test Order |
|
||||
| **Aktor Utama** | Admin Lab / Clerk, Analis Lab, Analis Lab Senior, Super User, Supervisor Lab, Manajer Lab |
|
||||
| **Aktor Sekunder** | Pasien |
|
||||
| **Tujuan** | Memperbarui test order untuk pasien. |
|
||||
| **Prasyarat** | 1. System beroperasi dan dapat diakses.<br>2. Petugas pendaftaran telah terautentikasi oleh System.<br>3. Test order tersedia di System, ditandai dengan adanya OID. |
|
||||
|
||||
### Alur Utama
|
||||
1. Aktor membuka halaman Test Ordering – Test Order Search & Update.
|
||||
2. Aktor memasukkan OID.
|
||||
3. System menampilkan data-data test order.
|
||||
4. Aktor melakukan update dan menyimpannya.
|
||||
5. System, mengkonfirmasi update test order berhasil dan menampilkan data test order berikut daftar SID.
|
||||
|
||||
### Alur Alternatif
|
||||
* **PVID belum ada:**
|
||||
1. System mengarahkan Aktor ke halaman Patient Visit Management – Patient Admission.
|
||||
2. Aktor melakukan activity patient admission.
|
||||
3. Aktir kembali ke test ordering.
|
||||
* **Non patient option** (Not detailed in text).
|
||||
|
||||
### Alur Pengecualian
|
||||
* **Test order tidak ada:**
|
||||
* System menolak melakukan update dan menampilkan pesan,” Test order does not exists”.
|
||||
* **Test order berstatus closed:** Ditandai dengan `ordertest.EndDate` memiliki value dan `orderstatus.OrderStatus` bernilai CL (Closed).
|
||||
* System menolak melakukan update dan menampilkan pesan,” This test order is inaccessible”.
|
||||
* **Test order berstatus archived:** Ditandai dengan `ordertest.ArchiveDate` memiliki value dan `orderstatus.OrderStatus` bernilai AC (Archived).
|
||||
* System menolak melakukan update dan menampilkan pesan,” This test order is already archived”.
|
||||
* **Test order berstatus deleted:** Ditandai dengan `ordertest.DelDate` memiliki value dan `orderstatus.OrderStatus` bernilai DL (Deleted).
|
||||
* System menolak melakukan update dan menampilkan pesan,” This test order is already deleted”.
|
||||
* **Update dilakukan dengan menghapus test yang telah ada hasilnya:**
|
||||
* System menampilkan data-data test order.
|
||||
* Aktor mengganti test yang telah ada hasilnya.
|
||||
* System menolak melakukan update dan menampilkan pesan,” This test order is inaccessible”.
|
||||
|
||||
### Kondisi Akhir
|
||||
* Test order terbentuk di System ditandai dengan adanya OID dengan status (`orderstatus.OrderStatus`) ”SC” (In process, scheduled).
|
||||
* SID terbentuk dan specimen label bisa dicetak atau tercetak otomatis.
|
||||
* Audit mencatat test order dilakukan secara manual, User ID yang melakukan, device dimana activity dilakukan dan kapan.
|
||||
```
|
||||
@ -665,6 +665,276 @@ components:
|
||||
type: string
|
||||
Formula:
|
||||
type: string
|
||||
refnum:
|
||||
type: array
|
||||
description: Numeric reference ranges (optional). Mutually exclusive with reftxt - a test can only have ONE reference type.
|
||||
items:
|
||||
type: object
|
||||
properties:
|
||||
RefNumID:
|
||||
type: integer
|
||||
NumRefType:
|
||||
type: string
|
||||
enum: [NMRC, THOLD]
|
||||
description: NMRC=Numeric range, THOLD=Threshold
|
||||
NumRefTypeLabel:
|
||||
type: string
|
||||
RangeType:
|
||||
type: string
|
||||
RangeTypeLabel:
|
||||
type: string
|
||||
Sex:
|
||||
type: string
|
||||
SexLabel:
|
||||
type: string
|
||||
LowSign:
|
||||
type: string
|
||||
LowSignLabel:
|
||||
type: string
|
||||
HighSign:
|
||||
type: string
|
||||
HighSignLabel:
|
||||
type: string
|
||||
High:
|
||||
type: number
|
||||
format: float
|
||||
Low:
|
||||
type: number
|
||||
format: float
|
||||
AgeStart:
|
||||
type: integer
|
||||
AgeEnd:
|
||||
type: integer
|
||||
Flag:
|
||||
type: string
|
||||
Interpretation:
|
||||
type: string
|
||||
reftxt:
|
||||
type: array
|
||||
description: Text reference ranges (optional). Mutually exclusive with refnum - a test can only have ONE reference type.
|
||||
items:
|
||||
type: object
|
||||
properties:
|
||||
RefTxtID:
|
||||
type: integer
|
||||
TxtRefType:
|
||||
type: string
|
||||
enum: [TEXT, VSET]
|
||||
description: TEXT=Free text, VSET=Value set
|
||||
TxtRefTypeLabel:
|
||||
type: string
|
||||
Sex:
|
||||
type: string
|
||||
SexLabel:
|
||||
type: string
|
||||
AgeStart:
|
||||
type: integer
|
||||
AgeEnd:
|
||||
type: integer
|
||||
RefTxt:
|
||||
type: string
|
||||
Flag:
|
||||
type: string
|
||||
examples:
|
||||
TEST_simple:
|
||||
summary: Technical test - no reference range
|
||||
value:
|
||||
id: 1
|
||||
TestCode: GLU
|
||||
TestName: Glucose
|
||||
TestType: TEST
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: SER
|
||||
Unit: mg/dL
|
||||
TEST_numeric_nmrc:
|
||||
summary: Technical test - numeric reference (NMRC)
|
||||
value:
|
||||
id: 1
|
||||
TestCode: GLU
|
||||
TestName: Glucose
|
||||
TestType: TEST
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: SER
|
||||
Unit: mg/dL
|
||||
refnum:
|
||||
- RefNumID: 1
|
||||
NumRefType: NMRC
|
||||
NumRefTypeLabel: Numeric
|
||||
RangeType: REF
|
||||
RangeTypeLabel: Reference Range
|
||||
Sex: '2'
|
||||
SexLabel: Male
|
||||
LowSign: GE
|
||||
LowSignLabel: '>=
|
||||
HighSign: LE
|
||||
HighSignLabel: '<='
|
||||
Low: 70
|
||||
High: 100
|
||||
AgeStart: 18
|
||||
AgeEnd: 99
|
||||
Flag: N
|
||||
Interpretation: Normal
|
||||
TEST_numeric_thold:
|
||||
summary: Technical test - threshold reference (THOLD)
|
||||
value:
|
||||
id: 1
|
||||
TestCode: GLU
|
||||
TestName: Glucose
|
||||
TestType: TEST
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: SER
|
||||
Unit: mg/dL
|
||||
refnum:
|
||||
- RefNumID: 2
|
||||
NumRefType: THOLD
|
||||
NumRefTypeLabel: Threshold
|
||||
RangeType: PANIC
|
||||
RangeTypeLabel: Panic Range
|
||||
Sex: '1'
|
||||
SexLabel: Female
|
||||
LowSign: LT
|
||||
LowSignLabel: '<'
|
||||
High: 40
|
||||
AgeStart: 0
|
||||
AgeEnd: 120
|
||||
Flag: L
|
||||
Interpretation: Critical Low
|
||||
TEST_text_text:
|
||||
summary: Technical test - text reference (TEXT)
|
||||
value:
|
||||
id: 1
|
||||
TestCode: RBC_MORPH
|
||||
TestName: RBC Morphology
|
||||
TestType: TEST
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: BLD
|
||||
Unit: null
|
||||
reftxt:
|
||||
- RefTxtID: 1
|
||||
TxtRefType: TEXT
|
||||
TxtRefTypeLabel: Text
|
||||
Sex: '2'
|
||||
SexLabel: Male
|
||||
AgeStart: 18
|
||||
AgeEnd: 99
|
||||
RefTxt: 'NORM=Normal;HYPO=Hypochromic;MACRO=Macrocytic'
|
||||
Flag: N
|
||||
TEST_text_vset:
|
||||
summary: Technical test - text reference (VSET)
|
||||
value:
|
||||
id: 1
|
||||
TestCode: STAGE
|
||||
TestName: Disease Stage
|
||||
TestType: TEST
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: null
|
||||
Unit: null
|
||||
reftxt:
|
||||
- RefTxtID: 2
|
||||
TxtRefType: VSET
|
||||
TxtRefTypeLabel: Value Set
|
||||
Sex: '1'
|
||||
SexLabel: Female
|
||||
AgeStart: 0
|
||||
AgeEnd: 120
|
||||
RefTxt: 'STG1=Stage 1;STG2=Stage 2;STG3=Stage 3;STG4=Stage 4'
|
||||
Flag: N
|
||||
PARAM:
|
||||
summary: Parameter - no reference range allowed
|
||||
value:
|
||||
id: 2
|
||||
TestCode: GLU_FAST
|
||||
TestName: Fasting Glucose
|
||||
TestType: PARAM
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: SER
|
||||
Unit: mg/dL
|
||||
CALC_numeric_nmrc:
|
||||
summary: Calculated test - numeric reference (NMRC)
|
||||
value:
|
||||
id: 3
|
||||
TestCode: BUN_CR_RATIO
|
||||
TestName: BUN/Creatinine Ratio
|
||||
TestType: CALC
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: SER
|
||||
Unit: null
|
||||
Formula: "BUN / Creatinine"
|
||||
refnum:
|
||||
- RefNumID: 5
|
||||
NumRefType: NMRC
|
||||
NumRefTypeLabel: Numeric
|
||||
RangeType: REF
|
||||
RangeTypeLabel: Reference Range
|
||||
Sex: '1'
|
||||
SexLabel: Female
|
||||
LowSign: GE
|
||||
LowSignLabel: '>=
|
||||
HighSign: LE
|
||||
HighSignLabel: '<='
|
||||
Low: 10
|
||||
High: 20
|
||||
AgeStart: 18
|
||||
AgeEnd: 120
|
||||
Flag: N
|
||||
Interpretation: Normal
|
||||
CALC_numeric_thold:
|
||||
summary: Calculated test - threshold reference (THOLD)
|
||||
value:
|
||||
id: 3
|
||||
TestCode: BUN_CR_RATIO
|
||||
TestName: BUN/Creatinine Ratio
|
||||
TestType: CALC
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: SER
|
||||
Unit: null
|
||||
Formula: "BUN / Creatinine"
|
||||
refnum:
|
||||
- RefNumID: 6
|
||||
NumRefType: THOLD
|
||||
NumRefTypeLabel: Threshold
|
||||
RangeType: PANIC
|
||||
RangeTypeLabel: Panic Range
|
||||
Sex: '1'
|
||||
SexLabel: Female
|
||||
LowSign: GT
|
||||
LowSignLabel: '>'
|
||||
Low: 20
|
||||
AgeStart: 18
|
||||
AgeEnd: 120
|
||||
Flag: H
|
||||
Interpretation: Elevated - possible prerenal cause
|
||||
|
||||
GROUP:
|
||||
summary: Panel/Profile - no reference range allowed
|
||||
value:
|
||||
id: 4
|
||||
TestCode: LIPID
|
||||
TestName: Lipid Panel
|
||||
TestType: GROUP
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: SER
|
||||
Unit: null
|
||||
TITLE:
|
||||
summary: Section header - no reference range allowed
|
||||
value:
|
||||
id: 5
|
||||
TestCode: CHEM_HEADER
|
||||
TestName: '--- CHEMISTRY ---'
|
||||
TestType: TITLE
|
||||
DisciplineID: 1
|
||||
DepartmentID: 1
|
||||
SpecimenType: null
|
||||
Unit: null
|
||||
|
||||
TestMap:
|
||||
type: object
|
||||
@ -1682,52 +1952,23 @@ paths:
|
||||
items:
|
||||
$ref: '#/components/schemas/PatientVisit'
|
||||
|
||||
/api/patvisitadt:
|
||||
post:
|
||||
/api/patvisitadt/visit/{visitId}:
|
||||
get:
|
||||
tags: [Patient Visits]
|
||||
summary: Create ADT visit (Admission/Discharge/Transfer)
|
||||
summary: Get ADT history by visit ID
|
||||
description: Retrieve the complete Admission/Discharge/Transfer history for a visit, including all locations and doctors
|
||||
security:
|
||||
- bearerAuth: []
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
type: object
|
||||
required:
|
||||
- InternalPVID
|
||||
- ADTCode
|
||||
properties:
|
||||
InternalPVID:
|
||||
type: integer
|
||||
description: Internal Visit ID from patvisit table (required)
|
||||
ADTCode:
|
||||
type: string
|
||||
enum: [A01, A02, A03, A04, A08]
|
||||
description: |
|
||||
A01: Admit
|
||||
A02: Transfer
|
||||
A03: Discharge
|
||||
A04: Register
|
||||
A08: Update
|
||||
LocationID:
|
||||
type: integer
|
||||
description: Location/ward ID
|
||||
AttDoc:
|
||||
type: integer
|
||||
description: Attending physician ContactID
|
||||
RefDoc:
|
||||
type: integer
|
||||
description: Referring physician ContactID
|
||||
AdmDoc:
|
||||
type: integer
|
||||
description: Admitting physician ContactID
|
||||
CnsDoc:
|
||||
type: integer
|
||||
description: Consulting physician ContactID
|
||||
parameters:
|
||||
- name: visitId
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
description: Internal Visit ID (InternalPVID)
|
||||
responses:
|
||||
'201':
|
||||
description: ADT visit created
|
||||
'200':
|
||||
description: ADT history retrieved successfully
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
@ -1735,17 +1976,61 @@ paths:
|
||||
properties:
|
||||
status:
|
||||
type: string
|
||||
example: success
|
||||
message:
|
||||
type: string
|
||||
example: ADT history retrieved
|
||||
data:
|
||||
type: object
|
||||
properties:
|
||||
PVADTID:
|
||||
type: integer
|
||||
type: array
|
||||
items:
|
||||
type: object
|
||||
properties:
|
||||
PVADTID:
|
||||
type: integer
|
||||
InternalPVID:
|
||||
type: integer
|
||||
ADTCode:
|
||||
type: string
|
||||
enum: [A01, A02, A03, A04, A08]
|
||||
LocationID:
|
||||
type: integer
|
||||
LocationName:
|
||||
type: string
|
||||
AttDoc:
|
||||
type: integer
|
||||
AttDocFirstName:
|
||||
type: string
|
||||
AttDocLastName:
|
||||
type: string
|
||||
RefDoc:
|
||||
type: integer
|
||||
RefDocFirstName:
|
||||
type: string
|
||||
RefDocLastName:
|
||||
type: string
|
||||
AdmDoc:
|
||||
type: integer
|
||||
AdmDocFirstName:
|
||||
type: string
|
||||
AdmDocLastName:
|
||||
type: string
|
||||
CnsDoc:
|
||||
type: integer
|
||||
CnsDocFirstName:
|
||||
type: string
|
||||
CnsDocLastName:
|
||||
type: string
|
||||
CreateDate:
|
||||
type: string
|
||||
format: date-time
|
||||
EndDate:
|
||||
type: string
|
||||
format: date-time
|
||||
|
||||
patch:
|
||||
$1
|
||||
delete:
|
||||
tags: [Patient Visits]
|
||||
summary: Update ADT visit
|
||||
summary: Delete ADT visit (soft delete)
|
||||
security:
|
||||
- bearerAuth: []
|
||||
requestBody:
|
||||
@ -1759,37 +2044,28 @@ paths:
|
||||
properties:
|
||||
PVADTID:
|
||||
type: integer
|
||||
description: ADT record ID (required)
|
||||
InternalPVID:
|
||||
type: integer
|
||||
description: Internal Visit ID from patvisit table
|
||||
ADTCode:
|
||||
type: string
|
||||
enum: [A01, A02, A03, A04, A08]
|
||||
description: |
|
||||
A01: Admit
|
||||
A02: Transfer
|
||||
A03: Discharge
|
||||
A04: Register
|
||||
A08: Update
|
||||
LocationID:
|
||||
type: integer
|
||||
description: Location/ward ID
|
||||
AttDoc:
|
||||
type: integer
|
||||
description: Attending physician ContactID
|
||||
RefDoc:
|
||||
type: integer
|
||||
description: Referring physician ContactID
|
||||
AdmDoc:
|
||||
type: integer
|
||||
description: Admitting physician ContactID
|
||||
CnsDoc:
|
||||
type: integer
|
||||
description: Consulting physician ContactID
|
||||
description: ADT record ID to delete
|
||||
responses:
|
||||
'200':
|
||||
description: ADT visit updated
|
||||
description: ADT visit deleted successfully
|
||||
|
||||
/api/patvisitadt/{id}:
|
||||
get:
|
||||
tags: [Patient Visits]
|
||||
summary: Get ADT record by ID
|
||||
description: Retrieve a single ADT record by its ID, including location and doctor details
|
||||
security:
|
||||
- bearerAuth: []
|
||||
parameters:
|
||||
- name: id
|
||||
in: path
|
||||
required: true
|
||||
schema:
|
||||
type: integer
|
||||
description: ADT record ID (PVADTID)
|
||||
responses:
|
||||
'200':
|
||||
description: ADT record retrieved successfully
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
@ -1797,97 +2073,56 @@ paths:
|
||||
properties:
|
||||
status:
|
||||
type: string
|
||||
example: success
|
||||
message:
|
||||
type: string
|
||||
example: ADT record retrieved
|
||||
data:
|
||||
type: object
|
||||
properties:
|
||||
PVADTID:
|
||||
type: integer
|
||||
InternalPVID:
|
||||
type: integer
|
||||
ADTCode:
|
||||
type: string
|
||||
enum: [A01, A02, A03, A04, A08]
|
||||
LocationID:
|
||||
type: integer
|
||||
LocationName:
|
||||
type: string
|
||||
AttDoc:
|
||||
type: integer
|
||||
AttDocFirstName:
|
||||
type: string
|
||||
AttDocLastName:
|
||||
type: string
|
||||
RefDoc:
|
||||
type: integer
|
||||
RefDocFirstName:
|
||||
type: string
|
||||
RefDocLastName:
|
||||
type: string
|
||||
AdmDoc:
|
||||
type: integer
|
||||
AdmDocFirstName:
|
||||
type: string
|
||||
AdmDocLastName:
|
||||
type: string
|
||||
CnsDoc:
|
||||
type: integer
|
||||
CnsDocFirstName:
|
||||
type: string
|
||||
CnsDocLastName:
|
||||
type: string
|
||||
CreateDate:
|
||||
type: string
|
||||
format: date-time
|
||||
EndDate:
|
||||
type: string
|
||||
format: date-time
|
||||
|
||||
# ========================================
|
||||
# Organization - Account Routes
|
||||
# ========================================
|
||||
/api/organization/account:
|
||||
get:
|
||||
tags: [Organization]
|
||||
summary: List accounts
|
||||
security:
|
||||
- bearerAuth: []
|
||||
responses:
|
||||
'200':
|
||||
description: List of accounts
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
type: object
|
||||
properties:
|
||||
status:
|
||||
type: string
|
||||
data:
|
||||
type: array
|
||||
items:
|
||||
$ref: '#/components/schemas/Account'
|
||||
|
||||
post:
|
||||
tags: [Organization]
|
||||
summary: Create account
|
||||
security:
|
||||
- bearerAuth: []
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/Account'
|
||||
responses:
|
||||
'201':
|
||||
description: Account created
|
||||
|
||||
patch:
|
||||
tags: [Organization]
|
||||
summary: Update account
|
||||
security:
|
||||
- bearerAuth: []
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
AccountName:
|
||||
type: string
|
||||
AccountCode:
|
||||
type: string
|
||||
AccountType:
|
||||
type: string
|
||||
responses:
|
||||
'200':
|
||||
description: Account updated
|
||||
|
||||
delete:
|
||||
tags: [Organization]
|
||||
summary: Delete account
|
||||
security:
|
||||
- bearerAuth: []
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
type: object
|
||||
required:
|
||||
- id
|
||||
properties:
|
||||
id:
|
||||
type: integer
|
||||
responses:
|
||||
'200':
|
||||
description: Account deleted
|
||||
|
||||
/api/organization/account/{id}:
|
||||
$2/account/{id}:
|
||||
get:
|
||||
tags: [Organization]
|
||||
summary: Get account by ID
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user