ORCA(日レセ)は電子カルテではない ── エンジニア視点で整理するレセコンと医療システムの構成

「電子カルテのORCA」という言葉を聞いたことがあるでしょうか。医療機関向けシステムの案件に関わると必ず出てくる名前ですが、実はこの呼び方には誤解が含まれています。ORCA(日医標準レセプトソフト)は電子カルテではありません。

この記事は、医療ITの案件に初めて関わるエンジニアに向けて、次の疑問に答えることを目標にします。

• ORCAとは何で、医療機関のシステム構成のどこに位置するのか
• レセコンが担う「レセプト業務」とは、システム的に見ると何をしているのか
• どんな技術で作られていて、公開されているソースには何が入っているのか
• WebORCAへの移行で何が変わり、連携する側は何を押さえるべきか

記述はすべて公開されている一次情報に基づきます。ソースコードに関する記述は、公式公開されている日レセ本体 5.2系ソース(2026年7月1日公開スナップショット、VERSIONファイル表記5.2.0) を実際にダウンロードして確認した結果です。

目次

1. まず結論 ── ORCAは「レセコン」である
2. レセプト業務とは何か ── システム視点の最短理解
3. 医療機関のシステム構成図 ── ORCAはどこにいるのか
4. ORCAプロジェクトの歴史とライセンス
5. 技術スタック ── COBOL 400万行の中身を実際に数える
6. ソースツリーの歩き方 ── どこに何があるか
7. 連携の入口 ── 日レセAPI・PushAPI・CLAIM
8. WebORCAへの移行で何が変わるか
9. まとめ ── エンジニアが押さえるべきポイント
10. 参考資料

1. まず結論 ── ORCAは「レセコン」である

ORCAプロジェクトの中心である「日医標準レセプトソフト」(略して日レセ)は、レセコン(レセプトコンピュータ)です。レセコンは、診療内容をもとに診療報酬を計算し、審査支払機関へ提出するレセプト(診療報酬明細書)を作成する業務システムです。

電子カルテとレセコンは役割がはっきり分かれています。

「電子カルテのORCA」という通称が生まれたのは、多くの電子カルテ製品が「レセコン部分はORCAと連携」という構成を取ってきたためです。エンジニアとしては、ORCA=請求系の基幹、電子カルテ=診療記録系という区別を最初に押さえておくと、以降の話がすべて整理しやすくなります。

2. レセプト業務とは何か ── システム視点の最短理解

レセコンが何のシステムかを理解するには、医療機関の収入の流れを知るのが早道です。日本の保険診療では、患者が窓口で払うのは原則1〜3割で、残りは医療機関が審査支払機関(社会保険診療報酬支払基金・国民健康保険団体連合会)へ月単位で請求します。この請求書がレセプトです。

システム的に見ると、レセコンは次の月次バッチサイクルを回す装置です。

1. 日次: 受付で保険資格を確認し、診療行為(診察・検査・投薬・処置…)を入力し、点数表に基づいて自動計算した窓口負担額で会計する。
2. 月次: 1か月分の診療行為を患者×保険の単位で集計し、レセプトを作成する。提出前にデータチェック(病名と処方の整合性など)を行い、電子レセプト(レセ電データ)として提出する。
3. 翌月以降: 審査で差し戻された「返戻」や減点された「査定」に対応し、修正して再請求する。

ここで重要なのは、点数計算のルールが2年ごとの診療報酬改定で変わることです。点数マスタ・薬価・算定ルールの改定にソフトウェアが追従できなければ、医療機関は正しく請求できません。レセコンというソフトウェアの本質的な難しさは、UIでもスケールでもなく、この制度追従を何十年も続けることにあります。後述するORCAのソースに刻まれた修正履歴は、まさにその記録です。

3. 医療機関のシステム構成図 ── ORCAはどこにいるのか

診療所の典型的な構成を図にすると、ORCA(日レセ)は院内システムのハブに近い位置にいます。

flowchart LR
    subgraph clinic["医療機関内"]
        EMR["電子カルテ<br/>診療記録・オーダー"]
        RSV["受付・予約システム"]
        ONS["オンライン資格確認端末"]
        ORCA["ORCA/日レセ<br/>レセコン(診療報酬請求)"]
        EMR -->|"日レセAPI(HTTP)"| ORCA
        RSV -->|"受付・予約連携"| ORCA
        ONS -->|"保険資格情報"| ORCA
    end
    ORCA -->|"レセプト(月次請求)"| PAY["審査支払機関<br/>支払基金・国保連合会"]

ポイントは次の3つです。

• 患者基本情報と保険情報のマスタはORCA側が持つ構成が多い。電子カルテはAPIで参照・更新する。患者番号の採番をどちらが握るかは、連携設計の最初の論点になる。
• 診療行為(何をしたか)は電子カルテからORCAへ送られ、ORCAが点数計算をして会計・請求につなげる。電子カルテは「オーダーの言葉」で、ORCAは「点数の言葉」で診療を記述するので、その変換(診療行為コードのマッピング)が連携の実務的な山場になる。
• 月次のレセプト提出はORCAの仕事。つまり医療機関の売上はORCAを通って請求される。連携ミスは診療記録の欠落ではなく請求金額の誤りとして現れる、という緊張感がこの領域の特徴。

4. ORCAプロジェクトの歴史とライセンス

ORCAは日本医師会(日医)のプロジェクトです。2001年11月の「日医IT化宣言」で、日本医師会が作るソフトウェアをオープンソースとして公開する方針が示され、その中心として開発されたのが日レセでした。2002年から医療現場での利用が始まり、以来20年以上にわたって開発が続いています。

エンジニア視点で特筆すべきは、業務システムのソースコードが20年以上公開され続けていることです。

• ライセンスは、ソースに同梱されている日医オープンソース使用許諾契約(JMA OpenSource License version 1.0)。GPLではなく日医独自の契約で、プログラムの使用(複製・翻案・頒布・公衆送信を含む)が非独占的かつ無償で許諾され、変更版の頒布時には同一条件を課す、というコピーレフト的な構造を持ちます。準拠法は日本法です。
• かつてはCVSリポジトリが公開されていましたが、商用版の提供開始に伴いCVSは非公開となり、現在は毎月1日に前月1日時点のソースがtarボールで公開される方式です。公開対象は本体・地域公費・公開帳票の3コンポーネントで、5.0系・5.1系・5.2系が並行して公開されています。
• 開発・提供体制も特徴的です。ソースの修正履歴を読むと、初期はNACL(開発受託元)のエンジニア名が並び、2022年頃からはORCAMO(日本医師会ORCA管理機構)名義のコミットに変わっていきます。周辺サービス(サポート、パッケージ、マニュアル等)は商用版としてORCA管理機構が提供し、導入・保守は全国の認定サポート事業者が担う、という分業モデルです。

つまりORCAは「オープンソースだが、GitHub的なコミュニティ開発ではない」ソフトウェアです。ソースは読める、フォークもできる、しかし本流の開発は単一の主体がベンダー的に進める──医療という、間違いが許されず制度追従が必須の領域を考えると、合理的な落とし所だと思います。

5. 技術スタック ── COBOL 400万行の中身を実際に数える

公開されている5.2系ソースのINSTALL.jaには、必要なソフトウェアとしてMONTSUQI(panda)、OpenCOBOL、PostgreSQL、MONPEなどが並びます。構成を要約すると次のとおりです。

言葉だけだと規模感が伝わらないので、5.2系スナップショット(展開後 約8,200ファイル・237MB)を実際に数えた結果を挙げます。

データベースのテーブル名は素直で、読み慣れると業務がそのまま見えてきます。たとえばtbl_ptinf(患者基本情報)、tbl_ptbyomei(患者病名)、tbl_uketuke(受付)、tbl_jyurrk(受療履歴)、tbl_tensu(点数マスタ)、tbl_syskanri(システム管理)といった具合です。「患者・保険・病名・診療行為・点数」という第1章の役割分担が、テーブル構成としてそのまま実装されているわけです。

アーキテクチャの要はMONTSUQIです。日レセの内部は、Javaクライアント(monsiaj)がサーバーから画面定義を受け取って表示し、入力をサーバー側のCOBOLプログラムが処理してPostgreSQLを読み書きする、という古典的な集中処理型です。どの画面がどのCOBOLプログラムに対応するかは、lddef/ディレクトリのLD定義ファイルに宣言的に書かれています。

flowchart LR
    CL["monsiaj<br/>Javaクライアント"] -->|"画面操作"| MW["MONTSUQI<br/>アプリケーションサーバー"]
    API["連携システム<br/>電子カルテなど"] -->|"日レセAPI(HTTP)"| MW
    MW -->|"lddef/*.ld の定義で振り分け"| AP["業務プログラム群<br/>COBOL 約1,750本"]
    AP --> DB[("PostgreSQL<br/>285テーブル")]

興味深いのは、画面のディスパッチとAPIのディスパッチが同じLD定義ファイルに同居していることです。つまり日レセAPIは後付けの別サーバーではなく、対話画面と同じ業務プログラム基盤の上に「画面の代わりにXMLで会話する入口」を追加したものとして実装されています。この設計の詳細は続編で扱います。

「COBOL+専用ミドルウェア+PostgreSQL」という構成は、モダンなWeb開発の感覚からは遠く見えます。しかし、1本のCOBOLプログラムのヘッダには2002年からの修正履歴がコメントで刻まれており、電子処方箋(2022年)やマイナ保険証の資格確認(2024年)といった直近の制度対応まで、同じコードベースが20年以上改定に追従し続けていることが読み取れます。この構成は「枯れて動き続けること」に最適化されてきた結果でもあります。

6. ソースツリーの歩き方 ── どこに何があるか

実際にソースを読むときの地図として、トップレベルの主要ディレクトリを整理しておきます。

実務上の注意をひとつ。ソースの文字コードはEUC-JP(ライセンス文書はISO-2022-JP)です。現代のエディタで開くと化けるので、iconv -f EUC-JP -t UTF-8を通して読むことになります。2002年当時のLinux環境の標準がそのまま保存されている、ある種のタイムカプセルです。

7. 連携の入口 ── 日レセAPI・PushAPI・CLAIM

外部システムのエンジニアがORCAに触るときの入口は、実質的に次の3つでした。

1. 日レセAPI ── 現在の推奨。連携システムがHTTPでリクエストを送り、患者情報取得・受付・診療行為登録などを行う。読み取り系はGETまたはPOST+XML、更新系はPOST+XMLが基本。公式サイトにAPI仕様が公開されている。
2. PushAPI ── 日レセ側で起きたイベント(帳票印刷指示など)を連携システムへ通知する仕組み。ポーリングではなくイベント駆動で画面連動を作れる。
3. CLAIM ── 医療情報交換の標準規約として長く使われてきたが、2026年3月でサポート終了。ソース上にはまだCLAIM系の処理が残っているが、既存のCLAIM連携はAPIへの移行が前提となった。

つまり、これからORCA連携を設計するなら日レセAPI一択です。そして先に触れたとおり、APIは対話画面と同じCOBOL業務プログラム基盤の上に実装されているため、「APIの挙動が分からない」ときはソースまで降りて確認できます。APIの全体像(公式一覧に載っていないエンドポイントを含む)をソースから把握する具体的な手順は、続編の記事で解説します。

8. WebORCAへの移行で何が変わるか

現在のORCAは「WebORCA」への移行期にあります。提供形態は大きく2つです。

• WebORCAクラウド版 ── ORCA管理機構が提供するクラウドサービスとして日レセを利用する形態。医療機関はサーバー管理から解放される。
• WebORCAオンプレ版 ── 院内サーバー(Ubuntu)にインストールして利用する形態。

重要なのは、どちらも中身は同じ日レセだということです。動いているソフトウェアが提供形態によって別物になるわけではなく、APIの種類も挙動も基本的に共通です。連携するエンジニアが押さえるべき違いは、実装ではなく接続まわりに集約されます。

• APIのリクエスト先パスにクラウド版は/apiプレフィックスが付く、接続情報・認証の設定が提供形態ごとに異なる、といった入口の違い。APIそのものの仕様は共通。
• クラウド版では、院内の連携システムがインターネット越しにAPIを呼ぶ構成になるため、ネットワーク経路や障害時の縮退動作の設計は、オンプレ構成より考えることが増える。
• 毎月公開されるソースにはWebORCA用の定義もそのまま含まれている(例: record/配下の.db.weborcaファイル)。同じソースツリーが両形態を支えている証拠であり、ソースを読んで得た知見はクラウド版に対しても通用する。なお.weborca版ではレスポンスの配列上限などが調整されている定義があるので、細部を確認するときはWebORCA用定義の有無も見る。

9. まとめ ── エンジニアが押さえるべきポイント

• ORCA(日レセ)は電子カルテではなくレセコン。患者・保険・病名・診療行為・点数という請求系データの基幹を握り、医療機関の売上はここを通って請求される。
• レセコンの本質的な難しさは2年ごとの診療報酬改定への追従を何十年も続けること。ORCAのソースの修正履歴はその実録になっている。
• 2001年の日医IT化宣言から続くオープンソースの業務システムで、ソースは毎月tarボールで公開。ライセンスはGPLではなく日医オープンソース使用許諾契約。
• 中身はCOBOL 1,754本・約406万行+MONTSUQI+PostgreSQL 285テーブル(5.2系実測)。画面もAPIも同じLD定義でディスパッチされる集中処理型アーキテクチャ。
• 外部連携は日レセAPIが現在の入口。CLAIMは2026年3月でサポートを終えた。WebORCA移行が進行中だが、クラウド版もオンプレ版も中身は同じ日レセであり、公開ソースから得た知見はどちらにも通用する。

次回は、この公開ソースコードを実際に読み、日レセAPIの全体像(どのURLがどのCOBOLプログラムで処理されるのか、公式一覧に載っていないエンドポイントは何か)をソースから把握する方法を、全137エンドポイントの対応表付きで解説します。

10. 参考資料

• ORCAとは - ORCA Project
• 技術情報 - 日医標準レセプトソフト - ORCA Project(ソースコード公開・API仕様・テーブル定義書)
• 日医標準レセプトソフトAPI - ORCA Project
• 日医標準レセプトソフト「ORCA」 - 日本医師会ORCA管理機構
• 日医標準レセプトソフト商用版について - 日本医師会ORCA管理機構
• WebORCAクラウド版 - ORCA Project
• 日レセ本体 5.2系ソースコード(2026年7月公開スナップショット) INSTALL.ja / doc/license.html / lddef/orcadb.inc ほか ── 本文中の実測値はすべてこのスナップショットに基づく

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

ORCAは電子カルテですか？

いいえ。ORCAプロジェクトの中心である日医標準レセプトソフト(日レセ)は、診療報酬請求(レセプト)を担当するレセコンです。診療記録を書く電子カルテは別のソフトウェアで、多くの医療機関では電子カルテとORCAをAPIで連携させて使います。「電子カルテのORCA」という言い方は、電子カルテと連携して使われることが多いために生まれた通称と考えるのが正確です。

ORCA(日レセ)のソースコードは誰でも読めますか？

読めます。日医標準レセプトソフト本体のソースコードは、日医オープンソース使用許諾契約(JMA OpenSource License)のもとで公開されており、毎月1日に前月1日時点のスナップショットがtarボールとしてダウンロードできます。かつてのCVSリポジトリは商用版の提供開始に伴い非公開になりましたが、ソース公開自体は継続されています。

ORCAはどんな技術で作られていますか？

サーバーはLinux上で動作し、業務ロジックの大部分はCOBOLで書かれています。データベースはPostgreSQL、業務プログラムの実行基盤にはMONTSUQI(panda)というオープンソースのミドルウェアを使い、クライアントにはJava製のmonsiajなどが使われます。5.2系のソースを数えると、COBOLだけで約1,750本・400万行超、データベースは280超のテーブルという規模です。

電子カルテとORCAはどうやって連携しますか？

現在の推奨は日レセAPIです。電子カルテなどの連携システムがHTTPでリクエストを送り、患者情報の取得や診療行為の登録などを行います。日レセ側からイベントを通知するPushAPIもあります。以前から使われてきたCLAIM(医療情報交換規約)による連携は2026年3月でサポートが終了したため、これから作る連携はAPI前提で設計するのが妥当です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。