تقييم صفحات LIS Worklist و Validation

الخلاصة التنفيذية

الصفحتان مبنيتان بشكل قوي ومناسب لتشغيل معملي حقيقي: يوجد تقسيم واضح بين قائمة الطلبات يمين/يسار حسب اللغة، وجدول نتائج، bulk actions، autosave، حالات العينات، panels، وإظهار نتائج خاصة مثل file/culture/histopathology. لكن حجم المنطق داخل كل Component كبير جدًا، ويوجد تكرار واضح بين Worklist و Validation. هذا يجعل الأداء مقبولًا في الأيام الهادئة، لكنه معرض للبطء في الأيام المزدحمة أو عند فتح مدى زمني 7/30 يوم.

7/10 قابلية الاستخدام

6/10 الأداء الحالي

5/10 سهولة الصيانة

8/10 اكتمال الوظائف

رأيي في صفحة Worklist

صفحة Worklist مناسبة أكثر لفني المعمل: تركيزها على إدخال النتائج، رفض التحليل، الإرسال لمعمل خارجي، إعادة القراءة، وإظهار الحالات المقفولة. الواجهة عملية وكثيفة، وهذا مناسب للمعمل، لكنها تحتاج تقليل الحمل وقت فتح الصفحة والتنقل بين الطلبات.

جيد تحميل النتائج يتم بفلتر تاريخ وحالات محددة بدل تحميل كل النتائج.
جيد يوجد autosave كل 30 ثانية باستخدام bulk draft.
ملاحظة منطق grouping للـ panels والـ locked rows كبير داخل Component واحد.
ملاحظة لا يوجد virtual scroll للجدول، وكل الصفوف تتبني في DOM مرة واحدة.

رأيي في صفحة Validation

صفحة Validation أقوى وظيفيًا من Worklist لأنها تشمل validate/approve/release/print/unpublish/retract وبحث بالتحليل عبر الطلبات. لكنها لذلك أثقل، وفيها فرص أكبر لتحسين الأداء، خصوصًا في البحث العام والطباعة وتحميل الـ normal ranges والـ patient history.

جيد يوجد progressive bulk actions حسب حالة النتائج.
جيد يوجد lazy patient history بدل تحميل تاريخ كل المرضى تلقائيًا.
ملاحظة صفحة واحدة تحمل مسؤوليات كثيرة: مراجعة، إصدار، طباعة، تقارير، history، lifecycle.
خطر أداء بحث التحليل عبر كل الطلبات يعتمد على فلترة client-side داخل النتائج المحملة فقط.

أهم نقاط الأداء المكتشفة

النقطة	التأثير	التوصية
تحميل النتائج مع `per_page=500` ثم paging client-side عبر `fetchAllPages`	جيد للأيام الصغيرة، لكن في أيام الضغط أو مدى 30 يوم سيزيد حجم الذاكرة والـ DOM بسرعة.	إضافة server-side pagination أو infinite loading حسب الطلبات وليس حسب كل النتائج.
الـ DOM يعرض جدول كامل بدون virtual scroll	لو الطلب المختار فيه panel كبير أو اليوم فيه طلبات كثيرة، التفاعل والكتابة في inputs قد يبطؤوا.	استخدام virtual scroll أو عرض الطلب المختار فقط مع lazy rendering للـ history/actions.
حسابات `requestCards()` و `displayRows()` تعيد group/sort/filter كثيرًا	كل تغيير في signal مثل البحث أو اختيار طلب يعيد حسابات على كل `allRows`.	تحويل البيانات بعد التحميل إلى Maps جاهزة: requestId -> rows، requestId -> cards، requestId -> displayRows.
تكرار كبير بين `dept-worklist` و `validation-worklist`	أي تحسين أو bug fix لازم يتكرر مرتين، ومع الوقت يحصل اختلاف في السلوك.	استخراج shared service/hook لمنطق load/process/group/panel/locked rows.
autosave كل 30 ثانية	مفيد جدًا، لكنه ممكن يبعت requests حتى مع تغييرات قليلة أو أثناء bulk action.	استخدام debounce بعد آخر تعديل + pause أثناء bulk action + حفظ عند blur/leave.
تحميل بيانات مساعدة متعددة في Validation: referrals, sections, samples, pivots, investigations	عدة round-trips قبل ظهور الصفحة كاملة.	تجهيز endpoint واحد مخصص للصفحة يرجع worklist payload جاهز ومجمع.

تحسينات سريعة

إظهار skeleton حقيقي للـ request cards والجدول بدل spinner عام.
إضافة عداد واضح لعدد الطلبات وعدد النتائج المحملة.
حفظ آخر فلتر مستخدم لكل مستخدم: القسم، التاريخ، الحالة.
تعطيل autosave مؤقتًا أثناء bulk approve/release/retract.
إضافة زر "Reload selected request only" بدل إعادة تحميل اليوم كله.

تحسينات متوسطة

استخراج WorklistDataService مشترك بين الصفحتين.
استخراج PanelGroupingService للـ panels والـ sub-sections.
استبدال بحث التحليل في Validation بنداء API مخصص.
تخزين normal ranges في cache مركزي وليس داخل الصفحة فقط.
تقليل الأعمدة الافتراضية وإتاحة اختيار الأعمدة حسب المستخدم.

تحسينات كبيرة

عمل endpoint موحد: /lis/worklist-context.
إضافة virtual scroll للجدول والـ request cards.
تقسيم Validation إلى sub-components: header, cards, table, dialogs, print actions.
إضافة server-side aggregation لحساب progress/status summary.
إضافة monitoring لزمن تحميل الصفحة وعدد API calls.

الأولويات المقترحة للتنفيذ

أولوية 1

تقليل تحميل البيانات الأولي

أهم تعديل هو نقل التجميع الثقيل من Angular للـ backend. بدل أن الصفحة تنادي results ثم pivots ثم samples ثم sections ثم investigations، الأفضل endpoint واحد يرجع قائمة الطلبات، النتائج، panel ancestry، normal ranges المطلوبة، والـ locked rows.

أولوية 2

منع بطء الـ DOM في الجداول الكبيرة

الجداول الحالية plain table مع scroll، وهذا جيد بصريًا لكن ليس الأفضل لو عدد الصفوف كبير. استخدم virtual scrolling أو render للطلب المختار فقط مع collapse افتراضي للـ panels الكبيرة.

أولوية 3

تقليل التكرار بين الصفحتين

Worklist و Validation يكرران نفس أنواع البيانات ونفس منطق panel grouping وlocked rows وhistory. استخراج منطق مشترك سيحسن الأداء والصيانة معًا، ويقلل احتمالات اختلاف السلوك بين الصفحتين.

ملاحظات UX مهمة

Worklist الأفضل إبراز "غير قابل للإدخال" بسبب حالة العينة بطريقة أوضح من مجرد disabled row.
Validation أزرار approve/release/retract كثيرة؛ يفضل toolbar ثابت sticky أعلى الجدول.
الصفحتان البحث الحالي مفيد، لكن يحتاج debounce بسيط حتى لا يعيد حساب الكروت مع كل حرف فورًا.
الصفحتان إضافة اختصارات لوحة مفاتيح لإدخال النتائج وحفظ الصف التالي ستسرع العمل اليومي.

ملاحظات Backend/API

الـ API يحتاج endpoint مصمم خصيصًا لهذه الشاشات، لأنهما ليستا مجرد CRUD.
يفضل أن يرجع الـ backend request summary جاهز بدل حسابه في المتصفح.
يفضل دعم request_ids وinclude ثابت وموثق للـ pivots/results.
ينبغي مراقبة خطأ result_type غير المدعوم لأنه يكسر تحميل الصفحات بالكامل.

الخطة العملية المختصرة

المرحلة	التعديل	النتيجة المتوقعة
1	إصلاح enum result types للأنواع `file`, `culture`, `histopathology`	منع كسر تحميل النتائج بالكامل بسبب صف واحد.
2	إضافة endpoint موحد لبيانات Worklist/Validation	تقليل عدد طلبات الشبكة وتسريع أول ظهور للصفحة.
3	استخراج منطق grouping/cache في service مشترك	تقليل التكرار وتحسين الصيانة.
4	إضافة virtual scroll أو lazy render للجدول	تحسين سرعة الكتابة والتنقل في الأيام المزدحمة.
5	إضافة performance logging: load time, API count, rows count	معرفة التحسن بالأرقام وليس بالانطباع.

الحكم النهائي

الصفحتان ليستا سيئتين؛ بالعكس فيهما شغل وظيفي كبير ومناسب لطبيعة المعمل. المشكلة الأساسية أن كمية المنطق والبيانات داخل المتصفح أكبر من اللازم. أفضل تحسين ليس تغيير الشكل فقط، بل نقل جزء من التجميع للـ backend، وتقليل DOM، وفصل المنطق المشترك. بهذا الشكل ستصبح الصفحتان أسرع وأكثر ثباتًا وأسهل في التطوير.

الملفات التي تمت مراجعتها: validation-worklist component، dept-worklist component، HTML templates، SCSS، و LisResultService.

تقييم عميق لصفحات المعمل: Worklist و Validation