ORCA (Nichi-Rece) bukan rekam medis elektronik — sistem billing medis dan arsitektur sistem fasilitas kesehatan dari sudut pandang engineer

Pernah mendengar sebutan “rekam medis elektronik ORCA”? Nama itu pasti muncul saat terlibat dalam proyek sistem untuk fasilitas kesehatan, tetapi sebutan itu mengandung kesalahpahaman. ORCA (JMA Standard Receipt Software) bukan rekam medis elektronik.

Artikel ini ditujukan kepada engineer yang baru pertama kali menangani proyek IT kesehatan, dan bertujuan menjawab pertanyaan berikut.

• Apa itu ORCA, dan di mana posisinya dalam arsitektur sistem fasilitas kesehatan
• Apa yang dilakukan “pekerjaan klaim” yang ditangani sistem billing medis, jika dilihat sebagai sistem
• Dengan teknologi apa dibuat, dan apa yang ada di sumber yang dipublikasikan
• Apa yang berubah pada migrasi ke WebORCA, dan apa yang perlu diperhatikan pihak yang mengintegrasikan

Semua uraian didasarkan pada informasi primer yang dipublikasikan. Uraian tentang kode sumber adalah hasil mengunduh dan memeriksa sendiri sumber Nichi-Rece seri 5.2 yang dipublikasikan resmi (snapshot 1 Juli 2026, file VERSION bertuliskan 5.2.0).

Daftar isi

1. Kesimpulan di awal: ORCA adalah sistem billing medis
2. Apa itu pekerjaan klaim: pemahaman tercepat dari sudut sistem
3. Diagram arsitektur sistem fasilitas kesehatan: di mana posisi ORCA
4. Sejarah dan lisensi proyek ORCA
5. Stack teknologi: menghitung sendiri isi 4 juta baris COBOL
6. Cara menelusuri source tree: apa yang ada di mana
7. Pintu integrasi: Nichi-Rece API, PushAPI, CLAIM
8. Apa yang berubah pada migrasi ke WebORCA
9. Ringkasan: poin yang perlu dipahami engineer
10. Referensi

Pada diagram, garis utuh menunjukkan relasi yang selalu berlaku dan garis putus-putus menunjukkan relasi bersyarat (syaratnya ada pada penjelasan masing-masing relasi di halaman rincian). Daftar lengkap relasi (total 19, beserta bukti dan tingkat kepastian) serta definisi konsep utama dikumpulkan di halaman rincian peta pengetahuan (dalam bahasa Jepang). Data: JSON-LD / Turtle

1. Kesimpulan di awal: ORCA adalah sistem billing medis

“JMA Standard Receipt Software” (disingkat Nichi-Rece), yang menjadi inti proyek ORCA, adalah sistem billing medis (di Jepang disebut rececon, singkatan dari receipt computer). Sistem ini menghitung biaya pelayanan dari isi tindakan, lalu membuat lembar klaim biaya pelayanan (receipt) yang diajukan ke lembaga peninjau dan pembayaran.

Peran rekam medis elektronik dan sistem billing medis terpisah dengan jelas.

Sebutan populer “rekam medis elektronik ORCA” lahir karena banyak produk rekam medis elektronik mengambil arsitektur “bagian billing diintegrasikan dengan ORCA”. Bagi engineer, begitu pembedaan ORCA = tulang punggung sisi klaim, rekam medis elektronik = sisi catatan klinis dipahami di awal, semua pembahasan berikutnya jauh lebih mudah ditata.

2. Apa itu pekerjaan klaim: pemahaman tercepat dari sudut sistem

Cara tercepat memahami sistem billing medis adalah memahami aliran pendapatan fasilitas kesehatan. Dalam pelayanan berasuransi di Jepang, pasien pada prinsipnya membayar 10–30% di loket, dan sisanya diklaim fasilitas kesehatan secara bulanan ke lembaga peninjau dan pembayaran (Social Insurance Medical Fee Payment Fund dan National Health Insurance Organizations). Dokumen klaim itu adalah receipt.

Dilihat sebagai sistem, sistem billing medis adalah perangkat yang menjalankan siklus batch bulanan berikut.

1. Harian: di penerimaan, kelayakan asuransi dicek, tindakan medis (konsultasi, pemeriksaan, obat, prosedur, …) diinput, lalu pembayaran di loket memakai biaya tanggungan pasien yang dihitung otomatis berdasarkan tabel poin.
2. Bulanan: tindakan satu bulan diagregasi per satuan pasien × asuransi, lalu lembar klaim dibuat. Sebelum pengajuan, data dicek (konsistensi diagnosis dan resep, dan sebagainya), kemudian diajukan sebagai klaim elektronik (data rece-den).
3. Bulan berikutnya dan seterusnya: menangani klaim yang dikembalikan peninjauan (henrei) dan klaim yang dipotong saat penilaian (satei), lalu dikoreksi dan diklaim ulang.

Yang penting di sini: aturan perhitungan poin berubah setiap dua tahun lewat revisi tarif pelayanan. Jika perangkat lunak tidak mengikuti revisi master poin, harga obat, dan aturan penghitungan, fasilitas kesehatan tidak dapat mengklaim dengan benar. Kesulitan esensial perangkat lunak billing medis bukan UI atau skala, melainkan mengikuti aturan itu selama puluhan tahun. Riwayat perbaikan yang terukir di sumber ORCA, yang dibahas nanti, adalah catatan itu.

3. Diagram arsitektur sistem fasilitas kesehatan: di mana posisi ORCA

Jika arsitektur khas klinik digambar, ORCA (Nichi-Rece) berada di posisi yang dekat dengan hub sistem internal.

flowchart LR
    subgraph clinic["Di dalam fasilitas kesehatan"]
        EMR["Rekam medis elektronik<br/>catatan klinis dan order"]
        RSV["Sistem penerimaan dan janji"]
        ONS["Terminal verifikasi kelayakan online"]
        ORCA["ORCA/Nichi-Rece<br/>sistem billing medis (klaim biaya pelayanan)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"integrasi penerimaan dan janji"| ORCA
        ONS -->|"informasi kelayakan asuransi"| ORCA
    end
    ORCA -->|"lembar klaim (klaim bulanan)"| PAY["Lembaga peninjau dan pembayaran<br/>Payment Fund dan federasi NHI"]

Ada tiga poin.

• Master informasi dasar pasien dan informasi asuransi sering dipegang sisi ORCA. Rekam medis elektronik merujuk dan memperbarui lewat API. Siapa yang memegang penomoran nomor pasien menjadi isu desain integrasi yang pertama.
• Tindakan medis (apa yang dilakukan) dikirim dari rekam medis elektronik ke ORCA, dan ORCA yang melakukan perhitungan poin lalu menyambungkannya ke kasir dan klaim. Rekam medis elektronik mendeskripsikan pelayanan dalam “bahasa order”, ORCA dalam “bahasa poin”, sehingga konversi itu (pemetaan kode tindakan) menjadi inti praktis dari integrasi.
• Pengajuan lembar klaim bulanan adalah pekerjaan ORCA. Artinya pendapatan fasilitas kesehatan diklaim melalui ORCA. Kesalahan integrasi muncul bukan sebagai catatan klinis yang hilang, melainkan sebagai jumlah klaim yang salah — ketegangan itu adalah ciri domain ini.

4. Sejarah dan lisensi proyek ORCA

ORCA adalah proyek Japan Medical Association (JMA). Pada “Deklarasi IT JMA” November 2001, JMA menunjukkan kebijakan mempublikasikan perangkat lunak yang dibuatnya sebagai open source, dan Nichi-Rece dikembangkan sebagai intinya. Pemakaian di lapangan medis dimulai tahun 2002, dan pengembangan berlanjut lebih dari 20 tahun.

Yang menonjol dari sudut engineer: kode sumber sistem bisnis terus dipublikasikan lebih dari 20 tahun.

• Lisensinya adalah JMA OpenSource License version 1.0 (perjanjian lisensi open source JMA) yang disertakan dalam sumber. Bukan GPL, melainkan kontrak khas JMA: penggunaan program (termasuk reproduksi, adaptasi, distribusi, dan transmisi publik) dilisensikan secara non-eksklusif dan cuma-cuma, dan saat versi yang diubah didistribusikan, syarat yang sama harus dikenakan — struktur semacam copyleft. Hukum yang berlaku adalah hukum Jepang.
• Dulu repositori CVS dipublikasikan, tetapi CVS menjadi privat seiring dimulainya penyediaan edisi komersial, dan sekarang pada tanggal 1 setiap bulan sumber per tanggal 1 bulan sebelumnya dipublikasikan sebagai tarball. Yang dipublikasikan adalah tiga komponen — inti, biaya publik daerah, dan formulir publik — dengan seri 5.0, 5.1, dan 5.2 dipublikasikan secara paralel.
• Struktur pengembangan dan penyediaan juga khas. Membaca riwayat perbaikan sumber, di masa awal nama engineer NACL (kontraktor pengembangan) berjajar, lalu sekitar 2022 berganti menjadi commit atas nama ORCAMO (Japan Medical Association ORCA Management Organization). Layanan pendukung (dukungan, paket, manual, dan sebagainya) disediakan sebagai edisi komersial oleh ORCA Management Organization, sementara penerapan dan pemeliharaan ditanggung penyedia dukungan tersertifikasi di seluruh negeri — model pembagian kerja.

Jadi ORCA adalah perangkat lunak “open source, tetapi bukan pengembangan komunitas ala GitHub”. Sumber bisa dibaca, fork juga bisa, tetapi pengembangan arus utama dijalankan satu organisasi dengan cara seperti vendor. Mengingat domain medis, di mana kesalahan tidak boleh dan mengikuti aturan wajib, itu menurut saya titik kompromi yang masuk akal.

5. Stack teknologi: menghitung sendiri isi 4 juta baris COBOL

Mulai bab ini nama khas bertambah sekaligus, jadi tabel istilah diletakkan di depan. Bacalah bab-bab berikutnya dengan tabel ini di samping.

INSTALL.ja pada sumber seri 5.2 yang dipublikasikan mencantumkan perangkat lunak yang diperlukan seperti MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE, dan sebagainya. Ringkasan arsitekturnya sebagai berikut.

Kata-kata saja tidak menyampaikan skalanya, jadi berikut hasil menghitung snapshot seri 5.2 (sekitar 8.200 file, 237 MB setelah diekstrak).

Nama tabel database lugas, dan setelah terbiasa membacanya, bisnisnya langsung terlihat. Penamaan mencampur “singkatan Inggris” dan “romaji Jepang”, jadi bagian Jepang perlu dikembalikan ke kanji dulu agar artinya tertangkap. Yang utama adalah sebagai berikut.

Pembagian peran bab 1 — “pasien, asuransi, diagnosis, tindakan, poin” — diimplementasikan apa adanya sebagai struktur tabel. Dokumen definisi tabel dipublikasikan di situs resmi, jadi jika cara membacanya ragu, nama resmi dapat dikonfirmasi di sana.

Inti arsitekturnya adalah MONTSUQI. Di dalam Nichi-Rece, klien Java (monsiaj) menerima definisi layar dari server lalu menampilkannya, input diproses program COBOL di sisi server, dan PostgreSQL dibaca-tulis — pemrosesan terpusat klasik. Layar mana yang sesuai dengan program COBOL mana dideklarasikan secara deklaratif di file definisi LD pada direktori lddef/.

flowchart LR
    CL["monsiaj<br/>klien Java"] -->|"operasi layar"| MW["MONTSUQI<br/>application server"]
    API["Sistem pengintegrasi<br/>rekam medis elektronik, dll."] -->|"Nichi-Rece API (HTTP)"| MW
    MW -->|"didispatch menurut definisi lddef/*.ld"| AP["Kumpulan program bisnis<br/>sekitar 1.750 COBOL"]
    AP --> DB[("PostgreSQL<br/>285 tabel")]

Yang menarik: dispatch layar dan dispatch API berada di file definisi LD yang sama. Artinya Nichi-Rece API bukan server terpisah yang ditambahkan belakangan, melainkan diimplementasikan sebagai “pintu yang berkomunikasi lewat XML sebagai pengganti layar”, ditambahkan di atas platform program bisnis yang sama dengan layar interaktif. Detail desain ini dibahas di kelanjutan.

Kombinasi “COBOL + middleware khusus + PostgreSQL” tampak jauh dari rasa pengembangan web modern. Namun, header satu program COBOL mengukir riwayat perbaikan sejak 2002 sebagai komentar, dan sampai adaptasi aturan terkini seperti resep elektronik (2022) dan verifikasi kelayakan kartu asuransi My Number (2024), codebase yang sama terus mengikuti revisi lebih dari 20 tahun. Arsitektur ini juga hasil dioptimalkan untuk “sudah matang dan tetap berjalan”.

6. Cara menelusuri source tree: apa yang ada di mana

Sebagai peta saat benar-benar membaca sumber, berikut direktori utama tingkat atas.

Satu catatan praktis. Kode sumber memakai encoding EUC-JP (dokumen lisensi ISO-2022-JP). Membukanya di editor modern akan rusak, jadi dibaca lewat iconv -f EUC-JP -t UTF-8. Semacam kapsul waktu: standar lingkungan Linux tahun 2002 tersimpan apa adanya.

7. Pintu integrasi: Nichi-Rece API, PushAPI, CLAIM

Bagi engineer sistem eksternal yang menyentuh ORCA, pintunya secara praktis ada tiga.

1. Nichi-Rece API — rekomendasi saat ini. Sistem pengintegrasi mengirim permintaan HTTP untuk pengambilan informasi pasien, penerimaan, pendaftaran tindakan medis, dan sebagainya. Sisi baca pada dasarnya GET atau POST+XML; sisi ubah POST+XML. Spesifikasi API dipublikasikan di situs resmi.
2. PushAPI — mekanisme memberitahukan event yang terjadi di sisi Nichi-Rece (instruksi cetak formulir, dan sebagainya) ke sistem pengintegrasi. Koordinasi layar dapat dibuat event-driven, bukan polling.
3. CLAIM — lama dipakai sebagai protokol standar pertukaran informasi medis, tetapi dukungan berakhir pada Maret 2026. Pemrosesan CLAIM masih tersisa di sumber, tetapi integrasi CLAIM yang ada kini mengandaikan migrasi ke API.

Jadi, jika merancang integrasi ORCA sekarang, pilihannya hanya Nichi-Rece API. Dan seperti disinggung sebelumnya, API diimplementasikan di atas platform program bisnis COBOL yang sama dengan layar interaktif, jadi ketika “perilaku API tidak jelas”, bisa turun ke sumber dan memeriksanya. Prosedur konkret untuk memahami keseluruhan API dari sumber (termasuk endpoint yang tidak ada di daftar resmi) dijelaskan di artikel kelanjutan.

8. Apa yang berubah pada migrasi ke WebORCA

ORCA saat ini berada di masa transisi menuju “WebORCA”. Bentuk penyediaan secara besar ada dua.

• WebORCA versi cloud — memakai Nichi-Rece sebagai layanan cloud yang disediakan ORCA Management Organization. Fasilitas kesehatan dibebaskan dari pengelolaan server. Pendaftaran lewat penyedia dukungan tersertifikasi, dan menurut informasi resmi, dari pendaftaran sampai layanan mulai diperkirakan sekitar 3 minggu. Di sisi fasilitas, server tidak diletakkan di dalam institusi; pemakaian lewat browser, dan pembaruan program akibat revisi tarif pelayanan juga dilakukan sekaligus di sisi cloud. Tarifnya bulanan per satu fasilitas kesehatan.
• WebORCA versi on-premises — dipasang di server internal (Ubuntu). Lingkungan penyediaan saat ini adalah Nichi-Rece Ver5.2.0 di Ubuntu 22.04 (jammy).

Tentang linimasa migrasi, ada dua poin yang perlu dipahami.

Yang pertama: jalur migrasi disediakan secara resmi. ORCA Project memublikasikan “Panduan migrasi lingkungan operasi Nichi-Rece”, dan secara eksplisit menargetkan prosedur migrasi dari Nichi-Rece 5.1.0 / 5.2.0 tipe lama (versi MONTSUQI) yang berjalan di Ubuntu 16.04 / 18.04 / 20.04 menuju WebORCA versi on-premises (Ubuntu 22.04 + 5.2.0). Arah sebaliknya, yaitu migrasi ke OS yang lebih rendah atau versi Nichi-Rece yang lebih rendah, tidak dapat dilakukan.

Yang kedua: batas waktu seragam “semua fasilitas kesehatan harus ke WebORCA kapan” tidak diumumkan. Yang berlaku sebagai tenggat praktis adalah tanggal berakhir dukungan yang ditetapkan per kombinasi OS dan paket Nichi-Rece; itu dipublikasikan sebagai “Jadwal dukungan paket Nichi-Rece dan OS”, dan versi yang mendekati akhir diumumkan secara terpisah. Bagi pihak yang membuat sistem pengintegrasi, cara praktis memahami waktunya bukan “kapan migrasi ke WebORCA”, melainkan mengonfirmasi versi Ubuntu dan Nichi-Rece yang dipakai fasilitas mitra, serta tanggal berakhir dukungannya.

Yang penting: keduanya isinya Nichi-Rece yang sama. Perangkat lunak yang berjalan tidak menjadi barang berbeda menurut bentuk penyediaan; jenis API dan perilakunya pada dasarnya sama. Perbedaan yang perlu dipahami engineer pengintegrasi terkumpul bukan pada implementasi, melainkan di sekitar koneksi.

• Perbedaan pintu, misalnya versi cloud menambahkan prefiks /api pada path permintaan API, dan pengaturan informasi koneksi serta autentikasi berbeda per bentuk penyediaan. Spesifikasi API itu sendiri sama.
• Pada versi cloud, sistem pengintegrasi di dalam fasilitas memanggil API lewat internet, jadi desain jalur jaringan dan perilaku terdegradasi saat gangguan punya lebih banyak yang dipikirkan dibanding arsitektur on-premises.
• Sumber yang dipublikasikan setiap bulan menyertakan definisi untuk WebORCA apa adanya (contoh: file .db.weborca di bawah record/). Itu bukti source tree yang sama menopang kedua bentuk, dan pengetahuan yang diperoleh dari membaca sumber berlaku juga untuk versi cloud. Perhatikan bahwa pada versi .weborca ada definisi yang menyesuaikan, misalnya batas atas array respons, jadi saat memeriksa detail, cek juga ada-tidaknya definisi khusus WebORCA.

9. Ringkasan: poin yang perlu dipahami engineer

• ORCA (Nichi-Rece) bukan rekam medis elektronik, melainkan sistem billing medis. Memegang tulang punggung data sisi klaim — pasien, asuransi, diagnosis, tindakan, poin — dan pendapatan fasilitas kesehatan diklaim melalui sini.
• Kesulitan esensial sistem billing medis adalah mengikuti revisi tarif pelayanan dua tahunan selama puluhan tahun. Riwayat perbaikan sumber ORCA menjadi catatan nyata itu.
• Sistem bisnis open source yang berlanjut sejak Deklarasi IT JMA 2001, dengan sumber dipublikasikan setiap bulan sebagai tarball. Lisensinya bukan GPL, melainkan JMA OpenSource License.
• Isinya 1.754 COBOL, sekitar 4,06 juta baris + MONTSUQI + 285 tabel PostgreSQL (terukur pada seri 5.2). Layar dan API didispatch dengan definisi LD yang sama, arsitektur pemrosesan terpusat.
• Pintu integrasi eksternal saat ini adalah Nichi-Rece API. CLAIM berakhir dukungannya pada Maret 2026. Migrasi WebORCA sedang berjalan, tetapi versi cloud maupun versi on-premises isinya Nichi-Rece yang sama, dan pengetahuan dari sumber publik berlaku untuk keduanya.

Berikutnya, sumber yang dipublikasikan ini akan benar-benar dibaca, dan cara memahami keseluruhan Nichi-Rece API dari sumber (URL mana diproses program COBOL mana, endpoint apa yang tidak ada di daftar resmi) akan dijelaskan, lengkap dengan tabel korespondensi seluruh 137 endpoint.

10. Referensi

• Apa itu ORCA - ORCA Project
• Informasi teknis - JMA Standard Receipt Software - ORCA Project (publikasi kode sumber, spesifikasi API, dokumen definisi tabel)
• JMA Standard Receipt Software API - ORCA Project
• JMA Standard Receipt Software “ORCA” - Japan Medical Association ORCA Management Organization
• Tentang edisi komersial JMA Standard Receipt Software - Japan Medical Association ORCA Management Organization
• WebORCA versi cloud - ORCA Project
• JMA Standard Receipt Software [WebORCA versi cloud] - Japan Medical Association ORCA Management Organization (jalur pendaftaran, bentuk penyediaan, tarif)
• Panduan migrasi lingkungan operasi Nichi-Rece - ORCA Project (sasaran dan prosedur migrasi ke WebORCA versi on-premises)
• Untuk pengguna JMA Standard Receipt Software - ORCA Project (tempat “Jadwal dukungan paket Nichi-Rece dan OS” dipublikasikan)
• Sumber Nichi-Rece inti seri 5.2 (snapshot Juli 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc dan lainnya — semua nilai terukur di artikel ini didasarkan pada snapshot ini

Artikel terkait

Artikel terbaru dengan tag yang sama untuk mendalami topik-topik terdekat.

Topik terkait

Halaman-halaman ini menempatkan topik dalam konteks layanan dan keputusan yang lebih luas.

Layanan yang terkait dengan topik ini

Artikel ini berkaitan langsung dengan layanan berikut.

Pertanyaan yang sering diajukan

Pertanyaan yang sering muncul dalam konsultasi tentang topik artikel ini.

Apakah ORCA adalah rekam medis elektronik?

Tidak. JMA Standard Receipt Software (Nichi-Rece), yang menjadi inti proyek ORCA, adalah sistem billing medis yang menangani klaim biaya pelayanan (receipt). Rekam medis elektronik tempat catatan klinis ditulis adalah perangkat lunak terpisah, dan banyak fasilitas kesehatan memakai rekam medis elektronik dan ORCA yang diintegrasikan lewat API. Sebutan "rekam medis elektronik ORCA" lebih tepat dipahami sebagai nama populer yang muncul karena ORCA sering dipakai bersama rekam medis elektronik.

Apakah kode sumber ORCA (Nichi-Rece) dapat dibaca siapa pun?

Bisa. Kode sumber JMA Standard Receipt Software sendiri dipublikasikan di bawah JMA OpenSource License (perjanjian lisensi open source JMA), dan pada tanggal 1 setiap bulan snapshot per tanggal 1 bulan sebelumnya dapat diunduh sebagai tarball. Repositori CVS yang dulu ada menjadi privat seiring dimulainya penyediaan edisi komersial, tetapi publikasi sumber itu sendiri dilanjutkan.

Dengan teknologi apa ORCA dibuat?

Server berjalan di Linux, dan sebagian besar logika bisnis ditulis dalam COBOL. Databasenya PostgreSQL, platform eksekusi program bisnis memakai middleware open source bernama MONTSUQI (panda), dan klien memakai monsiaj yang ditulis dalam Java, dan sebagainya. Jika sumber seri 5.2 dihitung, COBOL saja sekitar 1.750 program dan lebih dari 4 juta baris, dengan lebih dari 280 tabel database.

Bagaimana rekam medis elektronik terintegrasi dengan ORCA?

Rekomendasi saat ini adalah Nichi-Rece API. Sistem pengintegrasi seperti rekam medis elektronik mengirim permintaan HTTP untuk mengambil informasi pasien, mendaftarkan tindakan medis, dan sebagainya. Ada juga PushAPI yang memberitahukan event dari sisi Nichi-Rece. Integrasi lewat CLAIM (standar pertukaran informasi medis), yang dipakai lama, berakhir dukungannya pada Maret 2026, jadi integrasi yang baru dibuat sebaiknya dirancang dengan asumsi API.

Profil penulis

Halaman perkenalan penulis artikel.

Go Komura

Direktur KomuraSoft LLC

Berspesialisasi dalam pengembangan perangkat lunak Windows, konsultasi teknis, dan investigasi bug, terutama pada proyek dengan sistem yang sudah ada dan bug yang sulit direproduksi.