ORCA (Nichi-Rece) ليس سجلاً طبيّاً إلكترونيّاً ── نظام الفوترة (rececon) وتكوين أنظمة الرعاية من منظور مهندس

هل سمعت عبارة «السجلّ الطبيّ الإلكتروني ORCA»؟ اسم يظهر حتماً في أيّ مشروع لأنظمة موجَّهة للمؤسّسات الطبيّة، لكن هذه التسمية تتضمّن سوء فهم. ORCA (JMA Standard Receipt Software) ليس سجلاً طبيّاً إلكترونيّاً.

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

• ما هو ORCA، وأين يقع في تكوين أنظمة المؤسّسة الطبيّة
• ما الذي يقوم به «عمل المطالبات» الذي يتولّاه نظام الفوترة، إذا نُظر إليه كنظام
• بأيّ تقنيات بُني، وما الذي تحتويه الشيفرة المصدرية المنشورة
• ماذا يتغيّر بالانتقال إلى WebORCA، وما الذي ينبغي لجهة الربط أن تثبّته

كلّ ما يرد هنا مبني على مصادر أوليّة منشورة. العبارات المتعلّقة بالشيفرة المصدرية نتيجة تنزيل مصدر Nichi-Rece سلسلة 5.2 المنشور رسميّاً (اللقطة المنشورة في 1 يوليو 2026، ملفّ VERSION يذكر 5.2.0) والتحقّق منه فعليّاً.

المحتويات

1. الخلاصة أوّلاً ── ORCA «نظام فوترة مطالبات»
2. ما هو عمل المطالبات ── أقصر فهم من منظور النظام
3. مخطّط تكوين أنظمة المؤسّسة الطبيّة ── أين يقع ORCA
4. تاريخ مشروع ORCA وترخيصه
5. المكدّس التقني ── عدّ نحو 4 ملايين سطر COBOL فعليّاً
6. التجوّل في شجرة المصدر ── أين يوجد ماذا
7. مداخل الربط ── Nichi-Rece API وPushAPI وCLAIM
8. ماذا يتغيّر بالانتقال إلى WebORCA
9. الخلاصة ── النقاط التي ينبغي للمهندس تثبيتها
10. المراجع

خريطة المعرفة لهذه المقالة

ORCA (Nichi-Rece) ليس سجلاً طبيّاً إلكترونيّاً، بل نظام فوترة (rececon) يتولّى حساب أجور الرعاية وإنشاء المطالبات، ويرتبط بالسجلّ الطبيّ الإلكتروني عبر Nichi-Rece API. منطق أعمال Nichi-Rece مكتوب بلغة COBOL، ويعمل فوق منصّة التشغيل MONTSUQI (panda) مع عميل Java المسمّى monsiaj وPostgreSQL، وتُوجَّه الشاشات وAPI بتعريف LD نفسه. مدخل الربط الخارجي هو أساساً Nichi-Rece API وPushAPI المنشوران بموجب عقد ترخيص المصادر المفتوحة للجمعية الطبيّة اليابانيّة، وقد انتهى دعم CLAIM المستخدم طويلاً في مارس 2026 وصار الانتقال إلى Nichi-Rece API هو الافتراض. الفترة الحاليّة فترة انتقال إلى WebORCA الإصدار السحابي والإصدار المحلّي، وتحلّ هذه الأشكال تدريجيّاً محلّ بيئة التقديم التقليديّة (إصدار MONTSUQI)، لكن المتن في الحالتين هو Nichi-Rece نفسه.

flowchart LR
    accTitle: خريطة معرفة ORCA (Nichi-Rece)
    accDescr: مخطّط يبيّن تقاسم الأدوار بين ORCA (Nichi-Rece) بوصفه نظام فوترة (rececon) والسجلّ الطبيّ الإلكتروني، ومكدّس COBOL وMONTSUQI وPostgreSQL وmonsiaj مع التوجيه بتعريف LD، ومسار تحوّل وسائل الربط Nichi-Rece API وPushAPI وCLAIM، وعلاقة الانتقال إلى WebORCA الإصدار السحابي والإصدار المحلّي
    orca_nichirese["ORCA (Nichi-Rece)"]
    receipt_computer["نظام الفوترة (rececon)"]
    receipt["المطالبة (كشف أجور الرعاية)"]
    electronic_medical_record["السجلّ الطبيّ الإلكتروني"]
    orca_api["Nichi-Rece API"]
    cobol["COBOL"]
    montsuqi["MONTSUQI"]
    postgresql["PostgreSQL"]
    monsiaj["monsiaj"]
    ld_definition["تعريف LD"]
    push_api["PushAPI"]
    claim_protocol["CLAIM (مواصفة تبادل المعلومات الطبيّة)"]
    jma_opensource_license["عقد ترخيص المصادر المفتوحة للجمعية الطبية اليابانية"]
    weborca_cloud["WebORCA الإصدار السحابي"]
    weborca_onpremise["WebORCA الإصدار المحلّي"]
    legacy_nichirese_deployment["بيئة التقديم التقليديّة (إصدار MONTSUQI)"]
    orca_nichirese -->|"ينفّذ"| receipt_computer
    receipt -->|"يشترط"| receipt_computer
    electronic_medical_record -.->|"يستخدم"| orca_api
    orca_nichirese -->|"يستخدم"| cobol
    orca_nichirese -->|"يستخدم"| montsuqi
    orca_nichirese -->|"يستخدم"| postgresql
    orca_nichirese -->|"يستخدم"| monsiaj
    montsuqi -->|"يُكوَّن بـ"| ld_definition
    orca_api -->|"يُكوَّن بـ"| ld_definition
    orca_api -->|"يشترط"| montsuqi
    monsiaj -->|"يشترط"| montsuqi
    orca_nichirese -->|"يستخدم"| orca_api
    orca_nichirese -->|"يستخدم"| push_api
    orca_api -->|"يخلف"| claim_protocol
    orca_nichirese -.->|"يشترط"| jma_opensource_license
    weborca_cloud -->|"ينفّذ"| orca_nichirese
    weborca_onpremise -->|"ينفّذ"| orca_nichirese
    weborca_onpremise -->|"يخلف"| legacy_nichirese_deployment
    legacy_nichirese_deployment -->|"يستخدم"| montsuqi

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 19، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

1. الخلاصة أوّلاً ── ORCA «نظام فوترة مطالبات»

«برمجية المطالبات القياسية للجمعية الطبية اليابانية» (JMA Standard Receipt Software، واختصارها Nichi-Rece) محور مشروع ORCA هي نظام فوترة مطالبات (rececon / receipt computer). يحسب نظام الفوترة أجور الرعاية من محتوى العلاج، وينشئ المطالبة (كشف أجور الرعاية الطبية، receipt) المقدَّمة إلى هيئات المراجعة والدفع.

أدوار السجلّ الطبيّ الإلكتروني ونظام فوترة المطالبات منفصلة بوضوح.

وُلد الاسم الشائع «السجلّ الإلكتروني ORCA» لأنّ كثيراً من منتجات السجلّ الطبيّ الإلكتروني اتّخذت تكويناً يقول «جزء الفوترة يرتبط بـORCA». بالنسبة للمهندس، إذا ثبّتَّ أوّلاً التمييز ORCA = العمود الفقري لجانب المطالبات، السجلّ الطبيّ الإلكتروني = جانب السجلّ السريري، صار ترتيب كلّ ما يلي أسهل.

2. ما هو عمل المطالبات ── أقصر فهم من منظور النظام

أسرع طريق لفهم ماهية نظام الفوترة هو معرفة تدفّق دخل المؤسّسة الطبيّة. في الرعاية المؤمَّن عليها في اليابان، يدفع المريض في الشبّاك 10 إلى 30 بالمئة كمبدأ، وتطالب المؤسّسة بالباقي شهريّاً من هيئات المراجعة والدفع (صندوق دفع أجور الرعاية الطبية للتأمين الاجتماعي، واتحادات هيئات التأمين الصحّي الوطني). وثيقة هذه المطالبة هي الـreceipt.

من منظور النظام، نظام الفوترة جهاز يدير دورة الدفعة الشهريّة التالية.

1. يوميّاً: يُتحقَّق في الاستقبال من أهليّة التأمين، وتُدخَل الإجراءات الطبيّة (المعاينة، الفحوص، صرف الدواء، العلاجات…)، وتُجرى المحاسبة بحصّة الشبّاك المحسوبة تلقائيّاً وفق جدول النقاط.
2. شهريّاً: تُجمَّع إجراءات شهر كامل بوحدة المريض × التأمين، وتُنشأ المطالبات. قبل التقديم يُجرى فحص للبيانات (اتّساق التشخيص مع الوصفة وغير ذلك)، وتُقدَّم كمطالبة إلكترونيّة (بيانات rece-den).
3. الشهر التالي وما بعده: معالجة «الإرجاع» (henrei) الذي ردّته المراجعة و«التخفيض» (satei) الذي خُفِّضت قيمته، ثمّ التصحيح وإعادة المطالبة.

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

3. مخطّط تكوين أنظمة المؤسّسة الطبيّة ── أين يقع ORCA

إذا رُسم تكوين عيادي نموذجي، يقع ORCA (Nichi-Rece) في موضع قريب من محور أنظمة المؤسّسة.

flowchart LR
    subgraph clinic["داخل المؤسّسة الطبيّة"]
        EMR["السجلّ الطبيّ الإلكتروني<br/>السجلّ السريري والطلبات"]
        RSV["نظام الاستقبال والحجز"]
        ONS["جهاز التحقّق من الأهليّة عبر الإنترنت"]
        ORCA["ORCA / Nichi-Rece<br/>نظام الفوترة (مطالبة أجور الرعاية)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"ربط الاستقبال والحجز"| ORCA
        ONS -->|"بيانات أهليّة التأمين"| ORCA
    end
    ORCA -->|"المطالبة (فاتورة شهريّة)"| PAY["هيئات المراجعة والدفع<br/>صندوق الدفع واتحادات التأمين الوطني"]

النقاط الثلاث هي التالية.

• كثيراً ما تمسك جهة ORCA بيانات المريض الأساسيّة وبيانات التأمين كبيانات رئيسيّة. يرجع إليها السجلّ الطبيّ الإلكتروني ويحدّثها عبر API. أيّ الجانبين يمسك ترقيم رقم المريض يصبح أوّل موضوع في تصميم الربط.
• تُرسل الإجراءات الطبيّة (ماذا أُنجز) من السجلّ الطبيّ الإلكتروني إلى ORCA، ويقوم ORCA بـحساب النقاط ويربطه بالمحاسبة والمطالبة. يصف السجلّ الطبيّ الإلكتروني العلاج بـ«لغة الطلبات»، ويصفه ORCA بـ«لغة النقاط»، لذا يصبح تحويل ذلك (مقابلة رموز الإجراءات الطبيّة) أصعب جزء عمليّ في الربط.
• تقديم المطالبات الشهريّة عمل ORCA. أي أنّ مبيعات المؤسّسة الطبيّة تُطالَب عبر ORCA. ميزة هذا المجال أنّ خطأ الربط يظهر لا كنقص في السجلّ السريري بل كخطأ في مبلغ المطالبة، وهذا التوتّر يميّز المجال.

4. تاريخ مشروع ORCA وترخيصه

ORCA مشروع للجمعية الطبية اليابانية (JMA). في «إعلان IT للجمعية الطبية اليابانية» في نوفمبر 2001 تبيَّن توجّه نشر البرمجيات التي تصنعها الجمعية كمصادر مفتوحة، وكانت Nichi-Rece محور ما طُوِّر في ذلك الإطار. بدأ الاستخدام في الميدان الطبي عام 2002، واستمرّ التطوير أكثر من عشرين سنة منذ ذلك الحين.

ما يستحقّ الذكر من منظور المهندس هو أنّ شيفرة نظام أعمال ظلّت تُنشَر أكثر من عشرين سنة.

• الترخيص هو عقد ترخيص المصادر المفتوحة للجمعية الطبية اليابانية (JMA OpenSource License version 1.0) المرفق بالمصدر. ليس GPL بل عقد خاص بالجمعية: يُمنَح استخدام البرنامج (بما في ذلك النسخ والاقتباس والتوزيع والإرسال العلني) بشكل غير حصري ومجّاني، وعند توزيع نسخة معدَّلة تُفرَض الشروط نفسها، أي بنية تشبه copyleft. القانون الواجب التطبيق هو القانون الياباني.
• كان مستودع CVS منشوراً في السابق، لكن مع بدء تقديم النسخة التجاريّة أُخفي CVS، والطريقة الحاليّة هي نشر مصدر بتاريخ اليوم الأوّل من الشهر السابق على هيئة tarball في اليوم الأوّل من كلّ شهر. أهداف النشر ثلاثة مكوّنات: المتن، والإعانات العامّة الإقليميّة، والنماذج المنشورة، وتُنشَر سلاسل 5.0 و5.1 و5.2 بالتوازي.
• نظام التطوير والتقديم مميَّز أيضاً. بقراءة سجلّ تعديلات المصدر، تصطفّ في البداية أسماء مهندسي NACL (جهة Custom Software Development المتعاقد معها للتطوير)، ومن نحو 2022 تنتقل الالتزامات إلى اسم ORCAMO (مؤسّسة إدارة ORCA التابعة للجمعية الطبية اليابانية). الخدمات المحيطة (الدعم، الحزم، الأدلّة وغيرها) تقدّمها مؤسّسة إدارة ORCA كنسخة تجاريّة، والتثبيت والصيانة يتولّاهما مقدّمو دعم معتمدون في أنحاء البلاد، أي نموذج تقسيم عمل.

أي أنّ ORCA برمجية «مفتوحة المصدر، لكنّها ليست تطويراً مجتمعيّاً على طريقة GitHub». يمكن قراءة المصدر، ويمكن عمل fork، لكن تطوير المسار الرئيسي تدفعه جهة واحدة بأسلوب مورِّد. وإذا فكّرت في مجال الطبّ، حيث لا يُتسامح مع الخطأ ومتابعة المنظومة التنظيمية إلزاميّة، بدا هذا موضع تسوية معقولاً.

5. المكدّس التقني ── عدّ نحو 4 ملايين سطر COBOL فعليّاً

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

في INSTALL.ja لمصدر سلسلة 5.2 المنشور، تصطفّ البرمجيات اللازمة مثل MONTSUQI (panda) وOpenCOBOL وPostgreSQL وMONPE. ملخّص التكوين كالتالي.

الكلمات وحدها لا تنقل حجم النطاق، لذا نذكر نتائج العدّ الفعلي للقطة سلسلة 5.2 (نحو 8,200 ملفّ و237MB بعد الفكّ).

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

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

عماد البنية هو MONTSUQI. داخل Nichi-Rece، يتلقّى عميل Java (monsiaj) تعريف الشاشة من الخادم ويعرضه، ويعالج برنامج COBOL على الخادم الإدخال ويقرأ PostgreSQL ويكتب إليه: معالجة مركزيّة كلاسيكيّة. أيّ شاشة تقابل أيّ برنامج COBOL مكتوب بشكل تصريحي في ملفّات تعريف LD في دليل lddef/.

flowchart LR
    CL["monsiaj<br/>عميل Java"] -->|"عمليات الشاشة"| MW["MONTSUQI<br/>خادم التطبيقات"]
    API["أنظمة الربط<br/>السجلّ الطبيّ الإلكتروني وغيره"] -->|"Nichi-Rece API (HTTP)"| MW
    MW -->|"التوزيع وفق تعريفات lddef/*.ld"| AP["مجموعة برامج الأعمال<br/>نحو 1,750 برنامجاً COBOL"]
    AP --> DB[("PostgreSQL<br/>285 جدولاً")]

الطريف أنّ توجيه الشاشات وتوجيه API يعيشان في ملفّ تعريف LD نفسه. أي أنّ Nichi-Rece API ليست خادماً منفصلاً أُضيف لاحقاً، بل نُفِّذت كإضافة «مدخل يتحادث بـXML بدلاً من الشاشة» فوق منصّة برامج الأعمال نفسها التي للشاشة التفاعليّة. تفاصيل هذا التصميم موضوع الجزء التالي.

تكوين «COBOL + برمجية وسيطة مخصَّصة + PostgreSQL» يبدو بعيداً عن حسّ تطوير الويب الحديث. لكن في ترويسة برنامج COBOL واحد محفور سجلّ تعديلات بالتعليقات منذ 2002، ويمكن قراءة أنّ قاعدة الشيفرة نفسها واصلت متابعة المراجعات أكثر من عشرين سنة، حتّى مواكبة أنظمة حديثة مثل الوصفة الإلكترونيّة (2022) والتحقّق من أهليّة بطاقة التأمين My Number (ماينا، 2024). هذا التكوين أيضاً نتيجة تحسين من أجل أن يبقى مستقرّاً ويظلّ يعمل.

6. التجوّل في شجرة المصدر ── أين يوجد ماذا

كخريطة عند قراءة المصدر فعليّاً، نرتّب الأدلّة الرئيسيّة في المستوى الأعلى.

ملاحظة عمليّة واحدة. ترميز أحرف المصدر EUC-JP (وثيقة الترخيص ISO-2022-JP). إذا فُتح بمحرّر حديث انكسر العرض، فتقرأه بعد iconv -f EUC-JP -t UTF-8. كبسولة زمنيّة حفظت معيار بيئة Linux آنذاك عام 2002 كما هو.

7. مداخل الربط ── Nichi-Rece API وPushAPI وCLAIM

عندما يلمس مهندس أنظمة خارجيّة ORCA، المداخل عمليّاً ثلاثة.

1. Nichi-Rece API ── التوصية الحاليّة. يرسل نظام الربط طلبات HTTP لجلب معلومات المريض والاستقبال وتسجيل الإجراءات الطبيّة وغيرها. عمليات القراءة أساساً GET أو POST+XML، وعمليات التحديث POST+XML. مواصفة API منشورة على الموقع الرسمي.
2. PushAPI ── آلية يُخطر بها نظام الربط بأحداث وقعت في جهة Nichi-Rece (مثل تعليمات طباعة نموذج). يمكن بناء تزامن الشاشات بمحرَّك أحداث لا بالاستقصاء (polling).
3. CLAIM ── استُخدم طويلاً كمواصفة قياسيّة لتبادل المعلومات الطبيّة، لكن الدعم انتهى في مارس 2026. ما تزال معالجة سلسلة CLAIM باقية في المصدر، لكن أصبح افتراض الانتقال إلى API قائماً لربط CLAIM القائم.

أي أنّ من سيصمّم ربط ORCA من الآن Nichi-Rece API هو الخيار الوحيد. وكما سبق، API منفَّذة فوق منصّة برامج أعمال COBOL نفسها التي للشاشة التفاعليّة، لذا عندما «لا يُفهم سلوك API» يمكن النزول إلى المصدر والتحقّق. الخطوات الملموسة لفهم الصورة الكاملة لـAPI (بما في ذلك نقاط النهاية غير الواردة في القائمة الرسميّة) من المصدر مشروحة في مقال الجزء التالي.

8. ماذا يتغيّر بالانتقال إلى WebORCA

ORCA الحالي في فترة انتقال إلى «WebORCA». أشكال التقديم نوعان كبيران.

• WebORCA الإصدار السحابي ── شكل يستخدم Nichi-Rece كخدمة سحابيّة تقدّمها مؤسّسة إدارة ORCA. تتحرّر المؤسّسة الطبيّة من إدارة الخوادم. يتمّ الطلب عبر مكتب دعم معتمد، وتشير الإرشادات الرسميّة إلى توقّع نحو ثلاثة أسابيع من الطلب حتّى بدء الخدمة. لا تضع المؤسّسة خادماً داخلها، وتستخدم من المتصفّح، وتحديثات البرنامج المرافقة لمراجعة أجور الرعاية تُجرى دفعة واحدة في جهة السحابة. الرسوم اشتراك شهري لكلّ مؤسّسة طبيّة.
• WebORCA الإصدار المحلّي ── شكل يُثبَّت على خادم داخل المؤسّسة (Ubuntu). بيئة التقديم الحاليّة Nichi-Rece Ver5.2.0 على Ubuntu 22.04 (jammy).

بشأن الخطّ الزمني للانتقال، نقطتان ينبغي تثبيتهما.

الأولى أنّ مسار الانتقال مُعدّ رسميّاً. ينشر مشروع ORCA «دليل ترحيل بيئة تشغيل Nichi-Rece»، ويُذكَر صراحةً أنّ المستهدَف هو إجراءات الانتقال من Nichi-Rece 5.1.0 / 5.2.0 التقليدي (إصدار MONTSUQI) العامل على Ubuntu 16.04 / 18.04 / 20.04 إلى WebORCA المحلّي (Ubuntu 22.04 + 5.2.0). الاتجاه المعاكس، أي الانتقال إلى نظام تشغيل أدنى أو إصدار Nichi-Rece أدنى، غير ممكن.

والثانية أنّه لا يوجد موعد نهائي موحَّد معلَن من نوع «على جميع المؤسّسات الانتقال إلى WebORCA بحلول تاريخ كذا». ما يفرض مهلة عملية هو تاريخ انتهاء الدعم المضبوط لكلّ تركيبة من نظام التشغيل وحزمة Nichi-Rece، ويُنشَر بعنوان «جدول دعم حزم Nichi-Rece ونظام التشغيل»، وتُعلَن الإصدارات القريبة من الانتهاء على حدة. بالنسبة لمن يبني نظام ربط، الطريقة العمليّة لفهم الخطّ الزمني ليست «متى الانتقال إلى WebORCA»، بل التحقّق من إصدار Ubuntu وNichi-Rece اللذين تستخدمهما المؤسّسة الطبيّة المقابلة، ومن تاريخ انتهاء دعمهما.

المهمّ أنّ المتن في الحالتين هو Nichi-Rece نفسه. البرمجية العاملة لا تصبح شيئاً آخر باختلاف شكل التقديم، وأنواع API وسلوكها مشتركة أساساً. ما ينبغي لمهندس الربط تثبيته يتجمّع لا في التنفيذ بل حول الاتّصال.

• فروق المدخل مثل إضافة بادئة /api لمسار طلب API في الإصدار السحابي، واختلاف إعدادات معلومات الاتّصال والمصادقة حسب شكل التقديم. مواصفة API نفسها مشتركة.
• في الإصدار السحابي يستدعي نظام الربط داخل المؤسّسة API عبر الإنترنت، لذا يزداد ما ينبغي التفكير فيه في مسار الشبكة وسلوك الوضع المخفَّض عند انقطاع الخدمة مقارنةً بالتكوين المحلّي.
• المصدر المنشور شهريّاً يتضمّن تعريفات WebORCA كما هي (مثال: ملفّات .db.weborca تحت record/). دليل على أنّ شجرة المصدر نفسها تدعم الشكلين، والمعرفة المستمدّة من قراءة المصدر تنطبق على الإصدار السحابي أيضاً. علماً أنّ إصدار .weborca فيه تعريفات ضُبطت فيها حدود مصفوفات الاستجابة وغيرها، لذا عند التحقّق من التفاصيل انظر أيضاً وجود تعريف WebORCA من عدمه.

9. الخلاصة ── النقاط التي ينبغي للمهندس تثبيتها

• ORCA (Nichi-Rece) ليس سجلاً طبيّاً إلكترونيّاً بل نظام فوترة مطالبات. يمسك العمود الفقري لبيانات المطالبات: المريض، التأمين، التشخيص، الإجراءات الطبيّة، النقاط، ومبيعات المؤسّسة الطبيّة تُطالَب عبره.
• الصعوبة الجوهريّة في نظام الفوترة هي مواصلة متابعة مراجعة أجور الرعاية كلّ سنتين لعقود. سجلّ تعديلات مصدر ORCA أصبح سجلّاً ميدانيّاً لذلك.
• نظام أعمال مفتوح المصدر ممتدّ من إعلان IT للجمعية عام 2001، ويُنشَر المصدر شهريّاً كـtarball. الترخيص ليس GPL بل عقد ترخيص المصادر المفتوحة للجمعية الطبية اليابانية.
• المتن 1,754 برنامجاً COBOL ونحو 4.06 مليون سطر + MONTSUQI + PostgreSQL بـ285 جدولاً (قياس سلسلة 5.2). بنية معالجة مركزيّة تُوجَّه فيها الشاشات وAPI بتعريف LD نفسه.
• الربط الخارجي مدخله الحالي Nichi-Rece API. انتهى دعم CLAIM في مارس 2026. انتقال WebORCA جارٍ، لكن الإصدار السحابي والمحلّي متنهما Nichi-Rece نفسه، والمعرفة من المصدر المنشور تنطبق على الحالتين.

في المرّة التالية سنقرأ هذه الشيفرة المنشورة فعليّاً، ونشرح طريقة فهم الصورة الكاملة لـNichi-Rece API من المصدر (أي عنوان URL يعالجه أيّ برنامج COBOL، وما هي نقاط النهاية غير الواردة في القائمة الرسميّة)، مع جدول مقابلة لجميع نقاط النهاية البالغ عددها 137.

10. المراجع

• ORCAとは - ORCA Project
• 技術情報 - 日医標準レセプトソフト - ORCA Project (نشر الشيفرة المصدرية، مواصفة API، وثائق تعريف الجداول)
• 日医標準レセプトソフトAPI - ORCA Project
• 日医標準レセプトソフト「ORCA」 - 日本医師会ORCA管理機構
• 日医標準レセプトソフト商用版について - 日本医師会ORCA管理機構
• WebORCAクラウド版 - ORCA Project
• 日医標準レセプトソフト［WebORCAクラウド版］- 日本医師会ORCA管理機構 (مسار الطلب، شكل التقديم، الرسوم)
• 日レセ運用環境移行手引き - ORCA Project (نطاق الانتقال إلى WebORCA المحلّي وإجراءاته)
• 日医標準レセプトソフト ご利用中の方へ - ORCA Project (مصدر نشر «جدول دعم حزم Nichi-Rece ونظام التشغيل»)
• مصدر متن Nichi-Rece سلسلة 5.2 (لقطة يوليو 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc وغيرها ── جميع القيم المقاسة في المتن مبنيّة على هذه اللقطة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل ORCA سجلّ طبيّ إلكتروني؟

لا. برمجية المطالبات القياسية للجمعية الطبية اليابانية (JMA Standard Receipt Software، واختصارها Nichi-Rece)، وهي محور مشروع ORCA، نظام فوترة مطالبات يتولّى مطالبات أجور الرعاية الطبية. السجلّ الطبيّ الإلكتروني الذي تُكتَب فيه السجلات السريرية برمجية أخرى، وتستخدمه مؤسّسات كثيرة مع ORCA عبر API. عبارة «السجلّ الإلكتروني ORCA» أدقّ ما تُفهم به أنّها اسم شائع وُلد لأنّه يُستخدم كثيراً إلى جانب السجلّ الطبيّ الإلكتروني.

هل يستطيع أيّ أحد قراءة الشيفرة المصدرية لـORCA (Nichi-Rece)؟

نعم. شيفرة JMA Standard Receipt Software نفسها منشورة بموجب عقد ترخيص المصادر المفتوحة للجمعية الطبية اليابانية (JMA OpenSource License)، وفي اليوم الأوّل من كلّ شهر يمكن تنزيل لقطة بتاريخ اليوم الأوّل من الشهر السابق على هيئة tarball. مستودع CVS السابق أُخفي مع بدء تقديم النسخة التجاريّة، لكن نشر المصدر نفسه مستمرّ.

بأيّ تقنيات بُني ORCA؟

الخادم يعمل على Linux، ومعظم منطق الأعمال مكتوب بـCOBOL. قاعدة البيانات PostgreSQL، ومنصّة تشغيل برامج الأعمال برمجية وسيطة مفتوحة المصدر تُسمّى MONTSUQI (panda)، والعميل غالباً monsiaj المكتوب بـJava. بعدّ مصدر سلسلة 5.2، COBOL وحده نحو 1,750 برنامجاً وأكثر من أربعة ملايين سطر، وقاعدة البيانات أكثر من 280 جدولاً.

كيف يرتبط السجلّ الطبيّ الإلكتروني بـORCA؟

التوصية الحاليّة هي Nichi-Rece API. يرسل نظام الربط، كالسجلّ الطبيّ الإلكتروني، طلبات HTTP لجلب معلومات المريض وتسجيل الإجراءات الطبية وغير ذلك. توجد أيضاً PushAPI يُخطر من خلالها Nichi-Rece بالأحداث إلى الخارج. الربط عبر CLAIM (مواصفة تبادل المعلومات الطبية)، الذي استُخدم طويلاً، انتهى دعمه في مارس 2026، لذا ينبغي تصميم أيّ ربط جديد على افتراض API.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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