# ENCOUNTER EDIT MODE - TEST DOCUMENTATION

## Overview
Dokumentasi lengkap untuk testing fitur edit encounter dengan endpoint GET dan PATCH.

**Branch:** `feat/encounter-adjustment-163`  
**Components:** encounter-entry.handler.ts, encounter.service.ts, entry.vue  
**API Endpoints:**
- GET: `{{base_url}}/v1/encounter/{id}`
- PATCH: `{{base_url}}/v1/encounter/{id}`

---

## System Architecture

### Handler Flow (Edit Mode)

```
Page Mount
  ├─ props.id > 0 (Edit Mode Detected)
  ├─ handleInit()
  │  ├─ Load specialists, doctors, payment types
  │  └─ Initialize form
  ├─ getFetchEncounterDetail()
  │  ├─ GET /v1/encounter/{id}?includes=patient,patient-person,specialist,subspecialist
  │  ├─ mapEncounterToForm() - Map API response to form
  │  └─ Set formObjects.value with:
  │     ├─ Patient data (name, NIK, RM)
  │     ├─ Doctor/Specialist info
  │     ├─ Payment type & BPJS data
  │     ├─ SEP type & SEP number
  │     ├─ Participant group code
  │     └─ Dates in ISO format
  └─ Entry form auto-watches props.objects & populates UI

Form Edit → Save Click
  ├─ handleSaveEncounter(formValues)
  │  ├─ Validation check (patient selected)
  │  ├─ Build payload with:
  │  │  ├─ patient_id
  │  │  ├─ appointment_doctor_code
  │  │  ├─ class_code, subClass_code
  │  │  ├─ unit_code (from user store)
  │  │  ├─ paymentMethod_code (mapped from paymentType)
  │  │  ├─ specialist_id, subspecialist_id
  │  │  ├─ vclaimReference (if BPJS)
  │  │  └─ registeredAt, visitDate
  │  ├─ if (isEditMode) PATCH /v1/encounter/{id}
  │  ├─ else POST /v1/encounter
  │  ├─ Success → Toast + Redirect to list
  │  └─ Error → Toast with error message
  └─ Console logging for debugging
```

### Data Mapping Reference

| API Field | Form Field | Notes |
|-----------|-----------|-------|
| `id` | (used in URL param) | Encounter ID for PATCH |
| `patient.id` | `selectedPatient.value` | Patient reference |
| `patient.person.name` | `patientName` | Read-only display |
| `patient.person.residentIdentityNumber` | `nationalIdentity` | Read-only display |
| `patient.number` | `medicalRecordNumber` | Read-only display |
| `appointment_doctor_id` or `responsible_doctor_id` | `doctorId` | String conversion |
| `specialist_id` | (resolved to code) | → `subSpecialistId` |
| `subspecialist_id` | (resolved to code) | → `subSpecialistId` |
| `registeredAt` or `visitDate` | `registerDate` | YYYY-MM-DD format |
| `paymentMethod_code` | `paymentType` | Mapping: insurance→jkn, cash→spm, membership→pks |
| `member_number` | `cardNumber` | BPJS card number |
| `ref_number` | `sepNumber` | SEP reference number |
| `sep_type` | `sepType` | Type of SEP (internal/external) |
| `participant_group_code` | `patientCategory` | Participant group |
| `vclaimReference` | (internal ref) | BPJS reference object |

---

## Test Cases

### TEST 1: Load Edit Page
**Objective:** Verify form loads with existing encounter data  
**URL:** `http://localhost:3000/outpatient/encounter/123/edit`

**Steps:**
1. Navigate to edit page with valid encounter ID
2. Observe browser console for logging:
   ```
   📥 [EDIT MODE] Loading encounter detail: {id: 123}
   📥 [EDIT MODE] API Response: {success: true, data: {...}}
   📋 [EDIT MODE] Mapped encounter to form: {...}
   ✅ [EDIT MODE] Encounter detail loaded and form mapped successfully
   ```
3. Verify form fields are populated with encounter data

**Expected Result:**
- Form shows loading spinner briefly
- All form fields populate with encounter data
- No validation errors shown initially
- Save button is enabled

**Check Items:**
- [ ] Patient name displayed correctly
- [ ] Doctor/Specialist selected correctly
- [ ] Register date displayed in YYYY-MM-DD format
- [ ] Payment type matches (jkn, spm, pks, jkmm)
- [ ] BPJS fields (card number, SEP number) populated if payment type is jkn
- [ ] No console errors

---

### TEST 2: Edit & Save Changes
**Objective:** Verify PATCH request sends correct payload  
**URL:** `http://localhost:3000/outpatient/encounter/123/edit`

**Setup:**
1. Page loaded from TEST 1 state
2. Encounter has: paymentType=spm, doctorId=5, subSpecialistId=GENERAL

**Steps:**
1. Change payment type from SPM to JKN
2. Change doctor selection
3. Click Save button
4. Observe browser console for:
   ```
   💾 [EDIT MODE] Sending PATCH request: {id: 123, payload: {...}}
   ```

**Expected Payload Structure:**
```json
{
  "patient_id": 456,
  "appointment_doctor_code": "5",
  "class_code": "ambulatory",
  "subClass_code": "reg",
  "unit_code": "UNIT001",
  "refSource_name": "RSSA",
  "refTypeCode": "bpjs",
  "paymentType": "jkn",
  "paymentMethod_code": "insurance",
  "specialist_id": null,
  "subspecialist_id": null,
  "registeredAt": "2025-12-02T00:00:00.000Z",
  "visitDate": "2025-12-02T00:00:00.000Z"
}
```

**Check Items:**
- [ ] PATCH endpoint called (not POST)
- [ ] ID correct in URL: `/v1/encounter/123`
- [ ] appointment_doctor_code is string, not number
- [ ] paymentMethod_code = 'insurance' when paymentType = 'jkn'
- [ ] Dates in ISO format with Z suffix
- [ ] Response success = true
- [ ] Console shows: `✅ [SAVE] Success - Redirecting to list page`

---

### TEST 3: BPJS Payment Type Conditional Fields
**Objective:** Verify JKN payment type shows/requires BPJS fields  
**URL:** `http://localhost:3000/outpatient/encounter/123/edit`

**Setup:**
1. Encounter has paymentType=spm
2. Card number and SEP number are empty/not shown

**Steps:**
1. Change payment type to JKN
2. Observe form rendering:
   - Card number field should appear and be enabled
   - SEP type field should appear
   - SEP number field should appear
3. Leave card number empty
4. Try to save
5. Observe validation error: "No. Kartu BPJS wajib diisi"

**Expected Result:**
- Form validation enforces JKN required fields
- No PATCH request sent if validation fails
- Error toast displayed with validation message

**Check Items:**
- [ ] Card number field visible when paymentType=jkn
- [ ] Card number field required (red asterisk)
- [ ] SEP type field visible when paymentType=jkn
- [ ] Validation prevents save without card number
- [ ] Validation prevents save without SEP number (if sepType selected)

---

### TEST 4: API Error Handling
**Objective:** Verify proper error handling for API failures  
**Scenario:** Network error or API returns error

**Setup:**
1. Open Developer Tools → Network tab
2. Filter to show XHR requests
3. Page in edit mode with encounter ID

**Steps (Simulate Error):**
1. Throttle network to "Slow 3G" or offline
2. Try to load page or save changes
3. Observe console and UI response

**Expected Result:**
- GET failure: Toast shows "Gagal memuat data kunjungan" + redirect to list
- PATCH failure: Toast shows error message from API or "Gagal memperbarui kunjungan"
- Console shows ❌ error logging with error details

**Check Items:**
- [ ] GET error shows appropriate error toast
- [ ] PATCH error shows appropriate error toast
- [ ] Automatic redirect on GET failure
- [ ] No redirect on PATCH failure (user can retry)
- [ ] Console shows stack trace for debugging

---

### TEST 5: Data Type Conversions
**Objective:** Verify all data type conversions work correctly

**Test Data:**
- appointmentDoctorId: 5 (number) → doctorId: "5" (string)
- registeredAt: "2025-12-02T10:30:00Z" → registerDate: "2025-12-02" (date only)
- paymentMethod_code: "insurance" → paymentType: "jkn"
- specialistId: 10 → specialist code resolution

**Steps:**
1. Load edit page with encounter containing above data
2. Verify form displays correctly
3. Save changes
4. Verify request payload has correct types

**Expected Result:**
- All conversions happen transparently
- Form displays human-readable values (dates, payment type names)
- API receives correct types (string IDs, ISO dates, code values)

**Check Items:**
- [ ] Doctor ID converted to string
- [ ] Dates displayed as YYYY-MM-DD, sent as ISO with Z
- [ ] Payment type display name matches code
- [ ] No type errors in console
- [ ] Specialist code properly resolved from ID

---

## Console Logging Guide

### Expected Log Patterns

**Page Load (Edit Mode):**
```javascript
📥 [EDIT MODE] Loading encounter detail: {id: 123}
📥 [EDIT MODE] API Response: {success: true, data: {...}}
📋 [EDIT MODE] Mapped encounter to form: {encounterData: {...}, formData: {...}, ...}
✅ [EDIT MODE] Encounter detail loaded and form mapped successfully
```

**Form Save (PATCH):**
```javascript
💾 [EDIT MODE] Sending PATCH request: {id: 123, payload: {...}}
📤 [SAVE] API Response: {success: true, message: "OK"}
✅ [SAVE] Success - Redirecting to list page
```

**Form Save (POST):**
```javascript
💾 [ADD MODE] Sending POST request: {payload: {...}}
📤 [SAVE] API Response: {success: true, message: "OK"}
✅ [SAVE] Success - Redirecting to list page
```

**Error Scenarios:**
```javascript
❌ [EDIT MODE] Failed to load encounter: 'Encounter not found'
❌ [SAVE] Failed: 'Validation error: invalid doctor_id'
❌ [SAVE] Error saving encounter: Error: Failed to put encounter
```

---

## Implementation Checklist

- [x] API endpoints verified (GET and PATCH exist in service)
- [x] Handler supports both create and update modes
- [x] Data mapping covers all form fields
- [x] SEP type and participant group code mapping added
- [x] Enhanced logging for debugging
- [x] Error handling with appropriate messages
- [x] Form state management with deep watch on objects prop
- [x] Type conversions for specialist/doctor IDs
- [x] Date format conversions (ISO ↔ YYYY-MM-DD)

---

## Debugging Tips

### 1. Check Form Population
Open DevTools Console and run:
```javascript
// Check if form data is set
console.log('Form objects:', $nuxt.$data.formObjects)
// Check if form fields have values
console.log('Doctor ID:', $nuxt.$data.doctorId)
```

### 2. Monitor API Calls
In Network tab:
- Filter: `encounter`
- Check GET request includes: `includes=patient,patient-person,specialist,subspecialist`
- Check PATCH request has correct ID in URL and payload in body

### 3. Trace Data Mapping
Search console for: `[EDIT MODE] Mapped encounter to form`
This shows:
- Original API response data
- Transformed form data
- All field mappings

### 4. Validate Payload
Before save, check:
```javascript
// In console, check the payload being sent
// Look for "💾 [EDIT MODE] Sending PATCH request" log
```

---

## Known Limitations & Workarounds

| Issue | Status | Workaround |
|-------|--------|-----------|
| File uploads not in payload | Current | Manual file upload after encounter save |
| Specialist tree fetch on edit | Current | Automatically triggered if subspecialistId present |
| SEP validation on edit | Current | Manual re-validation if SEP changed |

---

## Next Steps

1. **Execute TEST 1-5** with valid encounter data
2. **Monitor console logs** for any [ERROR] patterns
3. **Verify API response** includes all expected fields
4. **Test with different payment types** (jkn, jkmm, spm, pks)
5. **Test with different class codes** (ambulatory, inpatient, emergency)
6. **Load test** with slow network to verify spinners work

---

## Support

For issues or questions:
1. Check console logs first (search for ❌ patterns)
2. Review data mapping in `mapEncounterToForm()`
3. Verify API response structure matches expectations
4. Check RBAC permissions for update access