تكامل نظام الفوترة السعودي (SBS)

 

الخطة التنفيذية لتكامل نظام الفوترة السعودي (SBS)

1.0 المقدمة ونطاق المشروع

تمثل هذه الوثيقة خارطة طريق تقنية مفصلة، صُممت لتوجيه مدير المشروع التقني خلال عملية نشر وتكامل حل الفوترة السعودي (SBS) ضمن البنية التحتية للمنشأة الصحية. تركز الخطة بشكل أساسي على بناء نظام مرن وقابل للتطوير، مع تحقيق الربط الآمن والفعال مع المنصة الوطنية للتعاملات الصحية "نفيس".

يهدف مشروع تكامل نظام SBS إلى تحقيق مجموعة من الأهداف الجوهرية التي تمثل نقلة نوعية في إدارة المطالبات المالية والطبية. تتمثل هذه الأهداف فيما يلي:

• توحيد اللغة (Unified Language): الانتقال من استخدام رموز الخدمات الداخلية المتعددة وغير الموحدة إلى اعتماد رموز SBS القياسية، مما يخلق لغة مشتركة بين جميع أطراف المنظومة الصحية.
• تقليل رفض المطالبات (Reducing Rejections): أتمتة تطبيق قواعد الفوترة الصادرة عن مجلس الضمان الصحي، مما يقلل من الأخطاء الناتجة عن الاجتهادات اليدوية ويزيد من نسبة قبول المطالبات من المرة الأولى.
• قابلية التشغيل البيني (Interoperability): تسهيل عملية تبادل البيانات الصحية والمالية بشكل آمن ومنظم مع منصة "نفيس"، مما يعزز الكفاءة التشغيلية بين مقدمي الرعاية وشركات التأمين.
• الشفافية والامتثال (Transparency & Compliance): ضمان التوافق الكامل مع لوائح مجلس الضمان الصحي (CHI)، وتوفير شفافية عالية في تفاصيل الفواتير للمرضى والجهات الرقابية.

إن الخطوة التأسيسية لأي عملية تكامل ناجحة تبدأ بالتحليل الدقيق للبنية الحالية وإعداد البنية التحتية للبيانات، وهو ما تتناوله المرحلة الأولى من هذه الخطة.

2.0 المرحلة الأولى: التحليل وإعداد البنية التحتية للبيانات

2.1. تعتبر هذه المرحلة استراتيجية وحاسمة، حيث إن فهم النظام الحالي وتصميم بنية بيانات قوية هما حجر الزاوية لضمان أن يكون الحل النهائي قابلاً للتطوير (Scalable) وجاهزاً للتشغيل (Plug and Play). يضمن الإعداد الصحيح في هذه المرحلة أن النظام يمكنه التعامل مع آلاف الأكواد والتحويلات اللحظية بكفاءة عالية.

2.2. تحليل متطلبات التكامل

تبدأ الخطوات الأولية بتحليل نظام معلومات المستشفى (HIS) الحالي لتحديد آلية تصدير بيانات الفواتير والمطالبات. يجب تحديد نقطة التكامل المثلى، سواء كانت عبر Webhook، كما هو مقترح في سير عمل n8n، والذي يستمع للأحداث الجديدة بشكل فوري، أو عبر واجهات برمجة تطبيقات أخرى يوفرها النظام الحالي. هذا التحليل سيحدد كيفية استلام البيانات الخام قبل إدخالها في خط أنابيب المعالجة.

2.3. تصميم ونشر مخطط قاعدة البيانات (Database Schema)

بناءً على المخطط التقني المقترح، يتم إنشاء أربعة جداول أساسية تشكل قلب النظام. هذه الجداول مصممة لدعم تعدد المنشآت (Multi-tenancy) وعمليات المعايرة (Normalization) بكفاءة.

جدول sbs_master_catalogue (المرجع الرئيسي) الوصف: هذا الجدول هو المرجع الرسمي والموثوق لجميع أكواد SBS الصادرة عن مجلس الضمان الصحي. يجب تحديثه دورياً.

الحقل	النوع	الوصف
sbs_id (PK)	VARCHAR	الرمز الفريد للخدمة (مثال: SBS-OP-100)
description_ar	TEXT	وصف الخدمة باللغة العربية
description_en	TEXT	وصف الخدمة باللغة الإنجليزية
version	VARCHAR	رقم إصدار الكود (مثال: V2.0, V3.0)
category	ENUM	نوع الخدمة (مختبر، أشعة، استشارة...)
effective_date	DATE	تاريخ بدء صلاحية الكود

جدول facility_internal_codes (الأكواد المحلية) الوصف: يسجل هذا الجدول رموز الخدمات الداخلية المستخدمة حالياً في نظام المستشفى (HIS) قبل تحويلها إلى رموز SBS.

الحقل	النوع	الوصف
internal_code (PK)	VARCHAR	الكود الداخلي للمنشأة (مثال: LAB_001)
facility_id	INT	معرف المنشأة لدعم تعدد الفروع
local_description	TEXT	الوصف كما يظهر في النظام المحلي
price_gross	DECIMAL	السعر الإجمالي للخدمة قبل تطبيق أي قواعد

جدول sbs_normalization_map (محرك التحويل) الوصف: يمثل هذا الجدول "العقل" أو المحرك الذي يربط بين الرموز الداخلية للمنشأة ورموز SBS القياسية. هذا الجدول هو قلب النظام.

الحقل	النوع	الوصف
map_id (PK)	INT	معرف فريد لعملية الربط
internal_code (FK)	VARCHAR	رابط للكود الداخلي في جدول facility_internal_codes
sbs_code (FK)	VARCHAR	رابط لكود SBS المعتمد في جدول sbs_master_catalogue
confidence	FLOAT	نسبة الثقة إذا تم الربط آلياً بواسطة الذكاء الاصطناعي
is_active	BOOLEAN	لتفعيل أو إلغاء تفعيل هذا الربط دون حذفه

جدول pricing_tier_rules (القواعد المالية) الوصف: يدير هذا الجدول الفروقات في التسعير بناءً على تصنيف المنشأة (Tier) أو مستوى اعتمادها (مثل CBAHI, JCI)، ويحدد نسبة الزيادة المئوية المسموح بها (والتي تتراوح بين 10% و 75% حسب اللوائح).

الحقل	النوع	الوصف
tier_level (PK)	INT	مستوى الاعتماد (1-8)
markup_pct	FLOAT	نسبة الزيادة المئوية المسموح بها
description	VARCHAR	وصف الفئة (مثال: مستشفى مرجعي)

2.4. إعداد بيانات الربط الأولية (Initial Data Mapping)

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

بعد تأسيس قاعدة البيانات وبنية البيانات الأساسية، تنتقل الخطة إلى مرحلة بناء الخدمات المصغرة التي ستتفاعل مع هذه البيانات لتنفيذ منطق العمل المطلوب.

3.0 المرحلة الثانية: تطوير وتكوين الخدمات المصغرة (Microservices)

3.1. تعتمد هذه الخطة على فلسفة الخدمات المصغرة، حيث يتم تقسيم النظام إلى مجموعة من الخدمات المستقلة (Decoupled Services) التي تتواصل عبر واجهات برمجة التطبيقات (APIs). هذا النهج يضمن تحقيق ميزة "Plug and Play"، مما يسهل عمليات الصيانة والتحديث المستقبلية لأي جزء من النظام دون التأثير على الأجزاء الأخرى.

3.2. تكوين خدمة المعايرة الذكية (AI-Powered Normalization Service)

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

• المستوى الأول (البحث المحلي): عند استلام طلب جديد، تقوم الخدمة أولاً بالبحث السريع في جدول sbs_normalization_map، والذي يعمل كمصدر موثوق ودائم لعمليات الربط المعتمدة. إذا تم العثور على تطابق مباشر، يتم إرجاع النتيجة فوراً.
• المستوى الثاني (الربط التلقائي بالذكاء الاصطناعي): في حال فشل البحث المحلي، تقوم الخدمة باستدعاء واجهة برمجة تطبيقات Gemini API. يتم توجيه النموذج عبر prompt مخصص يطلب منه أن يعمل كـ "خبير ترميز طبي سعودي" (expert Saudi Medical Coder) لتحليل وصف الخدمة واقتراح كود SBS الأكثر دقة مع درجة ثقة.

3.3. تكوين خدمة التوقيع الرقمي (Security & Signer Service)

هذه الخدمة مسؤولة عن تأمين المطالبات قبل إرسالها إلى منصة نفيس، وتعتبر التطبيق العملي لمتطلبات المصادقة المتبادلة (mTLS) والتوقيع الرقمي التي تفرضها المنصة. تتضمن عملية التوقيع خطوات دقيقة لضمان سلامة البيانات:

1. التحويل إلى الصيغة الموحدة (Canonical Form): قبل التوقيع، يتم تحويل حمولة المطالبة (Payload) بصيغة JSON إلى نص موحد باستخدام json.dumps مع تفعيل خيار sort_keys=True. هذه الخطوة تضمن أن يكون ترتيب الحقول ثابتاً دائماً، مما ينتج عنه توقيع ثابت لنفس البيانات.
2. التوقيع باستخدام المفتاح الخاص: يتم استخدام المفتاح الخاص للمنشأة لتوقيع النص الموحد باستخدام خوارزمية RSASSA-PKCS1-v1_5 مع دالة التجزئة SHA-256.
3. إرجاع الاستجابة الموقعة: تقوم الخدمة بعد ذلك بإرجاع كائن JSON يحتوي على التوقيع المشفر بصيغة Base64، والخوارزمية المستخدمة (RS256)، والطابع الزمني، ليتم استخدامه لاحقاً من قبل منسق سير العمل.

ملاحظة أمنية هامة: من المبادئ المعمارية الأساسية لهذا النظام أنه في بيئة الإنتاج، لا يتم تخزين المفاتيح الخاصة أبداً في الكود البرمجي أو ملفات الإعدادات. سيتم جلبها عند وقت التشغيل من نظام معتمد لإدارة الأسرار مثل HashiCorp Vault أو AWS KMS. المفتاح المستخدم في الكود المرجعي (MOCK_PRIVATE_KEY_PEM) هو للمحاكاة فقط.

3.4. تكوين محرك القواعد المالية وجسر نفيس (Financial Rules & NPHIES Bridge)

بالإضافة إلى الخدمات السابقة، يتم بناء مكونين أساسيين آخرين لإكمال دورة حياة المطالبة:

• محرك القواعد المالية (Financial Rules Engine): هذا المكون مسؤول عن تطبيق قواعد مجلس الضمان الصحي (CHI) المعقدة. يقوم بحساب تكاليف الحزم (Bundles)، والتحقق من حدود التغطية التأمينية، وتطبيق أي زيادة في الأسعار بناءً على فئة اعتماد المستشفى.
• جسر نفيس (NPHIES Bridge): يتولى هذا المكون إدارة الاتصال المباشر مع منصة نفيس. وهو مسؤول عن معالجة إعادة المحاولة (Retries) في حال انقطاع الخدمة، وتخزين معرفات المعاملات (Transaction IDs) التي يتم استلامها من المنصة لتتبع حالة المطالبات.

بعد بناء هذه الخدمات المستقلة، تأتي الخطوة التالية وهي ربطها معاً في سير عمل مؤتمت ومتكامل لمعالجة المطالبات بكفاءة.

4.0 المرحلة الثالثة: تكامل سير العمل والأتمتة (Workflow Integration)

4.1. في هذه المرحلة، يتم تحويل الخدمات المصغرة المنفصلة إلى خط أنابيب آلي ومتكامل (Automated Pipeline) لمعالجة المطالبات من البداية إلى النهاية. الهدف هو تقليل التدخل اليدوي إلى أدنى حد ممكن، مما يضمن سرعة التنفيذ وتقليل احتمالية حدوث الأخطاء البشرية.

4.2. بناء خط أنابيب معالجة المطالبات (Claim Processing Pipeline)

بالاستناد إلى ملف n8n_integrated_sbs_workflow.json، يتم بناء سير عمل يربط جميع الخدمات معاً في تسلسل منطقي ودقيق. يوضح التسلسل التالي خطوات معالجة المطالبة داخل هذا الخط، مع مطابقة أسماء الخطوات لتلك الموجودة في ملف التنفيذ:

1. الاستلام (Trigger): تبدأ العملية تلقائياً عند استلام مطالبة جديدة من نظام معلومات المستشفى (HIS) عبر Webhook (Node: Webhook: HIS Claim).
2. المعايرة (Normalization): يتم استدعاء خدمة المعايرة الذكية (Node: AI Normalizer Step). تقوم هذه الخدمة بتحويل رمز الخدمة المحلي إلى رمز SBS الموحد. يتم استخدام قيمة sbs_mapped_code المرتجعة في الخطوة التالية لبناء كائن FHIR المتوافق.
3. بناء حمولة FHIR: يتم استخدام البيانات المعايرة لإنشاء كائن JSON متوافق مع معيار تبادل البيانات الصحية HL7 FHIR R4. تتم هذه الخطوة في عقدة Build FHIR Object.
4. التوقيع الرقمي (Digital Signing): يُرسل كائن FHIR الناتج إلى خدمة التوقيع الرقمي (Node: Digital Signer Step) للحصول على توقيع إلكتروني يضمن سلامة البيانات وموثوقيتها.
5. الإرسال النهائي: أخيراً، يتم إرسال المطالبة النهائية إلى منصة نفيس (Node: Final NPHIES Submission). يتم إرفاق التوقيع الرقمي في ترويسة الطلب تحت اسم X-NPHIES-Signature، وهو شرط أساسي لقبول المعاملة.

قبل الانتقال إلى بيئة الإنتاج الحقيقية، من الضروري التحقق من صحة وفعالية هذا السير المتكامل في بيئة اختبار آمنة ومعزولة لضمان عمل جميع المكونات بسلاسة.

5.0 المرحلة الرابعة: الاختبار والتحقق وإدارة الشهادات

5.1. تحظى مرحلة الاختبار بأهمية قصوى، فهي لا تقتصر على كونها فحصاً تقنياً لسلامة الكود، بل هي ضمانة للامتثال المالي والتنظيمي. يهدف الاختبار الدقيق إلى منع رفض المطالبات في بيئة الإنتاج الحقيقية، مما يحافظ على استقرار التدفقات النقدية للمنشأة.

5.2. إدارة الشهادات الرقمية للاتصال بمنصة نفيس

يتطلب الاتصال بمنصة نفيس بروتوكول المصادقة المتبادلة mTLS، حيث يتحقق كل طرف (المنشأة الصحية ومنصة نفيس) من هوية الطرف الآخر باستخدام شهادات رقمية. تتم عملية الحصول على هذه الشهادات وتثبيتها عبر ثلاث خطوات رئيسية:

1. توليد طلب توقيع الشهادة (CSR): يتم إنشاء طلب توقيع شهادة (Certificate Signing Request) من الخادم الذي سيستضيف النظام.
2. رفع الطلب إلى بوابة مطوري نفيس: يتم تقديم طلب CSR عبر بوابة المطورين الخاصة بمنصة نفيس للحصول على الاعتماد وإصدار الشهادة.
3. تثبيت حزمة الشهادات: بعد الموافقة، يتم استلام حزمة الشهادات (عادةً بصيغة .p12 أو .pem) وتثبيتها على الخادم لاستخدامها في توقيع جميع المعاملات الصادرة.

5.3. استراتيجية الاختبار في بيئة Sandbox

يجب الالتزام بقاعدة أساسية وحاسمة: "لا تقم بالنشر على بيئة الإنتاج قبل اختبار جميع السيناريوهات على بيئة نفيس التجريبية (Sandbox)". تضمن هذه البيئة محاكاة كاملة لبيئة الإنتاج دون أي تأثير مالي حقيقي. تشمل سيناريوهات الاختبار الإلزامية ما يلي:

• مطالبة ناجحة ونظيفة (Clean Claim): للتحقق من أن المسار الأساسي يعمل بشكل صحيح.
• مطالبة مرفوضة بسبب كود خاطئ (Invalid Code): للتحقق من أن النظام يعالج رسائل الخطأ من نفيس بشكل سليم.
• مطالبة مركبة: اختبار إرسال مطالبة تحتوي على عدة خدمات SBS في فاتورة واحدة للتحقق من التعامل مع الحالات المعقدة.

5.4. تطبيق منطق التحقق المسبق (Pre-Flight Check)

يتم تطبيق منطق تحقق مسبق (A Pre-Flight Check must be implemented) قبل إرسال أي مطالبة إلى نفيس. يعمل هذا الفحص، كما هو موضح في دالة validateSbsCompliance، كـ "محاكي تحقق" داخلي يكتشف الأخطاء الهيكلية الشائعة مثل نوع المورد الخاطئ أو فقدان كود SBS. يعمل هذا التحقق الداخلي كإجراء لتوفير التكاليف وزيادة الكفاءة، حيث يمنع الطلبات غير الصالحة من استهلاك حصص واجهة برمجة تطبيقات نفيس ويوفر تغذية راجعة فورية لفريق العمليات دون الاعتماد على أنظمة خارجية.

بعد اجتياز جميع هذه الاختبارات بنجاح والتحقق من كافة السيناريوهات، يصبح النظام جاهزاً للمرحلة النهائية وهي النشر والتشغيل.

6.0 المرحلة الخامسة: خطة النشر والتشغيل والمراقبة

6.1. تمثل مرحلة النشر تتويجاً لجميع مراحل التخطيط والتطوير والاختبار السابقة. يتطلب الانتقال إلى بيئة الإنتاج تخطيطاً دقيقاً لضمان انتقال سلس ومستقر دون التأثير على العمليات اليومية للمنشأة الصحية.

6.2. قائمة مراجعة الجاهزية للنشر (Go-Live Checklist)

قبل إطلاق النظام، يجب على الفريق التقني التأكد من استكمال جميع البنود في قائمة المراجعة التالية لضمان الجاهزية الكاملة:

• [ ] تم تكوين متغيرات بيئة الإنتاج (Production environment variables)، بما في ذلك روابط API ومفاتيح التشفير المحملة من Vault.
• [ ] تم تثبيت شهادات mTLS الخاصة بالإنتاج بنجاح.
• [ ] تم نقل بيانات الربط النهائية (sbs_normalization_map) إلى قاعدة بيانات الإنتاج.
• [ ] تم تكوين نظام مراقبة (Monitoring) وتسجيل (Logging) الأخطاء.

6.3. استراتيجية ما بعد الإطلاق

لضمان استدامة النظام وكفاءته على المدى الطويل، يجب تبني مجموعة من أفضل الممارسات التشغيلية:

• تحديث تلقائي لجداول SBS: إنشاء خدمة آلية (Worker Service) تعمل في الخلفية لجلب أحدث إصدارات أكواد SBS من المصادر الرسمية بشكل دوري. هذا يمنع استخدام أكواد ملغاة قد تؤدي إلى رفض المطالبات.
• سجلات مشفرة: التأكيد على ضرورة تشفير أي معلومات تعريف شخصية للمرضى (PII) في سجلات النظام (Logs)، وذلك للامتثال التام للوائح قانون حماية البيانات الشخصية (PDPL) في المملكة.
• المراقبة والتحليل: استخدام لوحة تحكم (Dashboard) لمراقبة المقاييس الرئيسية مثل زمن استجابة الخدمات، ومعدل استخدام واجهات برمجة التطبيقات، ونسبة قبول ورفض المطالبات. تساعد هذه البيانات في تحديد نقاط الضعف وتحسين أداء النظام بشكل مستمر.

6.4. باتباع هذه الخطة التنفيذية الشاملة، تضمن المنشأة الصحية بناء حل متكامل ومرن وممتثل للوائح، مما يعزز الكفاءة المالية والتشغيلية ويدعم التحول الرقمي في القطاع الصحي.