Host Query (orders) — لا يُرجِّع تحليلاً له نتيجة بالفعل، فقط اللي لسه مالوش نتيجة + التعامل مع إعادة الفحص (re-test)
Moon ERP · LIS · LabMachineController::orders() · تحليل قبل التنفيذ
📅 13 يونيو 2026 ⛔ خطة فقط — لم يُنفَّذ شيءيعني الـorders لازم تفلتر: ترجّع فقط التحاليل اللي لسه مستنية نتيجة على العينة دي + المربوطة بالجهاز ده. أي تحليل اتعمل وله نتيجة → يتشال من الرد (عشان الجهاز ميعيدش تشغيله ويهدر ريجنت أو يدوس على نتيجة موجودة).
orders(barcode) دلوقتي (بعد إصلاح اليوم — صارت per-sample):
النتيجة في جدول lab_results (صف لكل تحليل لكل طلب)، فيه sample_id + investigation_id + lab_request_investigation_id + status + result_value.
| الحالة | المعنى | القرار في الاستعلام |
|---|---|---|
pending | مستنية نتيجة | يرجّعها ✅ (فاضية) |
| (مفيش صف نتيجة) | لسه ماتعملش result أصلاً | يرجّعها ✅ |
retracted / invalidated / entered_in_error | النتيجة اتسحبت/أُلغيت → محتاجة تتعمل تاني | يرجّعها ✅ (إعادة) |
entered / validated / approved / released | ليها نتيجة فعلاً | ميرجّعهاش ⛔ |
result_value فاضي أو الحالة ∈ {pending, retracted, invalidated, entered_in_error} أو مفيش صف نتيجة. ويستثني لو الحالة ∈ {entered, validated, approved, released} وفيها قيمة.في الـLIS، إعادة الفحص بتعمل باركود/عينة جديدة (الكانبان: «Re-test → new barcode → back to collection»، والنتيجة القديمة تتحفظ كـprevious_result). فيه retest_of وretest_count على lab_sample_investigations.
lab_result جديد بحالة pending على العينة الجديدة؟ ولا بيعيد استخدام نفس الصف ويبوّظ retest_count من غير ما يرجّع الحالة pending؟
| الحالة | السؤال | المقترح (للنقاش) |
|---|---|---|
| تحت التشغيل (in_progress) | تحليل لسه بيتشغّل على الجهاز — يرجّع تاني لو الجهاز سأل؟ | يرجّع (الحالة لسه pending، مفيش value) — التشغيل المتوازي مش مشكلة لأن النتيجة لسه فاضية. |
| بانل (CBC وغيره) | الباركود فيه بانل بعض أعضاؤه اتعملوا — نرجّع الباقي؟ | نرجّع أعضاء البانل اللي لسه فاضية فقط. ملاحظة: توسيع البانل في الاستعلام لسه فجوة منفصلة — نتعامل معاها سوا. |
| عينة فيها كذا تحليل، بعضهم اتعمل | السيناريو الأساسي بتاعك | يرجّع الفاضي فقط (دي جوهر الخطة). |
| نتيجة متطابقة من الجهاز بس لسه pending مطابقة | الجهاز بعت نتيجة (machine_result) بس لسه ماتطبّقتش على lab_result | المصدر = lab_results (النتيجة المعتمدة). لو الـlab_result لسه pending → يرجّع. (نقطة نقاش: هل machine_result pending يكفي إنه «اتعمل»؟ الأنضف: لأ، نعتمد lab_result.) |
| نطاق الجهاز | تحليل اتعمل على جهاز تاني | الفلتر يشوف النتيجة بغضّ النظر عن الجهاز اللي عملها — لو ليه نتيجة، ميرجّعش لأي جهاز. |
تعديل واحد في LabMachineController::orders(): بعد ما نجيب تحاليل العينة المربوطة بالجهاز، نعمل LEFT JOIN على lab_results (بـ sample_id + investigation_id) ونستثني اللي ليها نتيجة معتمدة.
lis.query_returns_empty_only (bool, default true) — يشغّل/يطفّي السلوك ده. لو معمل عايز السلوك القديم (يرجّع الكل) يقدر يطفّيه.| الخطر | الأثر | التخفيف |
|---|---|---|
| نرجّع تحليل له نتيجة | الجهاز يعيد تشغيله → هدر ريجنت + دوس على نتيجة | هو ده اللي بنصلّحه — الفلتر يمنعه. |
| نفلتر أكتر من اللازم | تحليل محتاج يتعمل ميرجّعش → عمره ما يتعمل (خطر إكلينيكي) | تعريف الحالات بدقة (نرجّع pending + الملغي + مفيش صف). نختبر قبل الإطلاق على عينات حقيقية. |
| re-test بيعيد استخدام الصف | إعادة الفحص ميرجّعش | خطوة التحقّق في القسم ٣ — لو كده نضيف شرط retest pending. |
| بانل نصّه متعمل | الأعضاء الفاضية ميرجّعوش (لو البانل مش متوسّع) | نربطه بشغل توسيع البانل المنفصل. |
lab_result جديد pending على الباركود الجديد (يحسم منطق الـre-test).orders(): LEFT JOIN lab_results + استثناء المعمول، خلف إعداد lis.query_returns_empty_only.in_progress يرجّع ولا لأ؟ (ب) نعتمد lab_result كمصدر «اتعمل» (مش machine_result pending)؟ — وأنا أكمّل.