ORCA (Nichi-Rece) EMR नहीं है — engineer की नज़र से rececon और hospital IT architecture

“EMR वाला ORCA” — यह वाक्य सुना है? Hospital systems के projects पर यह नाम ज़रूर आता है, लेकिन इसमें misconception है। ORCA (JMA Standard Receipt Software) EMR नहीं है।

यह लेख healthcare IT के काम से पहली बार मिलने वाले engineers के लिए है, और इन सवालों का जवाब देना चाहता है।

• ORCA क्या है, और hospital की system architecture में कहाँ बैठता है
• Rececon जो “receipt work” करता है, system की नज़र से वह क्या कर रहा है
• किन technologies पर बना है, और published source में क्या है
• WebORCA migration पर क्या बदलता है, और integrating side को क्या पकड़ना चाहिए

यहाँ सब published primary sources पर है। Source code वाली बातें officially published Nichi-Rece 5.2 series source (1 July 2026 का snapshot, VERSION file में 5.2.0) download करके देखने का नतीजा हैं।

विषय सूची

1. निष्कर्ष पहले — ORCA एक “rececon” है
2. Receipt work क्या है — system की नज़र से सबसे छोटा रास्ता
3. Hospital की system architecture — ORCA कहाँ है
4. ORCA project का इतिहास और license
5. Technology stack — COBOL के 4 million lines का अंदरूनी हिस्सा वास्तव में गिनना
6. Source tree कैसे घूमें — कहाँ क्या है
7. Integration के entry points — Nichi-Rece API, PushAPI, CLAIM
8. WebORCA migration पर क्या बदलता है
9. सारांश — engineers को क्या पकड़ना चाहिए
10. संदर्भ

इस लेख का knowledge map

ORCA (Nichi-Rece) EMR नहीं, medical fees calculate करने और receipt बनाने वाला rececon है, और EMR से Nichi-Rece API से जुड़ता है। Nichi-Rece की business logic COBOL में है, MONTSUQI (panda) execution platform पर Java client monsiaj और PostgreSQL के साथ चलती है, screens और API दोनों एक ही LD definition से dispatch होते हैं। External integration का entry point JMA OpenSource License के तहत प्रकाशित Nichi-Rece API और PushAPI हैं; लंबे समय चला CLAIM March 2026 में support end हो गया और Nichi-Rece API पर migrate करना अब आधार रह गया है। अभी WebORCA cloud edition और on-premises edition की migration period है, legacy (MONTSUQI edition) deployment से चरणबद्ध replacement चल रहा है, लेकिन अंदर दोनों वही Nichi-Rece हैं।

flowchart LR
    accTitle: ORCA (Nichi-Rece) का knowledge map
    accDescr: ORCA (Nichi-Rece) rececon के रूप में EMR से roles बाँटता है; COBOL, MONTSUQI, PostgreSQL, monsiaj का technology stack और LD definition से dispatch; Nichi-Rece API, PushAPI, CLAIM जैसे integration के तरीकों का बदलाव; WebORCA cloud edition और on-premises edition पर migration — ये relations दिखाने वाला diagram
    orca_nichirese["ORCA (Nichi-Rece)"]
    receipt_computer["rececon (receipt computer)"]
    receipt["receipt (medical fee statement)"]
    electronic_medical_record["EMR (electronic medical record)"]
    orca_api["Nichi-Rece API"]
    cobol["COBOL"]
    montsuqi["MONTSUQI"]
    postgresql["PostgreSQL"]
    monsiaj["monsiaj"]
    ld_definition["LD definition"]
    push_api["PushAPI"]
    claim_protocol["CLAIM (medical information exchange protocol)"]
    jma_opensource_license["JMA OpenSource License"]
    weborca_cloud["WebORCA cloud edition"]
    weborca_onpremise["WebORCA on-premises edition"]
    legacy_nichirese_deployment["legacy (MONTSUQI edition) deployment"]
    orca_nichirese -->|"implement करता है"| receipt_computer
    receipt -->|"require करता है"| receipt_computer
    electronic_medical_record -.->|"use करता है"| orca_api
    orca_nichirese -->|"use करता है"| cobol
    orca_nichirese -->|"use करता है"| montsuqi
    orca_nichirese -->|"use करता है"| postgresql
    orca_nichirese -->|"use करता है"| monsiaj
    montsuqi -->|"से configure"| ld_definition
    orca_api -->|"से configure"| ld_definition
    orca_api -->|"require करता है"| montsuqi
    monsiaj -->|"require करता है"| montsuqi
    orca_nichirese -->|"use करता है"| orca_api
    orca_nichirese -->|"use करता है"| push_api
    orca_api -->|"का successor"| claim_protocol
    orca_nichirese -.->|"require करता है"| jma_opensource_license
    weborca_cloud -->|"implement करता है"| orca_nichirese
    weborca_onpremise -->|"implement करता है"| orca_nichirese
    weborca_onpremise -->|"का successor"| legacy_nichirese_deployment
    legacy_nichirese_deployment -->|"use करता है"| montsuqi

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 19, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

1. निष्कर्ष पहले — ORCA एक “rececon” है

ORCA project के केंद्र में “JMA Standard Receipt Software” (छोटा नाम Nichi-Rece) है, और यह एक rececon (receipt computer / medical billing system) है। Rececon clinic में जो हुआ उससे medical fees calculate करता है, और claims review & payment organizations को submit करने वाला receipt (medical fee statement) बनाता है।

EMR और rececon की भूमिकाएँ साफ़ बँटी हैं।

“EMR वाला ORCA” यह nickname इसलिए बना क्योंकि बहुत से EMR products ने “billing हिस्सा ORCA से जुड़े” वाली architecture ली। Engineer के लिए शुरुआत में यह भेद पकड़ लो: ORCA = claims-side backbone, EMR = clinical-record side। इसके बाद सब बातें बैठती हैं।

2. Receipt work क्या है — system की नज़र से सबसे छोटा रास्ता

Rececon किस तरह का system है, यह समझने का तेज़ रास्ता hospital की आय का प्रवाह देखना है। जापान के insured care में patient counter पर नियम से 10–30% देता है, और बाकी hospital claims review & payment organizations (Social Insurance Medical Fee Payment Fund और National Health Insurance Federation) से महीने के हिसाब से claim करता है। यही claim document receipt है।

System की नज़र से rececon यह monthly batch cycle घुमाने वाली मशीन है।

1. Daily: Reception पर insurance eligibility check, procedures (consult, tests, meds, treatments…) enter, fee schedule से automatically निकले counter copay पर accounting।
2. Monthly: एक महीने के procedures को patient × insurance इकाई पर aggregate कर receipt बनाना। Submit से पहले data check (diagnoses और prescriptions की consistency आदि), फिर electronic receipt (rece-den data) के रूप में submit।
3. अगले महीने और आगे: Review में लौटे “henrei” (returned claims) और घटे “satei” (assessment reductions) सँभालना, सुधार कर फिर से claim।

यहाँ महत्वपूर्ण: fee-point calculation के नियम हर दो साल की medical fee revision से बदलते हैं। Fee-point master, drug prices, calculation rules के पीछे software न चले तो hospital सही claim नहीं कर सकता। Rececon software की असली कठिनाई UI नहीं, scale नहीं — दशकों तक इस regulation को follow करते रहना है। आगे ORCA source में लिखी revision history ठीक वही रिकॉर्ड है।

3. Hospital की system architecture — ORCA कहाँ है

Clinic की typical architecture खींचें तो ORCA (Nichi-Rece) in-house systems के hub के पास बैठता है।

flowchart LR
    subgraph clinic["Hospital / clinic के अंदर"]
        EMR["EMR<br/>clinical records · orders"]
        RSV["Reception / appointment system"]
        ONS["Online eligibility verification terminal"]
        ORCA["ORCA / Nichi-Rece<br/>rececon (medical fee claims)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"reception / appointment integration"| ORCA
        ONS -->|"insurance eligibility information"| ORCA
    end
    ORCA -->|"receipt (monthly claim)"| PAY["Claims review & payment org<br/>Payment Fund · NHI Federation"]

तीन बिंदु:

• Patient master और insurance master अक्सर ORCA side रखता है। EMR API से read/update करता है। Patient number कौन assign करे, यह integration design का पहला सवाल बनता है।
• Procedures (क्या हुआ) EMR से ORCA जाते हैं, ORCA fee-point calculation कर billing और claims से जोड़ता है। EMR “orders की भाषा” में लिखता है, ORCA “fee points की भाषा” में — यह mapping (procedure codes) integration का practically सबसे भारी हिस्सा है।
• Monthly receipt submit ORCA का काम है। मतलब hospital की आय ORCA से होकर claim होती है। Integration की गलती clinical record के गायब होने के रूप में नहीं, गलत claim amount के रूप में दिखती है — यही इस domain का tension है।

4. ORCA project का इतिहास और license

ORCA Japan Medical Association (JMA) का project है। November 2001 के “JMA IT Declaration” में JMA जो software बनाए उसे open source प्रकाशित करने की नीति आई, और उसके केंद्र में Nichi-Rece बना। 2002 से clinics में उपयोग शुरू हुआ, और तब से 20+ साल development चल रहा है।

Engineer की नज़र से खास बात: line-of-business system का source 20+ साल लगातार प्रकाशित है।

• License source के साथ बंडल JMA OpenSource License version 1.0 है। GPL नहीं, JMA का अपना समझौता: program का use (reproduction, adaptation, distribution, public transmission सहित) non-exclusive और royalty-free permitted है, और modified version बाँटते समय वही शर्तें लगानी पड़ती हैं — copyleft जैसी structure। Governing law जापानी कानून है।
• पहले CVS repository public था, commercial edition शुरू होने पर CVS private हो गया। अब हर महीने की 1 तारीख को पिछले महीने की 1 तारीख का source tarball प्रकाशित होता है। प्रकाशित तीन components हैं — मुख्य product, regional public-expense support, public forms — और 5.0, 5.1, 5.2 series समानांतर प्रकाशित हैं।
• Development और delivery भी अलग हैं। Source की revision history पढ़ो तो शुरुआत में NACL (development contractor) के engineer नाम हैं, 2022 के आसपास से ORCAMO (Japan Medical Association ORCA Management Organization) नाम के commits आते हैं। Support, packaging, manuals जैसी आसपास की services commercial edition के रूप में ORCA Management Organization देती है, rollout और maintenance देश भर के certified support providers करते हैं — यही division of labour है।

मतलब ORCA “open source है, लेकिन GitHub-style community development नहीं” वाला software है। Source पढ़ सकते हो, fork भी, लेकिन mainline एक ही organization vendor की तरह चलाता है। Healthcare जैसे क्षेत्र में जहाँ गलती स्वीकार्य नहीं और regulation follow करना अनिवार्य है, यह एक reasonable trade-off लगता है।

5. Technology stack — COBOL के 4 million lines का अंदरूनी हिस्सा वास्तव में गिनना

इस chapter से proper nouns अचानक बढ़ जाते हैं, इसलिए पहले glossary। आगे के chapters भी इस table को साथ रखकर पढ़ो।

Published 5.2 series source के INSTALL.ja में ज़रूरी software के रूप में MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE आदि हैं। Architecture सार में ऐसी है।

शब्दों से पैमाना नहीं आता, इसलिए 5.2 series snapshot (extract के बाद लगभग 8,200 files, 237 MB) वास्तव में गिनने का नतीजा:

Database table नाम सीधे हैं, पढ़ने की आदत पड़ते ही business दिखने लगता है। Naming “English abbreviations” और “Japanese romaji” मिला है, इसलिए जापानी हिस्से को kanji में लौटाओ तो मतलब बैठता है। मुख्य कुछ:

Chapter 1 का role split — patient, insurance, diagnoses, procedures, fee points — table structure के रूप में ज्यों का त्यों implement है। Table definition docs official site पर हैं, पढ़ने में उलझन हो तो वहाँ formal नाम confirm करो।

Architecture की कुंजी MONTSUQI है। Nichi-Rece internally एक classic centralized-processing system है: Java client (monsiaj) server से screen definitions लेकर दिखाता है, input server-side COBOL programs सँभालते हैं, वे PostgreSQL read/write करते हैं। कौन सी screen किस COBOL program से जुड़ी है, यह lddef/ की LD definition files में declarative लिखा है।

flowchart LR
    CL["monsiaj<br/>Java client"] -->|"screen operations"| MW["MONTSUQI<br/>application server"]
    API["Integrating system<br/>EMR आदि"] -->|"Nichi-Rece API (HTTP)"| MW
    MW -->|"lddef/*.ld definitions से dispatch"| AP["Business programs<br/>COBOL ~1,750"]
    AP --> DB[("PostgreSQL<br/>285 tables")]

दिलचस्प बात: screen का dispatch और API का dispatch एक ही LD definition file में साथ रहते हैं। मतलब Nichi-Rece API बाद में जोड़ा गया अलग server नहीं; interactive screens वाले उसी business-program platform पर “screen की जगह XML से बात करने वाला entry point” जोड़कर बना है। इस design का विस्तार अगले लेख में है।

“COBOL + dedicated middleware + PostgreSQL” modern web development की आदत से दूर दिखता है। फिर भी एक COBOL program के header में 2002 से revision history comments में खुदी है, electronic prescriptions (2022) और My Number health insurance card eligibility (2024) जैसी हाल की regulation तक — वही codebase 20+ साल revisions follow कर रहा है यह पढ़ा जा सकता है। यह architecture “mature stack पर लंबे समय चलते रहना” पर optimize होने का नतीजा भी है।

6. Source tree कैसे घूमें — कहाँ क्या है

Source वास्तव में पढ़ते समय के map के रूप में top-level के मुख्य directories:

एक practical सावधानी। Source का character encoding EUC-JP है (license document ISO-2022-JP)। आधुनिक editor में खोलो तो mojibake आता है, इसलिए iconv -f EUC-JP -t UTF-8 से पढ़ना पड़ता है। 2002 के Linux environment का standard ज्यों का त्यों बचा हुआ time capsule है।

7. Integration के entry points — Nichi-Rece API, PushAPI, CLAIM

External system के engineer जब ORCA छूते हैं, entry points व्यवहार में ये तीन हैं।

1. Nichi-Rece API — आज की recommendation। Integrating system HTTP से request भेजकर patient information, reception, procedure registration आदि करता है। Read APIs GET या POST+XML, update APIs basically POST+XML। Official site पर API spec प्रकाशित है।
2. PushAPI — Nichi-Rece तरफ़ हुए events (form print instructions आदि) integrating system को notify करने का तंत्र। Polling नहीं, event-driven screen coordination बन सकती है।
3. CLAIM — medical information exchange के standard protocol के रूप में लंबे समय चला, लेकिन March 2026 में end of support। Source में CLAIM-related processing अभी है, लेकिन मौजूदा CLAIM integrations के लिए API पर migrate करना अब आधार रह गया है।

मतलब अब ORCA integration design करो तो Nichi-Rece API ही एकमात्र विकल्प है। और जैसा ऊपर कहा, API interactive screens वाले उसी COBOL business-program platform पर बना है, इसलिए “API का व्यवहार समझ नहीं आ रहा” हो तो source तक उतरकर देख सकते हो। API का पूरा चित्र (official list में न दिखने वाले endpoints सहित) source से कैसे निकालें, यह अगले लेख में है।

8. WebORCA migration पर क्या बदलता है

आज ORCA “WebORCA” की ओर transition में है। Delivery रूप मुख्यतः दो हैं।

• WebORCA cloud edition — ORCA Management Organization के cloud service के रूप में Nichi-Rece चलाना। Hospital server administration से मुक्त होता है। Apply करना certified support provider के through होता है, official guidance में apply से service start तक लगभग 3 weeks बताए गए हैं। Hospital side clinic में server नहीं रखता, browser से उपयोग करता है, medical fee revision के program updates भी cloud side एक साथ होते हैं। Fee प्रति hospital monthly है।
• WebORCA on-premises edition — in-house server (Ubuntu) पर install कर चलाना। मौजूदा delivery Ubuntu 22.04 (jammy) पर Nichi-Rece Ver5.2.0 है।

Migration की timeline पर दो बातें पकड़नी हैं।

एक, migration का रास्ता officially तैयार है। ORCA Project “Nichi-Rece runtime environment migration guide” प्रकाशित करता है, और Ubuntu 16.04 / 18.04 / 20.04 पर चलने वाले legacy (MONTSUQI edition) Nichi-Rece 5.1.0 / 5.2.0 से WebORCA on-premises (Ubuntu 22.04 + 5.2.0) पर जाने की प्रक्रिया स्पष्ट लक्षित है। उलटी दिशा, यानी older OS या older Nichi-Rece version पर जाना, संभव नहीं।

दूसरी, “सभी hospitals इस तारीख तक WebORCA पर जाएँ” जैसा एक समान deadline प्रकाशित नहीं है। Practice में जो deadline actually लागू होता है वह OS और Nichi-Rece package के combination पर तय support end date है, यह “Nichi-Rece package and OS support schedule” के रूप में प्रकाशित होता है, और अंत के नज़दीक versions अलग से announce होते हैं। Integrating system बनाने वाले के लिए सवाल “WebORCA कब?” नहीं, जिस hospital से integrate कर रहे हो उसका Ubuntu और Nichi-Rece version, और उसका support end date देखना timeline पकड़ने का practical तरीका है।

महत्वपूर्ण: दोनों के अंदर वही Nichi-Rece है। चल रहा software delivery रूप से अलग उत्पाद नहीं बन जाता; API के प्रकार और व्यवहार मूलतः आम हैं। Integrating engineer को जो अंतर पकड़ना है, वह implementation नहीं, connection setup के आसपास सीमित है।

• Entry-point अंतर जैसे cloud edition API request path पर /api prefix, connection और authentication settings delivery रूप के हिसाब से अलग। API spec स्वयं आम है।
• Cloud edition में in-house integrating system internet के पार API call करता है, इसलिए network path और outage पर degraded-mode का design on-premises से ज़्यादा सोच माँगता है।
• हर महीने प्रकाशित source में WebORCA वाली definitions भी ज्यों की त्यों शामिल हैं (उदाहरण: record/ के नीचे .db.weborca files)। एक ही source tree दोनों रूप सँभालता है, इसका सबूत; source पढ़कर मिला ज्ञान cloud edition पर भी चलता है। ध्यान दें, .weborca edition में response array limits आदि adjust हैं, इसलिए बारीकी देखते समय WebORCA-specific definition है या नहीं, यह भी देखो।

9. सारांश — engineers को क्या पकड़ना चाहिए

• ORCA (Nichi-Rece) EMR नहीं, rececon है। Patient, insurance, diagnoses, procedures, fee points — claims-side data का backbone यहीं है, और hospital की आय यहीं से होकर claim होती है।
• Rececon की असली कठिनाई हर दो साल की medical fee revision को दशकों तक follow करते रहना है। ORCA source की revision history उसी की documentary record है।
• 2001 के JMA IT Declaration से चला open-source line-of-business system, source हर महीने tarball। License GPL नहीं, JMA OpenSource License।
• अंदर COBOL 1,754 programs · लगभग 4.06 million lines + MONTSUQI + PostgreSQL 285 tables (5.2 series measurement)। Screens और APIs एक ही LD definition से dispatch होने वाली centralized-processing architecture।
• External integration का आज का entry point Nichi-Rece API है। CLAIM March 2026 में end of support पर पहुँचा। WebORCA migration चल रहा है, लेकिन cloud और on-premises दोनों के अंदर वही Nichi-Rece है, published source से मिला ज्ञान दोनों पर चलता है।

अगली बार हम यह published source वास्तव में पढ़ेंगे, और Nichi-Rece API का पूरा चित्र (कौन सा URL कौन सा COBOL program सँभालता है, official list में कौन से endpoints नहीं हैं) source से कैसे निकालें — सभी 137 endpoints की mapping table के साथ समझाएँगे।

10. संदर्भ

• What is ORCA - ORCA Project
• Technical information - JMA Standard Receipt Software - ORCA Project (source code release, API spec, table definition docs)
• JMA Standard Receipt Software API - ORCA Project
• JMA Standard Receipt Software “ORCA” - Japan Medical Association ORCA Management Organization
• About the commercial edition of 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 (apply का रास्ता, delivery रूप, fee)
• Nichi-Rece runtime environment migration guide - ORCA Project (WebORCA on-premises पर migration का लक्ष्य और प्रक्रिया)
• JMA Standard Receipt Software, for current users - ORCA Project (“Nichi-Rece package and OS support schedule” कहाँ प्रकाशित है)
• Nichi-Rece 5.2 series source (July 2026 published snapshot) INSTALL.ja / doc/license.html / lddef/orcadb.inc आदि — लेख की measured values इसी snapshot पर हैं

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

क्या ORCA एक electronic medical record (EMR) है?

नहीं। ORCA project के केंद्र में JMA Standard Receipt Software (Nichi-Rece) है — medical fee claims (receipts) सँभालने वाला rececon। Clinical notes लिखने वाला EMR अलग software है, और बहुत से hospitals EMR को ORCA से API के ज़रिए जोड़कर चलाते हैं। "EMR वाला ORCA" यह nickname इसलिए बना क्योंकि ORCA अक्सर EMR के साथ जुड़कर चलता है — यही सही समझ है।

ORCA (Nichi-Rece) का source code कोई भी पढ़ सकता है?

हाँ। JMA Standard Receipt Software के source JMA OpenSource License के तहत प्रकाशित हैं, और हर महीने की 1 तारीख को पिछले महीने की 1 तारीख का snapshot tarball के रूप में download होता है। पुराना CVS repository commercial edition शुरू होने पर private हो गया, लेकिन source प्रकाशित होना जारी है।

ORCA किन technologies पर बना है?

Server Linux पर चलता है, business logic का बड़ा हिस्सा COBOL में है। Database PostgreSQL है, business programs का execution platform open-source middleware MONTSUQI (panda) है, client की तरफ़ Java का monsiaj आदि। 5.2 series source गिनें तो COBOL अकेले लगभग 1,750 programs और 4 million lines से ऊपर, database 280 से अधिक tables — यही पैमाना है।

EMR और ORCA कैसे integrate होते हैं?

आज की recommendation Nichi-Rece API है। EMR जैसे integrating system HTTP से request भेजकर patient information लाते हैं, procedures register करते हैं। Nichi-Rece तरफ़ से events notify करने वाला PushAPI भी है। लंबे समय से चला CLAIM (medical information exchange protocol) March 2026 में support end हो चुका है, इसलिए अब बनने वाली integration API मानकर design करो।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।