ORCA(니치레세)는 전자차트가 아니다 ── 엔지니어 관점에서 정리하는 레세콘과 의료 시스템 구성

‘전자차트의 ORCA’라는 말을 들어 보셨을 것입니다. 의료기관용 시스템 프로젝트를 맡으면 반드시 나오는 이름이지만, 이 호칭에는 오해가 들어 있습니다. ORCA(일본의사회 표준 레셉트 소프트웨어)는 전자차트가 아닙니다.

이 글은 의료 IT 프로젝트를 처음 맡는 엔지니어를 대상으로, 다음 질문에 답하는 것을 목표로 합니다.

• ORCA란 무엇이며, 의료기관 시스템 구성의 어디에 놓이는가
• 레세콘이 맡는 ‘레셉트 업무’란, 시스템으로 보면 무엇을 하는가
• 어떤 기술로 만들어져 있고, 공개된 소스에는 무엇이 들어 있는가
• WebORCA로 바꾸면 무엇이 달라지고, 연동하는 쪽은 무엇을 알아 두어야 하는가

서술은 모두 공개된 1차 정보에 근거합니다. 소스 코드에 관한 서술은, 공식 공개된 니치레세 본체 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. 참고 자료

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 19건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

1. 먼저 결론 ── ORCA는 ‘레세콘’이다

ORCA 프로젝트의 중심인 ‘일본의사회 표준 레셉트 소프트웨어’(줄여서 니치레세)는 레세콘(레셉트 컴퓨터)입니다. 레세콘은 진료 내용을 바탕으로 진료보수를 계산하고, 심사지급기관에 제출하는 레셉트(진료보수명세서)를 만드는 업무 시스템입니다.

전자차트와 레세콘은 역할이 분명하게 나뉩니다.

‘전자차트의 ORCA’라는 통칭이 생긴 것은, 많은 전자차트 제품이 ‘레세콘 부분은 ORCA와 연동’하는 구성을 취해 왔기 때문입니다. 엔지니어로서는 ORCA=청구 계통의 기간, 전자차트=진료 기록 계통이라는 구분을 처음에 잡아 두면, 이후 이야기가 모두 정리되기 쉽습니다.

2. 레셉트 업무란 무엇인가 ── 시스템 관점으로 빠르게 이해하기

레세콘이 어떤 시스템인지 이해하려면, 의료기관의 수입이 어떻게 흐르는지를 아는 편이 빠릅니다. 일본의 보험 진료에서는 환자가 창구에서 내는 금액은 원칙적으로 1~3할이고, 나머지는 의료기관이 심사지급기관(사회보험진료보수지급기금·국민건강보험단체연합회)에 월 단위로 청구합니다. 이 청구서가 레셉트입니다.

시스템으로 보면 레세콘은 다음 월별 배치 사이클을 돌리는 장치입니다.

1. 매일: 접수에서 보험 자격을 확인하고, 진료행위(진찰·검사·투약·처치…)를 입력한 뒤, 점수표에 따라 자동 계산한 창구 본인부담금으로 수납한다.
2. 매월: 한 달분의 진료행위를 환자×보험 단위로 집계해 레셉트를 만든다. 제출 전에 데이터 점검(병명과 처방의 정합성 등)을 하고, 전자 레셉트(레세덴 데이터)로 제출한다.
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/>지급기금·국보연합회"]

포인트는 다음 세 가지입니다.

• 환자 기본 정보와 보험 정보의 마스터는 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일 시점의 소스가 tarball로 공개되는 방식입니다. 공개 대상은 본체·지역 공비·공개 서식의 세 컴포넌트이며, 5.0 계열·5.1 계열·5.2 계열이 나란히 공개됩니다.
• 개발·제공 체제도 특이합니다. 소스의 수정 이력을 읽으면, 초기는 NACL(개발 수탁처)의 엔지니어 이름이 이어지다가 2022년경부터는 ORCAMO(일본의사회 ORCA관리기구) 명의의 commit으로 바뀝니다. 주변 서비스(지원, 패키지, 매뉴얼 등)는 상용판으로 ORCA관리기구가 제공하고, 도입·유지보수는 전국의 인증 지원 사업자가 맡는 분업 모델입니다.

곧 ORCA는 ‘오픈소스이지만 GitHub식 커뮤니티 개발은 아닌’ 소프트웨어입니다. 소스는 읽을 수 있고 fork도 할 수 있지만, 본류 개발은 단일 주체가 벤더처럼 진행합니다. 의료처럼 실수가 허용되지 않고 제도 변경을 따라가야 하는 영역을 생각하면, 합리적인 타협점이라고 봅니다.

5. 기술 스택 ── COBOL 400만 행의 내용을 직접 세어 보기

이 장부터 고유 명사가 한꺼번에 늘어나므로, 먼저 용어표를 둡니다. 이후 장도 이 표를 옆에 두고 읽어 주십시오.

공개된 5.2 계열 소스의 INSTALL.ja에는 필요한 소프트웨어로 MONTSUQI(panda), OpenCOBOL, PostgreSQL, MONPE 등이 나열됩니다. 구성을 요약하면 다음과 같습니다.

말만으로는 규모가 잘 안 느껴지므로, 5.2 계열 스냅샷(압축 해제 후 약 8,200개 파일·237MB)을 직접 세어 본 결과를 제시합니다.

데이터베이스의 테이블 이름은 직설적이라, 익숙해지면 업무가 그대로 보입니다. 이름은 ‘영어 약어’와 ‘일본어 로마자’가 섞여 있으므로, 일본어 부분을 한자로 되돌리면 뜻이 잡힙니다. 주요한 것을 나열하면 다음과 같습니다.

‘환자·보험·병명·진료행위·점수’라는 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’ 구성은 요즘 웹 개발 감각과는 멀어 보입니다. 그러나 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를 다룰 때의 입구는 실질적으로 다음 세 가지입니다.

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’로의 전환기에 있습니다. 제공 형태는 크게 두 가지입니다.

• WebORCA 클라우드 버전 ── ORCA관리기구가 제공하는 클라우드 서비스로 니치레세를 쓰는 형태. 의료기관은 서버 관리에서 벗어난다. 신청은 인증 지원 사업소를 거치는 형태이며, 공식 안내에서는 신청부터 서비스 시작까지 3주 정도를 본다고 되어 있다. 의료기관 쪽은 원내에 서버를 두지 않고 브라우저로 이용하며, 진료보수 개정에 따른 프로그램 갱신도 클라우드 쪽에서 한꺼번에 이루어진다. 요금은 의료기관 1곳당 월액제.
• WebORCA 온프레미스 버전 ── 원내 서버(Ubuntu)에 설치해 쓰는 형태. 현재 제공 환경은 Ubuntu 22.04(jammy) 위의 니치레세 Ver5.2.0.

전환의 시간축에서 알아 둘 점은 두 가지입니다.

하나는 전환 경로가 공식으로 마련되어 있다는 것입니다. ORCA Project는 ‘니치레세 운용 환경 이행 안내’를 공개하고 있으며, Ubuntu 16.04 / 18.04 / 20.04에서 동작하는 기존형(MONTSUQI 버전) 니치레세 5.1.0 / 5.2.0에서 WebORCA 온프레미스 버전(Ubuntu 22.04 + 5.2.0)으로 옮기는 절차가 대상으로 명시되어 있습니다. 반대 방향, 곧 하위 OS·하위 니치레세 버전으로 옮기는 것은 할 수 없습니다.

다른 하나는 ‘모든 의료기관은 언제까지 WebORCA로’라는 일률 기한이 공표되어 있는 것은 아니다는 점입니다. 실무상 기한으로 작용하는 것은 OS와 니치레세 패키지 조합마다 정해진 지원 종료일 쪽이며, 이는 ‘니치레세 패키지 및 OS 지원 일정’으로 공표되고, 종료가 가까운 버전은 개별 안내됩니다. 연동 시스템을 만드는 쪽으로서는 ‘WebORCA 전환은 언제인가’가 아니라, 상대 의료기관이 쓰는 Ubuntu와 니치레세 버전, 그리고 그 지원 종료일을 확인하는 것이 시간축을 잡는 실무적인 방법입니다.

중요한 것은 어느 쪽이든 알맹이는 같은 니치레세라는 점입니다. 돌아가는 소프트웨어가 제공 형태에 따라 다른 물건이 되는 것은 아니며, API의 종류도 동작도 기본적으로 같습니다. 연동하는 엔지니어가 알아 둘 차이는 구현이 아니라 접속 주변에 모입니다.

• API 요청 경로에 클라우드 버전은 /api prefix가 붙는다, 접속 정보·인증 설정이 제공 형태마다 다르다, 라는 입구의 차이. API 자체의 사양은 공통.
• 클라우드 버전에서는 원내 연동 시스템이 인터넷 너머로 API를 부르는 구성이 되므로, 네트워크 경로나 장애 시 기능 축소 동작의 설계는 온프레미스 구성보다 생각할 일이 늘어난다.
• 매월 공개되는 소스에는 WebORCA용 정의도 그대로 들어 있다(예: record/ 아래의 .db.weborca 파일). 같은 소스 트리가 두 형태를 받치고 있다는 증거이며, 소스를 읽어 얻은 지식은 클라우드 버전에도 통한다. 또한 .weborca 버전에서는 응답 배열 상한 등이 조정된 정의가 있으므로, 세부를 확인할 때는 WebORCA용 정의의 유무도 본다.

9. 정리 ── 엔지니어가 알아 둘 포인트

• ORCA(니치레세)는 전자차트가 아니라 레세콘입니다. 환자·보험·병명·진료행위·점수라는 청구 데이터의 기간계를 쥐고, 의료기관의 매출은 이곳을 거쳐 청구됩니다.
• 레세콘의 본질적인 어려움은 2년마다의 진료보수 개정을 수십 년 동안 따라가는 일입니다. ORCA 소스의 수정 이력은 그 실제 기록이 되어 있습니다.
• 2001년 일본의사회 IT화 선언에서 이어진 오픈소스 업무 시스템이며, 소스는 매월 tarball로 공개됩니다. 라이선스는 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
• 일본의사회 표준 레셉트 소프트웨어［WebORCA 클라우드 버전］- 일본의사회 ORCA관리기구(신청 경로·제공 형태·요금)
• 니치레세 운용 환경 이행 안내 - ORCA Project(WebORCA 온프레미스 버전으로의 전환 대상과 절차)
• 일본의사회 표준 레셉트 소프트웨어 이용 중이신 분께 - ORCA Project(‘니치레세 패키지 및 OS 지원 일정’의 게재처)
• 니치레세 본체 5.2 계열 소스 코드(2026년 7월 공개 스냅샷) INSTALL.ja / doc/license.html / lddef/orcadb.inc 외 ── 본문의 실측값은 모두 이 스냅샷에 근거함

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

ORCA는 전자차트인가요?

아닙니다. ORCA 프로젝트의 중심인 일본의사회 표준 레셉트 소프트웨어(니치레세)는 진료보수 청구(레셉트)를 담당하는 레세콘입니다. 진료 기록을 작성하는 전자차트는 별도 소프트웨어이며, 많은 의료기관에서는 전자차트와 ORCA를 API로 연동해 사용합니다. '전자차트의 ORCA'라는 말은, 전자차트와 묶어 쓰는 경우가 많아서 생긴 통칭으로 보는 것이 정확합니다.

ORCA(니치레세)의 소스 코드는 누구나 읽을 수 있나요?

읽을 수 있습니다. 일본의사회 표준 레셉트 소프트웨어 본체의 소스 코드는 일본의사회 오픈소스 사용허락계약(JMA OpenSource License) 아래에서 공개되며, 매월 1일에 전월 1일 시점의 스냅샷을 tarball로 받을 수 있습니다. 예전의 CVS 저장소는 상용판 제공이 시작되면서 비공개가 되었지만, 소스 공개 자체는 이어지고 있습니다.

ORCA는 어떤 기술로 만들어져 있나요?

서버는 Linux에서 동작하며, 업무 로직의 대부분은 COBOL로 작성되어 있습니다. 데이터베이스는 PostgreSQL, 업무 프로그램의 실행 기반에는 MONTSUQI(panda)라는 오픈소스 미들웨어를 쓰고, 클라이언트에는 Java로 만든 monsiaj 등이 쓰입니다. 5.2 계열 소스를 세어 보면 COBOL만 약 1,750개·400만 행을 넘고, 데이터베이스는 280개를 넘는 테이블 규모입니다.

전자차트와 ORCA는 어떻게 연동하나요?

지금은 니치레세API가 권장입니다. 전자차트 같은 연동 시스템이 HTTP로 요청을 보내 환자 정보 조회나 진료행위 등록 등을 합니다. 니치레세 쪽에서 이벤트를 알리는 PushAPI도 있습니다. 오래 쓰여 온 CLAIM(의료정보교환규약) 연동은 2026년 3월에 지원이 끝났으므로, 앞으로 만드는 연동은 API를 전제로 설계하는 것이 타당합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.