People → Clients vs. patients

Purpose

Clarify the domain model: in CS Logbook, clients are the humans (pet owners), patients are the animals. This page exists because some other veterinary practice management systems use the words differently, and the distinction is load-bearing for DEA recordkeeping.

Regulatory basis: DEA rules require dispensing and administration records to identify the recipient. CS Logbook treats the patient (the animal) as the formal recipient, with the client (the owner) as an attribute of the patient.

When to use it

• Onboarding a new staff member — set expectations for terminology
• Migrating from another PMS — make sure data lands in the right buckets
• Training a front-desk receptionist — they'll be creating client + patient records all day
• DEA audit prep — auditors will ask "who received this dose?" — your answer is the patient (animal), not the client (owner)

The model

┌──────────────────────────────┐
│ CLIENT (pet owner)           │
│  - first_name, last_name     │
│  - email, phone              │
│  - address                   │
│  - is_active                 │
└─────┬────────────────────────┘
      │ 1 client → many patients
      ↓
┌──────────────────────────────┐
│ PATIENT (animal)             │
│  - name (animal's name)      │
│  - species, breed            │
│  - weight_lbs                │
│  - microchip                 │
│  - allergies                 │
│  - medical_alerts            │
│  - is_active                 │
└─────┬────────────────────────┘
      │ 0 or 1 patient_id on transaction
      ↓
┌──────────────────────────────┐
│ TRANSACTION                  │
│  - administered / dispensed  │
│  - quantity                  │
│  - prescriber, performer     │
└──────────────────────────────┘

A client owns 0+ patients. A patient belongs to exactly one client (you can transfer a patient to a different client later — useful when an animal is rehomed).

A transaction of type administered or dispensed references a patient_id. Through the FK, you also know the client. So when DEA asks "who received this dose?", the chain is:

Transaction → Patient (Bella, Golden Retriever, 8 years) → Client (Jane Smith)

Why "client" and not "owner"?

Convention from veterinary practice software. The "owner" is a possessive role; "client" is the relationship the clinic has with that person. CS Logbook follows the established veterinary-software convention.

The database column on patients is client_id, not owner_id, for the same reason.

Why "patient" and not "pet"?

Same reason. In a clinical context (which DEA recordkeeping is), the animal is a patient — they receive treatment, have a medical record, and may be dispensed controlled substances. "Pet" is the lay term; "patient" is the clinical term.

How they interact with transactions

administered transaction

Dr. Smith administered 0.3mL of Ketamine to Bella

Captures:

• patient_id = Bella (the animal)
• prescriber_user_id = Dr. Smith (a prescribing vet)
• performed_by = whoever filed the transaction (usually the same as prescriber, but can be a tech if working under the prescriber)

No client_id is recorded directly on the transaction — that's looked up through the patient's client_id foreign key.

dispensed transaction

Dr. Smith dispensed 30 tablets of Phenobarbital for Diesel; Jane Smith picked up

Captures the same fields. The fact that "Jane Smith picked up" is implicit in the patient's owner — the client field on Diesel's record.

If you need to record that a different person picked up the dispensed medication (e.g., Jane sent her partner), use the Notes field on the transaction.

waste, disposal, adjustment, transfer, received

These don't reference a patient — they're inventory operations, not clinical events.

Soft-delete and history

Both clients and patients support soft-delete: marking the record as deleted hides it from active lists but preserves transaction history. This is required for DEA recordkeeping — you cannot purge a patient who has historical controlled-substance transactions.

When you soft-delete a patient:

• The patient disappears from active patient lists
• Existing transactions referencing the patient remain queryable
• The patient's deleted_at timestamp is set
• The transaction can still be resolved to "Bella (deleted)" in audit reports

When you soft-delete a client:

• The client disappears from active client lists
• The client's patients remain (you can transfer them to a different client first if you want)
• Existing transactions traced through the patients remain queryable

You can restore a soft-deleted record (clients or patients) — useful when a client returns after a long absence.

You cannot hard-delete a client or patient with associated transactions. The system blocks the action; the only way to truly remove the data is to first delete every related transaction (which itself requires going through corrections), and that path exists primarily for GDPR / privacy requests, not for normal use.

Common mistakes (carrying terminology from other PMS)

• Treating "patient" as the owner. Some legacy systems use "patient" for the human bringing the animal. In CS Logbook, "patient" is always the animal.
• Creating a separate client per visit. You don't. One client (the owner) owns one or more patients across all visits over time.
• Forgetting to link a patient to a client at creation. Patients are required to have a client (you can't save a patient without selecting one). The form supports quick-adding a client inline if you don't yet have one.

Related

• Clients — full client form and lifecycle
• Patients — full patient form and lifecycle
• Inventory → Transactions — how administered / dispensed reference patients
• Glossary § Client and Glossary § Patient