ORCA (Nichi-Rece) Is Not an Electronic Medical Record System — Medical Billing Systems and Healthcare IT Architecture from an Engineer's Perspective

Have you ever heard the phrase “the ORCA electronic medical record”? It is a name that comes up without fail on any project involving systems for medical institutions — but the phrasing contains a misconception. ORCA (the JMA Standard Receipt Software) is not an electronic medical record system.

This article is aimed at engineers encountering healthcare IT work for the first time, and sets out to answer the following questions.

• What is ORCA, and where does it sit in the system architecture of a medical institution?
• What is the “receipt work” a medical billing system handles actually doing, in system terms?
• What technologies is it built with, and what is in the source code that is published?
• What changes with the move to WebORCA, and what should an integrator be aware of?

Everything here is based on published primary sources. Statements about the source code are the result of actually downloading and inspecting the officially published Nichi-Rece 5.2 series source (the snapshot published on 1 July 2026, VERSION file reading 5.2.0).

Table of Contents

1. The Bottom Line First — ORCA Is a “Medical Billing System”
2. What Receipt Work Is — The Shortest Path to Understanding It as a System
3. The System Architecture of a Medical Institution — Where ORCA Sits
4. The History and Licence of the ORCA Project
5. The Technology Stack — Actually Counting the Four Million Lines of COBOL
6. Navigating the Source Tree — What Lives Where
7. Integration Entry Points — The Nichi-Rece API, PushAPI, and CLAIM
8. What Changes with the Move to WebORCA
9. Summary — The Points Engineers Should Grasp
10. References

1. The Bottom Line First — ORCA Is a “Medical Billing System”

The “JMA Standard Receipt Software” (Nichi-Rece for short), which sits at the centre of the ORCA project, is a medical billing system (in Japanese, a receipt computer or rececon). A medical billing system calculates the medical fee due from what was clinically performed and produces the receipt (medical fee claim) submitted to the claims review and payment organisations.

Electronic medical record systems and medical billing systems have clearly separated roles.

The nickname “the ORCA electronic medical record” arose because many electronic medical record products have been built around a “the billing part integrates with ORCA” architecture. As an engineer, once you fix the distinction — ORCA = the backbone of the claims side, electronic medical record = the clinical record side — everything that follows falls into place much more easily.

2. What Receipt Work Is — The Shortest Path to Understanding It as a System

The quickest way to understand what kind of system a medical billing system is, is to understand how revenue flows through a medical institution. Under Japan’s insured medical care, the patient pays only 10–30 per cent at the counter as a rule, and the remainder is claimed monthly by the medical institution from the claims review and payment organisations (the Social Insurance Medical Fee Payment Fund and the National Health Insurance Organisations). That claim document is the receipt.

Viewed as a system, a medical billing system is a machine that turns the following monthly batch cycle.

1. Daily: reception verifies insurance eligibility, medical procedures (consultation, tests, prescriptions, treatments, and so on) are entered, and the patient is billed the counter charge automatically calculated from the fee schedule.
2. Monthly: a month’s worth of procedures is aggregated per patient × insurance combination and turned into receipts. Before submission, a data check is run (consistency between diagnoses and prescriptions, and so on) and the result is submitted as electronic receipt data (rece-den data).
3. The following month and beyond: handle claims sent back by the review process (henrei, returned claims) and claims reduced on assessment (satei), correct them and re-submit.

The important thing here is that the rules for calculating fee points change with the biennial medical fee revision. If the software cannot keep up with revisions to the fee master, drug prices, and calculation rules, the medical institution cannot claim correctly. The essential difficulty of a medical billing system is not the UI and not scale — it is sustaining that regulatory compliance for decades. The revision histories carved into ORCA’s source, discussed below, are precisely that record.

3. The System Architecture of a Medical Institution — Where ORCA Sits

Drawn out, the typical architecture of a clinic puts ORCA (Nichi-Rece) close to the hub of the in-house systems.

flowchart LR
    subgraph clinic["Inside the medical institution"]
        EMR["Electronic medical record<br/>clinical records & orders"]
        RSV["Reception & appointment system"]
        ONS["Online eligibility verification terminal"]
        ORCA["ORCA/Nichi-Rece<br/>medical billing system (medical fee claims)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"reception & appointment integration"| ORCA
        ONS -->|"insurance eligibility information"| ORCA
    end
    ORCA -->|"receipts (monthly claims)"| PAY["Claims review & payment organisations<br/>Payment Fund & NHI Organisations"]

There are three points to note.

• In most architectures, the master data for patients and insurance lives on the ORCA side. The electronic medical record system reads and updates it through the API. Which side owns the allocation of patient numbers is the first point of contention in any integration design.
• Medical procedures (what was done) are sent from the electronic medical record system to ORCA, and ORCA performs the fee point calculation that feeds billing and claims. The electronic medical record system describes care in the “language of orders” and ORCA in the “language of fee points”, so translating between them (mapping procedure codes) is the practical crux of the integration.
• Monthly receipt submission is ORCA’s job. In other words, a medical institution’s revenue is claimed through ORCA. Integration mistakes surface not as missing clinical records but as wrong claim amounts — that tension is characteristic of this domain.

4. The History and Licence of the ORCA Project

ORCA is a project of the Japan Medical Association (JMA). The “JMA IT Declaration” of November 2001 set out the policy that software built by the Japan Medical Association would be released as open source, and Nichi-Rece was developed as the centrepiece of that policy. Use in clinical settings began in 2002, and development has continued for over twenty years since.

What is remarkable from an engineer’s point of view is that the source code of a line-of-business system has been published continuously for more than twenty years.

• The licence is the JMA OpenSource License version 1.0, bundled with the source. It is not GPL but the JMA’s own agreement: use of the program (including reproduction, adaptation, distribution, and public transmission) is granted non-exclusively and free of charge, and distributing a modified version imposes the same terms — a copyleft-like structure. The governing law is Japanese law.
• A CVS repository used to be public, but CVS was taken private when the commercial edition launched. The current arrangement is that on the first of every month the source as of the first of the previous month is published as a tarball. Three components are published — the main product, regional public-expense support, and public forms — and the 5.0, 5.1, and 5.2 series are published in parallel.
• The development and delivery structure is distinctive too. Read the revision histories in the source and you find engineer names from NACL (the development contractor) in the early years, shifting from around 2022 to commits under the name of ORCAMO (the Japan Medical Association ORCA Management Organization). Peripheral services (support, packaging, manuals, and so on) are provided by the ORCA Management Organization as the commercial edition, while rollout and maintenance are handled by certified support providers across the country — a division-of-labour model.

ORCA is therefore software that is “open source, but not GitHub-style community development”. You can read the source, you can fork it, but the mainline is driven by a single body in a vendor-like fashion. Given a domain such as healthcare, where mistakes are unacceptable and regulatory compliance is mandatory, I think that is a reasonable place to land.

5. The Technology Stack — Actually Counting the Four Million Lines of COBOL

INSTALL.ja in the published 5.2 series source lists MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE and others as required software. Summarised, the architecture is as follows.

Words alone do not convey the scale, so here are the results of actually counting the 5.2 series snapshot (roughly 8,200 files and 237 MB once extracted).

The database table names are refreshingly plain, and once you get used to reading them the business shows through directly. For instance tbl_ptinf (patient master data), tbl_ptbyomei (patient diagnoses), tbl_uketuke (reception), tbl_jyurrk (treatment history), tbl_tensu (fee point master), tbl_syskanri (system management). The division of roles from Section 1 — patient, insurance, diagnosis, procedure, fee points — is implemented directly as the table structure.

The keystone of the architecture is MONTSUQI. Internally, Nichi-Rece is a classic centralised-processing system: the Java client (monsiaj) receives screen definitions from the server and renders them, input is processed by COBOL programs on the server, and those read and write PostgreSQL. Which screen corresponds to which COBOL program is declared in the LD definition files in the lddef/ directory.

flowchart LR
    CL["monsiaj<br/>Java client"] -->|"screen interaction"| MW["MONTSUQI<br/>application server"]
    API["Integrating system<br/>e.g. electronic medical record"] -->|"Nichi-Rece API (HTTP)"| MW
    MW -->|"dispatched by definitions in lddef/*.ld"| AP["Business programs<br/>approx. 1,750 COBOL sources"]
    AP --> DB[("PostgreSQL<br/>285 tables")]

What is interesting is that screen dispatch and API dispatch live in the same LD definition file. In other words, the Nichi-Rece API is not a separate server bolted on afterwards; it is implemented as an “entry point that converses in XML instead of via a screen”, added on top of the same business program platform as the interactive screens. The details of this design are covered in the follow-up article.

The combination “COBOL + bespoke middleware + PostgreSQL” looks a long way from the sensibilities of modern web development. And yet the header of a single COBOL program carries a revision history in comments going back to 2002, right through to recent regulatory work such as electronic prescriptions (2022) and My Number health insurance card eligibility verification (2024) — you can read off the fact that the same codebase has kept up with revisions for over twenty years. This architecture is also the result of optimising for “being mature and continuing to run”.

6. Navigating the Source Tree — What Lives Where

As a map for actually reading the source, here are the main top-level directories.

One practical warning. The source is encoded in EUC-JP (the licence document is ISO-2022-JP). Opening it in a modern editor gives you mojibake, so you end up reading it through iconv -f EUC-JP -t UTF-8. It is a kind of time capsule in which the standard of the Linux environment of 2002 has been preserved as-is.

7. Integration Entry Points — The Nichi-Rece API, PushAPI, and CLAIM

For an engineer on an external system touching ORCA, there have effectively been three entry points.

1. The Nichi-Rece API — the current recommendation. The integrating system sends HTTP requests to fetch patient information, register reception, register medical procedures, and so on. Read operations are basically GET or POST + XML; write operations are POST + XML. The API specification is published on the official site.
2. PushAPI — a mechanism for notifying the integrating system of events occurring on the Nichi-Rece side (form print instructions, for example). It lets you build screen-level coordination event-driven rather than by polling.
3. CLAIM — long used as the standard protocol for medical information exchange, but support ended in March 2026. CLAIM-related processing still remains in the source, but existing CLAIM integrations are now premised on migrating to the API.

In short, if you are designing an ORCA integration now, the Nichi-Rece API is the only choice. And as noted above, because the API is implemented on the same COBOL business program platform as the interactive screens, when “the API’s behaviour isn’t clear” you can descend into the source and check. The concrete procedure for grasping the whole API surface from the source (including endpoints that do not appear in the official list) is explained in the follow-up article.

8. What Changes with the Move to WebORCA

ORCA is currently in a transition period towards “WebORCA”. There are broadly two delivery forms.

• WebORCA cloud edition — using Nichi-Rece as a cloud service provided by the ORCA Management Organization. The medical institution is freed from server administration.
• WebORCA on-premises edition — installed on an in-house server (Ubuntu).

The important thing is that both are the same Nichi-Rece inside. The software running does not become a different product depending on the delivery form; the set of APIs and their behaviour are fundamentally common to both. The differences an integrating engineer needs to be aware of are concentrated not in the implementation but around connectivity.

• Entry-point differences such as the cloud edition prefixing API request paths with /api, and connection and authentication settings differing per delivery form. The API specification itself is common.
• With the cloud edition, in-house integrating systems call the API across the internet, so network routing and degraded-mode behaviour during outages take more design thought than an on-premises architecture.
• The monthly source release includes the WebORCA definitions as well (for example the .db.weborca files under record/). That is evidence that a single source tree supports both delivery forms, and it means knowledge gained by reading the source applies to the cloud edition too. Note that some .weborca definitions adjust things like response array limits, so when you are checking details, look for whether a WebORCA-specific definition exists.

9. Summary — The Points Engineers Should Grasp

• ORCA (Nichi-Rece) is not an electronic medical record system but a medical billing system. It owns the backbone of the claims-side data — patient, insurance, diagnosis, procedure, fee points — and a medical institution’s revenue is claimed through it.
• The essential difficulty of a medical billing system is sustaining compliance with the biennial medical fee revision for decades. The revision histories in ORCA’s source are the documentary record of exactly that.
• It is an open-source line-of-business system running since the JMA IT Declaration of 2001, with the source published monthly as a tarball. The licence is not GPL but the JMA OpenSource License.
• Inside, it is 1,754 COBOL sources totalling roughly 4.06 million lines, plus MONTSUQI, plus 285 PostgreSQL tables (measured on the 5.2 series). Screens and APIs are dispatched through the same LD definitions in a centralised-processing architecture.
• The Nichi-Rece API is the current entry point for external integration. CLAIM reached end of support in March 2026. The WebORCA migration is under way, but both the cloud and on-premises editions are the same Nichi-Rece inside, so knowledge gained from the published source applies to either.

Next time, we will actually read this published source code and explain how to grasp the whole picture of the Nichi-Rece API from the source — which URL is handled by which COBOL program, and what endpoints are missing from the official list — complete with a mapping table of all 137 endpoints.

10. References

• What Is ORCA - ORCA Project
• Technical Information - JMA Standard Receipt Software - ORCA Project (source code releases, API specifications, table definition documents)
• JMA Standard Receipt Software API - ORCA Project
• JMA Standard Receipt Software “ORCA” - Japan Medical Association ORCA Management Organization
• About the Commercial Edition of the JMA Standard Receipt Software - Japan Medical Association ORCA Management Organization
• WebORCA Cloud Edition - ORCA Project
• Nichi-Rece 5.2 series source code (snapshot published July 2026) INSTALL.ja / doc/license.html / lddef/orcadb.inc and others — all measured figures in this article are based on this snapshot

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is ORCA an electronic medical record system?

No. The JMA Standard Receipt Software (Nichi-Rece), which sits at the centre of the ORCA project, is a medical billing system responsible for medical fee claims (receipts). The electronic medical record system that clinical notes are written into is separate software, and most medical institutions use an electronic medical record system integrated with ORCA via an API. The phrase "the ORCA electronic medical record" is best understood as a nickname that arose because ORCA is so often used alongside one.

Can anyone read the source code of ORCA (Nichi-Rece)?

Yes. The source code of the JMA Standard Receipt Software itself is published under the JMA OpenSource License, and on the first of every month a snapshot as of the first of the previous month can be downloaded as a tarball. The old CVS repository was taken private when the commercial edition launched, but the source release itself has continued.

What technologies is ORCA built with?

The server runs on Linux, and the bulk of the business logic is written in COBOL. The database is PostgreSQL, the execution platform for the business programs is an open-source middleware called MONTSUQI (panda), and the client is typically monsiaj, written in Java. Counting the 5.2 series source, COBOL alone accounts for roughly 1,750 programs and over four million lines, with more than 280 database tables.

How does an electronic medical record system integrate with ORCA?

The current recommendation is the Nichi-Rece API. The integrating system — the electronic medical record system, for example — sends HTTP requests to fetch patient information, register medical procedures, and so on. There is also a PushAPI through which Nichi-Rece notifies events outward. Integration via CLAIM (the medical information exchange standard), used for many years, reached end of support in March 2026, so any new integration should be designed on the assumption of the API.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.