Add dental module phase 4 and phase 5 documentation, including treatment estimates, clinical operations, and preset content

- Introduced phase 4 documentation detailing treatment estimates, data models, state machines, API endpoints, and new dashboard metrics.
- Added phase 5 documentation covering consumables, lab operations, periodontal charts, sterilization cycles, clinical images, and a checklist for professional review.
- Created a preset content document outlining default dental service packages and protocols for clinics.
This commit is contained in:
hamed
2026-08-20 16:21:08 +03:30
parent 601d211d6f
commit 2f030edef1
12 changed files with 1794 additions and 3 deletions
@@ -0,0 +1,232 @@
# فاز ۵ — پریو، لابراتوار، استریلیزاسیون، مواد مصرفی و تصاویر
> پیش‌نیاز: فاز ۱ تا ۴.
> خروجی قابل تست: شاخص‌های هزینه و کیفیت، و ثبت بالینی کامل‌تر.
این فاز چهار موضوع مستقل دارد.
هرکدام جداگانه قابل اجراست و ترتیبشان اجباری نیست.
---
## ۱. مواد مصرفی — عمدتاً موجود است
`Inventory` و `SessionConsumable` از قبل هستند.
| موجودیت | مسیر |
|---|---|
| `InventoryItem` | `src/Inventory/Entity/InventoryItem.php` |
| `InventoryPackage` و `InventoryPackageItem` | همان پوشه |
| `SessionConsumable` | `src/Patient/Entity/SessionConsumable.php` |
| `ServiceItemConsumable` | `src/ClinicService/Entity/ServiceItemConsumable.php` |
قیمت در `SessionConsumable` اسنپ‌شات می‌شود، مثل `SessionService`.
`ServiceItem` هم می‌تواند به یک بستهٔ مصرفی وصل شود.
**پس کار این فاز فقط این است:**
- بستهٔ پیش‌فرض دندانپزشکی به `DentalPreset` اضافه شود: کامپوزیت، ماده بی‌حسی، فایل روتاری، سوزن، ماسک، دستکش.
- شاخص `consumable_cost_ratio` به `DentalMetricProvider` اضافه شود.
هیچ موجودیت تازه‌ای لازم نیست.
اگر کسی جدول مصرف مواد دندانپزشکی جدا ساخت، منبع حقیقت دوم ساخته است.
### تسک‌ها
| کد | تسک | معیار پذیرش |
|---|---|---|
| DM5-01 | بستهٔ مصرفی دندانپزشکی در قالب پیش‌فرض | نصب دوم چیزی تکرار نمی‌کند |
| DM5-02 | شاخص `consumable_cost_ratio` | مخرج صفر، `null` می‌دهد |
---
## ۲. لابراتوار — تازه است
### مدل داده
`Lab` — جدول `dental_labs`
| ستون | نوع |
|---|---|
| `id`, `uuid` | |
| `entity_type`, `entity_id` | جفت محیط |
| `title` | string 150 |
| `phone` | string 20, nullable |
| `active` | bool |
| `created_at`, `updated_at` | int |
`LabOrder` — جدول `dental_lab_orders`
| ستون | نوع | توضیح |
|---|---|---|
| `id`, `uuid` | | |
| `entity_type`, `entity_id` | | |
| `lab_id` | int | |
| `patient_record_id` | int | |
| `estimate_item_id` | int, nullable | ردیف برآوردی که این سفارش برایش است |
| `tooth_numbers` | json | دندان‌های درگیر |
| `description` | string 500 | |
| `status` | string 20 | |
| `cost_rials` | int | |
| `sent_at`, `due_at`, `received_at` | int, nullable | |
| `created_at`, `updated_at` | int | |
### ماشین حالت
```
draft ─▶ sent ─▶ in_lab ─▶ ready ─▶ received ─▶ delivered
└────▶ returned_for_fix ─▶ in_lab
```
`due_at` مبنای هشدار تأخیر است.
یک job روزانه سفارش‌های گذشته از موعد و در حالت غیرنهایی را برای داشبورد علامت می‌زند.
اتصال به `estimate_item_id` اختیاری است ولی توصیه‌شده.
بدون آن، بهای تمام‌شدهٔ آن ردیف قابل محاسبه نیست و شاخص حاشیهٔ سود بی‌معنا می‌شود.
### API
```
GET /api/v1/dental/labs
POST /api/v1/dental/lab
PATCH /api/v1/dental/lab/{uuid}
GET /api/v1/dental/lab-orders?status=&overdue=
POST /api/v1/dental/lab-order
PATCH /api/v1/dental/lab-order/{uuid}
POST /api/v1/dental/lab-order/{uuid}/transition
```
دسترسی: هر چهار نقش می‌بینند و ثبت می‌کنند. لابراتوار کار مشترک درمانگاه است.
### شاخص‌ها
| کلید | تعریف |
|---|---|
| `lab_cost_ratio` | جمع هزینهٔ لابراتوار تقسیم بر تولید |
| `lab_overdue_count` | تعداد سفارش گذشته از موعد |
| `lab_turnaround_days` | میانگین فاصلهٔ ارسال تا دریافت |
### تسک‌ها
| کد | تسک | معیار پذیرش |
|---|---|---|
| DM5-03 | موجودیت `Lab` و مخزن | یکتایی نام در محیط |
| DM5-04 | موجودیت `LabOrder` و ماشین حالت | گذار غیرمجاز `AppException` |
| DM5-05 | اندپوینت‌های لابراتوار | همهٔ حالت‌های دسترسی |
| DM5-06 | job هشدار تأخیر | سفارش نهایی‌شده علامت نمی‌خورد |
| DM5-07 | سه شاخص لابراتوار | مخرج صفر |
| DM5-08 | صفحهٔ لابراتوار در پنل | فیلتر وضعیت و تأخیر |
---
## ۳. چارت پریودنتال — تازه است
### مدل داده
`PeriodontalExam` — جدول `dental_periodontal_exams`
| ستون | نوع |
|---|---|
| `id`, `uuid` | |
| `chart_id` | int |
| `examined_at` | int |
| `examined_by_user_id` | int, nullable |
| `note` | string 500, nullable |
`PeriodontalMeasurement` — جدول `dental_periodontal_measurements`
| ستون | نوع | توضیح |
|---|---|---|
| `exam_id` | int | `ON DELETE CASCADE` |
| `tooth_number` | smallint | |
| `site` | smallint | ۱ تا ۶ |
| `pocket_depth` | smallint | میلی‌متر |
| `recession` | smallint | |
| `bleeding_on_probing` | bool | |
| `mobility` | smallint | ۰ تا ۳ |
**چرا معاینه جدا از اندازه‌گیری:**
پریو دنباله‌ای است. مقایسهٔ معاینهٔ امروز با شش ماه پیش تمام ارزش این چارت است.
اگر اندازه‌ها روی خود دندان بازنویسی شوند، آن مقایسه از بین می‌رود.
این دقیقاً قرینهٔ `ToothStatus` است که عمداً فقط وضعیت جاری را نگه می‌دارد.
ثبت کامل یک معاینه ۱۹۲ عدد است.
پس فرم باید صفحه‌کلیدمحور باشد و با `Tab` پیش برود، وگرنه کسی استفاده‌اش نمی‌کند.
### تسک‌ها
| کد | تسک | معیار پذیرش |
|---|---|---|
| DM5-09 | دو موجودیت پریو | یکتایی دندان و سایت در معاینه |
| DM5-10 | اندپوینت ثبت و خواندن معاینه | ثبت دسته‌ای در یک درخواست |
| DM5-11 | فرم پریو صفحه‌کلیدمحور | حرکت با `Tab` بین سایت‌ها |
| DM5-12 | نمای مقایسهٔ دو معاینه | اختلاف با رنگ نشان داده می‌شود |
---
## ۴. استریلیزاسیون — تازه است
### مدل داده
`SterilizationCycle` — جدول `dental_sterilization_cycles`
| ستون | نوع |
|---|---|
| `id`, `uuid` | |
| `entity_type`, `entity_id` | |
| `device_resource_id` | int, nullable |
| `program` | string 50 |
| `started_at`, `finished_at` | int |
| `chemical_indicator_ok` | bool |
| `biological_test_at` | int, nullable |
| `result` | string 20 |
| `operator_user_id` | int, nullable |
| `note` | string 500, nullable |
اتوکلاو به‌عنوان `ClinicResource` تعریف می‌شود، نه یک جدول دستگاه تازه.
دلیل: نوع منبع از قبل قابل تعریف است و تقویم و دسترسی‌اش هم همان‌جاست.
در این فاز، سیکل استریل به گردش کار درمان گره نمی‌خورد.
فقط ثبت و گزارش است.
گره‌زدن ست ابزار به جلسهٔ درمان کار بزرگی است و باید جدا تصمیم‌گیری شود.
### تسک‌ها
| کد | تسک | معیار پذیرش |
|---|---|---|
| DM5-13 | موجودیت سیکل استریل | ثبت بدون دستگاه هم ممکن است |
| DM5-14 | اندپوینت ثبت و فهرست | فیلتر بازه و نتیجه |
| DM5-15 | یادآور تست بیولوژیک هفتگی | نبود تست در هفته، هشدار داشبورد |
| DM5-16 | صفحهٔ استریلیزاسیون در پنل | گزارش قابل چاپ |
---
## ۵. تصاویر بالینی — روی سیستم موجود
`PatientAttachment` از قبل هست و به پرونده وصل است.
کار این بخش فقط افزودن دو ستون اختیاری است:
```
tooth_numbers json nullable
image_type string 20 nullable periapical | bitewing | opg | cbct | photo
```
**چرا ستون روی همان جدول و نه جدول دندانی جدا:**
برخلاف ویژگی خدمت که تنظیمات مشترک همهٔ حوزه‌هاست، ضمیمه سند خود پرونده است و هر حوزه‌ای می‌تواند تصویر داشته باشد.
جدول جدا یعنی یک ضمیمه در دو جا و دو مسیر آپلود.
### تسک‌ها
| کد | تسک | معیار پذیرش |
|---|---|---|
| DM5-17 | دو ستون روی `PatientAttachment` | ضمیمهٔ بدون دندان مثل قبل کار می‌کند |
| DM5-18 | فیلتر ضمیمه بر اساس دندان در تب چارت | کلیک روی دندان، تصاویرش را نشان می‌دهد |
---
## ۶. رضایت آگاهانه — خارج از این سند
فرم رضایت آگاهانه در همهٔ حوزه‌ها لازم است، نه فقط دندانپزشکی.
ساختنش داخل ماژول دندانپزشکی یعنی حوزهٔ بعدی باید دوباره بسازدش.
پیشنهاد: سند جدا، در سطح پرونده بیمار.