simrsx-fe/ENCOUNTER_EDIT_TEST.md

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:

{
  "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):

📥 [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):

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

Form Save (POST):

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

Error Scenarios:

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

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

---

Debugging Tips

1. Check Form Population

Open DevTools Console and run:

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

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