ORCA (Nichi-Rece) — это не электронная медицинская карта: система медицинского биллинга и архитектура ИТ в медицине глазами инженера

Слышали выражение «электронная карта ORCA»? В проектах по системам для медицинских организаций это имя всплывает почти неизбежно, но в самой формулировке уже сидит недоразумение. ORCA (JMA Standard Receipt Software) — это не электронная медицинская карта.

Статья рассчитана на инженеров, которые впервые заходят в медицинский ИТ, и отвечает на такие вопросы.

• Что такое ORCA и где он стоит в архитектуре систем медицинской организации
• Что с системной точки зрения делает «работа со счетами», за которую отвечает система медицинского биллинга
• На каких технологиях он собран и что лежит в опубликованных исходниках
• Что меняется при переходе на WebORCA и что важно стороне интеграции

Всё ниже опирается на открытые первоисточники. Утверждения про исходный код — результат фактической загрузки и просмотра официально опубликованных исходников линейки Nichi-Rece 5.2 (снимок от 1 июля 2026 года, в файле VERSION указано 5.2.0).

Оглавление

1. Сначала вывод — ORCA это система медицинского биллинга
2. Что такое работа со счетами — самое короткое системное понимание
3. Схема систем медицинской организации — где стоит ORCA
4. История проекта ORCA и лицензия
5. Технологический стек — считаем 4 млн строк COBOL по факту
6. Как ходить по дереву исходников — что где лежит
7. Точки входа интеграции — Nichi-Rece API, PushAPI, CLAIM
8. Что меняется при переходе на WebORCA
9. Итог — что инженеру стоит держать в голове
10. Источники

Карта знаний этой статьи

ORCA (Nichi-Rece) — это не электронная медицинская карта, а система медицинского биллинга, которая считает тариф медицинской помощи и формирует счета (receipt); с электронной картой она связывается через Nichi-Rece API. Бизнес-логика Nichi-Rece написана на COBOL и работает на среде выполнения MONTSUQI (panda) вместе с Java-клиентом monsiaj и PostgreSQL; и экраны, и API диспетчеризуются одними и теми же LD-определениями. Главный вход внешней интеграции — Nichi-Rece API и PushAPI, публикуемые по договору JMA OpenSource License; CLAIM, которым пользовались много лет, закончил поддержку в марте 2026 года, и переход на Nichi-Rece API стал исходной предпосылкой. Сейчас идёт переходный период к облачной и локальной редакциям WebORCA: классическую среду поставки (редакция MONTSUQI) постепенно заменяют, но внутри в обоих случаях это тот же Nichi-Rece.

flowchart LR
    accTitle: Карта знаний ORCA (Nichi-Rece)
    accDescr: Рисунок, показывающий разделение ролей между ORCA (Nichi-Rece) как системой медицинского биллинга и электронной медицинской картой; технологический стек COBOL, MONTSUQI, PostgreSQL и monsiaj с диспетчеризацией по LD-определениям; смену средств интеграции — Nichi-Rece API, PushAPI и CLAIM; и переход на облачную и локальную редакции WebORCA
    orca_nichirese["ORCA (Nichi-Rece)"]
    receipt_computer["rececon (система счетов)"]
    receipt["счёт за медпомощь (receipt)"]
    electronic_medical_record["электронная медкарта"]
    orca_api["Nichi-Rece API"]
    cobol["COBOL"]
    montsuqi["MONTSUQI"]
    postgresql["PostgreSQL"]
    monsiaj["monsiaj"]
    ld_definition["определения LD"]
    push_api["PushAPI"]
    claim_protocol["CLAIM (обмен мед. данными)"]
    jma_opensource_license["лицензия JMA OpenSource"]
    weborca_cloud["WebORCA (облачная версия)"]
    weborca_onpremise["WebORCA (локальная версия)"]
    legacy_nichirese_deployment["традиционная среда (MONTSUQI)"]
    orca_nichirese -->|"реализует"| receipt_computer
    receipt -->|"требует"| receipt_computer
    electronic_medical_record -.->|"использует"| orca_api
    orca_nichirese -->|"использует"| cobol
    orca_nichirese -->|"использует"| montsuqi
    orca_nichirese -->|"использует"| postgresql
    orca_nichirese -->|"использует"| monsiaj
    montsuqi -->|"настраивается"| ld_definition
    orca_api -->|"настраивается"| ld_definition
    orca_api -->|"требует"| montsuqi
    monsiaj -->|"требует"| montsuqi
    orca_nichirese -->|"использует"| orca_api
    orca_nichirese -->|"использует"| push_api
    orca_api -->|"преемник"| claim_protocol
    orca_nichirese -.->|"требует"| jma_opensource_license
    weborca_cloud -->|"реализует"| orca_nichirese
    weborca_onpremise -->|"реализует"| orca_nichirese
    weborca_onpremise -->|"преемник"| legacy_nichirese_deployment
    legacy_nichirese_deployment -->|"использует"| montsuqi

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 19, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

1. Сначала вывод — ORCA это система медицинского биллинга

В центре проекта ORCA стоит «JMA Standard Receipt Software» (сокращённо Nichi-Rece). Это система медицинского биллинга (яп. レセコン, receipt computer). По оказанным услугам она считает тариф медицинской помощи и формирует счёт (яп. レセプト, receipt — требование на оплату медицинской помощи), который подают в организации экспертизы и оплаты.

У электронной медицинской карты и системы медицинского биллинга роли разделены жёстко.

Обиходное «электронная карта ORCA» появилось потому, что у многих продуктов электронных карт архитектура была «расчётную часть связываем с ORCA». Инженеру достаточно сначала зафиксировать различие: ORCA = ядро расчётной стороны, электронная карта = сторона клинических записей — дальше всё складывается заметно проще.

2. Что такое работа со счетами — самое короткое системное понимание

Чтобы понять, что за система стоит за медицинским биллингом, быстрее всего посмотреть, как в медицинской организации движутся доходы. В японской страховой медицине пациент у регистратуры платит, как правило, 10–30%, а остаток организация ежемесячно предъявляет организациям экспертизы и оплаты (Фонд оплаты медицинской помощи по социальному страхованию и федерации ассоциаций национального медицинского страхования). Этот документ и есть счёт (receipt).

С системной точки зрения система медицинского биллинга — это машина, которая прогоняет такой ежемесячный пакетный цикл.

1. Ежедневно: на приёме проверяют страховой статус, вводят оказанные услуги (осмотр, анализы, лекарства, процедуры…) и проводят расчёт с пациентом по сумме сооплаты, которую система считает по таблице баллов.
2. Ежемесячно: услуги за месяц сводят в разрезе «пациент × страховка» и формируют счета. Перед подачей гоняют проверку данных (согласованность диагноза и назначений и т. п.) и отправляют как электронный счёт (данные rece-den).
3. Со следующего месяца: обрабатывают возвраты экспертизы («henrei») и снижения суммы («satei»), правят и подают заново.

Важно здесь то, что правила расчёта баллов меняются с пересмотром тарифов раз в два года. Если ПО не успевает за обновлением мастера баллов, цен на лекарства и правил расчёта, организация не может корректно выставить счета. Принципиальная сложность системы биллинга — не UI и не масштаб, а десятилетиями держать соответствие этой нормативной базе. История правок, зафиксированная в исходниках ORCA, о которой ниже, как раз и есть эта летопись.

3. Схема систем медицинской организации — где стоит ORCA

Если нарисовать типичную схему поликлиники, ORCA (Nichi-Rece) стоит почти в роли хаба внутренних систем.

flowchart LR
    subgraph clinic["Внутри медицинской организации"]
        EMR["Электронная медицинская карта<br/>записи о лечении и назначения"]
        RSV["Система приёма и записи"]
        ONS["Терминал онлайн-проверки страхового статуса"]
        ORCA["ORCA/Nichi-Rece<br/>система медицинского биллинга (счета)"]
        EMR -->|"Nichi-Rece API (HTTP)"| ORCA
        RSV -->|"интеграция приёма и записи"| ORCA
        ONS -->|"данные о страховом статусе"| ORCA
    end
    ORCA -->|"счета (ежемесячное выставление)"| PAY["Организации экспертизы и оплаты<br/>фонд оплаты и федерации нац. медстрахования"]

Три главных пункта.

• Мастер базовых данных пациента и страховки чаще живёт на стороне ORCA. Электронная карта читает и обновляет его через API. Кто владеет нумерацией номера пациента — первый спорный вопрос проектирования интеграции.
• Оказанные услуги (что сделали) уходят из электронной карты в ORCA, и ORCA делает расчёт баллов, из которого следуют касса и выставление счетов. Электронная карта описывает лечение «языком назначений», ORCA — «языком баллов», поэтому перевод между ними (сопоставление кодов услуг) — самая трудоёмкая часть интеграции на практике.
• Ежемесячная подача счетов — работа ORCA. Иначе говоря, выручка медицинской организации выставляется через ORCA. Ошибка интеграции проявляется не как дыра в клинической записи, а как неверная сумма счёта — такое напряжение характерно для этой области.

4. История проекта ORCA и лицензия

ORCA — проект Японской медицинской ассоциации (JMA). В ноябре 2001 года «Декларация JMA об информатизации» зафиксировала курс публиковать ПО, которое делает ассоциация, как открытый исходный код; центральным продуктом этой линии и стал Nichi-Rece. Использование в клиниках началось в 2002 году, разработка идёт уже больше двадцати лет.

С инженерной точки зрения особенно важно, что исходный код бизнес-системы публикуют непрерывно больше двадцати лет.

• Лицензия — JMA OpenSource License version 1.0, которая лежит в комплекте с исходниками. Это не GPL, а собственный договор JMA: использование программы (включая воспроизведение, переработку, распространение и публичную передачу) разрешено на неисключительной и безвозмездной основе, а при распространении изменённой версии нужно наложить те же условия — copyleft-подобная конструкция. Применимое право — японское.
• Раньше был открыт репозиторий CVS, но с запуском коммерческой редакции CVS закрыли. Сейчас 1-го числа каждого месяца публикуют tarball исходников по состоянию на 1-е число предыдущего месяца. Публикуют три компонента — ядро, региональные пособия за публичный счёт и открытые бланки; линейки 5.0, 5.1 и 5.2 выходят параллельно.
• Устройство разработки и поставки тоже характерное. В истории правок исходников сначала идут имена инженеров NACL (подрядчик разработки), примерно с 2022 года коммиты идут от имени ORCAMO (Japan Medical Association ORCA Management Organization). Сопутствующие услуги (поддержка, пакеты, руководства и т. п.) как коммерческую редакцию даёт ORCA Management Organization, внедрение и сопровождение — сертифицированные организации поддержки по стране: модель разделения труда.

То есть ORCA — ПО «с открытым исходным кодом, но не community-разработка в духе GitHub». Исходники можно читать, можно форкать, но основную линию ведёт один субъект по-вендорски. Для медицины, где ошибка недопустима, а соответствие нормам обязательно, это, на мой взгляд, разумная точка равновесия.

5. Технологический стек — считаем 4 млн строк COBOL по факту

С этой главы собственных имён резко прибавляется, поэтому сначала — таблица терминов. Дальнейшие главы удобно читать, держа её рядом.

В INSTALL.ja опубликованных исходников линейки 5.2 среди необходимого ПО перечислены MONTSUQI (panda), OpenCOBOL, PostgreSQL, MONPE и другие. Схема в сжатом виде такая.

Словами масштаб не чувствуется, поэтому ниже — фактический подсчёт снимка линейки 5.2 (после распаковки около 8200 файлов, 237 МБ).

Имена таблиц прямые: когда к ним привыкаешь, сквозь них сразу видна предметная область. В именовании смешаны «английские сокращения» и «японский в латинице», поэтому японскую часть полезно мысленно вернуть в иероглифы. Основные такие.

Разделение ролей из главы 1 — «пациент, страховка, диагноз, услуга, баллы» — буквально реализовано как структура таблиц. Документы с определениями таблиц опубликованы на официальном сайте: если чтение имени буксует, официальное название можно сверить там.

Ключ архитектуры — MONTSUQI. Внутри Nichi-Rece это классическая централизованная обработка: Java-клиент (monsiaj) получает с сервера определения экранов и рисует их, ввод обрабатывают программы COBOL на сервере, они читают и пишут PostgreSQL. Какой экран какому COBOL соответствует, декларативно описано в LD-файлах каталога lddef/.

flowchart LR
    CL["monsiaj<br/>клиент на Java"] -->|"работа с экраном"| MW["MONTSUQI<br/>сервер приложений"]
    API["Интегрирующая система<br/>электронная медицинская карта и др."] -->|"Nichi-Rece API (HTTP)"| MW
    MW -->|"маршрутизация по определениям lddef/*.ld"| AP["Бизнес-программы<br/>COBOL около 1750 программ"]
    AP --> DB[("PostgreSQL<br/>285 таблиц")]

Интересно, что диспетчеризация экранов и диспетчеризация API живут в одних и тех же LD-файлах. То есть Nichi-Rece API — не отдельный сервер, прикрученный потом, а «вход, который говорит XML вместо экрана», добавленный поверх той же платформы бизнес-программ, что и диалоговые экраны. Детали этой конструкции — в продолжении.

Схема «COBOL + своё промежуточное ПО + PostgreSQL» с точки зрения современной веб-разработки выглядит далёкой. Но в заголовке одной программы COBOL комментариями врезана история правок с 2002 года — вплоть до недавних нормативных изменений вроде электронного рецепта (2022) и проверки страхового статуса по карте My Number (2024): одна и та же кодовая база больше двадцати лет догоняет пересмотры тарифов. Эта архитектура ещё и результат оптимизации под «вызреть и стабильно работать дальше».

6. Как ходить по дереву исходников — что где лежит

Как карта для реального чтения исходников — основные каталоги верхнего уровня.

Одно практическое замечание. Кодировка исходников — EUC-JP (лицензионный документ — ISO-2022-JP). В современном редакторе текст «ломается», поэтому читают через iconv -f EUC-JP -t UTF-8. Своего рода капсула времени: стандарт Linux-среды 2002 года сохранён как есть.

7. Точки входа интеграции — Nichi-Rece API, PushAPI, CLAIM

Для инженера внешней системы, который касается ORCA, входов по сути три.

1. Nichi-Rece API — текущая рекомендация. Интегрирующая система шлёт HTTP-запросы: получает данные пациента, регистрирует приём, регистрирует оказанные услуги и т. п. Чтение — в основном GET или POST+XML, запись — POST+XML. Спецификация API опубликована на официальном сайте.
2. PushAPI — механизм уведомления интегрирующей системы о событиях на стороне Nichi-Rece (например, указание напечатать бланк). Экранную связку можно строить событийно, без поллинга.
3. CLAIM — долго был стандартным протоколом обмена медицинской информацией, но поддержка закончилась в марте 2026 года. Обработка CLAIM в исходниках ещё есть, однако существующие связки по CLAIM теперь предполагают переход на API.

Иначе говоря, если проектируете интеграцию с ORCA сейчас — только Nichi-Rece API. И как уже сказано, API сидит на той же COBOL-платформе бизнес-программ, что и диалоговые экраны, поэтому когда «поведение API непонятно», можно спуститься в исходники и проверить. Конкретный способ собрать полную картину API из исходников (включая конечные точки, которых нет в официальном списке) разобран в статье-продолжении.

8. Что меняется при переходе на WebORCA

Сейчас ORCA в переходном периоде к «WebORCA». Форм поставки по сути две.

• WebORCA, облачная редакция — Nichi-Rece как облачный сервис ORCA Management Organization. Медицинская организация освобождается от сопровождения серверов. Заявку подают через сертифицированную организацию поддержки; в официальных материалах от заявки до старта сервиса закладывают около трёх недель. На стороне организации сервер в клинике не ставят: работают из браузера, обновления программ при пересмотре тарифов делает облако централизованно. Оплата — ежемесячная с организации.
• WebORCA, локальная редакция — устанавливают на сервер в клинике (Ubuntu). Текущая среда поставки — Nichi-Rece Ver5.2.0 на Ubuntu 22.04 (jammy).

По срокам перехода важно держать два пункта.

Первый: официальный маршрут миграции есть. ORCA Project публикует «руководство по переносу среды эксплуатации Nichi-Rece»: в нём явно указан переход с классического Nichi-Rece 5.1.0 / 5.2.0 (редакция MONTSUQI) на Ubuntu 16.04 / 18.04 / 20.04 на WebORCA локальную редакцию (Ubuntu 22.04 + 5.2.0). В обратную сторону, то есть на более старую ОС и более старую версию Nichi-Rece, мигрировать нельзя.

Второй: единого срока «все организации к такому-то дню на WebORCA» не объявляли. На практике работает дата окончания поддержки для конкретной пары «ОС + пакет Nichi-Rece»: её публикуют как «расписание поддержки пакетов Nichi-Rece и ОС», а версии, у которых срок близко, анонсируют отдельно. Стороне интеграции полезнее не спрашивать «когда переход на WebORCA», а уточнять Ubuntu и версию Nichi-Rece у конкретной организации и дату окончания их поддержки — это и есть практический способ держать временную ось.

Важно, что внутри и то и другое — тот же Nichi-Rece. Работающее ПО не становится другим продуктом из-за формы поставки; набор API и поведение в основном общие. Различия, которые должен держать инженер интеграции, сосредоточены не в реализации, а вокруг подключения.

• Разница входа: у облачной редакции к пути API-запроса добавляется префикс /api, параметры подключения и аутентификации зависят от формы поставки. Сама спецификация API общая.
• В облачной редакции внутренние интегрирующие системы вызывают API через интернет, поэтому маршруты сети и деградированное поведение при сбое требуют больше проектирования, чем в локальной схеме.
• В ежемесячно публикуемые исходники определения для WebORCA входят как есть (например файлы .db.weborca в record/). Это свидетельство, что одно дерево исходников держит обе формы, и знания, полученные из исходников, применимы и к облачной редакции. В .weborca-вариантах иногда сдвинуты, например, верхние границы массивов в ответах, поэтому при сверке деталей смотрите, есть ли определение именно для WebORCA.

9. Итог — что инженеру стоит держать в голове

• ORCA (Nichi-Rece) — не электронная медицинская карта, а система медицинского биллинга. Он держит ядро расчётных данных — пациент, страховка, диагноз, услуга, баллы — и выручка медицинской организации выставляется через него.
• Принципиальная сложность системы биллинга — десятилетиями догонять пересмотр тарифов раз в два года. История правок в исходниках ORCA — документальная летопись именно этого.
• Это открытая бизнес-система с декларации JMA об информатизации 2001 года; исходники ежемесячно публикуют tarball. Лицензия — не GPL, а JMA OpenSource License.
• Внутри — 1754 программы COBOL, около 4,06 млн строк + MONTSUQI + 285 таблиц PostgreSQL (замер линейки 5.2). И экраны, и API диспетчеризуются одними LD-определениями в архитектуре централизованной обработки.
• Внешняя интеграция сейчас входит через Nichi-Rece API. CLAIM закончил поддержку в марте 2026 года. Переход на WebORCA идёт, но и облачная, и локальная редакции внутри — тот же Nichi-Rece, так что знания из открытых исходников работают для обеих.

В следующий раз разберём эти открытые исходники на практике и покажем, как из кода собрать полную картину Nichi-Rece API: какой URL обрабатывает какая программа COBOL и какие конечные точки отсутствуют в официальном списке — с таблицей соответствия всех 137 конечных точек.

10. Источники

• Что такое ORCA — ORCA Project
• Техническая информация — JMA Standard Receipt Software — ORCA Project (публикация исходного кода, спецификация API, документы с определениями таблиц)
• API JMA Standard Receipt Software — ORCA Project
• JMA Standard Receipt Software «ORCA» — Japan Medical Association ORCA Management Organization
• О коммерческой редакции JMA Standard Receipt Software — Japan Medical Association ORCA Management Organization
• WebORCA, облачная редакция — ORCA Project
• JMA Standard Receipt Software [WebORCA, облачная редакция] — Japan Medical Association ORCA Management Organization (канал заявки, форма поставки, тарифы)
• Руководство по переносу среды эксплуатации Nichi-Rece — ORCA Project (объект и процедура перехода на локальную редакцию WebORCA)
• Для тех, кто уже пользуется JMA Standard Receipt Software — ORCA Project (источник публикации «расписания поддержки пакетов Nichi-Rece и ОС»)
• Исходный код ядра Nichi-Rece линейки 5.2 (снимок, опубликованный в июле 2026 года) INSTALL.ja / doc/license.html / lddef/orcadb.inc и др. — все фактические значения в тексте сняты с этого снимка

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

ORCA — это электронная медицинская карта?

Нет. В центре проекта ORCA стоит JMA Standard Receipt Software (Nichi-Rece) — система медицинского биллинга, которая считает тариф медицинской помощи и формирует счета (receipt, требования на оплату медицинской помощи). Электронная медицинская карта, куда пишут записи о лечении, — отдельное ПО; во многих организациях её связывают с ORCA через API. Формула «электронная карта ORCA» точнее всего понимается как обиходное название, возникшее потому, что ORCA часто работает в паре с электронной картой.

Может ли кто угодно читать исходный код ORCA (Nichi-Rece)?

Да. Исходный код самой JMA Standard Receipt Software публикуется по договору JMA OpenSource License, и 1-го числа каждого месяца можно скачать tarball со снимком на 1-е число предыдущего месяца. Прежний репозиторий CVS закрыли с запуском коммерческой редакции, но публикация исходников продолжается.

На каких технологиях сделан ORCA?

Сервер работает на Linux, большая часть бизнес-логики написана на COBOL. База данных — PostgreSQL, среда выполнения бизнес-программ — открытое промежуточное ПО MONTSUQI (panda), клиент — в том числе monsiaj на Java. По подсчёту исходников линейки 5.2 один COBOL даёт около 1750 программ и более 4 млн строк, в базе — более 280 таблиц.

Как электронная медицинская карта связывается с ORCA?

Сейчас рекомендуют Nichi-Rece API. Интегрирующая система — например электронная карта — шлёт HTTP-запросы, получает данные пациента, регистрирует оказанные услуги и так далее. Есть и PushAPI, через который Nichi-Rece уведомляет о событиях. Связка по CLAIM (стандарту обмена медицинской информацией), которой пользовались много лет, закончила поддержку в марте 2026 года, поэтому новую интеграцию проектируют уже из расчёта на API.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.