تحليل متكامل للداشبورد الحالية (فرونت + باكند بنداءات حية)، مقارنة بمؤشرات معامل التحاليل العالمية (CAP / ISO 15189 / Westgard)، وثلاثة اتجاهات تصميم كاملة — وخطة تنفيذ مرحلية. وثيقة خطة فقط: لا يُنفَّذ أي شيء قبل اعتمادك.
الداشبورد الحالية (`/lab`) هي صفحة تجميع تقارير مش لوحة قيادة: 9 كروت KPI + 4 رسوم + جدول TAT، كلها بنفس الوزن البصري، مجمّدة على آخر 30 يوم، وبتتجاهل فلاتر الفرع والقسم الموجودة أصلاً في النظام.
الكارت بيقرأ total_payments (عدد عمليات الدفع) ويعرضه تحت عنوان «إيراد» — والكارت اللي جنبه «مدفوعات معلّقة» بيعرض في الحقيقة المُحصَّل اليوم مش المعلّق. كارتان ماليان مقلوبان.
البادج بيجيب requests.meta.total (كل الطلبات تاريخياً) مش عدد النتائج المعلّقة — رقم مضلل بيكبر للأبد.
أي endpoint يفشل بيتحول لـ 0 بدون أي تنبيه — «صفر إيراد» و«فشل التحميل» شكلهم واحد. المدير ممكن ياخد قرار على رقم ناقص.
كروت «آخر 30 يوم» جنب كروت «اليوم» على نفس الشاشة بدون أي توضيح — الأرقام بتبان متناقضة.
الـ agent الثاني عمل جرداً بنداءات حية على dev: أكثر من 20 endpoint جاهزة تكفي لبناء داشبورد عالمية — معظمها غير مستغل في الداشبورد الحالية إطلاقاً.
| المصدر الجاهز | المؤشرات المستخرجة | عيّنة حية (dev اليوم) |
|---|---|---|
| reports/turnaround-time | TAT بالدقيقة لكل تحليل وقسم + expected_tat_hours للمقارنة بالهدف | Hemoglobin متوسط 13.5 دقيقة (هدفه ساعة) |
| reports/abnormals | نسبة غير الطبيعي + عدد الحرج + توزيع الأعلام + أعلى 20 تحليلاً | 74 صادر، 52 غير طبيعي، 8 حرجة |
| lis/critical-alerts | طابور النتائج الحرجة: المريض، الفلاغ، الإقرار، الإبلاغ، التصعيد | 8+ غير مُقرّة (acknowledged_at: null) |
| worklist/cards | حالة كل طلب بالمراحل (معلق/مُدخل/مُعتمد/صادر) + الإجراء التالي — نمط الـ aggregation المثالي | LR-2026-00332: صادر 21/21 |
| reports/workload | الأحمال لكل قسم وفني (إجمالي/منجز/معلق) | هيماتولوجي 91 (51 منجز / 34 معلق) |
| reports/revenue + test-volume | الإيراد اليومي/التحصيل/المتبقي + الحجم بالمصدر والأولوية، وكلها تقبل branch_id | 11 فاتورة، 2,651 إجمالي، 303 متبقي |
| cashier-sessions + reconciliation | الورديات المفتوحة، المتوقع نقداً، العجز/الزيادة، Z-report | وردية مفتوحة فرع 8، فيزا 402.5 |
| reports/insurance-claims | مطالبات التأمين: المفوتر/المحصّل/المعلّق | 15 مطالبة، 893.55 معلّقة بالكامل |
| reports/qc-summary + profitability + external-labs-financial + doctor-commissions | جودة QC، ربحية الأقسام والتحاليل، صافي حسابات معامل B2B، عمولات الأطباء | جاهزة بنيوياً (QC فاضي في dev) |
أعمدة التوقيت موجودة فعلاً على lab_samples / lab_results / lab_requests وتسمح بحساب كل وصلة في السلسلة: طلب←سحب، سحب←استلام، استلام←قبول، قبول←معالجة، معالجة، إدخال←اعتماد، اعتماد←إصدار، وإجمالي الرحلة — بالإضافة لزمن إقرار النتائج الحرجة وTAT الإحالات الخارجية. كل ده محتاج aggregation جديدة بس، مش أعمدة جديدة.
| المؤشر الغايب | البيانات | الجهد |
|---|---|---|
| نسبة الالتزام بالـ TAT + P50/P90/P95 لكل أولوية | موجودة (timestamps + expected_tat_hours) | M |
| نسبة الرفض + باريتو الأسباب | موجودة (rejected_at + rejection_reasons) | S |
| أعمار تراكم الاعتماد (validation backlog aging) | موجودة (status + entered_at vs now) | S |
| متوسط زمن إقرار الحرج + % غير المُقرّ | موجودة (critical_alerts) | S |
| funnel اليوم الحي (طلبات مفتوحة بالمرحلة والأولوية) | موجودة | S |
| فلتر فرع على QC / التكاليف / العمولات / التأمين | عمود branch_id متاح | S |
| نسبة إعادة التحليل (retest rate) | audit log | M |
| تتبع توقف الأجهزة (analyzer uptime) | مفيش جدول — محتاج schema | L — مؤجل |
مرجعية CAP / CLIA / ISO 15189 وقواعد Westgard وممارسات SENAITE / Orchard / Sunquest. المبدأ الحاكم: كل رقم لازم يجاوب «أعمل إيه دلوقتي؟» — وإلا فهو رقم استعراضي. و«47 معلّق» ضجيج؛ «12 معلّق أكتر من ساعتين، منهم 3 STAT» إنذار.
| الشخصية | المؤشر | الهدف العالمي | أفضل تمثيل | التحديث |
|---|---|---|---|---|
| مدير المعمل العمليات اليومية |
التزام TAT لكل أولوية | STAT <60 دقيقة ≥90% · روتيني نفس اليوم ≥90% | bullet gauge + سباركلاين | 5–15 د |
| المعلّق بالمرحلة + الأعمار | صفر STAT متأخر >30 د في الاعتماد | funnel + جدول حراري | 2–5 د | |
| نسبة رفض العينات + الأسباب | <2% (ممتاز <1%) | رقم + باريتو | ساعة | |
| النتائج الحرجة + زمن الإبلاغ | ≥95% خلال 30–60 د، إقرار 100% | عدّاد إنذار + جدول | حي ≤1 د | |
| مسؤول الجودة | QC لكل تحليل×جهاز×مستوى | >95–98% pass | مصفوفة حرارية + Levey-Jennings | لكل run |
| مخالفات Westgard + التقارير المصحَّحة | نادرة ومحلولة · تصحيح <0.5% | سجل + ترند | حي / يومي | |
| المالك المالية |
إيراد اليوم/الشهر vs الهدف + توقع نهاية الشهر | نسبة للهدف الداخلي | رقم كبير + bullet + خط تراكمي | ساعة/يومي |
| مزيج الدافعين (كاش/تأمين/B2B) + أعمار المديونية | دلو >90 يوم = إنذار | stacked bars بالزمن | يومي | |
| أعلى التحاليل إيراداً وحجماً + الخصومات اليدوية | ~20% من التحاليل = 80% من الإيراد | باريتو + drill بالمستخدم | يومي | |
| الاستقبال | التسجيلات بالساعة + السحب المعلّق | تسجيل←سحب <10–15 د | منحنى ساعي + جدول أعمار | 1–2 د |
| أطول مريض منتظر | >20–30 د = تدخل فوري | كارت بطل واحد | حي |
شريط فلاتر عالمي ثابت (الفترة: اليوم/أمس/الأسبوع/الشهر/مخصص · الفرع · القسم · الأولوية) بيسري على كل المناطق + chips للفلاتر النشطة + «آخر تحديث» وإيقاف مؤقت للتحديث التلقائي.
المرحلة الكهرمانية المتوهجة = «هنا الاختناق» — نقرة واحدة توصلك لشاشة السحب مباشرة. الداشبورد بتتحول من تقرير لأداة فرز.
كلها مبنية على هوية التطبيق الفعلية: شل المعمل داكن كحلي #0c1222 بأكسنت سماوي #0ea5e9، وذهب الـ ERP #f5a623، وخطا Cairo / JetBrains Mono، وChart.js 4 (الـ funnel والـ heatmap هيتبنوا CSS/SVG — وفيه سابقة: رسم Levey-Jennings مرسوم يدوياً في شاشة QC).
ليه دي الصح للمعمل ده: مستخدمو /lab اليوميون هم استقبال وساحبين وفنيين ومعتمِدين — سؤالهم «فين الشغل وإيه الواقف؟» مش «هامش الربح كام». والشل داكن أصلاً — ده الاتجاه الوحيد اللي بيخلي تجربة /lab منتجاً واحداً متماسكاً بدل «حساء كروت فاتح في إطار داكن». وبيصلّح الفشل الجوهري: فرض أولوية تشغيلية بدل الوزن المتساوي.
أسرع تنفيذاً وأكثر أماناً (أغلبه PrimeNG وtokens موجودة، والوحيد الصحيح في الوضعين فاتح/داكن بدون شغل إضافي) — لكنه «الاختيار الآمن مش الأفضل» لجمهور تشغيلي. هنسرّب أنماطه الهادئة للبلوكات الثانوية في التوصية الهجينة.
جميل للمالك لكن بيجاوب سؤالاً مش بيتسأل يومياً جوه المعمل — والمالية عندها فعلاً /lab/cost-dashboard و/lab/financial-reports. هناخد منه «شريط الأرقام المالية بالدلتا» كصف Z5 جوه التوصية.
بدل 12 نداء: GET /lis/dashboard واحد على نمط worklist/cards المجرَّب — يعيد استخدام دوال LISReportService الموجودة + 3 تجميعات جديدة هزيلة (لقطة اليوم الحية، إقرار الحرج، نسب الـ TAT). تقارير التفصيل الـ 12 تفضل كما هي للـ drill-down.
GET /lis/dashboard?from=&to=&branch_id=§ion_id= { "headline": { requests_total, results_released, results_pending, tat_avg_minutes, tat_p50, tat_p90, tat_sla_breach_pct, // جديد M abnormal_rate, critical_count, critical_unacked, critical_avg_ack_minutes, // جديد S samples_rejected, rejection_rate, // جديد S revenue_total, revenue_collected, revenue_outstanding, qc_pass_rate, costed_coverage_pct }, "today": { // لقطة حية مستقلة عن from/to — جديد S open_requests, reception_pending, in_processing, awaiting_validation, ready_to_release, cashier_open_sessions, cash_collected, payments_count }, "trends": { daily_volume[], daily_revenue[], tat_funnel[] }, "breakdowns": { by_section[], by_source[], by_priority[], top_abnormal[], by_technician[] }, "alerts": { critical_unacked[], validation_backlog[], costing_uncosted, insurance_outstanding } }
كل مرحلة تتسلّم بنفس نظامنا: agents متوازيون بملكية ملفات صارمة ← بوابات اختبار ← نشر BE+FE معاً ← قياس أداء ← مراجعة Codex ← push.
| اليوم | بعد المرحلة 1 | بعد المرحلة 3 | |
|---|---|---|---|
| الاكتمال | 3/10 | 7/10 | 9/10 |
| دقة تمثيل الأداء | 2.5/10 | 8/10 | 9/10 |
| نداءات HTTP | ~12 | 1–2 | 1–2 |
| التصميم | 5/10 | 8/10 | 9/10 |
التوصية: Mission Control الهجين (داكن، funnel بطل). البديل الأسرع: Clinical Clarity فاتح في سبرنت واحد. — اعتماد أحدهما يطلق المرحلة 1.
زي ما هي مقترحة (endpoint + funnel + إنذارات + إصلاحات) ولا تحب تضيف/تشيل؟
الفترة الافتراضية «اليوم» (تشغيلي — التوصية) ولا «آخر 30 يوم» (زي الحالي)؟ وهل المدير متعدد الفروع يفتح على «كل الفروع» مجمَّعة؟
التوصية: إنذارات 60ث · funnel 3د · مالية عند الفتح فقط — موافق؟ (قابل للإيقاف من الهيدر)