ADR-005: Doctor Verification in Admin Service

Status

Accepted. Doctor-profile storage references are superseded by ADR-013; the new doctor service owns professional profiles.

Context

Doctors must be verified before they can create prescriptions. We needed to decide where to place verification logic:

• Identity Service: Since it's about doctor profiles
• Admin Service: Since admins perform verification
• Separate Verification Service: If verification becomes complex

Decision

We will place doctor verification in the Admin Service because it's an admin workflow.

Rationale

Why Admin Service?

Aspect	Admin Service	Identity Service
Who performs it	Admins	Doctors (upload only)
Workflow	Review queue, approve/reject	Profile storage
Audit trail	Admin actions tracked	Profile changes
Business rule	Only verified doctors can prescribe	Stores verification status

Verification Flow

1. Doctor uploads documents → Identity Service (stores on DoctorProfile)
2. Admin reviews queue → Admin Service (verification queue)
3. Admin approves/rejects → Admin Service publishes event
4. Identity Service updates → DoctorProfile.status changes based on event

Verification Entity

type DoctorVerification struct {
    ID              string
    DoctorProfileID string
    UserID          string
    DoctorName      string
    LicenseNumber   string
    Specialization  string
    Documents       []string
    Status          string  // pending, verified, rejected
    ReviewedBy      *string // admin user ID
    ReviewedAt      *time.Time
    RejectionReason *string
}

Endpoints

POST /api/v1/admin/verifications              // Submit verification
GET  /api/v1/admin/verifications/pending      // Pending queue
GET  /api/v1/admin/verifications/{id}         // Get details
POST /api/v1/admin/verifications/{id}/approve // Approve
POST /api/v1/admin/verifications/{id}/reject  // Reject

Consequences

Positive

• Clear separation: Identity stores, Admin reviews
• Audit trail of admin actions
• Easy to add verification rules later

Negative

• Cross-service dependency (Admin → Identity via events)

Related Decisions

• ADR-004: Doctor as Role
• ADR-003: Event-Driven Architecture