ORCA (Nichi-Rece) không phải hồ sơ bệnh án điện tử — cấu trúc hệ thống billing y tế và CNTT y tế nhìn từ góc độ kỹ sư

Đã nghe cụm “hồ sơ bệnh án điện tử ORCA” chưa? Làm dự án hệ thống cho cơ sở y tế thì tên này chắc chắn xuất hiện — nhưng cách gọi đó chứa hiểu nhầm. ORCA (phần mềm Receipt chuẩn của Hiệp hội Y khoa Nhật Bản) không phải hồ sơ bệnh án điện tử.

Bài này hướng tới kỹ sư lần đầu đụng dự án CNTT y tế, với mục tiêu trả lời các câu hỏi sau.

• ORCA là gì, và nằm ở đâu trong cấu trúc hệ thống của cơ sở y tế
• “Công việc receipt” mà rececon đảm nhận, nhìn từ góc hệ thống, thực ra đang làm gì
• Được xây bằng công nghệ nào, và mã nguồn công khai chứa gì
• Chuyển sang WebORCA thì gì đổi, phía liên kết cần nắm gì

Mọi mô tả đều dựa trên nguồn sơ cấp đã công bố. Phần viết về mã nguồn là kết quả tải và kiểm tra thực tế mã nguồn Nichi-Rece dòng 5.2 được công bố chính thức (snapshot công bố ngày 1 tháng 7 năm 2026, tệp VERSION ghi 5.2.0).

Mục lục

1. Kết luận trước — ORCA là “rececon”
2. Công việc receipt là gì — hiểu nhanh nhất từ góc hệ thống
3. Sơ đồ cấu trúc hệ thống cơ sở y tế — ORCA đứng ở đâu
4. Lịch sử và giấy phép dự án ORCA
5. Stack công nghệ — đếm thực tế hơn 4 triệu dòng COBOL
6. Cách đi trong source tree — cái gì nằm đâu
7. Cửa vào liên kết — API Nichi-Rece, PushAPI, CLAIM
8. Chuyển sang WebORCA thì gì đổi
9. Tóm lại — những điểm kỹ sư cần nắm
10. Tài liệu tham khảo

Bản đồ tri thức của bài viết này

ORCA (Nichi-Rece) không phải bệnh án điện tử mà là rececon đảm nhận tính chi phí khám chữa bệnh và lập receipt, liên thông với bệnh án điện tử qua API Nichi-Rece. Logic nghiệp vụ của Nichi-Rece viết bằng COBOL, chạy trên nền thực thi MONTSUQI (panda) kết hợp client Java monsiaj và PostgreSQL; cả màn hình lẫn API đều được dispatch theo cùng một định nghĩa LD. Cửa vào liên thông bên ngoài chủ yếu là API Nichi-Rece và PushAPI được công bố theo hợp đồng giấy phép nguồn mở JMA; CLAIM dùng lâu năm kết thúc hỗ trợ vào tháng 3 năm 2026 và tiền đề là chuyển sang API Nichi-Rece. Hiện đang trong giai đoạn chuyển sang WebORCA bản đám mây và bản tại chỗ, môi trường cung cấp truyền thống (bản MONTSUQI) đang bị thay thế dần, nhưng bên trong cả hai đều là cùng một Nichi-Rece.

flowchart LR
    accTitle: Bản đồ tri thức ORCA (Nichi-Rece)
    accDescr: Sơ đồ cho thấy ORCA (Nichi-Rece) với vai trò rececon phân chia nhiệm vụ với bệnh án điện tử, stack COBOL, MONTSUQI, PostgreSQL, monsiaj và dispatch theo định nghĩa LD, diễn biến các phương thức liên thông API Nichi-Rece, PushAPI, CLAIM, cùng quan hệ chuyển sang WebORCA bản đám mây và bản tại chỗ
    orca_nichirese["ORCA (Nichi-Rece)"]
    receipt_computer["Rececon (máy tính lập receipt)"]
    receipt["Receipt (bảng kê chi phí KCB)"]
    electronic_medical_record["Bệnh án điện tử"]
    orca_api["API Nichi-Rece"]
    cobol["COBOL"]
    montsuqi["MONTSUQI"]
    postgresql["PostgreSQL"]
    monsiaj["monsiaj"]
    ld_definition["Định nghĩa LD"]
    push_api["PushAPI"]
    claim_protocol["CLAIM (quy ước trao đổi thông tin y tế)"]
    jma_opensource_license["Giấy phép nguồn mở JMA"]
    weborca_cloud["WebORCA bản đám mây"]
    weborca_onpremise["WebORCA bản tại chỗ"]
    legacy_nichirese_deployment["Môi trường cung cấp truyền thống (bản MONTSUQI)"]
    orca_nichirese -->|"triển khai"| receipt_computer
    receipt -->|"yêu cầu"| receipt_computer
    electronic_medical_record -.->|"sử dụng"| orca_api
    orca_nichirese -->|"sử dụng"| cobol
    orca_nichirese -->|"sử dụng"| montsuqi
    orca_nichirese -->|"sử dụng"| postgresql
    orca_nichirese -->|"sử dụng"| monsiaj
    montsuqi -->|"cấu hình bằng"| ld_definition
    orca_api -->|"cấu hình bằng"| ld_definition
    orca_api -->|"yêu cầu"| montsuqi
    monsiaj -->|"yêu cầu"| montsuqi
    orca_nichirese -->|"sử dụng"| orca_api
    orca_nichirese -->|"sử dụng"| push_api
    orca_api -->|"kế nhiệm"| claim_protocol
    orca_nichirese -.->|"yêu cầu"| jma_opensource_license
    weborca_cloud -->|"triển khai"| orca_nichirese
    weborca_onpremise -->|"triển khai"| orca_nichirese
    weborca_onpremise -->|"kế nhiệm"| legacy_nichirese_deployment
    legacy_nichirese_deployment -->|"sử dụng"| montsuqi

Trong sơ đồ, đường liền nét biểu thị quan hệ luôn đúng và đường nét đứt biểu thị quan hệ có điều kiện (điều kiện nằm trong phần giải thích từng quan hệ trên trang chi tiết). Danh sách đầy đủ các quan hệ (tổng 19, kèm bằng chứng và mức chắc chắn) cùng định nghĩa các khái niệm chính được tập hợp tại trang chi tiết bản đồ tri thức (bằng tiếng Nhật). Dữ liệu: JSON-LD / Turtle

1. Kết luận trước — ORCA là “rececon”

Trung tâm dự án ORCA là “phần mềm Receipt chuẩn của Hiệp hội Y khoa Nhật Bản” (JMA Standard Receipt Software, gọi tắt Nichi-Rece): đó là rececon (máy tính lập phiếu claim, hệ thống billing y tế). Rececon là hệ thống nghiệp vụ tính thù lao khám chữa từ nội dung khám, rồi lập receipt (bảng kê thanh toán viện phí) để nộp cho cơ quan thẩm định và thanh toán.

Hồ sơ bệnh án điện tử và rececon phân vai rõ.

Biệt danh “EMR ORCA” ra đời vì nhiều sản phẩm hồ sơ bệnh án điện tử chọn cấu trúc “phần billing thì liên kết ORCA”. Với kỹ sư, nắm sớm sự phân biệt ORCA = lõi phía đòi thanh toán, EMR = phía ghi chép khám chữa thì mọi chuyện sau dễ sắp hơn.

2. Công việc receipt là gì — hiểu nhanh nhất từ góc hệ thống

Muốn hiểu rececon là hệ thống gì, đường tắt là nắm dòng tiền của cơ sở y tế. Trong khám chữa bảo hiểm ở Nhật, bệnh nhân trả tại quầy nguyên tắc 10–30%, phần còn lại cơ sở y tế đòi theo tháng từ cơ quan thẩm định thanh toán (Quỹ thanh toán thù lao khám chữa bệnh bảo hiểm xã hội và Liên đoàn bảo hiểm y tế quốc dân). Tờ đòi đó là receipt.

Nhìn như hệ thống, rececon là máy chạy vòng batch theo tháng sau.

1. Hàng ngày: tiếp nhận xác minh tư cách bảo hiểm, nhập dịch vụ khám chữa (khám, xét nghiệm, cấp thuốc, thủ thuật…), quyết toán theo số tiền bệnh nhân trả tại quầy đã tính tự động dựa trên bảng điểm.
2. Hàng tháng: cộng dồn dịch vụ khám chữa một tháng theo đơn vị bệnh nhân × bảo hiểm, lập receipt. Trước khi nộp thì kiểm tra dữ liệu (tính nhất quán chẩn đoán và đơn thuốc, v.v.), nộp dưới dạng receipt điện tử (dữ liệu rece-den).
3. Từ tháng sau: xử lý “henrei” bị thẩm định trả lại và “satei” bị cắt điểm, sửa rồi đòi lại.

Điểm quan trọng: quy tắc tính điểm đổi theo đợt sửa thù lao khám chữa hai năm một lần. Phần mềm không bám được việc sửa master điểm, giá thuốc, quy tắc tính thì cơ sở y tế không đòi đúng được. Độ khó cốt lõi của phần mềm rececon không nằm ở UI hay scale, mà ở việc bám theo chế độ đó suốt hàng chục năm. Lịch sử sửa khắc trên mã nguồn ORCA, sẽ nói sau, chính là biên bản của việc đó.

3. Sơ đồ cấu trúc hệ thống cơ sở y tế — ORCA đứng ở đâu

Vẽ cấu trúc điển hình của phòng khám, ORCA (Nichi-Rece) đứng gần vị trí hub của hệ thống trong viện.

flowchart LR
    subgraph clinic["Trong cơ sở y tế"]
        EMR["Hồ sơ bệnh án điện tử<br/>ghi chép khám chữa · order"]
        RSV["Hệ thống tiếp nhận · đặt lịch"]
        ONS["Thiết bị xác minh tư cách online"]
        ORCA["ORCA / Nichi-Rece<br/>rececon (đòi thanh toán viện phí)"]
        EMR -->|"API Nichi-Rece (HTTP)"| ORCA
        RSV -->|"liên kết tiếp nhận · đặt lịch"| ORCA
        ONS -->|"thông tin tư cách bảo hiểm"| ORCA
    end
    ORCA -->|"receipt (đòi theo tháng)"| PAY["Cơ quan thẩm định thanh toán<br/>Payment Fund · NHI Organizations"]

Ba điểm then chốt.

• Master thông tin cơ bản bệnh nhân và thông tin bảo hiểm thường nằm phía ORCA. EMR tham chiếu và cập nhật qua API. Bên nào nắm việc cấp số bệnh nhân là luận điểm đầu tiên của thiết kế liên kết.
• Dịch vụ khám chữa (đã làm gì) được gửi từ EMR sang ORCA; ORCA tính điểm rồi nối sang quyết toán và đòi tiền. EMR mô tả khám chữa bằng “ngôn ngữ order”, ORCA bằng “ngôn ngữ điểm”, nên phép chuyển đó (ánh xạ mã dịch vụ khám chữa) là đoạn khó thực tế của liên kết.
• Nộp receipt hàng tháng là việc của ORCA. Nghĩa là doanh thu cơ sở y tế được đòi đi qua ORCA. Sai liên kết hiện ra không phải thiếu ghi chép khám chữa mà là sai số tiền đòi — độ căng đó đặc trưng cho lĩnh vực này.

4. Lịch sử và giấy phép dự án ORCA

ORCA là dự án của Hiệp hội Y khoa Nhật Bản (JMA). Tuyên bố tin học hóa JMA tháng 11 năm 2001 nêu chủ trương công bố phần mềm Hiệp hội Y khoa Nhật Bản làm dưới dạng mã nguồn mở, và Nichi-Rece được phát triển làm trung tâm. Sử dụng tại hiện trường y tế bắt đầu từ 2002, phát triển đã kéo dài hơn 20 năm.

Đáng chú ý với kỹ sư là mã nguồn một hệ thống nghiệp vụ được công bố liên tục hơn 20 năm.

• Giấy phép là Hợp đồng cho phép sử dụng mã nguồn mở của JMA (JMA OpenSource License version 1.0) đi kèm mã nguồn. Không phải GPL mà là hợp đồng riêng của JMA: việc dùng chương trình (gồm sao chép, phỏng tác, phân phối, truyền tới công chúng) được cho phép không độc quyền và không thu phí; khi phân phối bản đã sửa thì phải áp cùng điều kiện — cấu trúc kiểu copyleft. Luật áp dụng là luật Nhật.
• Trước đây kho CVS được mở, nhưng khi bản thương mại ra mắt CVS bị đóng; hiện nay ngày 1 hàng tháng, mã nguồn tại thời điểm ngày 1 tháng trước được công bố dạng tarball. Đối tượng công bố gồm ba thành phần: phần thân, chi phí công cộng theo vùng, và mẫu biểu mẫu công khai; dòng 5.0, 5.1, 5.2 được công bố song song.
• Cơ chế phát triển và cung cấp cũng đặc thù. Đọc lịch sử sửa trong mã nguồn, thời kỳ đầu thấy tên kỹ sư của NACL (đơn vị nhận thầu phát triển), khoảng từ 2022 chuyển sang commit mang tên ORCAMO (Tổ chức quản lý ORCA của Hiệp hội Y khoa Nhật Bản). Dịch vụ xung quanh (hỗ trợ, gói, tài liệu, v.v.) do Tổ chức quản lý ORCA cung cấp như bản thương mại; triển khai và bảo trì do nhà cung cấp hỗ trợ được chứng nhận trên cả nước đảm nhận — mô hình phân công.

Tức ORCA là phần mềm “mã nguồn mở, nhưng không phải phát triển cộng đồng kiểu GitHub”. Đọc được mã, fork được, nhưng dòng chính do một chủ thể đẩy theo kiểu vendor. Với y tế — lĩnh vực không cho phép sai và bắt buộc bám chế độ — tôi nghĩ đó là chỗ đáp hợp lý.

5. Stack công nghệ — đếm thực tế hơn 4 triệu dòng COBOL

Từ chương này tên riêng tăng đột ngột, nên đặt bảng thuật ngữ trước. Các chương sau hãy đọc với bảng này bên cạnh.

INSTALL.ja trong mã nguồn dòng 5.2 công bố liệt kê phần mềm cần thiết: MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE, v.v. Tóm cấu trúc như sau.

Chỉ lời thì không thấy quy mô, nên đây là kết quả đếm thực tế snapshot dòng 5.2 (sau giải nén khoảng 8.200 tệp, 237 MB).

Tên bảng thẳng thắn; quen đọc thì nghiệp vụ hiện ra nguyên. Cách đặt tên trộn “viết tắt tiếng Anh” và “romaji tiếng Nhật”, nên khôi phục phần tiếng Nhật về kanji thì nghĩa ra. Các bảng chính như sau.

Phân vai chương 1 — bệnh nhân, bảo hiểm, chẩn đoán, dịch vụ khám chữa, điểm — được hiện thực đúng như cấu trúc bảng. Tài liệu định nghĩa bảng được công bố trên trang chính thức, phân vân cách đọc thì đối chiếu tên chính thức ở đó.

Chìa khóa kiến trúc là MONTSUQI. Bên trong Nichi-Rece là xử lý tập trung cổ điển: client Java (monsiaj) nhận định nghĩa màn hình từ máy chủ rồi hiển thị; đầu vào do chương trình COBOL phía máy chủ xử lý, đọc ghi PostgreSQL. Màn hình nào tương ứng chương trình COBOL nào được khai báo mang tính mô tả trong tệp định nghĩa LD ở thư mục lddef/.

flowchart LR
    CL["monsiaj<br/>client Java"] -->|"thao tác màn hình"| MW["MONTSUQI<br/>application server"]
    API["Hệ thống liên kết<br/>EMR, v.v."] -->|"API Nichi-Rece (HTTP)"| MW
    MW -->|"phân phối theo định nghĩa lddef/*.ld"| AP["Nhóm chương trình nghiệp vụ<br/>khoảng 1.750 chương trình COBOL"]
    AP --> DB[("PostgreSQL<br/>285 bảng")]

Đáng chú ý là dispatch màn hình và dispatch API sống chung trong cùng tệp định nghĩa LD. Nghĩa là API Nichi-Rece không phải máy chủ khác gắn thêm sau; nó được hiện thực như “cửa vào nói chuyện bằng XML thay cho màn hình”, thêm trên cùng nền chương trình nghiệp vụ với màn hình tương tác. Chi tiết thiết kế này sẽ nói ở bài tiếp.

Cấu trúc “COBOL + middleware riêng + PostgreSQL” nhìn xa so với cảm giác phát triển web hiện đại. Nhưng phần đầu một chương trình COBOL khắc lịch sử sửa bằng comment từ 2002, tới cả ứng phó chế độ gần đây như đơn thuốc điện tử (2022) và xác minh tư cách thẻ bảo hiểm My Number (2024) — đọc ra được rằng cùng một codebase đã bám đợt sửa suốt hơn 20 năm. Cấu trúc này cũng là kết quả tối ưu cho “già và tiếp tục chạy”.

6. Cách đi trong source tree — cái gì nằm đâu

Làm bản đồ khi đọc mã, gom các thư mục top-level chính như sau.

Một lưu ý thực tế. Mã nguồn mã hóa EUC-JP (văn bản giấy phép là ISO-2022-JP). Mở bằng editor hiện đại thì vỡ chữ, nên đọc qua iconv -f EUC-JP -t UTF-8. Đó là một kiểu time capsule: chuẩn môi trường Linux năm 2002 được giữ nguyên.

7. Cửa vào liên kết — API Nichi-Rece, PushAPI, CLAIM

Khi kỹ sư hệ thống bên ngoài đụng ORCA, cửa vào thực chất là ba thứ sau.

1. API Nichi-Rece — khuyến nghị hiện nay. Hệ thống liên kết gửi yêu cầu HTTP để lấy thông tin bệnh nhân, tiếp nhận, đăng ký dịch vụ khám chữa, v.v. Phía đọc cơ bản là GET hoặc POST+XML; phía cập nhật là POST+XML. Đặc tả API được công bố trên trang chính thức.
2. PushAPI — cơ chế thông báo sự kiện xảy ra phía Nichi-Rece (chỉ thị in biểu mẫu, v.v.) sang hệ thống liên kết. Làm được phối hợp màn hình theo sự kiện, không phải polling.
3. CLAIM — từng dùng lâu như quy ước chuẩn trao đổi thông tin y tế, nhưng hỗ trợ kết thúc tháng 3 năm 2026. Trên mã nguồn vẫn còn xử lý họ CLAIM, song liên kết CLAIM hiện có lấy việc chuyển sang API làm tiền đề.

Nghĩa là, nếu sắp thiết kế liên kết ORCA thì chỉ còn API Nichi-Rece. Và như đã nói, API nằm trên cùng nền chương trình nghiệp vụ COBOL với màn hình tương tác, nên khi “không rõ hành vi API” có thể xuống mã nguồn mà kiểm. Thủ tục cụ thể để nắm toàn cảnh API từ mã nguồn (kể cả endpoint không có trên danh sách chính thức) được giải thích trong bài tiếp.

8. Chuyển sang WebORCA thì gì đổi

ORCA hiện đang ở giai đoạn chuyển sang “WebORCA”. Hình thức cung cấp chia lớn thành hai.

• WebORCA bản cloud — dùng Nichi-Rece như dịch vụ cloud do Tổ chức quản lý ORCA cung cấp. Cơ sở y tế được giải phóng khỏi quản lý máy chủ. Đăng ký đi qua văn phòng hỗ trợ được chứng nhận; thông báo chính thức cho biết từ đăng ký đến khi dịch vụ bắt đầu nên tính khoảng 3 tuần. Phía cơ sở y tế không đặt máy chủ trong viện, dùng từ trình duyệt; cập nhật chương trình theo đợt sửa thù lao khám chữa cũng được làm gộp phía cloud. Phí theo tháng cho mỗi cơ sở y tế.
• WebORCA bản on-prem — cài trên máy chủ trong viện (Ubuntu). Môi trường cung cấp hiện hành là Nichi-Rece Ver5.2.0 trên Ubuntu 22.04 (jammy).

Về trục thời gian chuyển đổi, có hai điểm cần nắm.

Một là đã có đường chuyển chính thức. ORCA Project công bố “Hướng dẫn chuyển môi trường vận hành Nichi-Rece”, ghi rõ đối tượng là quy trình chuyển từ Nichi-Rece 5.1.0 / 5.2.0 kiểu cũ (bản MONTSUQI) chạy trên Ubuntu 16.04 / 18.04 / 20.04 sang WebORCA bản on-prem (Ubuntu 22.04 + 5.2.0). Chiều ngược — chuyển xuống OS thấp hơn, phiên bản Nichi-Rece thấp hơn — thì không được.

Hai là không có hạn chót thống nhất kiểu “mọi cơ sở y tế phải sang WebORCA trước ngày nào” được công bố. Hạn có hiệu lực trong thực tế là ngày kết thúc hỗ trợ đặt theo từng tổ hợp OS và gói Nichi-Rece; điều đó được công bố dưới tên “Lịch hỗ trợ gói Nichi-Rece và OS”, phiên bản gần hết hạn được thông báo riêng. Với phía làm hệ thống liên kết, cách nắm trục thời gian thực tế không phải hỏi “khi nào chuyển WebORCA”, mà là xác nhận phiên bản Ubuntu và Nichi-Rece mà cơ sở y tế đối tác đang dùng, cùng ngày kết thúc hỗ trợ của chúng.

Điều quan trọng: cả hai bên trong đều cùng một Nichi-Rece. Phần mềm đang chạy không thành thứ khác theo hình thức cung cấp; loại API và hành vi về cơ bản chung. Khác biệt kỹ sư liên kết cần nắm gom vào quanh kết nối, không phải hiện thực.

• Khác cửa vào kiểu bản cloud gắn tiền tố /api vào đường dẫn yêu cầu API, thông tin kết nối và thiết lập xác thực khác nhau theo hình thức cung cấp. Đặc tả bản thân API thì chung.
• Bản cloud khiến hệ thống liên kết trong viện gọi API qua internet, nên thiết kế đường mạng và hành vi thu hẹp khi sự cố phải nghĩ nhiều hơn cấu trúc on-prem.
• Mã nguồn công bố hàng tháng vẫn chứa nguyên định nghĩa cho WebORCA (ví dụ tệp .db.weborca dưới record/). Đó là bằng chứng cùng một source tree chống đỡ cả hai hình thức, nên kiến thức đọc mã cũng dùng được với bản cloud. Lưu ý bản .weborca có định nghĩa chỉnh trần mảng phản hồi, v.v., nên khi kiểm chi tiết hãy xem luôn có định nghĩa dành cho WebORCA hay không.

9. Tóm lại — những điểm kỹ sư cần nắm

• ORCA (Nichi-Rece) không phải hồ sơ bệnh án điện tử mà là rececon. Nó nắm lõi dữ liệu phía đòi thanh toán — bệnh nhân, bảo hiểm, chẩn đoán, dịch vụ khám chữa, điểm — và doanh thu cơ sở y tế được đòi đi qua đây.
• Độ khó cốt lõi của rececon là bám theo đợt sửa thù lao khám chữa hai năm một lần suốt hàng chục năm. Lịch sử sửa trong mã nguồn ORCA chính là biên niên sử đó.
• Là hệ thống nghiệp vụ mã nguồn mở nối từ Tuyên bố tin học hóa JMA năm 2001; mã được công bố hàng tháng dạng tarball. Giấy phép không phải GPL mà là Hợp đồng cho phép sử dụng mã nguồn mở của JMA.
• Bên trong là 1.754 chương trình COBOL, khoảng 4,06 triệu dòng + MONTSUQI + 285 bảng PostgreSQL (đo trên dòng 5.2). Cả màn hình lẫn API đều được dispatch bằng cùng định nghĩa LD, kiến trúc xử lý tập trung.
• Liên kết bên ngoài hiện lấy API Nichi-Rece làm cửa vào. CLAIM kết thúc hỗ trợ tháng 3 năm 2026. Việc chuyển WebORCA đang diễn ra, nhưng bản cloud lẫn bản on-prem bên trong đều cùng Nichi-Rece; kiến thức lấy từ mã nguồn công khai dùng được cho cả hai.

Kỳ sau sẽ đọc thực tế mã nguồn công khai này và giải thích cách nắm toàn cảnh API Nichi-Rece từ mã nguồn (URL nào do chương trình COBOL nào xử lý, endpoint nào không có trên danh sách chính thức), kèm bảng tương ứng toàn bộ 137 endpoint.

10. Tài liệu tham khảo

• ORCA là gì - ORCA Project
• Thông tin kỹ thuật - Phần mềm Receipt chuẩn của JMA - ORCA Project (công bố mã nguồn, đặc tả API, tài liệu định nghĩa bảng)
• API phần mềm Receipt chuẩn của JMA - ORCA Project
• Phần mềm Receipt chuẩn của JMA “ORCA” - Tổ chức quản lý ORCA của Hiệp hội Y khoa Nhật Bản
• Về bản thương mại phần mềm Receipt chuẩn của JMA - Tổ chức quản lý ORCA của Hiệp hội Y khoa Nhật Bản
• WebORCA bản cloud - ORCA Project
• Phần mềm Receipt chuẩn của JMA [WebORCA bản cloud] - Tổ chức quản lý ORCA của Hiệp hội Y khoa Nhật Bản (đường đăng ký, hình thức cung cấp, phí)
• Hướng dẫn chuyển môi trường vận hành Nichi-Rece - ORCA Project (đối tượng và quy trình chuyển sang WebORCA bản on-prem)
• Dành cho người đang dùng phần mềm Receipt chuẩn của JMA - ORCA Project (nơi đăng “Lịch hỗ trợ gói Nichi-Rece và OS”)
• Mã nguồn phần thân Nichi-Rece dòng 5.2 (snapshot công bố tháng 7 năm 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc và khác — mọi số đo trong bài đều dựa trên snapshot này

Bài viết liên quan

Các bài viết gần đây có cùng thẻ để tìm hiểu sâu hơn những chủ đề lân cận.

Chủ đề liên quan

Các trang này đặt chủ đề trong bối cảnh rộng hơn của dịch vụ và quyết định.

Dịch vụ liên quan đến chủ đề này

Bài viết liên quan trực tiếp đến các dịch vụ sau.

Câu hỏi thường gặp

Các câu hỏi thường gặp khi tư vấn về chủ đề của bài viết.

ORCA có phải hồ sơ bệnh án điện tử không?

Không. Phần mềm Receipt chuẩn của Hiệp hội Y khoa Nhật Bản (JMA Standard Receipt Software, gọi tắt Nichi-Rece), nằm ở trung tâm dự án ORCA, là hệ thống billing y tế (rececon) phụ trách lập phiếu thanh toán viện phí (receipt). Hồ sơ bệnh án điện tử dùng để viết ghi chép khám chữa là phần mềm khác; nhiều cơ sở y tế dùng EMR liên kết với ORCA qua API. Cách nói "EMR ORCA" nên hiểu là biệt danh sinh ra vì ORCA thường được dùng kèm EMR.

Mã nguồn ORCA (Nichi-Rece) ai cũng đọc được chứ?

Đọc được. Mã nguồn phần mềm Receipt chuẩn của JMA được công bố theo Hợp đồng cho phép sử dụng mã nguồn mở của JMA (JMA OpenSource License); ngày 1 hàng tháng có thể tải snapshot tại thời điểm ngày 1 tháng trước dưới dạng tarball. Kho CVS trước đây bị đóng khi bản thương mại ra mắt, nhưng việc công bố mã nguồn vẫn tiếp tục.

ORCA được xây bằng công nghệ gì?

Máy chủ chạy trên Linux, phần lớn logic nghiệp vụ viết bằng COBOL. Cơ sở dữ liệu là PostgreSQL; nền chạy chương trình nghiệp vụ dùng middleware mã nguồn mở tên MONTSUQI (panda); phía client dùng monsiaj viết bằng Java, v.v. Đếm mã nguồn dòng 5.2 thì riêng COBOL khoảng 1.750 chương trình, hơn 4 triệu dòng, cơ sở dữ liệu hơn 280 bảng.

Hồ sơ bệnh án điện tử liên kết với ORCA như thế nào?

Khuyến nghị hiện nay là API Nichi-Rece. Hệ thống liên kết như EMR gửi yêu cầu HTTP để lấy thông tin bệnh nhân, đăng ký dịch vụ khám chữa, v.v. Cũng có PushAPI để phía Nichi-Rece thông báo sự kiện ra ngoài. Liên kết bằng CLAIM (quy ước trao đổi thông tin y tế), dùng đã lâu, kết thúc hỗ trợ tháng 3 năm 2026, nên liên kết làm mới nên thiết kế trên giả định API.

Hồ sơ tác giả

Trang giới thiệu tác giả bài viết.

Go Komura

Đại diện của KomuraSoft LLC

Chuyên về phát triển phần mềm Windows, tư vấn kỹ thuật và điều tra lỗi, đặc biệt trong các dự án có hệ thống hiện hữu và lỗi khó tái hiện.