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

 

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

مقدمة: مواجهة تحدي التحول الرقمي في القطاع الصحي السعودي

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

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

للتغلب على تعقيدات هذا التكامل، سنستعرض نهجاً مبتكراً يعتمد على خدمات مستقلة وقابلة للربط الفوري "Plug and Play"، مما يضمن ليس فقط الامتثال للوائح الحالية، بل يؤسس لنظام مستدام وقادر على مواكبة التطورات المستقبلية في القطاع الصحي.

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

1. الرؤية المعمارية: نهج الخدمات المنفصلة (Decoupled) لتحقيق قابلية الربط الفوري "Plug and Play"

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

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

تتمثل الفوائد الرئيسية لهذا النهج في النقاط التالية:

• قابلية التوسع (Scalability): يمكن توسيع كل خدمة بشكل مستقل عن الأخرى بناءً على حجم الضغط عليها. على سبيل المثال، إذا زاد عدد عمليات معايرة الأكواد، يمكن زيادة موارد "خدمة المعايرة" فقط، دون الحاجة إلى تعديل أو زيادة موارد "خدمة التوقيع الرقمي" أو أي جزء آخر من النظام.
• سهولة الصيانة (Maintainability): يتيح فصل الخدمات إجراء تحديثات وصيانة على جزء من النظام دون التأثير على الأجزاء الأخرى. فمثلاً، تحديث خوارزمية التوقيع الرقمي في "خدمة التشفير" لا يتطلب إعادة نشر أو اختبار أي خدمة أخرى، مما يقلل المخاطر ويسرّع من وتيرة التطوير.
• مرونة التكامل (Integration Flexibility): يسمح هذا التصميم بإنشاء "محولات" (Adapters) مخصصة لكل نظام من أنظمة معلومات المستشفيات (HIS) المختلفة. تقوم هذه المحولات بترجمة البيانات من النظام المحلي إلى تنسيق موحد يفهمه النظام الأساسي، مما يسهل عملية ربط أي مستشفى أو عيادة جديدة بالنظام دون الحاجة لتغيير المنطق الأساسي للمعالجة.

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

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

2. المكونات الأساسية للمعمارية: الخدمات المصغرة (Microservices)

تستند هذه المعمارية على أربعة أعمدة أساسية، تتمثل في أربع خدمات مصغرة متخصصة. كل خدمة مصممة لتنفيذ مهمة محددة بدقة، مما يضمن فصلاً واضحاً للمسؤوليات (Separation of Concerns) ويسهل إدارة النظام وتطويره.

2.1. خدمة المعايرة (The Normalizer Service): العقل المدبر لتوحيد الرموز

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

تتم عملية المعايرة عبر مرحلتين متتاليتين لضمان السرعة والدقة:

1. البحث في قاعدة البيانات المحلية (Static Mapping): تبدأ الخدمة بالبحث عن تطابق مباشر وسريع للرمز المحلي في قاعدة بيانات الربط المحلية (sbs_normalization_map). يجب تخزين جدول الربط هذا (sbs_normalization_map) في الذاكرة عند بدء تشغيل الخدمة، كما يتضح من قاموس MAPPING_DB في الكود المرجعي، لتحقيق أداء بحث فائق السرعة يصل إلى أجزاء من الملي ثانية.
2. المعايرة التلقائية المعتمدة على الذكاء الاصطناعي (Dynamic AI Auto-Mapping): في حال عدم العثور على تطابق في قاعدة البيانات المحلية، تقوم الخدمة باستدعاء نموذج ذكاء اصطناعي توليدي (Gemini)، والذي تم تلقينه ليعمل كـ "خبير ترميز طبي سعودي متخصص في نظام الفوترة السعودي". يقوم النموذج بتحليل الوصف النصي للخدمة ويقترح رمز SBS الأكثر دقة.

كمخرجات أساسية، لا تُرجع الخدمة رمز SBS المعاير فحسب، بل تُرجع أيضاً الوصف الرسمي للخدمة (official_description) ودرجة الثقة في دقة الربط (confidence_score)، مما يتيح للنظام إمكانية تمييز المطالبات ذات الثقة المنخفضة لمراجعتها يدوياً. يمكن تنفيذ هذه الخدمة باستخدام أطر عمل حديثة مثل FastAPI أو Node.js.

2.2. محرك القواعد المالية (Financial Rules Engine): ضامن الامتثال المالي

هذا المكون هو المسؤول عن تطبيق القواعد المالية وقواعد العمل المعقدة التي يفرضها مجلس الضمان الصحي (CHI). يعمل كحارس لضمان أن كل مطالبة تتوافق مع اللوائح المالية قبل إرسالها، مما يقلل بشكل كبير من معدلات الرفض لأسباب مالية.

تشمل مهامه الرئيسية ما يلي:

• حساب الحزم الطبية (Calculating Bundles): تجميع الخدمات التي يجب فوترتها كحزمة واحدة وفقاً للوائح.
• التحقق من حدود التغطية التأمينية (Verifying coverage limits): التأكد من أن تكلفة الخدمة لا تتجاوز حدود بوليصة التأمين.
• تطبيق هوامش الربح (Applying Markups): إضافة هوامش الربح المعتمدة بناءً على مستوى اعتماد المنشأة الصحية (مثل CBAHI أو JCI).

2.3. خدمة التشفير والتوقيع الرقمي (Security & Signer Service): حارس بوابة البيانات

تؤدي هذه الخدمة مهمة أمنية حيوية ومزدوجة: فهي مسؤولة عن إدارة الشهادات الرقمية اللازمة لإنشاء اتصال آمن عبر بروتوكول mTLS مع منصة نفيس، بالإضافة إلى التوقيع الرقمي لكل حزمة بيانات (JSON Payload) قبل إرسالها.

تتبع عملية التوقيع الرقمي خطوات دقيقة لضمان سلامة البيانات:

1. التوحيد القياسي (Canonicalization): يتم تحويل حزمة بيانات FHIR JSON الواردة إلى سلسلة نصية موحدة ومرتبة، لضمان أن يكون التوقيع متطابقاً في كل مرة لنفس البيانات.
2. التوقيع (Signing): يُستخدم المفتاح الخاص للمنشأة لتوقيع السلسلة النصية الموحدة باستخدام خوارزمية SHA-256 مع RSA.
3. ترميز (Encoding): يتم ترميز التوقيع الناتج باستخدام Base64 لتهيئته للإرسال ضمن ترويسة HTTP.

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

2.4. وسيط نفيس (NPHIES Bridge): مدير الاتصالات الموثوق

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

تشمل مسؤولياته الأساسية ما يلي:

• إدارة الاتصال الآمن مع منصة نفيس: إنشاء وإدارة الجلسات الآمنة عبر بروتوكول mTLS.
• معالجة إعادة المحاولات بآلية التراجع الأسي (Handling retries using Exponential Backoff): إعادة إرسال الطلبات تلقائياً في حال فشل الاتصال أو عدم توفر الخدمة مؤقتاً.
• تخزين معرفات المعاملات (Storing Transaction IDs): حفظ وتخزين معرفات المعاملات التي يتم استلامها من نفيس بعد كل عملية إرسال ناجحة، وذلك لأغراض التتبع والتدقيق.

في القسم التالي، سنوضح كيف تعمل هذه الخدمات المنفصلة معاً بتناغم ضمن مسار عمل مؤتمت بالكامل.

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

3. مسار العمل المؤتمت لمعالجة المطالبات (Automated Pipeline)

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

فيما يلي تسلسل الأحداث في هذا المسار الآلي:

1. الاستلام من نظام المستشفى (Trigger: HIS Webhook): تبدأ العملية عندما يقوم نظام معلومات المستشفى (HIS) بإرسال بيانات مطالبة جديدة عبر Webhook آمن.
2. معايرة الرموز (Step 1: Normalizer Service): يتم تمرير بيانات المطالبة، بما في ذلك رمز الخدمة الداخلي، إلى "خدمة المعايرة". تقوم الخدمة بترجمة الرمز المحلي إلى رمز SBS الرسمي المعتمد.
3. بناء كائن FHIR وتطبيق القواعد المالية (Step 2: FHIR Object Construction & Rules Application): باستخدام رمز SBS المعاير وبقية تفاصيل المطالبة، يتم بناء كائن JSON متوافق تماماً مع معيار HL7 FHIR R4. قبل إتمام بناء الكائن، يتم التحقق من محتوياته عبر "محرك القواعد المالية" لضمان الامتثال للوائح مجلس الضمان الصحي وتطبيق أي حسابات ضرورية. يمكن تنفيذ هذه الخطوة كاستدعاء مكتبة برمجية داخل خدمة بناء FHIR أو كاستدعاء خدمة مصغرة منفصلة.
4. التوقيع الرقمي (Step 3: Signer Service): بعد التحقق من سلامة البيانات المالية والطبية، يتم إرسال حزمة FHIR JSON النهائية إلى "خدمة التوقيع الرقمي" للحصول على توقيع إلكتروني يضمن سلامة البيانات.
5. الإرسال النهائي لمنصة نفيس (Step 4: NPHIES Bridge): أخيراً، يقوم "وسيط نفيس" بتقديم حزمة FHIR الموقعة إلى واجهة برمجة تطبيقات نفيس، مع إرفاق التوقيع الرقمي في ترويسة HTTP (X-NPHIES-Signature). ينتظر الوسيط استلام رد فوري من المنصة وتخزين معرف المعاملة.

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

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

4. أسس البيانات والأمن

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

4.1. مخطط قاعدة البيانات (Database Schema)

يمثل مخطط قاعدة البيانات المرن قلب محرك المعايرة، وهو مصمم لدعم تعدد المنشآت (Multi-tenancy) وإدارة إصدارات الأكواد المختلفة بفعالية.

جدول sbs_master_catalogue (كتالوج SBS الرئيسي) هذا الجدول هو المرجع الأساسي الذي يحتوي على جميع أكواد SBS الرسمية الصادرة عن الجهات التنظيمية.

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

جدول facility_internal_codes (الأكواد الداخلية للمنشأة) يخزن هذا الجدول الأكواد الخاصة التي تستخدمها كل منشأة صحية في نظامها الداخلي.

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

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

الحقل (Field)	النوع (Type)	الوصف
map_id	INT	المعرف الفريد لعملية الربط.
internal_code	VARCHAR	مفتاح خارجي مرتبط بجدول facility_internal_codes.
sbs_code	VARCHAR	مفتاح خارجي مرتبط بجدول sbs_master_catalogue.
confidence	FLOAT	درجة الثقة في دقة الربط (خاصة عند استخدام الربط الآلي).
is_active	BOOLEAN	حقل لتفعيل أو تعطيل هذا الربط المحدد.

هذا الجدول هو الجسر العلائقي الأساسي في المحرك، حيث ينشئ علاقة "many-to-one" التي تربط internal_code من جدول facility_internal_codes برمز sbs_code الرسمي في جدول sbs_master_catalogue.

جدول pricing_tier_rules (قواعد فئات التسعير) يدير هذا الجدول الاختلافات في الأسعار بناءً على مستوى اعتماد المنشأة الصحية.

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

4.2. بروتوكولات الأمان: شهادات mTLS وتوقيع البيانات

تفرض منصة نفيس بروتوكول المصادقة المتبادلة (Mutual TLS أو mTLS) كشرط أساسي لجميع الاتصالات. هذا يعني أن كلاً من العميل (نظام المستشفى) والخادم (منصة نفيس) يجب أن يقدما شهادات رقمية للتحقق من هوية بعضهما البعض قبل إنشاء أي قناة اتصال.

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

1. توليد طلب توقيع شهادة (CSR Generation): يتم إنشاء ملف طلب توقيع الشهادة (CSR) من الخادم الذي سيقوم بالاتصال بمنصة نفيس.
2. الاعتماد من نفيس (NPHIES Approval): يُرفع ملف CSR عبر بوابة مطوري نفيس ليتم التحقق منه والموافقة عليه من قبل المنصة.
3. تثبيت الحزمة (Bundle Installation): بعد الموافقة، تتلقى المنشأة حزمة الشهادات المعتمدة، والتي يجب تثبيتها على الخادم لاستخدامها في الاتصال والتوقيع الرقمي.

يتم إكمال هذه المنظومة الأمنية من خلال عملية التوقيع الرقمي، حيث يقوم النظام بأخذ حزمة FHIR JSON، وتوحيدها قياسياً، وتجزئتها باستخدام خوارزمية SHA-256، ثم توقيعها باستخدام المفتاح الخاص للمنشأة، وإرفاق التوقيع الناتج كترويسة HTTP في الطلب المرسل عبر قناة mTLS الآمنة.

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

5. أفضل الممارسات للقادة التقنيين

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

• الاختبار في بيئة الـ Sandbox: قبل الانتقال إلى بيئة الإنتاج، من الضروري اختبار جميع السيناريوهات المحتملة بشكل شامل في بيئة الاختبار (Sandbox) التي توفرها نفيس. يشمل ذلك اختبار المطالبات الناجحة، والمطالبات التي تحتوي على أكواد غير صالحة، والمطالبات المركبة، وغيرها من الحالات الحدية.
• التحقق المسبق (Pre-Flight Checks): يُنصح بتطبيق دالة تحقق داخلية (مثل validateSbsCompliance) تقوم بفحص المطالبة للتأكد من امتثالها لقواعد SBS و FHIR قبل إرسالها إلى نفيس. هذا النهج الاستباقي يقلل بشكل كبير من عدد المطالبات المرفوضة ويوفر الوقت والموارد.
• التحديث التلقائي للكتالوجات: يجب إنشاء خدمة عاملة (Worker Service) مؤتمتة تقوم بشكل دوري بتنزيل أحدث إصدارات كتالوجات أكواد SBS من المصادر الرسمية وتحديث قاعدة البيانات الرئيسية. هذا يضمن عدم استخدام أكواد ملغاة أو قديمة، مما يمنع رفض المطالبات لهذا السبب.
• تشفير السجلات (Encrypted Logging): وفقاً لنظام حماية البيانات الشخصية السعودي (PDPL)، يجب تشفير جميع السجلات التي تحتوي على أي معلومات يمكن التعرف من خلالها على المريض (PII). يعد هذا الإجراء ضرورياً لضمان الامتثال القانوني وحماية خصوصية المرضى.

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

خاتمة: بناء الجيل القادم من أنظمة الفوترة الصحية

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

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

إن تبني هذه الرؤية المعمارية يمكّن قادة التكنولوجيا في القطاع الصحي من تجاوز المتطلبات الحالية وبناء أساس متين ومقاوم للمستقبل، قادر على دعم الابتكار الرقمي المستمر في منظومة الرعاية الصحية في المملكة.