ORCA (Nichi-Rece) אינה EMR — rececon וארכיטקטורת מערכות במוסד רפואי, מבט הנדסי

שמעתם את הביטוי “התיק הרפואי האלקטרוני ORCA”? השם עולה תמיד בפרויקטים של מערכות למוסדות רפואיים — אבל בניסוח יש טעות. ORCA (JMA Standard Receipt Software) אינה תיק רפואי אלקטרוני.

המאמר מיועד למהנדסים שפוגשים לראשונה פרויקט IT רפואי, והמטרה היא לענות על השאלות האלה.

• מהי ORCA, ואיפה היא יושבת בארכיטקטורת המערכות של מוסד רפואי
• מה “עבודת ה-receipt” ש-rececon מבצעת, כשמסתכלים על זה כמערכת
• באילו טכנולוגיות זה בנוי, ומה נמצא בקוד המקור שפורסם
• מה משתנה במעבר ל-WebORCA, ומה צד האינטגרציה צריך לשים לב אליו

הכל מבוסס על מקורות ראשוניים שפורסמו. מה שנאמר על קוד המקור הוא תוצאה של הורדה ובדיקה בפועל של מקור סדרת 5.2 של Nichi-Rece שפורסם רשמית (snapshot מ-1 ביולי 2026, קובץ VERSION מציין 5.2.0).

תוכן עניינים

1. קודם כל — ORCA היא “rececon”
2. מהי עבודת receipt — איך להבין את זה במהירות כמערכת
3. ארכיטקטורת המערכות במוסד רפואי — איפה יושבת ORCA
4. היסטוריה ורישיון של פרויקט ORCA
5. ה-stack — ספירה בפועל של 4 מיליון שורות COBOL
6. איך לנווט ב-source tree — מה נמצא איפה
7. נקודות הכניסה לאינטגרציה — Nichi-Rece API, PushAPI ו-CLAIM
8. מה משתנה במעבר ל-WebORCA
9. סיכום — מה מהנדס צריך לשים לב אליו
10. מקורות

knowledge map של המאמר

ORCA (Nichi-Rece) אינו תיק רפואי אלקטרוני אלא rececon שמחשב שכר טיפול ומייצר receipt, ומתחבר ל-EMR דרך Nichi-Rece API. הלוגיקה העסקית של Nichi-Rece כתובה ב-COBOL, רצה על תשתית הריצה MONTSUQI (panda) יחד עם לקוח Java בשם monsiaj ועם PostgreSQL, וגם מסכים וגם API עוברים dispatch לפי אותן הגדרות LD. נקודות הכניסה לאינטגרציה חיצונית הן בעיקר Nichi-Rece API ו-PushAPI שמפורסמים תחת JMA OpenSource License. CLAIM, שהיה בשימוש שנים, סיים תמיכה במרץ 2026, והמעבר ל-Nichi-Rece API הפך לתנאי. כרגע זו תקופת מעבר ל-WebORCA Cloud ול-WebORCA On-premises; סביבת ההפצה המסורתית (מהדורת MONTSUQI) מוחלפת בהדרגה, אבל בפנים זו אותה Nichi-Rece בשתי הצורות.

flowchart LR
    accTitle: knowledge map: ORCA (Nichi-Rece)
    accDescr: Diagram שמראה את חלוקת התפקידים בין ORCA (Nichi-Rece) כ-rececon לבין תיק רפואי אלקטרוני; את ה-stack של COBOL, MONTSUQI, PostgreSQL ו-monsiaj ואת ה-dispatch לפי הגדרות LD; את השינוי באמצעי האינטגרציה Nichi-Rece API, PushAPI ו-CLAIM; ואת יחסי המעבר ל-WebORCA Cloud ול-WebORCA On-premises.
    orca_nichirese["ORCA (Nichi-Rece)"]
    receipt_computer["rececon (receipt computer)"]
    receipt["receipt (פירוט שכר טיפול)"]
    electronic_medical_record["תיק רפואי אלקטרוני (EMR)"]
    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["JMA OpenSource License"]
    weborca_cloud["WebORCA Cloud"]
    weborca_onpremise["WebORCA On-premises"]
    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

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 19, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

1. קודם כל — ORCA היא “rececon”

“JMA Standard Receipt Software” (Nichi-Rece בקיצור), שנמצאת במרכז פרויקט ORCA, היא rececon (receipt computer / מערכת billing רפואי). rececon מחשבת שכר טיפול מתוך מה שבוצע קלינית, ומייצרת את ה-receipt (פירוט שכר טיפול) שמוגש לגופי הביקורת והתשלום.

לתיק רפואי אלקטרוני ול-rececon יש תפקידים מופרדים בבירור.

הכינוי “ה-EMR שנקרא ORCA” נוצר כי מוצרי EMR רבים נבנו במבנה “חלק ה-billing מתחבר ל-ORCA”. למהנדס, ברגע שמקבעים את ההבחנה ORCA = עמוד השדרה של צד התביעות, EMR = צד הרשומה הקלינית, כל מה שבא אחר כך מסתדר.

2. מהי עבודת receipt — איך להבין את זה במהירות כמערכת

הדרך המהירה להבין איזו מערכת היא rececon היא להבין איך נכנס כסף למוסד רפואי. בטיפול מבוטח ביפן, המטופל משלם בקבלה ככלל 10%–30%, ואת היתרה המוסד תובע מדי חודש מגופי הביקורת והתשלום (Social Insurance Medical Fee Payment Fund ו-National Health Insurance Organizations). מסמך התביעה הזה הוא ה-receipt.

כמערכת, rececon היא מכונה שמריצה את מחזור ה-batch החודשי הבא.

1. יומי: בקבלה מאמתים זכאות ביטוח, מזינים פעולות טיפול (ביקור, בדיקות, תרופות, פעולות…), ועושים חשבון לפי השתתפות עצמית שחושבה אוטומטית מלוח הנקודות.
2. חודשי: פעולות של חודש מרוכזות לפי מטופל × ביטוח, ומיוצר receipt. לפני הגשה רצים data check (עקביות בין אבחנה למרשם וכו’) ומגישים כ-electronic receipt (נתוני rece-den).
3. מהחודש הבא והלאה: מטפלים ב-henrei (תביעות שהוחזרו בביקורת) וב-satei (הפחתה בהערכה), מתקנים ותובעים מחדש.

הנקודה החשובה: כללי חישוב הנקודות משתנים בתיקון שכר הטיפול אחת לשנתיים. אם התוכנה לא עוקבת אחרי עדכון לוח הנקודות, מחירי תרופות וכללי החישוב, המוסד לא יכול לתבוע נכון. הקושי המהותי של rececon אינו UI ולא scale, אלא להמשיך את המעקב אחרי הרגולציה עשרות שנים. היסטוריית התיקונים שמופיעה במקור של ORCA, בהמשך, היא בדיוק התיעוד הזה.

3. ארכיטקטורת המערכות במוסד רפואי — איפה יושבת ORCA

במבנה טיפוסי של מרפאה, ORCA (Nichi-Rece) יושבת קרוב ל-hub של המערכות הפנימיות.

flowchart LR
    subgraph clinic["בתוך המוסד הרפואי"]
        EMR["תיק רפואי אלקטרוני<br/>רשומות קליניות ו-orders"]
        RSV["מערכת קבלה ותורים"]
        ONS["מסוף online eligibility"]
        ORCA["ORCA / Nichi-Rece<br/>rececon (תביעות שכר טיפול)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"אינטגרציית קבלה ותורים"| ORCA
        ONS -->|"נתוני זכאות ביטוח"| ORCA
    end
    ORCA -->|"receipt (תביעה חודשית)"| PAY["גופי ביקורת ותשלום<br/>Payment Fund / NHI"]

שלוש הנקודות הן אלה.

• במבנים רבים, מאסטר פרטי המטופל והביטוח יושב בצד ORCA. ה-EMR קורא ומעדכן ב-API. מי מחזיק את מספור מספר המטופל הוא אחת השאלות הראשונות בתכנון האינטגרציה.
• פעולות טיפול (מה בוצע) נשלחות מה-EMR ל-ORCA, ו-ORCA עושה חישוב נקודות ומחברת לחשבון ולתביעה. ה-EMR מתאר טיפול ב”שפת orders”, ORCA ב”שפת נקודות”, ולכן המיפוי (מיפוי קודי פעולות טיפול) הוא הקטע הקשה בפועל באינטגרציה.
• הגשת receipt חודשית היא עבודת ORCA. כלומר ההכנסות של המוסד עוברות בתביעה דרך ORCA. טעות אינטגרציה מופיעה לא כחסר ברשומה הקלינית אלא כסכום תביעה שגוי — זה המתח שמאפיין את התחום.

4. היסטוריה ורישיון של פרויקט ORCA

ORCA הוא פרויקט של Japan Medical Association (JMA). בהצהרת ה-IT של JMA בנובמבר 2001 נקבעה מדיניות לפרסם תוכנה ש-JMA מפתחת כקוד פתוח, ו-Nichi-Rece פותחה כמרכז של זה. שימוש בשטח התחיל ב-2002, והפיתוח נמשך יותר מ-20 שנה.

מנקודת מבט הנדסית, הבולט הוא שקוד מקור של מערכת עסקית ממשיך להיות מפורסם יותר מ-20 שנה.

• הרישיון הוא JMA OpenSource License version 1.0 שמצורף למקור. זה לא GPL אלא חוזה ייחודי של JMA: שימוש בתוכנית (כולל העתקה, עיבוד, הפצה ושידור לציבור) מותר באופן לא-בלעדי ובחינם, ובהפצת גרסה שעברה שינוי חובה להטיל את אותם תנאים — מבנה בסגנון copyleft. הדין החל הוא הדין היפני.
• בעבר מאגר CVS היה פומבי, אבל עם השקת המהדורה המסחרית ה-CVS הפך לפרטי, והיום ב-1 בכל חודש מתפרסם כ-tarball המקור נכון ל-1 בחודש הקודם. יעדי הפרסום הם שלושה רכיבים: הליבה, regional public expense, וטפסים ציבוריים; סדרות 5.0, 5.1 ו-5.2 מתפרסמות במקביל.
• גם מבנה הפיתוח והאספקה ייחודי. בהיסטוריית התיקונים במקור מופיעים בהתחלה שמות מהנדסים של NACL (ספק Custom Software Development), ומסביבות 2022 ה-commits עוברים לשם ORCAMO (Japan Medical Association ORCA Management Organization). שירותים נלווים (תמיכה, חבילות, מדריכים וכו’) מספקת ORCA Management Organization כמהדורה מסחרית, וההטמעה והתחזוקה בידי ספקי תמיכה מוסמכים ברחבי הארץ — מודל חלוקת עבודה.

כלומר ORCA היא תוכנה “בקוד פתוח, אבל לא פיתוח קהילה בסגנון GitHub”. אפשר לקרוא את המקור, אפשר לעשות fork, אבל הפיתוח הראשי מתקדם בידי גוף אחד כמו vendor. בתחום רפואי שבו טעויות לא מתקבלות ומעקב רגולטורי הוא חובה, זה נראה לי נקודת איזון סבירה.

5. ה-stack — ספירה בפועל של 4 מיליון שורות COBOL

מהפרק הזה שמות עצם מתרבים בבת אחת, ולכן קודם טבלת מונחים. כדאי להשאיר אותה בצד גם בפרקים הבאים.

ב-INSTALL.ja של מקור סדרת 5.2 שפורסם מופיעים כתוכנות נדרשות MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE ועוד. סיכום המבנה הוא זה.

מילים לבד לא מעבירות סדר גודל, ולכן הנה ספירה בפועל על snapshot סדרת 5.2 (אחרי פריסה כ-8,200 קבצים, 237MB).

שמות הטבלאות ישרים: אחרי שמתרגלים, רואים את העסק עצמו. השמות מערבבים קיצורי אנגלית עם romaji מיפנית, ולכן מחזירים את החלק היפני ל-kanji ואז המשמעות מתבהרת. העיקריות הן אלה.

חלוקת התפקידים מפרק 1 — מטופל, ביטוח, אבחנה, פעולת טיפול, נקודות — ממומשת כמו שהיא במבנה הטבלאות. מסמכי הגדרת הטבלאות מפורסמים באתר הרשמי, ואם קריאת השם מבלבלת אפשר לאמת שם את השם הרשמי.

המפתח בארכיטקטורה הוא MONTSUQI. בפנים של Nichi-Rece זה עיבוד מרכזי קלאסי: לקוח Java (monsiaj) מקבל הגדרות מסך מהשרת ומציג אותן, קלט מטופל בתוכניות COBOL בצד השרת, והן קוראות וכותבות PostgreSQL. איזה מסך ממופה לאיזו תוכנית COBOL כתוב באופן הצהרתי בקובצי הגדרות LD תחת lddef/.

flowchart LR
    CL["monsiaj<br/>לקוח Java"] -->|"פעולות מסך"| MW["MONTSUQI<br/>application server"]
    API["מערכת משלבת<br/>EMR וכו'"] -->|"Nichi-Rece API (HTTP)"| MW
    MW -->|"ניתוב לפי הגדרות lddef/*.ld"| AP["קבוצת תוכניות עסקיות<br/>כ-1,750 COBOL"]
    AP --> DB[("PostgreSQL<br/>285 טבלאות")]

מעניין שdispatch של מסכים ו-dispatch של API יושבים באותם קובצי הגדרות LD. כלומר Nichi-Rece API אינו שרת נפרד שנוסף אחר כך, אלא מימוש של “נקודת כניסה שמשוחחת ב-XML במקום מסך” על אותה פלטפורמת תוכניות עסקיות של המסך האינטראקטיבי. פירוט התכנון הזה בפרק ההמשך.

המבנה “COBOL + middleware ייעודי + PostgreSQL” נראה רחוק מתחושת פיתוח Web מודרני. אבל בכותרת של תוכנית COBOL אחת מופיעה בהערות היסטוריית תיקונים מ-2002, ואפשר לקרוא שאותו code base ממשיך לעקוב אחרי תיקוני רגולציה יותר מ-20 שנה, עד התאמות עדכניות כמו מרשם אלקטרוני (2022) ואימות זכאות של My Number insurance card (2024). המבנה הזה הוא גם תוצאה של אופטימיזציה ל”להמשיך לרוץ אחרי שהמערכת הבשילה”.

6. איך לנווט ב-source tree — מה נמצא איפה

כמפה לקריאה בפועל, הנה הספריות העיקריות ברמה העליונה.

הערה מעשית אחת. קידוד המקור הוא 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, אבל אינטגרציית CLAIM קיימת מניחה מעבר ל-API.

כלומר, מי שמתכנן עכשיו אינטגרציה ל-ORCA, Nichi-Rece API הוא הבחירה היחידה. וכפי שנגענו קודם, ה-API ממומש על אותה פלטפורמת תוכניות COBOL של המסך האינטראקטיבי, ולכן כש”ההתנהגות של ה-API לא ברורה” אפשר לרדת עד המקור. איך לקבל מהמקור את התמונה המלאה של ה-API (כולל endpoints שלא מופיעים ברשימה הרשמית) מוסבר ב-מאמר ההמשך.

8. מה משתנה במעבר ל-WebORCA

ORCA הנוכחית נמצאת בתקופת מעבר ל-“WebORCA”. צורות האספקה הן בעיקר שתיים.

• WebORCA Cloud — שימוש ב-Nichi-Rece כשירות ענן ש-ORCA Management Organization מספקת. המוסד משתחרר מניהול שרת. ההרשמה עוברת דרך ספק תמיכה מוסמך, ובהודעה הרשמית מצפים כ-3 שבועות מההרשמה עד תחילת השירות. בצד המוסד אין שרת פנימי; משתמשים מהדפדפן, וגם עדכוני תוכנית בעקבות תיקון שכר הטיפול רצים במרוכז בצד הענן. התמחור הוא תשלום חודשי למוסד.
• WebORCA On-premises — התקנה על שרת פנימי (Ubuntu). סביבת האספקה הנוכחית היא Nichi-Rece Ver5.2.0 על Ubuntu 22.04 (jammy).

לגבי ציר הזמן של המעבר, שתי נקודות שכדאי לשים לב אליהן.

הראשונה: יש מסלול מעבר רשמי. ORCA Project מפרסמת “מדריך מעבר סביבת ההפעלה של Nichi-Rece”, ומציינת במפורש כיעד את המעבר מ-Nichi-Rece 5.1.0 / 5.2.0 מהסוג המסורתי (מהדורת MONTSUQI) שרצה על Ubuntu 16.04 / 18.04 / 20.04 אל WebORCA On-premises (Ubuntu 22.04 + 5.2.0). הכיוון ההפוך, כלומר מעבר ל-OS נמוך יותר או לגרסת Nichi-Rece נמוכה יותר, אינו אפשרי.

השנייה: אין תאריך אחיד מפורסם בסגנון “כל המוסדות חייבים לעבור ל-WebORCA עד תאריך X”. מה שעובד בפועל כתאריך יעד הוא תאריך סוף התמיכה שמוגדר לכל צירוף של OS וחבילת Nichi-Rece. זה מפורסם כ”לוח התמיכה של חבילות Nichi-Rece ו-OS”, וגרסאות שקרובות לסיום מקבלות הודעה נפרדת. לצד שבונה מערכת משלבת, הדרך המעשית להבין את ציר הזמן אינה “מתי המעבר ל-WebORCA” אלא לאשר איזו גרסת Ubuntu ו-Nichi-Rece המוסד שמולו עובדים מריץ, ומה תאריך סוף התמיכה שלהן.

החשוב: בשני המקרים התוכן בפנים הוא אותה Nichi-Rece. התוכנה שרצה אינה הופכת לדבר אחר לפי צורת האספקה, וגם סוגי ה-API וההתנהגות משותפים ביסודם. ההבדל שמהנדס אינטגרציה צריך לשים לב אליו מתרכז סביב החיבור, לא סביב המימוש.

• הבדלי כניסה כמו קידומת /api בנתיב הבקשה במהדורת הענן, והגדרות חיבור ואימות שמשתנות לפי צורת האספקה. מפרט ה-API עצמו משותף.
• במהדורת הענן, המערכת המשלבת במוסד קוראת ל-API דרך האינטרנט, ולכן תכנון נתיב הרשת והתנהגות degraded בתקלה דורש יותר מחשבה מאשר במבנה on-prem.
• במקור שמתפרסם מדי חודש כלולות כמו שהן גם הגדרות ל-WebORCA (למשל קבצי .db.weborca תחת record/). זו הוכחה שאותו source tree תומך בשתי הצורות, והידע שנצבר מקריאת המקור תקף גם למהדורת הענן. במהדורת .weborca יש הגדרות שבהן למשל תקרת מערכים בתגובה מכוונת, ולכן כשבודקים פרטים כדאי לראות גם אם יש הגדרת WebORCA.

9. סיכום — מה מהנדס צריך לשים לב אליו

• ORCA (Nichi-Rece) אינה תיק רפואי אלקטרוני אלא rececon. היא מחזיקה את עמוד השדרה של נתוני צד התביעות — מטופל, ביטוח, אבחנה, פעולת טיפול, נקודות — וההכנסות של המוסד עוברות בתביעה דרך כאן.
• הקושי המהותי של rececon הוא להמשיך עשרות שנים את המעקב אחרי תיקון שכר הטיפול אחת לשנתיים. היסטוריית התיקונים במקור של ORCA היא התיעוד בפועל של זה.
• זו מערכת עסקית בקוד פתוח שנמשכת מהצהרת ה-IT של JMA ב-2001, והמקור מתפרסם מדי חודש כ-tarball. הרישיון אינו GPL אלא JMA OpenSource License.
• בפנים: 1,754 קבצי COBOL, כ-4.06 מיליון שורות + MONTSUQI + 285 טבלאות PostgreSQL (מדידת סדרת 5.2). ארכיטקטורת עיבוד מרכזי שבה גם מסכים וגם API עוברים dispatch באותן הגדרות LD.
• לאינטגרציה חיצונית Nichi-Rece API היא נקודת הכניסה הנוכחית. CLAIM סיים תמיכה במרץ 2026. מעבר WebORCA בעיצומו, אבל גם מהדורת הענן וגם on-prem הם אותה Nichi-Rece בפנים, והידע מהמקור שפורסם תקף לשניהם.

בפעם הבאה נקרא בפועל את קוד המקור שפורסם, ונסביר איך לקבל מהמקור את התמונה המלאה של Nichi-Rece API (איזה URL מטופל באיזו תוכנית COBOL, ואילו endpoints חסרים ברשימה הרשמית) — עם טבלת מיפוי של כל 137 ה-endpoints.

10. מקורות

• What Is ORCA - ORCA Project
• Technical Information - JMA Standard Receipt Software - ORCA Project (פרסום קוד מקור, מפרט API, מסמכי הגדרת טבלאות)
• JMA Standard Receipt Software API - ORCA Project
• JMA Standard Receipt Software “ORCA” - Japan Medical Association ORCA Management Organization
• About the Commercial Edition of the JMA Standard Receipt Software - Japan Medical Association ORCA Management Organization
• WebORCA Cloud Edition - ORCA Project
• JMA Standard Receipt Software [WebORCA Cloud Edition] - Japan Medical Association ORCA Management Organization (מסלול הרשמה, צורת אספקה, תמחור)
• Nichi-Rece Runtime Environment Migration Guide - ORCA Project (יעדי המעבר ל-WebORCA On-premises והצעדים)
• For Current Users of JMA Standard Receipt Software - ORCA Project (מקור הפרסום של “לוח התמיכה של חבילות Nichi-Rece ו-OS”)
• קוד מקור ליבת Nichi-Rece סדרת 5.2 (snapshot שפורסם ביולי 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc ועוד — כל המדידות בגוף המאמר מבוססות על ה-snapshot הזה

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם ORCA היא תיק רפואי אלקטרוני?

לא. JMA Standard Receipt Software (Nichi-Rece), שנמצאת במרכז פרויקט ORCA, היא מערכת billing רפואי (rececon) שאחראית על תביעות שכר טיפול (receipts). התיק הרפואי האלקטרוני שבו כותבים רשומות קליניות הוא תוכנה נפרדת, וברוב המוסדות הרפואיים מחברים EMR ל-ORCA דרך API. הביטוי "ה-EMR שנקרא ORCA" מדויק יותר ככינוי שנוצר כי ORCA משמשת לעיתים קרובות יחד עם EMR.

האם כל אחד יכול לקרוא את קוד המקור של ORCA (Nichi-Rece)?

כן. קוד המקור של JMA Standard Receipt Software עצמה מפורסם תחת JMA OpenSource License, וב-1 בכל חודש אפשר להוריד כ-tarball snapshot נכון ל-1 בחודש הקודם. מאגר ה-CVS הישן הפך לפרטי עם השקת המהדורה המסחרית, אבל פרסום המקור עצמו נמשך.

באילו טכנולוגיות בנויה ORCA?

השרת רץ על Linux, ורוב הלוגיקה העסקית כתובה ב-COBOL. מסד הנתונים הוא PostgreSQL, פלטפורמת ההרצה לתוכניות העסקיות היא middleware בקוד פתוח בשם MONTSUQI (panda), ובצד הלקוח משמשים בין השאר monsiaj שנכתב ב-Java. בספירה של מקור סדרת 5.2, COBOL לבדו הוא כ-1,750 תוכניות ויותר מ-4 מיליון שורות, עם יותר מ-280 טבלאות במסד.

איך תיק רפואי אלקטרוני מתחבר ל-ORCA?

ההמלצה הנוכחית היא Nichi-Rece API. מערכת משלבת כמו EMR שולחת בקשות HTTP, לשליפת פרטי מטופל, רישום פעולות טיפול ועוד. יש גם PushAPI שבו Nichi-Rece מודיעה על אירועים החוצה. אינטגרציה ב-CLAIM (תקן להחלפת מידע רפואי), שהייתה בשימוש שנים, הגיעה לסוף תמיכה במרץ 2026, ולכן אינטגרציה חדשה צריך לתכנן מתוך הנחה של API.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.