ORCA (Nichi-Rece) ไม่ใช่เวชระเบียนอิเล็กทรอนิกส์ — มุมมองวิศวกรต่อ rececon และสถาปัตยกรรมระบบ IT ทางการแพทย์

เคยได้ยินคำว่า «เวชระเบียนอิเล็กทรอนิกส์ ORCA» หรือไม่ ชื่อนี้โผล่ทุกครั้งที่เข้าไปเกี่ยวข้องกับงานระบบของสถานพยาบาล แต่คำเรียกนี้มีความเข้าใจผิดปนอยู่ ORCA (JMA Standard Receipt Software) ไม่ใช่เวชระเบียนอิเล็กทรอนิกส์

บทความนี้มุ่งตอบคำถามต่อไปนี้ให้วิศวกรที่เพิ่งเข้ามาเกี่ยวข้องกับงาน IT ทางการแพทย์ครั้งแรก

• ORCA คืออะไร และอยู่ตรงไหนในสถาปัตยกรรมระบบของสถานพยาบาล
• «งาน receipt (ใบเคลม)» ที่ rececon รับผิดชอบ เมื่อมองเป็นระบบแล้วทำอะไรอยู่
• สร้างด้วยเทคโนโลยีอะไร และซอร์สที่เปิดอยู่มีอะไรอยู่ข้างใน
• การย้ายไป WebORCA เปลี่ยนอะไร และฝั่งที่เชื่อมควรจับอะไรไว้

ข้อความทั้งหมดอิงข้อมูลปฐมภูมิที่เปิดเผย คำบรรยายเรื่องซอร์สโค้ดเป็นผลจากการดาวน์โหลดและตรวจซอร์สตัวจริงของ Nichi-Rece สาย 5.2 (สแนปช็อตที่เปิดเมื่อ 1 กรกฎาคม 2026 ไฟล์ VERSION ระบุ 5.2.0) ที่ทางการเปิดเผย

สารบัญ

1. สรุปก่อนเลย — ORCA คือ «rececon»
2. งาน receipt (ใบเคลม) คืออะไร — ทางลัดที่สั้นที่สุดในมุมระบบ
3. แผนภาพสถาปัตยกรรมระบบของสถานพยาบาล — ORCA อยู่ตรงไหน
4. ประวัติและไลเซนส์ของโครงการ ORCA
5. สแต็กเทคโนโลยี — นับจริงเนื้อใน COBOL 4 ล้านบรรทัด
6. วิธีเดินต้นไม้ซอร์ส — อะไรอยู่ที่ไหน
7. ทางเข้าของการเชื่อม — Nichi-Rece API, PushAPI, CLAIM
8. การย้ายไป WebORCA เปลี่ยนอะไร
9. สรุป — จุดที่วิศวกรควรจับไว้
10. อ้างอิง

แผนที่ความรู้ของบทความนี้

ORCA (Nichi-Rece) ไม่ใช่เวชระเบียนอิเล็กทรอนิกส์ แต่เป็น rececon ที่คำนวณค่ารักษาและสร้าง receipt และเชื่อมกับเวชระเบียนอิเล็กทรอนิกส์ผ่าน Nichi-Rece API ตรรกะธุรกิจของ Nichi-Rece เขียนด้วย COBOL รันบนแพลตฟอร์ม MONTSUQI (panda) คู่กับไคลเอนต์ Java ชื่อ monsiaj และ PostgreSQL ทั้งหน้าจอและ API ถูก dispatch ด้วยนิยาม LD ชุดเดียวกัน จุดเข้าเชื่อมภายนอกหลักคือ Nichi-Rece API กับ PushAPI ที่เปิดภายใต้สัญญาอนุญาตใช้โอเพนซอร์สของสมาคมแพทย์ญี่ปุ่น CLAIM ที่ใช้มานานสิ้นสุดการสนับสนุนในเดือนมีนาคม 2026 จึงถือว่าต้องย้ายไป Nichi-Rece API ตอนนี้อยู่ช่วงย้ายไป WebORCA รุ่นคลาวด์และรุ่น on-prem แทนที่สภาพแวดล้อมจัดส่งแบบเดิม (รุ่น MONTSUQI) เป็นขั้น ๆ แต่ข้างในทั้งสองแบบเป็น Nichi-Rece ตัวเดียวกัน

flowchart LR
    accTitle: แผนที่ความรู้ของ ORCA (Nichi-Rece)
    accDescr: แผนภาพที่แสดงว่า ORCA (Nichi-Rece) เป็น rececon ที่แบ่งหน้าที่กับเวชระเบียนอิเล็กทรอนิกส์, สแต็ก COBOL, MONTSUQI, PostgreSQL, monsiaj และการ dispatch ด้วยนิยาม LD, วิวัฒนาการของช่องทางเชื่อม Nichi-Rece API, PushAPI, CLAIM และการย้ายไป WebORCA รุ่นคลาวด์กับรุ่น on-prem
    orca_nichirese["ORCA (Nichi-Rece)"]
    receipt_computer["rececon (ระบบเรียกเก็บค่ารักษา)"]
    receipt["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 รุ่น on-prem"]
    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 คือ «rececon»

แกนของโครงการ ORCA คือ «JMA Standard Receipt Software» (ย่อว่า Nichi-Rece) ซึ่งเป็น rececon (คอมพิวเตอร์ใบเคลม / ระบบเรียกเก็บค่ารักษา) rececon คือระบบธุรกิจที่คำนวณค่ารักษาจากรายการที่ให้บริการ แล้วสร้าง receipt (ใบเคลมค่ารักษา) เพื่อยื่นต่อหน่วยงานตรวจสอบและจ่ายเงิน

เวชระเบียนอิเล็กทรอนิกส์กับ rececon แยกหน้าที่ชัด

ชื่อเล่น «เวชระเบียนอิเล็กทรอนิกส์ ORCA» เกิดเพราะผลิตภัณฑ์เวชระเบียนอิเล็กทรอนิกส์จำนวนมากใช้โครง «ส่วนเรียกเก็บเงินเชื่อมกับ ORCA» ในฐานะวิศวกร ถ้าจับความต่าง ORCA = แกนฝั่งเรียกเก็บเงิน, เวชระเบียนอิเล็กทรอนิกส์ = ฝั่งบันทึกการรักษา ไว้ตั้งแต่ต้น เรื่องถัดไปจะจัดเรียงง่ายขึ้นทั้งหมด

2. งาน receipt (ใบเคลม) คืออะไร — ทางลัดที่สั้นที่สุดในมุมระบบ

ทางเร็วที่สุดที่จะเข้าใจว่า rececon เป็นระบบแบบใด คือรู้กระแสรายได้ของสถานพยาบาล ในการรักษาภายใต้ประกันของญี่ปุ่น ผู้ป่วยจ่ายที่เคาน์เตอร์โดยหลัก 10–30% ส่วนที่เหลือสถานพยาบาลเรียกเก็บเป็นรายเดือนจากหน่วยงานตรวจสอบและจ่ายเงิน (Social Insurance Medical Fee Payment Fund และ National Health Insurance Organizations) เอกสารเรียกเก็บนั้นคือ receipt (ใบเคลม)

มองเป็นระบบ rececon คือเครื่องที่หมุนรอบแบตช์รายเดือนต่อไปนี้

1. รายวัน: ที่เคาน์เตอร์รับ ตรวจสิทธิ์ประกัน ลงรายการรักษา (ตรวจ ตรวจแล็บ จ่ายยา หัตถการ …) แล้วคิดเงินที่เคาน์เตอร์ด้วยยอดที่คำนวณอัตโนมัติจากตารางคะแนนค่ารักษา
2. รายเดือน: รวมรายการรักษาของหนึ่งเดือนต่อหน่วยผู้ป่วย × ประกัน แล้วสร้างใบเคลม ก่อนยื่น มีการตรวจข้อมูล (ความสอดคล้องของชื่อโรคกับใบสั่งยา เป็นต้น) แล้วยื่นเป็นใบเคลมอิเล็กทรอนิกส์ (ข้อมูล rece-den)
3. เดือนถัดไปเป็นต้นไป: จัดการใบเคลมที่ถูกส่งคืนจากงานตรวจสอบ («henrei» / ส่งคืน) และใบที่ถูกตัดยอด («satei» / ลดคะแนน) แก้แล้วเรียกเก็บใหม่

จุดสำคัญตรงนี้คือ กฎการคำนวณคะแนนเปลี่ยนทุกครั้งที่มีการปรับค่ารักษาสองปีครั้ง ถ้าซอฟต์แวร์ตามมาสเตอร์คะแนน ราคายา และกฎการคิดไม่ทัน สถานพยาบาลเรียกเก็บได้ไม่ถูกต้อง ความยากแท้ของซอฟต์แวร์ rececon ไม่ได้อยู่ที่ UI หรือสเกล แต่อยู่ที่ การตามระบบกฎเกณฑ์นี้ต่อเนื่องหลายสิบปี ประวัติแก้ที่ฝังในซอร์สของ ORCA ซึ่งจะพูดทีหลัง คือบันทึกของเรื่องนั้นพอดี

3. แผนภาพสถาปัตยกรรมระบบของสถานพยาบาล — ORCA อยู่ตรงไหน

ถ้าวาดโครงแบบฉบับของคลินิก ORCA (Nichi-Rece) อยู่ในตำแหน่งใกล้ฮับของระบบในโรงพยาบาล

flowchart LR
    subgraph clinic["ในสถานพยาบาล"]
        EMR["เวชระเบียนอิเล็กทรอนิกส์<br/>บันทึกการรักษา / ออร์เดอร์"]
        RSV["ระบบรับ / นัดหมาย"]
        ONS["เครื่องยืนยันสิทธิ์ออนไลน์"]
        ORCA["ORCA / Nichi-Rece<br/>rececon (เรียกเก็บค่ารักษา)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"เชื่อมรับ / นัดหมาย"| ORCA
        ONS -->|"ข้อมูลสิทธิ์ประกัน"| ORCA
    end
    ORCA -->|"ใบเคลม (เรียกเก็บรายเดือน)"| PAY["หน่วยงานตรวจสอบและจ่ายเงิน<br/>Payment Fund / NHI Organizations"]

มีสามจุดที่ต้องจับ

• มาสเตอร์ข้อมูลพื้นฐานผู้ป่วยและข้อมูลประกันมักอยู่ฝั่ง ORCA เวชระเบียนอิเล็กทรอนิกส์อ้างอิงและอัปเดตผ่าน API ว่าฝั่งไหนถือสิทธิ์ออกเลขผู้ป่วย เป็นประเด็นแรกของการออกแบบการเชื่อม
• รายการรักษา (ทำอะไรไป) ถูกส่งจากเวชระเบียนอิเล็กทรอนิกส์ไป ORCA แล้ว ORCA คำนวณคะแนนค่ารักษา ต่อไปยังการคิดเงินและการเรียกเก็บ เวชระเบียนอิเล็กทรอนิกส์บรรยายการรักษาด้วย «ภาษาของออร์เดอร์» ORCA บรรยายด้วย «ภาษาของคะแนน» ดังนั้นการแปลง (แมปโค้ดรายการรักษา) คือด่านจริงของการเชื่อม
• การยื่นใบเคลมรายเดือนเป็นงานของ ORCA กล่าวคือ ยอดขายของสถานพยาบาลถูกเรียกเก็บผ่าน ORCA ความตึงของโดเมนนี้คือ ความผิดพลาดในการเชื่อมไม่โผล่เป็นบันทึกการรักษาที่ขาด แต่โผล่เป็นยอดเรียกเก็บที่ผิด

4. ประวัติและไลเซนส์ของโครงการ ORCA

ORCA เป็นโครงการของสมาคมแพทย์ญี่ปุ่น (JMA) ในเดือนพฤศจิกายน 2001 «คำประกาศไอทีของสมาคมแพทย์ญี่ปุ่น» วางนโยบายว่าซอฟต์แวร์ที่สมาคมแพทย์ญี่ปุ่นสร้างจะเปิดเป็นโอเพนซอร์ส และ Nichi-Rece ถูกพัฒนาเป็นแกนของนโยบายนั้น การใช้ในสถานพยาบาลเริ่มในปี 2002 และพัฒนาต่อเนื่องมากว่า 20 ปีตั้งแต่นั้น

จุดที่โดดเด่นในมุมวิศวกรคือ ซอร์สโค้ดของระบบธุรกิจถูกเปิดต่อเนื่องมากว่า 20 ปี

• ไลเซนส์คือ สัญญาอนุญาตใช้โอเพนซอร์สของสมาคมแพทย์ญี่ปุ่น (JMA OpenSource License version 1.0) ที่แนบมากับซอร์ส ไม่ใช่ GPL แต่เป็นสัญญาของสมาคมแพทย์ญี่ปุ่นเอง การใช้โปรแกรม (รวมทำสำเนา ดัดแปลง แจกจ่าย ส่งสู่สาธารณะ) ได้รับอนุญาตแบบไม่ผูกขาดและไม่มีค่าใช้จ่าย และการแจกจ่ายรุ่นที่แก้ต้องใช้เงื่อนไขเดียวกัน เป็นโครงคล้าย copyleft กฎหมายที่ใช้บังคับคือกฎหมายญี่ปุ่น
• เคยมีคลัง CVS ที่เปิดอยู่ แต่พอเริ่มมีรุ่นเชิงพาณิชย์ CVS ถูกปิด ปัจจุบันใช้วิธี ในวันที่ 1 ของทุกเดือน เปิดซอร์ส ณ วันที่ 1 ของเดือนก่อนเป็น tarball สิ่งที่เปิดมีสามคอมโพเนนต์ คือตัวหลัก ค่าใช้จ่ายสาธารณะระดับภูมิภาค และแบบฟอร์มที่เปิด และสาย 5.0, 5.1, 5.2 ถูกเปิดขนานกัน
• โครงสร้างพัฒนาและจัดส่งก็มีลักษณะเฉพาะ อ่านประวัติแก้ในซอร์ส จะเห็นชื่อวิศวกรของ NACL (ผู้รับจ้างพัฒนา) ในช่วงต้น แล้วราวปี 2022 เป็นต้นไปเปลี่ยนเป็นคอมมิตในนาม ORCAMO (องค์กรบริหาร ORCA ของสมาคมแพทย์ญี่ปุ่น) บริการรอบข้าง (ซัพพอร์ต แพ็กเกจ คู่มือ เป็นต้น) องค์กรบริหาร ORCA จัดเป็นรุ่นเชิงพาณิชย์ ส่วนการติดตั้งและดูแลรับโดยผู้ให้บริการซัพพอร์ตที่ได้รับการรับรองทั่วประเทศ เป็นโมเดลแบ่งงาน

กล่าวคือ ORCA เป็นซอฟต์แวร์ที่ «เป็นโอเพนซอร์ส แต่ไม่ใช่การพัฒนาแบบชุมชนแบบ GitHub» อ่านซอร์สได้ ฟอร์กได้ แต่สายหลักถูกขับโดยหน่วยงานเดียวในลักษณะผู้ขาย — เมื่อคิดถึงโดเมนการแพทย์ที่ผิดไม่ได้และต้องตามระบบกฎเกณฑ์ ผู้เขียนมองว่าเป็นจุดลงตัวที่สมเหตุสมผล

5. สแต็กเทคโนโลยี — นับจริงเนื้อใน COBOL 4 ล้านบรรทัด

ตั้งแต่บทนี้ชื่อเฉพาะจะเพิ่มรวดเร็ว จึงวางตารางคำศัพท์ไว้ก่อน อ่านบทถัดไปโดยวางตารางนี้ไว้ข้าง ๆ

ใน 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/>COBOL ประมาณ 1,750 โปรแกรม"]
    AP --> DB[("PostgreSQL<br/>285 ตาราง")]

ที่น่าสนใจคือ การดิสแพตช์หน้าจอและการดิสแพตช์ API อยู่ร่วมในไฟล์นิยาม LD เดียวกัน กล่าวคือ Nichi-Rece API ไม่ใช่เซิร์ฟเวอร์อีกชุดที่ต่อท้ายทีหลัง แต่ถูกอิมพลีเมนต์เป็นการเพิ่ม «ทางเข้าที่คุยด้วย XML แทนหน้าจอ» บนแพลตฟอร์มโปรแกรมธุรกิจชุดเดียวกับหน้าจอโต้ตอบ รายละเอียดของการออกแบบนี้จะอยู่ในตอนต่อ

โครง «COBOL + มิดเดิลแวร์เฉพาะทาง + PostgreSQL» ดูไกลจากความรู้สึกของการพัฒนาเว็บสมัยใหม่ แต่ในส่วนหัวของโปรแกรม COBOL หนึ่งไฟล์ มีประวัติแก้เป็นคอมเมนต์ตั้งแต่ปี 2002 จนถึงงานตามระบบล่าสุดอย่างใบสั่งยาอิเล็กทรอนิกส์ (2022) และการยืนยันสิทธิ์บัตรประกันสุขภาพ My Number (2024) อ่านออกได้ว่า โค้ดเบสเดียวกันตามการปรับระบบต่อเนื่องมากว่า 20 ปี โครงนี้ยังเป็นผลจากการถูกปรับให้เหมาะกับ «นิ่งแล้วแต่ยังรันต่อไปได้»

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 (เช่น คำสั่งพิมพ์แบบฟอร์ม) ไปยังระบบที่เชื่อม สร้างการประสานหน้าจอแบบ event-driven ได้โดยไม่ต้องโพล
3. CLAIM — ถูกใช้มานานในฐานะข้อตกลงมาตรฐานแลกเปลี่ยนข้อมูลทางการแพทย์ แต่ สิ้นสุดการสนับสนุนในเดือนมีนาคม 2026 ในซอร์สยังเหลือการประมวลสาย CLAIM แต่การเชื่อม CLAIM ที่มีอยู่ถูกวางบนสมมติฐานว่าจะย้ายไป API

กล่าวคือ ถ้าจะออกแบบการเชื่อม ORCA ตอนนี้ Nichi-Rece API เป็นทางเดียว และดังที่พูดไปแล้ว API ถูกอิมพลีเมนต์บนแพลตฟอร์มโปรแกรมธุรกิจ COBOL ชุดเดียวกับหน้าจอโต้ตอบ ดังนั้นตอน «พฤติกรรม API ไม่ชัด» สามารถลงไปดูที่ซอร์สได้ ขั้นตอนจริงในการจับภาพรวม API จากซอร์ส (รวมเอนด์พอยต์ที่ไม่มีในรายการทางการ) อธิบายใน บทความตอนต่อ

8. การย้ายไป WebORCA เปลี่ยนอะไร

ORCA ตอนนี้อยู่ในช่วงย้ายไป «WebORCA» รูปแบบการจัดส่งแบ่งใหญ่เป็นสองแบบ

• WebORCA รุ่นคลาวด์ — ใช้ Nichi-Rece ในฐานะบริการคลาวด์ที่องค์กรบริหาร ORCA จัดให้ สถานพยาบาลหลุดจากการดูแลเซิร์ฟเวอร์ การสมัครผ่านสำนักงานซัพพอร์ตที่ได้รับการรับรอง ตามประกาศทางการให้เผื่อประมาณ 3 สัปดาห์ตั้งแต่สมัครถึงเริ่มใช้บริการ ฝั่งสถานพยาบาลไม่ตั้งเซิร์ฟเวอร์ในโรงพยาบาล ใช้ผ่านเบราว์เซอร์ และการอัปเดตโปรแกรมตามการปรับค่ารักษาถูกทำรวมที่ฝั่งคลาวด์ คิดเงินเป็นรายเดือนต่อสถานพยาบาลหนึ่งแห่ง
• WebORCA รุ่น on-prem — ติดตั้งบนเซิร์ฟเวอร์ในโรงพยาบาล (Ubuntu) สภาพแวดล้อมที่จัดส่งปัจจุบันคือ Nichi-Rece Ver5.2.0 บน Ubuntu 22.04 (jammy)

เรื่องแกนเวลาของการย้าย มีสองจุดที่ควรจับไว้

ข้อแรก เส้นทางย้ายถูกจัดไว้ทางการ ORCA Project เปิด «คู่มือย้ายสภาพแวดล้อมเดินระบบ Nichi-Rece» และระบุชัดว่าขั้นตอนเป้าหมายคือการย้ายจาก Nichi-Rece แบบเดิม (รุ่น MONTSUQI) 5.1.0 / 5.2.0 ที่รันบน Ubuntu 16.04 / 18.04 / 20.04 ไปยัง WebORCA รุ่น on-prem (Ubuntu 22.04 + 5.2.0) ทิศตรงข้าม คือย้ายลง OS ที่ต่ำกว่าหรือเวอร์ชัน Nichi-Rece ที่ต่ำกว่า ทำไม่ได้

ข้อสอง ไม่ได้มีการประกาศเส้นตายแบบ «สถานพยาบาลทั้งหมดต้องไป WebORCA ภายในเมื่อไร» เป็นเส้นเดียว สิ่งที่ทำงานเป็นเส้นตายในงานจริงคือ วันสิ้นสุดซัพพอร์ต ที่ตั้งตามคู่ของ OS กับแพ็กเกจ Nichi-Rece ซึ่งถูกประกาศเป็น «ตารางซัพพอร์ตแพ็กเกจ Nichi-Rece และ OS» และเวอร์ชันที่ใกล้สิ้นจะถูกแจ้งแยก สำหรับฝั่งที่สร้างระบบเชื่อม วิธีจับแกนเวลาในงานจริงไม่ใช่ถามว่า «ย้ายไป WebORCA เมื่อไร» แต่คือ ตรวจเวอร์ชัน Ubuntu กับ Nichi-Rece ที่สถานพยาบาลฝั่งตรงข้ามใช้อยู่ และวันสิ้นสุดซัพพอร์ตของคู่นั้น

สิ่งสำคัญคือ ข้างในทั้งสองแบบเป็น Nichi-Rece ตัวเดียวกัน ซอฟต์แวร์ที่รันไม่ได้กลายเป็นคนละตัวตามรูปแบบการจัดส่ง ชนิด API และพฤติกรรมโดยหลักก็ร่วมกัน ความต่างที่วิศวกรฝั่งเชื่อมควรจับ ไม่ได้อยู่ที่อิมพลีเมนต์ แต่กระจุกที่เรื่องการต่อ

• ความต่างของทางเข้า เช่น รุ่นคลาวด์เติมคำนำหน้า /api ที่พาธปลายทางของคำขอ API และการตั้งค่าข้อมูลการต่อกับการยืนยันตัวตนต่างกันตามรูปแบบการจัดส่ง สเปกของตัว API เองร่วมกัน
• รุ่นคลาวด์ทำให้ระบบเชื่อมในโรงพยาบาลเรียก API ข้ามอินเทอร์เน็ต จึงมีเรื่องต้องคิดเรื่องเส้นทางเครือข่ายและพฤติกรรมย่อตอนขัดข้องมากกว่าโครง on-prem
• ซอร์สที่เปิดทุกเดือน รวมนิยามสำหรับ WebORCA ไว้ตรง ๆ (เช่น ไฟล์ .db.weborca ใต้ record/) เป็นหลักฐานว่าต้นไม้ซอร์สชุดเดียวรองรับทั้งสองรูปแบบ และความรู้ที่ได้จากการอ่านซอร์สใช้กับรุ่นคลาวด์ได้ด้วย ทั้งนี้ในรุ่น .weborca มีนิยามที่ปรับเพดานอาร์เรย์ของคำตอบ เป็นต้น ดังนั้นตอนตรวจรายละเอียดให้ดูด้วยว่ามีนิยามสำหรับ WebORCA หรือไม่

9. สรุป — จุดที่วิศวกรควรจับไว้

• ORCA (Nichi-Rece) ไม่ใช่เวชระเบียนอิเล็กทรอนิกส์ แต่เป็น rececon ถือแกนข้อมูลฝั่งเรียกเก็บเงินอย่างผู้ป่วย ประกัน ชื่อโรค รายการรักษา คะแนนค่ารักษา และยอดขายของสถานพยาบาลถูกเรียกเก็บผ่านตรงนี้
• ความยากแท้ของ rececon คือ การตามการปรับค่ารักษาสองปีครั้งต่อเนื่องหลายสิบปี ประวัติแก้ในซอร์สของ ORCA คือบันทึกจริงของเรื่องนั้น
• เป็น ระบบธุรกิจโอเพนซอร์ส ที่สืบจากคำประกาศไอทีของสมาคมแพทย์ญี่ปุ่นปี 2001 ซอร์สถูกเปิดเป็น tarball ทุกเดือน ไลเซนส์ไม่ใช่ GPL แต่เป็นสัญญาอนุญาตใช้โอเพนซอร์สของสมาคมแพทย์ญี่ปุ่น
• ข้างในคือ COBOL 1,754 โปรแกรม ประมาณ 4.06 ล้านบรรทัด + MONTSUQI + PostgreSQL 285 ตาราง (วัดจริงสาย 5.2) ทั้งหน้าจอและ API ถูกดิสแพตช์ด้วยนิยาม LD ชุดเดียวกันในสถาปัตยกรรมประมวลผลรวม
• ทางเข้าเชื่อมภายนอกตอนนี้คือ Nichi-Rece API CLAIM สิ้นสุดซัพพอร์ตในเดือนมีนาคม 2026 การย้าย WebORCA กำลังเดิน แต่ทั้งรุ่นคลาวด์และรุ่น on-prem ข้างในเป็น 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 ของสมาคมแพทย์ญี่ปุ่น (ช่องทางสมัคร รูปแบบการจัดส่ง ค่าใช้จ่าย)
• คู่มือย้ายสภาพแวดล้อมเดินระบบ Nichi-Rece - ORCA Project (เป้าหมายและขั้นตอนการย้ายไป WebORCA รุ่น on-prem)
• ถึงผู้ที่กำลังใช้ซอฟต์แวร์ใบเคลมมาตรฐานของสมาคมแพทย์ญี่ปุ่น - ORCA Project (แหล่งประกาศ «ตารางซัพพอร์ตแพ็กเกจ Nichi-Rece และ OS»)
• ซอร์สโค้ดตัวหลัก Nichi-Rece สาย 5.2 (สแนปช็อตที่เปิดกรกฎาคม 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc และอื่น ๆ — ค่าที่วัดในบทความทั้งหมดอิงสแนปช็อตนี้

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ORCA เป็นเวชระเบียนอิเล็กทรอนิกส์หรือไม่?

ไม่ใช่ JMA Standard Receipt Software (Nichi-Rece) ซึ่งเป็นแกนของโครงการ ORCA คือ rececon ที่รับผิดชอบการเรียกเก็บค่ารักษา (receipt / ใบเคลม) เวชระเบียนอิเล็กทรอนิกส์ที่ใช้เขียนบันทึกการรักษาเป็นซอฟต์แวร์อีกชุด และสถานพยาบาลจำนวนมากเชื่อมเวชระเบียนอิเล็กทรอนิกส์กับ ORCA ผ่าน API คำเรียก «เวชระเบียนอิเล็กทรอนิกส์ ORCA» ควรถูกเข้าใจว่าเป็นชื่อเล่นที่เกิดเพราะมักถูกใช้คู่กับเวชระเบียนอิเล็กทรอนิกส์

ซอร์สโค้ดของ ORCA (Nichi-Rece) อ่านได้ทุกคนหรือไม่?

อ่านได้ ซอร์สโค้ดของ JMA Standard Receipt Software ถูกเปิดภายใต้สัญญาอนุญาตใช้โอเพนซอร์สของสมาคมแพทย์ญี่ปุ่น (JMA OpenSource License) และในวันที่ 1 ของทุกเดือนดาวน์โหลดสแนปช็อต ณ วันที่ 1 ของเดือนก่อนเป็น tarball ได้ คลัง CVS เดิมถูกปิดเมื่อเริ่มมีรุ่นเชิงพาณิชย์ แต่การเปิดซอร์สเองยังดำเนินต่อ

ORCA สร้างด้วยเทคโนโลยีอะไร?

เซิร์ฟเวอร์รันบน Linux และตรรกะธุรกิจส่วนใหญ่เขียนด้วย COBOL ฐานข้อมูลคือ PostgreSQL แพลตฟอร์มรันโปรแกรมธุรกิจใช้มิดเดิลแวร์โอเพนซอร์สชื่อ MONTSUQI (panda) ฝั่งไคลเอนต์ใช้ monsiaj ที่เขียนด้วย Java เป็นต้น นับซอร์สสาย 5.2 เฉพาะ COBOL มีประมาณ 1,750 โปรแกรม กว่า 4 ล้านบรรทัด ฐานข้อมูลมีตารางกว่า 280 ตาราง

เวชระเบียนอิเล็กทรอนิกส์เชื่อมกับ ORCA อย่างไร?

แนวทางที่แนะนำตอนนี้คือ Nichi-Rece API ระบบที่เชื่อม เช่น เวชระเบียนอิเล็กทรอนิกส์ ส่งคำขอ HTTP เพื่อดึงข้อมูลผู้ป่วย ลงทะเบียนรายการรักษา เป็นต้น มี PushAPI ที่ฝั่ง Nichi-Rece แจ้งเหตุการณ์ออกไปด้วย การเชื่อมด้วย CLAIM (ข้อตกลงแลกเปลี่ยนข้อมูลทางการแพทย์) ที่ใช้มานานสิ้นสุดการสนับสนุนในเดือนมีนาคม 2026 ดังนั้นงานเชื่อมที่สร้างใหม่ควรออกแบบบนสมมติฐาน API

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก