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

 

1.0 المقدمة: أهداف ونطاق خطة التنفيذ

1.1 السياق الاستراتيجي

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

1.2 الهدف الأساسي

الهدف الأساسي من خطة التنفيذ هذه هو نشر حل تكامل قائم على بنية الخدمات المصغرة (Microservices)، يقوم بأتمتة دورة حياة المطالبة التأمينية بالكامل. تبدأ هذه الدورة من لحظة استلام المطالبة من النظام الصحي الداخلي للمستشفى (HIS)، مرورًا بمعايرة البيانات وتطبيق القواعد المالية، وانتهاءً بتقديم مورد FHIR متوافق وموقع رقميًا إلى منصة نفيس.

1.3 هيكل الخطة

تغطي هذه الخطة المراحل الخمس الرئيسية اللازمة لعملية النشر الناجح:

• المرحلة الأولى: إعداد البنية التحتية والخدمات الأساسية: نشر وتهيئة الخدمات المصغرة وقواعد البيانات التي تشكل العمود الفقري للنظام.

• المرحلة الثانية: تهيئة محرك الربط ومعايرة البيانات: إعداد المنطق المسؤول عن ترجمة الأكواد المحلية إلى أكواد SBS الموحدة.

• المرحلة الثالثة: أتمتة سير العمل وتكامل الأنظمة: ربط الخدمات المصغرة في مسار عمل مؤتمت بالكامل، يبدأ من النظام الصحي وينتهي بمنصة نفيس.

• المرحلة الرابعة: تطبيق متطلبات الأمان والاتصال: تنفيذ بروتوكولات التشفير والتوقيع الرقمي اللازمة للتواصل الآمن مع نفيس.

• المرحلة الخامسة: الاختبار والتحقق قبل التشغيل النهائي: إجراء اختبارات شاملة لضمان جاهزية النظام واستقراره قبل الانتقال إلى بيئة الإنتاج.

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

--------------------------------------------------------------------------------

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

2.1 تحليل بنية النظام

إن أساس هذا الحل هو بنية الخدمات المصغرة المنفصلة (Decoupled Microservices Architecture)، المصممة خصيصًا لتحقيق مرونة "التوصيل والتشغيل" (Plug and Play). تسمح هذه البنية بتطوير وتحديث كل خدمة بشكل مستقل، مما يضمن قابلية التوسع والصيانة على المدى الطويل. يوضح هذا القسم بالتفصيل عملية نشر وتهيئة المكونات الأساسية للنظام.

2.2 نشر الخدمات المصغرة الأساسية

يتم نشر الخدمات التالية كحاويات مستقلة (Docker Containers) تتواصل عبر واجهات برمجة التطبيقات (APIs).

الخدمة المصغرة (Microservice)	الوظيفة الأساسية (Core Function)	ملاحظات الإعداد (Configuration Notes)
خدمة المعايرة (The Normalizer Service)	استقبال الكود المحلي من نظام المستشفى (HIS) وتحويله إلى كود SBS المعتمد.	تعتمد على آلية تحديث مدعومة بالذكاء الاصطناعي (AI) لاقتراح أكواد للخدمات غير المعرفة مسبقًا.
محرك القواعد المالي (Financial Rules Engine)	تطبيق القواعد التنظيمية لمجلس الضمان الصحي (CHI) على المطالبات.	مسؤول عن حساب حزم الخدمات (Bundles)، والتحقق من حدود التغطية، وتطبيق هوامش الربح بناءً على فئة اعتماد المستشفى.
خدمة التشفير والتوقيع (Security & Signer Service)	إدارة الشهادات الرقمية لبروتوكول mTLS وتوقيع كل حمولة بيانات (JSON Payload) قبل إرسالها إلى نفيس.	يجب عزل المفاتيح الخاصة (Private Keys) في حاوية مشفرة وآمنة (Vault) وعدم تخزينها مباشرة في الكود.
وسيط نفيس (NPHIES Bridge)	إدارة الاتصال المباشر مع واجهات برمجة تطبيقات نفيس.	مسؤول عن معالجة إعادة الإرسال التلقائي (Retries) في حال انقطاع الخدمة، وتخزين معرفات المعاملات (Transaction IDs) لأغراض التدقيق.

2.3 تصميم مخطط قاعدة البيانات

تدعم بنية قاعدة البيانات عمليات المعايرة والتسعير، وهي مصممة لدعم عدة منشآت صحية (Multi-tenancy).

كتالوج SBS الرئيسي (sbs_master_catalogue)

يعمل هذا الجدول كمرجع أساسي وموثوق لجميع أكواد SBS الرسمية الصادرة عن مجلس الضمان الصحي. يجب تحديثه بشكل دوري لضمان الامتثال.

الحقل (Field)	النوع (Type)	الوصف
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.

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

محرك الربط والمعايرة (sbs_normalization_map)

هذا الجدول هو قلب نظام التكامل، حيث يتم فيه ربط كل كود محلي بالكود الرسمي المقابل له في نظام SBS.

الحقل (Field)	النوع (Type)	الوصف
map_id (PK)	INT	معرف فريد لعملية الربط.
internal_code (FK)	VARCHAR	رابط إلى جدول الأكواد المحلية.
sbs_code (FK)	VARCHAR	رابط إلى جدول كتالوج SBS الرئيسي.
confidence	FLOAT	نسبة الثقة في الربط (تستخدم عند الربط التلقائي عبر AI).
is_active	BOOLEAN	يسمح بتفعيل أو إيقاف عملية ربط معينة دون حذفها.

قواعد التسعير والاعتماد (pricing_tier_rules)

يدير هذا الجدول منطق التسعير المتغير بناءً على مستوى اعتماد المنشأة الصحية (مثل CBAHI أو JCI) وفقًا للوائح وزارة الصحة.

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

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

--------------------------------------------------------------------------------

3.0 المرحلة الثانية: تهيئة محرك الربط ومعايرة البيانات

3.1 أهمية معايرة البيانات

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

3.2 آلية المعايرة ثنائية الطبقات

يعتمد محرك المعايرة على عملية متسلسلة من خطوتين لضمان السرعة والدقة، كما هو مفصل في منطق خدمة sbs_normalizer_api.py.

1. الخطوة الأولى: البحث في قاعدة البيانات المحلية عند استلام طلب جديد، يقوم النظام أولاً بإجراء بحث سريع في جدول الربط المحلي (sbs_normalization_map). إذا تم العثور على تطابق مباشر بين الكود الداخلي (internal_code) وكود SBS، يتم إرجاع النتيجة فورًا. هذه الطريقة تضمن أداءً عاليًا للغالبية العظمى من المعاملات المتكررة.

2. الخطوة الثانية: الربط التلقائي عبر الذكاء الاصطناعي في حال عدم العثور على تطابق في قاعدة البيانات المحلية، يقوم النظام بتفعيل طبقة الذكاء الاصطناعي. يتم إرسال الكود الداخلي، والوصف النصي للخدمة، ومعرف المنشأة إلى خدمة Gemini AI. تقوم الخدمة بتحليل الوصف واقتراح كود SBS الأنسب (suggested_code) مع الوصف الرسمي (official_description) ودرجة ثقة (confidence_score) في دقة الاقتراح. يتم تحقيق ذلك من خلال تزويد الذكاء الاصطناعي بتعليمات نظام محددة تؤطر مهمته على أنه "مرمز طبي سعودي خبير متخصص في نظام الفوترة السعودي".

3.3 تعبئة البيانات الأولية

لضمان فعالية النظام منذ اليوم الأول، يجب على فريق التنفيذ اتخاذ الإجراءات التالية لتعبئة جدول sbs_normalization_map بالبيانات الأولية:

1. استخراج قائمة الأكواد: توليد قائمة كاملة بجميع أكواد الخدمات الداخلية النشطة من النظام الصحي للمستشفى (HIS).

2. ورشة عمل للترميز: عقد جلسات عمل مشتركة بين فريق تقنية المعلومات والمرمزين الطبيين لمراجعة القائمة وربط كل كود داخلي (internal_code) بكود SBS الرسمي المقابل له (sbs_code).

3. الرفع المبدئي للبيانات: إدراج نتائج ورشة العمل في جدول sbs_normalization_map كقاعدة أساسية يعتمد عليها النظام.

4. وضع خطة للمراجعة: تحديد آلية دورية لمراجعة الاقتراحات التي يقدمها الذكاء الاصطناعي واعتمادها لإضافتها بشكل دائم إلى قاعدة البيانات.

بمجرد تهيئة محرك المعايرة وتغذيته بالبيانات الأولية، تركز المرحلة التالية على دمج هذا المحرك ضمن سير عمل مؤتمت بالكامل.

--------------------------------------------------------------------------------

4.0 المرحلة الثالثة: أتمتة سير العمل وتكامل الأنظمة

4.1 مقدمة إلى أتمتة سير العمل

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

4.2 تفصيل مسار العمل المتكامل

بناءً على ملف n8n_integrated_sbs_workflow.json، يتم تقسيم سير العمل المؤتمت إلى الخطوات المتسلسلة التالية:

1. المُشغِّل (Webhook: HIS Claim): تبدأ العملية عندما يقوم النظام الصحي للمستشفى (HIS) بإرسال بيانات المطالبة الأولية عبر طلب POST إلى نقطة نهاية (Endpoint) محددة. تعمل هذه النقطة كمُشغِّل (Trigger) لكامل سير العمل.

2. المعايرة (AI Normalizer Step): يتم استلام البيانات الأولية (مثل facility_id و service_code) وإرسالها مباشرة إلى نقطة النهاية /normalize الخاصة بخدمة المعايرة. تقوم هذه الخدمة بإرجاع كود SBS المعتمد والوصف الرسمي.

3. بناء كائن FHIR (Build FHIR Object): يتم استخدام البيانات التي تمت معايرتها (sbs_mapped_code, official_description) لبناء كائن JSON يتبع معيار Claim FHIR R4. تضمن هذه الخطوة أن تكون بنية البيانات متوافقة تمامًا مع متطلبات نفيس.

4. التوقيع الرقمي (Digital Signer Step): يتم إرسال كائن FHIR الذي تم بناؤه في الخطوة السابقة إلى نقطة النهاية /sign الخاصة بخدمة التوقيع. تقوم هذه الخدمة بتوقيع الحمولة باستخدام المفتاح الخاص للمنشأة وإرجاع توقيع رقمي.

5. الإرسال النهائي (Final NPHIES Submission): في الخطوة الأخيرة، يتم إرسال حمولة FHIR الأصلية وغير الموقعة من الخطوة 3 في متن الطلب، بينما يتم إرفاق التوقيع الرقمي من الخطوة 4 في ترويسة الطلب X-NPHIES-Signature للمصادقة والتحقق من سلامة البيانات. يتم إرسال هذا الطلب المكتمل إلى نقطة النهاية الرسمية لنفيس (https://nphies.sa/api/v1/Claim).

4.3 إعدادات نقطة الاستقبال (Webhook)

لتفعيل مُشغِّل سير العمل، يجب التأكد من تكوين نقطة الاستقبال بشكل صحيح. كما يتضح من سجلات النظام، فإن مجرد إدراج بيانات الـ Webhook في قاعدة البيانات لا يكفي. يجب اتباع التعليمات التالية بدقة:

• تفعيل سير العمل: من الضروري التأكد من أن سير العمل في واجهة مستخدم n8n تم ضبطه على وضع "Active". بدون تفعيل سير العمل، لن يتم تسجيل عنوان URL الإنتاجي ولن يكون متاحًا لاستقبال الطلبات من النظام الصحي للمستشفى، مما يؤدي إلى ظهور رسالة الخطأ: "The workflow must be active for a production URL to run successfully."

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

--------------------------------------------------------------------------------

5.0 المرحلة الرابعة: تطبيق متطلبات الأمان والاتصال بمنصة نفيس

5.1 تحليل ضرورات الأمان

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

5.2 دورة حياة الشهادة الرقمية

يجب على فريق تقنية المعلومات اتباع الخطوات الثلاث التالية للحصول على الشهادات الرقمية المطلوبة وتركيبها:

1. توليد CSR (CSR Generation): الخطوة الأولى هي إنشاء "طلب توقيع شهادة" (Certificate Signing Request) من الخادم الذي سيقوم بالاتصال بمنصة نفيس. يحتوي هذا الطلب على المفتاح العام للمنشأة ومعلومات التعريف الخاصة بها.

2. الاعتماد من نفيس (NPHIES Approval): يتم رفع ملف CSR الذي تم إنشاؤه عبر بوابة المطورين الخاصة بمنصة نفيس. يقوم فريق نفيس بالتحقق من الطلب والموافقة عليه وتوقيع الشهادة.

3. تثبيت الحزمة (Bundle Installation): بعد الموافقة، تتلقى المنشأة حزمة الشهادات الكاملة (عادة بصيغة .p12 أو .pem). يجب تثبيت هذه الحزمة على الخادم لاستخدامها في إنشاء اتصال mTLS الآمن وتوقيع جميع المعاملات الصادرة.

5.3 آلية التوقيع الرقمي

تتم عملية التوقيع الرقمي لكل مطالبة قبل إرسالها لضمان عدم التلاعب بها، وذلك وفقًا للخطوات الموضحة في خدمة sbs_signer_api.py:

• التحويل إلى الصيغة الموحدة (Canonicalization): قبل التوقيع، يجب تحويل حمولة FHIR JSON إلى سلسلة نصية موحدة وثابتة. يتم ذلك عن طريق فرز مفاتيح الكائن أبجديًا (json.dumps(request.payload, sort_keys=True)). هذه الخطوة تضمن أن أي تغيير طفيف في ترتيب الحقول لن يؤدي إلى توقيع مختلف.

• عملية التوقيع: يتم توقيع السلسلة النصية الموحدة باستخدام المفتاح الخاص للمنشأة وخوارزمية SHA-256 with RSA (باستخدام padding.PKCS1v15() و hashes.SHA256()).

• الترميز (Encoding): يتم ترميز التوقيع الرقمي الناتج باستخدام Base64 لتحويله إلى سلسلة نصية آمنة للنقل عبر بروتوكول HTTP.

• إرفاق الترويسة: يتم إرفاق التوقيع المرمّز بترميز Base64 في طلب الإرسال إلى نفيس ضمن ترويسة X-NPHIES-Signature. (ملاحظة: بينما قد تظهر بعض الوثائق ترويسة بديلة مثل X-Signature، فإن X-NPHIES-Signature هي الترويسة المعتمدة لهذا التنفيذ).

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

--------------------------------------------------------------------------------

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

6.1 تأسيس إطار التحقق

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

6.2 خطة اختبار التحقق المسبق (Pre-Flight Check)

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

حالة الاختبار (Test Case)	الخطوات (Steps)	النتيجة المتوقعة (Expected Outcome)
مطالبة صحيحة (Valid Claim)	1. إنشاء حمولة بيانات FHIR من نوع Claim. <br> 2. تضمين كود خدمة صحيح من نظام SBS ضمن حقل productOrService. <br> 3. إرسال الحمولة إلى محرك التحقق.	يقوم النظام بالتحقق من المطالبة بنجاح وإرجاع حالة PASS، مما يشير إلى أنها جاهزة للإرسال إلى نفيس.
خطأ: نوع الملف (Invalid Resource)	1. إنشاء حمولة بيانات حيث يتم تعيين السمة resourceType إلى "Patient" بدلاً من "Claim".	يرفض النظام الحمولة فورًا ويعيد رسالة خطأ توضح أن نوع المورد غير صالح ("Invalid Resource Type").
خطأ: كود SBS مفقود (Missing SBS Code)	1. إنشاء حمولة بيانات من نوع Claim حيث تفتقر مصفوفة coding داخل productOrService إلى إدخال يحتوي فيه حقل system على "sbs.sa".	يرفض النظام الحمولة ويعيد حالة FAIL مع رسالة واضحة: 'Missing SBS Code'.

6.3 رموز الأخطاء الشائعة في نفيس لتصحيح الأخطاء

أثناء الاختبار مع بيئة Sandbox الخاصة بنفيس، من المتوقع ظهور بعض الأخطاء. القائمة التالية تلخص أشهر رموز الأخطاء وكيفية تفسيرها:

• 422 Unprocessable Entity - value-not-in-valueset: هذا يعني أن كود SBS المرسل غير موجود في قائمة الأكواد المعتمدة لدى نفيس. الحل: يجب تحديث جدول sbs_master_catalogue والتأكد من أن كود الخدمة ليس قديمًا أو ملغيًا.

• 400 Bad Request - invariant: يشير إلى انتهاك قاعدة عمل. على سبيل المثال، إرسال كود خدمة يتطلب وجود تشخيص طبي محدد (ICD-10-AM) دون إرفاقه. الحل: مراجعة قواعد العمل الخاصة بالكود المرسل وتضمين المعلومات الداعمة المطلوبة.

• 400 Bad Request - required: يعني أن حقلاً إلزاميًا مفقود في حمولة البيانات، مثل الفشل في إرسال معرّف system URI داخل كائن coding. الحل: التحقق من أن بنية FHIR JSON كاملة وتطابق المواصفات السعودية.

6.4 القائمة المرجعية النهائية للتنفيذ

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

• بيئة Sandbox: يجب إجراء جميع أنواع الاختبارات الوظيفية واختبارات التحمل في بيئة Sandbox الخاصة بمنصة نفيس أولاً. لا تقم أبدًا بالنشر على بيئة الإنتاج مباشرة.

• سجلات مشفرة (Encrypted Logs): يجب التأكد من أن جميع السجلات التي قد تحتوي على معلومات تعريف شخصية للمرضى (PII) يتم تشفيرها بالكامل للامتثال للوائح قانون حماية البيانات الشخصية (PDPL).

• تحديث تلقائي (Automated Updates): يوصى بإنشاء خدمة عاملة (Worker Service) تعمل في الخلفية للتحقق بشكل دوري (أسبوعي أو شهري) من وجود تحديثات على كتالوج أكواد SBS الرسمية وتحديث جدول sbs_master_catalogue تلقائيًا، وذلك لتجنب استخدام أكواد ملغاة.