clinicpro/docs/new_feture/dental-module/phase-5-clinical-ops.md

فاز ۵ — پریو، لابراتوار، استریلیزاسیون، مواد مصرفی و تصاویر

پیش‌نیاز: فاز ۱ تا ۴. خروجی قابل تست: شاخص‌های هزینه و کیفیت، و ثبت بالینی کامل‌تر.

این فاز چهار موضوع مستقل دارد. هرکدام جداگانه قابل اجراست و ترتیبشان اجباری نیست.

---

۱. مواد مصرفی — عمدتاً موجود است

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	فیلتر ضمیمه بر اساس دندان در تب چارت	کلیک روی دندان، تصاویرش را نشان می‌دهد

---

۶. رضایت آگاهانه — خارج از این سند

فرم رضایت آگاهانه در همهٔ حوزه‌ها لازم است، نه فقط دندانپزشکی. ساختنش داخل ماژول دندانپزشکی یعنی حوزهٔ بعدی باید دوباره بسازدش. پیشنهاد: سند جدا، در سطح پرونده بیمار.