المنهج ← معمل نفيس التطبيقي — Sandbox حي
١١

معمل نفيس التطبيقي — Sandbox حي

NPHIES Sandbox Lab
١٦ ساعة تعليمية
٥ مختبرات
أمثلة كود حية وقابلة للتشغيل
هدف المعمل

في الوحدة الخامسة تعلّمت مفهوم كل خدمة من خدمات نفيس. هذا المعمل يأخذك خطوة أبعد: بناء دورة كاملة من طلبات FHIR فعلية القابلة للتشغيل في بيئة اختبار (Sandbox)، من التحقق من الأهلية وحتى استلام كشف الدفع — لمريض واحد افتراضي، خطوة بخطوة.

المختبر ١ — طلب التحقق من الأهلية

الخطوة الأولى دائماً: التأكد من أن المريض مغطى قبل تقديم أي خدمة.

// CoverageEligibilityRequest — التحقق من تغطية المريض { "resourceType": "CoverageEligibilityRequest", "status": "active", "purpose": ["validation", "benefits"], "patient": { "reference": "Patient/NPHIES-1012345678" }, "created": "2026-07-03", "insurer": { "reference": "Organization/TAWUNIYA" }, "provider": { "reference": "Organization/RIYADH-CENTRAL-001" }, "insurance": [{ "coverage": { "reference": "Coverage/POLICY-88213" } }] }
الاستجابة المتوقعة

مورد CoverageEligibilityResponse بحالة outcome: "complete" يحتوي على تفاصيل التغطية النشطة، نسبة تحمّل المريض (Copay)، والحد الأقصى المتبقي للبوليصة إن وُجد.

المختبر ٢ — طلب التفويض المسبق

بعد تأكيد الأهلية، ولأن قسطرة القلب من الإجراءات التي تتطلب موافقة مسبقة، نُرسل طلب تفويض قبل الجراحة.

// Claim (use: preauthorization) — طلب تفويض مسبق { "resourceType": "Claim", "status": "active", "type": { "coding": [{ "code": "institutional" }] }, "use": "preauthorization", "patient": { "reference": "Patient/NPHIES-1012345678" }, "provider": { "reference": "Organization/RIYADH-CENTRAL-001" }, "insurer": { "reference": "Organization/TAWUNIYA" }, "diagnosis": [{ "sequence": 1, "diagnosisCodeableConcept": { "coding": [{ "system": "ICD-10-AM", "code": "I21.0", "display": "STEMI anterior" }] } }], "item": [{ "sequence": 1, "productOrService": { "coding": [{ "system": "CPT", "code": "92928", "display": "PCI w/ stent" }] }, "net": { "value": 45000, "currency": "SAR" } }] }
المختبر ٣ — تحويل التفويض إلى مطالبة فعلية

بعد إجراء العملية فعلياً، تُحوَّل نفس البيانات إلى مطالبة (use: "claim") مع إضافة سطر خدمة ثانٍ (تحاليل ما بعد العملية) — وهذا هو المثال الكامل الذي رأيته في الوحدة الخامسة.

  • الفرق الوحيد بين طلب التفويض والمطالبة الفعلية: حقل use يتغيّر من "preauthorization" إلى "claim"، وتُضاف الفترة الفعلية للخدمة
  • مرجع التفويض: يجب تضمين رقم التفويض المُستلم في حقل insurance.preAuthRef لربط المطالبة بالموافقة السابقة
المختبر ٤ — قراءة استجابة كشف الدفع
// PaymentReconciliation — مقتطف من كشف الدفع { "resourceType": "PaymentReconciliation", "status": "active", "outcome": "partial", "detail": [{ "type": { "coding": [{ "code": "payment" }] }, "request": { "reference": "Claim/CLAIM-2026-00451" }, "amount": { "value": 41000, "currency": "SAR" } }], "formCode": { "coding": [{ "code": "CO-97", "display": "Bundled service — stress test included in PCI" }] } }
تحليل هذا المثال

المبلغ المطالَب به كان ٤٦,٥٠٠ ريال، والمدفوع فعلياً ٤١,٠٠٠ ريال. الفرق ١,٥٠٠ ريال يطابق تماماً قيمة اختبار الإجهاد القلبي (93016) — لأن هذا الاختبار اعتُبر مضمّناً ضمن إجراء القسطرة (92928) وفق قواعد CCI. هذا مثال حي على كيف تنعكس معرفتك بـCCI من الوحدة الثالثة مباشرة على تفسير كشف الدفع.

المختبر ٥ — مشروع مصغّر: دورة كاملة من الصفر
  • المهمة: يُعطى الطالب سيناريو سريري جديد (مريضة ٤٢ عاماً، استئصال مرارة بالمنظار) ويُطلب منه بناء أربعة موارد FHIR متتالية بنفسه: طلب أهلية، طلب تفويض، مطالبة، واستجابة كشف دفع افتراضية
  • معايير التقييم: صحة بنية JSON، صحة أكواد ICD وCPT المُستخدمة، والاتساق المنطقي بين المراحل الأربع (نفس رقم المريض ونفس مرجع التفويض عبر كل الموارد)
قائمة تحقق الوحدة
أستطيع قراءة وتفسير بنية أي مورد FHIR أساسي في نفيس
أفهم كيف يتحول طلب التفويض إلى مطالبة فعلية بنفس البيانات تقريباً
أستطيع تفسير الفرق بين المبلغ المطالَب والمدفوع بالرجوع لقواعد CCI
أنجزت دورة FHIR كاملة بنفسي من الأهلية حتى كشف الدفع