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

Pernah mendengar sebutan “rekam medis elektronik ORCA”? Nama itu selalu 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 receipt” yang ditangani sistem billing medis, jika dilihat sebagai sistem
• Dengan teknologi apa dibuat, dan apa yang ada di sumber yang dipublikasikan
• Apa yang berubah dengan migrasi ke WebORCA, dan apa yang harus dipegang 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 dulu — ORCA adalah “sistem billing medis”
2. Apa itu pekerjaan receipt — cara tercepat memahaminya sebagai sistem
3. Diagram arsitektur sistem fasilitas kesehatan — di mana ORCA berada
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 masuk integrasi — Nichi-Rece API, PushAPI, CLAIM
8. Apa yang berubah dengan migrasi ke WebORCA
9. Ringkasan — poin yang harus dipegang engineer
10. Referensi

Peta pengetahuan artikel ini

ORCA (Nichi-Rece) bukan rekam medis elektronik, melainkan rececon yang menghitung biaya pelayanan medis dan membuat receipt, lalu terintegrasi dengan rekam medis elektronik lewat Nichi-Rece API. Logika bisnis Nichi-Rece ditulis dalam COBOL, berjalan di atas platform eksekusi MONTSUQI (panda) bersama klien Java monsiaj dan PostgreSQL, dan layar maupun API di-dispatch dengan definisi LD yang sama. Pintu masuk integrasi eksternal berpusat pada Nichi-Rece API dan PushAPI yang dipublikasikan di bawah JMA OpenSource License; CLAIM yang lama dipakai berakhir dukungannya pada Maret 2026, dan migrasi ke Nichi-Rece API menjadi prasyarat. Saat ini berada di masa transisi ke WebORCA edisi cloud dan on-premises; penggantian bertahap dari lingkungan penyediaan lama (edisi MONTSUQI) sedang berjalan, tetapi isinya di kedua bentuk adalah Nichi-Rece yang sama.

flowchart LR
    accTitle: Peta pengetahuan ORCA (Nichi-Rece)
    accDescr: Diagram yang menunjukkan pembagian peran ORCA (Nichi-Rece) sebagai rececon dengan rekam medis elektronik; stack COBOL, MONTSUQI, PostgreSQL, dan monsiaj beserta dispatch berdasarkan definisi LD; perubahan sarana integrasi Nichi-Rece API, PushAPI, dan CLAIM; serta relasi migrasi ke WebORCA edisi cloud dan on-premises
    orca_nichirese["ORCA (Nichi-Rece)"]
    receipt_computer["rececon (sistem billing medis)"]
    receipt["receipt (klaim biaya medis)"]
    electronic_medical_record["rekam medis elektronik"]
    orca_api["Nichi-Rece API"]
    cobol["COBOL"]
    montsuqi["MONTSUQI"]
    postgresql["PostgreSQL"]
    monsiaj["monsiaj"]
    ld_definition["definisi LD"]
    push_api["PushAPI"]
    claim_protocol["CLAIM (standar pertukaran informasi medis)"]
    jma_opensource_license["JMA OpenSource License"]
    weborca_cloud["WebORCA cloud edition"]
    weborca_onpremise["WebORCA on-premises edition"]
    legacy_nichirese_deployment["lingkungan penyediaan lama (edisi MONTSUQI)"]
    orca_nichirese -->|"mengimplementasikan"| receipt_computer
    receipt -->|"mensyaratkan"| receipt_computer
    electronic_medical_record -.->|"menggunakan"| orca_api
    orca_nichirese -->|"menggunakan"| cobol
    orca_nichirese -->|"menggunakan"| montsuqi
    orca_nichirese -->|"menggunakan"| postgresql
    orca_nichirese -->|"menggunakan"| monsiaj
    montsuqi -->|"dikonfigurasi dengan"| ld_definition
    orca_api -->|"dikonfigurasi dengan"| ld_definition
    orca_api -->|"mensyaratkan"| montsuqi
    monsiaj -->|"mensyaratkan"| montsuqi
    orca_nichirese -->|"menggunakan"| orca_api
    orca_nichirese -->|"menggunakan"| push_api
    orca_api -->|"penerus dari"| claim_protocol
    orca_nichirese -.->|"mensyaratkan"| jma_opensource_license
    weborca_cloud -->|"mengimplementasikan"| orca_nichirese
    weborca_onpremise -->|"mengimplementasikan"| orca_nichirese
    weborca_onpremise -->|"penerus dari"| legacy_nichirese_deployment
    legacy_nichirese_deployment -->|"menggunakan"| montsuqi

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 dulu — 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, receipt computer). Sistem billing medis menghitung biaya medis dari isi tindakan, lalu membuat receipt (klaim biaya medis) yang diajukan ke lembaga peninjau dan pembayaran.

Rekam medis elektronik dan sistem billing medis punya peran yang terpisah dengan jelas.

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

2. Apa itu pekerjaan receipt — cara tercepat memahaminya sebagai sistem

Cara tercepat memahami sistem billing medis adalah memahami aliran pendapatan fasilitas kesehatan. Dalam pelayanan medis 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 (pemeriksaan, tes, obat, prosedur, …) diinput, lalu kasir memakai biaya loket yang dihitung otomatis berdasarkan tabel poin.
2. Bulanan: tindakan satu bulan diagregasi per satuan pasien × asuransi, lalu receipt dibuat. Sebelum pengajuan, data dicek (konsistensi diagnosis dan resep, dll.), kemudian diajukan sebagai receipt 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 medis. Jika perangkat lunak tidak mengikuti revisi master poin, harga obat, dan aturan penghitungan, fasilitas kesehatan tidak dapat mengklaim dengan benar. Kesulitan esensial perangkat lunak sistem billing medis bukan UI atau skala, melainkan mengikuti aturan itu selama puluhan tahun. Riwayat perbaikan yang terukir di sumber ORCA, yang dibahas nanti, justru adalah catatan itu.

3. Diagram arsitektur sistem fasilitas kesehatan — di mana ORCA berada

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 medis)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"integrasi penerimaan dan janji"| ORCA
        ONS -->|"informasi kelayakan asuransi"| ORCA
    end
    ORCA -->|"receipt (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 receipt 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 “JMA IT Declaration” 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 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 peluncuran edisi komersial, dan sekarang pada tanggal 1 setiap bulan sumber per tanggal 1 bulan sebelumnya dipublikasikan sebagai tarball. Yang dipublikasikan adalah tiga komponen — inti, dukungan public-expense 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, dll.) 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 hidup bersama di file definisi LD yang sama. Artinya Nichi-Rece API bukan server terpisah yang ditambahkan belakangan, melainkan diimplementasikan sebagai “pintu masuk yang bercakap dalam 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 masuk integrasi — Nichi-Rece API, PushAPI, CLAIM

Bagi engineer sistem eksternal yang menyentuh ORCA, pintu masuknya 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, dll.) 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 dicek. Prosedur konkret untuk menangkap keseluruhan API dari sumber (termasuk endpoint yang tidak ada di daftar resmi) dijelaskan di artikel kelanjutan.

8. Apa yang berubah dengan migrasi ke WebORCA

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

• WebORCA cloud edition — 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 medis juga dilakukan sekaligus di sisi cloud. Tarifnya bulanan per satu fasilitas kesehatan.
• WebORCA on-premises edition — dipasang di server internal (Ubuntu). Lingkungan penyediaan saat ini adalah Nichi-Rece Ver5.2.0 di Ubuntu 22.04 (jammy).

Tentang sumbu waktu migrasi, ada dua poin yang harus dipegang.

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 (edisi MONTSUQI) yang berjalan di Ubuntu 16.04 / 18.04 / 20.04 menuju WebORCA on-premises edition (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 menangkap sumbu waktu 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 harus dipegang engineer pengintegrasi terkumpul bukan pada implementasi, melainkan di sekitar koneksi.

• Perbedaan pintu masuk, misalnya cloud edition menambahkan prefiks /api pada path permintaan API, dan pengaturan informasi koneksi serta autentikasi berbeda per bentuk penyediaan. Spesifikasi API itu sendiri sama.
• Pada cloud edition, sistem pengintegrasi di dalam institusi memanggil API lewat internet, jadi desain jalur jaringan dan perilaku terdegradasi saat gangguan punya lebih banyak yang dipikirkan dibanding arsitektur on-prem.
• 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 cloud edition. 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 harus dipegang 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 medis dua tahunan selama puluhan tahun. Riwayat perbaikan sumber ORCA menjadi catatan nyata itu.
• Sistem bisnis open source yang berlanjut sejak JMA IT Declaration 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 masuk integrasi eksternal saat ini adalah Nichi-Rece API. CLAIM berakhir dukungannya pada Maret 2026. Migrasi WebORCA sedang berjalan, tetapi cloud edition maupun on-premises edition isinya Nichi-Rece yang sama, dan pengetahuan dari sumber publik berlaku untuk keduanya.

Berikutnya, sumber yang dipublikasikan ini akan benar-benar dibaca, dan cara menangkap 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 cloud edition - ORCA Project
• JMA Standard Receipt Software [WebORCA cloud edition] - 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 on-premises edition)
• 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?

Bukan. JMA Standard Receipt Software (Nichi-Rece), yang menjadi inti proyek ORCA, adalah sistem billing medis (rececon) yang menangani klaim biaya medis (receipt). Rekam medis elektronik tempat catatan klinis ditulis adalah perangkat lunak terpisah, dan banyak fasilitas kesehatan memakai rekam medis elektronik yang diintegrasikan dengan ORCA 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?

Ya. Kode sumber JMA Standard Receipt Software sendiri dipublikasikan di bawah JMA OpenSource License, dan pada tanggal 1 setiap bulan snapshot per tanggal 1 bulan sebelumnya dapat diunduh sebagai tarball. Repositori CVS yang dulu ada menjadi privat seiring peluncuran 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. Database-nya 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.