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. 참고 자료

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일 시점의 소스가 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)을 실제로 세어 본 결과를 제시합니다.

데이터베이스의 테이블명은 솔직해서, 읽는 데 익숙해지면 업무가 그대로 보이기 시작합니다. 명명 방식은 ‘영어 약어’와 ‘일본어 로마자’가 섞여 있으므로, 일본어 부분을 일단 한자로 되돌리면 의미를 파악할 수 있습니다. 주요한 것을 나열하면 다음과 같습니다.

‘환자・보험・병명・진료행위・점수’라는 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 프리픽스가 붙는다, 접속 정보・인증 설정이 제공 형태마다 다르다는 등의 입구의 차이. 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
• 일본의사회 표준 레셉트 소프트웨어[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일 시점의 스냅샷이 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를 전제로 설계하는 것이 타당합니다.

저자 프로필

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

Go Komura

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

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