마이나보험증을 태그하면 무슨 일이 일어나는가 ── 온라인 자격확인과 레세콘 연계를 ORCA 소스코드로 읽다

진료소 접수에서 마이나보험증을 카드 리더에 태그하면, 몇 초 만에 본인 확인과 보험 자격 확인이 끝납니다. 그 몇 초 뒤에서 어떤 시스템이 어떤 순서로 동작하는지──특히 최종적으로 청구를 담당하는 레세콘에 자격 정보가 어떻게 도착하는지를 설명할 수 있는 엔지니어는, 의외로 많지 않을 것입니다.

지지난번에는 ORCA(일의표준레셉트소프트)가 레세콘이라는 점을, 지난번에는 니치레세 API의 전체 모습을 소스코드에서 파악하는 방법을 썼습니다. 이번에는 그 응용편으로, 온라인 자격확인(통칭 온자)을 레세콘 쪽에서 해부합니다.

• 마이나보험증을 태그한 뒤, 자격 정보가 레세콘에 등록되기까지의 전체 흐름
• 자격확인 단말과 레세콘을 잇는 「파일 연계」의 내용
• ORCA 쪽 진입점 ── 온자 관련 API 20개와 tbl_onshi_* 테이블군
• COBOL 수정 이력에 새겨진, 2020년부터 2026년까지의 제도 대응 연표

제도 쪽 서술은 후생노동성·ORCA 공식의 공개 자료에, 소스코드에 관한 서술은 공식 공개된 니치레세 본체 5.2계열 소스(2026년 7월 1일 공개 스냅샷) 를 실제로 읽고 확인한 결과에 근거합니다.

이 글의 전제

대상 독자는 접수 시스템·전자차트·예약 시스템 등, 레세콘과 연계하는 시스템을 만드는 엔지니어입니다. COBOL을 읽을 필요는 없습니다(인용 부분은 그때그때 설명합니다). 의료 사무 실무 경험도 전제하지 않습니다.

시리즈 세 번째이므로, 앞 두 편에서 설명한 용어가 그대로 나옵니다. 이 글만으로도 읽을 수 있도록, 최소한의 어휘를 여기에 모아 둡니다.

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

목차

1. 먼저 결론 ── 자격확인은 「등장하는 네 주체」의 릴레이이다
2. 제도를 짧게 이해하기 ── 온라인 자격확인이란 무엇인가
3. 단말과 레세콘 사이 ── OQS 파일 연계라는 접점
4. ORCA 쪽 진입점 ── 온자 관련 API 20개를 소스에서 세다
5. 데이터가 가는 곳 ── tbl_onshi_* 13개 테이블
6. tbl_onshi_kaku를 읽다 ── 한 번의 자격확인이 무엇을 남기는가
7. 수정 이력은 제도의 연표다 ── 2020〜2026
8. 환자 등록으로의 반영 ── 결과는 「그대로」 보험 정보가 되지 않는다
9. 연계 시스템을 만드는 쪽의 실무 포인트
10. 정리
11. 참고 자료

1. 먼저 결론 ── 자격확인은 「등장하는 네 주체」의 릴레이이다

마이나보험증을 태그한 뒤 자격 정보가 레세콘에 실리기까지를 한 장으로 그리면, 등장하는 주체는 넷입니다.

flowchart LR
    subgraph clinic["의료기관 안"]
        CR["얼굴 인증<br/>카드 리더"]
        TERM["자격확인 단말"]
        REN["연계 프로그램<br/>(니치레세에서는 onshi-tools)"]
        ORCA["ORCA/니치레세<br/>tbl_onshi_* 에 축적"]
        UKE["접수·환자 등록 업무"]
        CR --> TERM
        TERM <-->|"공유 폴더<br/>OQS〜.xml"| REN
        REN -->|"온자 관련 API<br/>(등록계)"| ORCA
        ORCA --> UKE
    end
    TERM <-->|"IP-VPN /<br/>IPsec+IKE"| OQS["온라인 자격확인 등 시스템<br/>(사회보험진료보수지급기금·국민건강보험중앙회)"]

1. 얼굴 인증 카드 리더가 마이넘버카드를 읽고, 본인 확인(얼굴 인증 또는 비밀번호)을 수행합니다.
2. 자격확인 단말이 온라인 자격확인 등 시스템의 네트워크(회선 사업자의 IP-VPN, 또는 인터넷을 통한 IPsec+IKE 접속)를 거쳐 온라인 자격확인 등 시스템(사회보험진료보수지급기금·국민건강보험중앙회가 운영)에 조회하고, 자격 정보를 XML로 받습니다.
3. 단말과 레세콘 사이는 파일 연계가 기본입니다. 결과 XML은 공유 폴더에 놓이고, 연계 프로그램이 레세콘으로 가져옵니다. 니치레세의 경우 이 역할을 맡는 공식 프로그램이 onshi-tools입니다.
4. 가져온 결과는 ORCA 안의 온자 전용 테이블군(tbl_onshi_*)에 일단 쌓이고, 접수·환자 등록 업무가 그곳에서 환자 정보·보험 정보로 반영합니다.

핵심은 자격확인 결과가 환자 마스터에 바로 쓰이지 않고, 전용 테이블에 일단 쌓인다는 점입니다. 「조회 기록」과 「환자 마스터로의 반영」이 나뉜 이 2단계 구조가, ORCA의 온자 연계를 읽는 열쇠입니다(6장·8장).

2. 제도를 짧게 이해하기 ── 온라인 자격확인이란 무엇인가

시스템 이야기로 들어가기 전에, 제도 쪽을 짧게 정리합니다.

• 무엇을 하는 구조인가: 마이넘버카드(마이나보험증) 또는 보험증의 기호·번호를 키로, 환자의 보험 자격을 온라인에서 즉시 확인하는 구조입니다. 보험자를 넘나드는 자격 이동(이직·이사 등)이 조회 시점에 반영되므로, 자격 오류로 인한 레셉트 반송을 줄일 수 있다는 점이 청구 업무 쪽에서 본 가장 큰 의의입니다.
• 언제부터: 2021년 10월에 본격 운영이 시작되었고, 2023년 4월부터 보험의료기관·약국에 시스템 도입이 원칙적으로 의무화되었습니다. 2024년 12월에는 건강보험증의 신규 발행이 종료되어, 마이나보험증을 기본으로 하는 체제로 옮겨 왔습니다.
• 자격 외에 무엇이 오는가: 환자가 카드 리더에서 동의하면, 약제 정보·특정 건강진단 정보·진료 정보를 의료기관 쪽에서 열람할 수 있습니다. 나아가 의료부조(생활보호) 자격확인이나, 지자체의 의료비 지원 정보 연계(PMH: Public Medical Hub)로 대상이 넓어지고 있습니다.

이름은 「자격확인」이지만, 실제로는 자격을 입구로 진료 정보까지 흐르는 의료 정보 연계의 간선이 되어 가는 중이라고 보는 것이 현재 위치입니다. 이 「대상의 확대」가 레세콘 코드에 어떻게 나타나는지는, 7장에서 연표로 봅니다.

3. 단말과 레세콘 사이 ── OQS 파일 연계라는 접점

의료기관 안의 접점, 즉 자격확인 단말과 레세콘(이나 전자차트) 사이는 어떻게 이어져 있을까요.

국가가 공개한 시스템 벤더용 자료에서는, 기존 시스템과 온라인 자격확인 등 시스템의 연계 방식으로 연계 애플리케이션에 의한 파일 연계 외에, 웹 애플리케이션 연계·얼굴 인증 연계·WebAPI 연계 같은 방식이 제시되어 있습니다. 중심이 되는 파일 연계는, 대략 「정해진 이름의 XML 파일을 정해진 폴더에 두면, 답 XML 파일이 돌아온다」는, 고전적이지만 확실한 구조입니다.

니치레세도 이 방식입니다. ORCA 공식의 「니치레세 온라인 자격확인」 페이지에는, 자격확인 단말과 주고받는 파일로

• 요구: OQSsiquc01req_Oxxxxxxxxxxxx.xml
• 결과: OQSsiquc01res_Oxxxxxxxxxxxx.xml

라는 이름이 나와 있고, 공유 폴더를 통해 이를 주고받습니다. 이 파일 주고받기와 니치레세로의 가져오기를 맡는 것이 공식 제공 onshi-tools이며, Ubuntu판과 Windows판이 제공됩니다(가져오기 서비스를 감시하는 도구나, 환경 점검 도구도 함께 공개되어 있습니다).

맨 앞의 OQS는 온라인 자격확인 등 시스템과 주고받는 파일에 공통으로 붙는 접두사입니다(약어의 전개는 공개 자료에 명시되어 있지 않습니다). 파일 이름은 접두사 OQS+요구 종류를 나타내는 부분(siquc01 등)+req(요구) 또는 res(결과)+의료기관 쪽에서 붙이는 식별자, 라는 구성입니다. 같은 체계로, 약제 정보의 요구 파일에는 YZK, 특정 건강진단 정보에는 TKK라는 다른 접두사가 붙습니다(4장).

이 「OQS」 어휘는 ORCA 공개 소스에도 등장합니다. 예를 들어 연계 프로그램용으로 조회 의뢰 데이터를 조립해 돌려주는 API(4장에서 볼 onlinequa1)의 응답 정의 record/xml_onlinequares1.db에는, InsurerNumber(보험자 번호), InsuredCardSymbol(피보험자증 기호), QualificationConfirmationDate(자격확인일), LimitApplicationCertificateRelatedConsFlg(한도액적용인정증 관련 동의 플래그) 같은 항목이 늘어서 있습니다. 같은 정의 파일에는, 방문 진료 등의 열람 동의 취소 요구 파일 이름이 OQSsihvd01req_xxxxxxxxxxxx.xml(2024-11 주석 포함)이라고 코멘트로 적혀 있어, OQS 명명이 소스에 그대로 나타납니다. 온라인 자격확인 등 시스템 쪽 XML 항목 이름이, 그대로 레세콘 API까지 관통하고 있는 셈입니다. 연계 시스템을 만드는 쪽에서는, 국가 사양서와 ORCA 소스를 같은 어휘로 맞춰 볼 수 있다는 점에서 고마운 설계입니다.

4. ORCA 쪽 진입점 ── 온자 관련 API 20개를 소스에서 세다

그러면 ORCA 쪽 진입점을 세어 봅니다. 지난번과 같은 방법으로, 5.2계열 소스의 LD 정의(lddef/*.ld)에서 bindapi 선언을 주우면, 온자 관련 엔드포인트는 3개의 LD 파일에 나뉘어 모두 20개입니다. 기능명은 모두, 담당 COBOL 프로그램 헤더에 적힌 「컴포넌트명」을 그대로 옮긴 것입니다.

(신규 작성 연월은 각 프로그램 헤더의 작성 일자란에서 가져왔습니다. 표기는 YYYY/MM으로 맞췄습니다. onlinequa4만 「2021년」인 것은, 헤더의 작성 일자가 21/xx/xx처럼 월일을 가린 형태로 적혀 있기 때문입니다. onlinequa1의 괄호 안은 구현 내용에서 보충한 것입니다)

이 목록은 역할로 세 그룹으로 나뉩니다.

1. 등록계(단말 쪽→니치레세): onlinequa2(얼굴 인증)·onlinequa3(보험증)을 비롯해, 약제·특정 건강진단·진료 정보·OCR 이미지·의료부조·의료비 지원 각각의 「등록, 갱신 처리」입니다. 자격확인 단말 쪽에서 도착한 결과를 니치레세로 흘려 넣는 진입점입니다.
2. 의뢰 조립계(연계 프로그램→니치레세): onlinequa1은 이름만 보면 「결과 조회 API」처럼 보이지만, 구현을 읽으면 다릅니다. uuid(필수)로 tbl_onshi_kaku의 최신 레코드를 읽고, 그곳에서 자격확인 단말에 던질 조회 의뢰(OQS 요구)의 내용──자격확인에 쓰는 보험자 번호·기호 번호·동의 플래그, 약제 정보·특정 건강진단 정보의 요구 파일 이름(YZKsiquc01req_～.xml, TKKsiquc01req_～.xml. 「～」는 환자 번호 끝을 X로 채워 20자리로 고정한 문자열)──을 조립해 돌려줍니다. PushAPI의 조회 지시를 받은 연계 프로그램이 「단말에 무엇을 물어야 하는지」를 가지러 오는 API이며, 축적 결과를 검색해 돌려주는 API가 아닙니다.
3. 취득계(전자차트 등→니치레세): /api01rv2/ 아래 3개는, 쌓여 있는 약제·특정 건강진단·진료 정보를 연계 시스템이 가져가기 위한 API입니다. 읽기 계열 API가 모이는 api01rv2에 놓여 있는 점도, 지난번에 본 니치레세 API 배치 규칙 그대로입니다.

나아가 소스에는 record/push_onlinequa.db라는 정의도 있어, 온자 주변의 PushAPI 이벤트(Bulk_Qualification·patient_qualification)가 준비되어 있음을 알 수 있습니다. 발행 지점을 읽으면, 조회 업무 화면, 접수·환자 등록에서 호출되는 자격확인 서브(ORCSONSHI001.CBL), 예약 환자 일괄 조회 화면(ORCGY06.CBL), 배치(ORCBONSHIPUSH.CBL)가 각각 조회 지시 이벤트를 발행합니다. 즉 이 이벤트는, 니치레세 쪽에서 연계 프로그램으로 「자격확인을 하러 가라」고 지시를 보내는 채널이 중심입니다. 다만 내용은 발행원마다 다릅니다. 클래스에는 Rreq(조회 의뢰) 외에 확인 필요 여부 플래그 값(Yes)이 그대로 들어가는 경우가 있고, uuid의 의미도, 개별 이벤트에서는 tbl_onshi_kaku의 레코드 uuid, 예약 환자 일괄 조회에서는 작업 관리 uuid, 배치의 일괄 지시에서는 uuid 없음, 으로 일정하지 않습니다. 수신 쪽은 이벤트 이름·클래스·uuid의 의미에 따라, onlinequa1(개별 의뢰 조립)·onlinequaapp1(예약 환자 일괄)·onlinerefall1(조회 번호 일괄 등록)을 나눠 호출해야 합니다. record/xml_onlinequareq1.db의 첫머리 코멘트에는, Push 통지를 받은 수신 프로그램(onshi_receiver)이 onlinequa1로 요구 데이터를 가져오는 흐름이 적혀 있어, 개별 이벤트에 한정하면 Push(조회 지시)→onlinequa1(의뢰 조립)→단말로의 요구 파일→onlinequa2/onlinequa3(결과 등록)이라는 한 바퀴를 읽을 수 있습니다. 반대로, 얼굴 인증·보험증의 결과 등록 API(onlinequa2/onlinequa3)는 이 이벤트를 발행하지 않습니다. 「결과가 등록된 순간의 통지」를 PushAPI에 기대하고 접수 화면을 만들면, 통지가 오지 않은 채 기다리게 되므로 주의해야 합니다(9장).

5. 데이터가 가는 곳 ── tbl_onshi_* 13개 테이블

등록계 API가 받은 데이터는 어디로 갈까요. DB 테이블 목록(lddef/orcadb.inc)에서 onshi를 포함한 테이블을 뽑으면 13개입니다. 이름만 봐도, 온자로 흘러오는 정보 종류가 그대로 비칩니다.

1장에서 말한 2단계 구조가, 여기서 분명해집니다. 온자에서 온 데이터는 환자 마스터(tbl_ptinf)나 보험 테이블에 바로 쓰이지 않고, 먼저 tbl_onshi_*라는 「온자의 말 그대로인 테이블」에 착지합니다. 국가 제도 쪽 어휘(자격·약제·특정 건강진단·진료 정보…)와 레세콘 내부 어휘(환자·보험·공비…) 사이에 완충 지대를 둔 설계이며, 제도 쪽 확장(테이블이 13개까지 늘어난 것 자체가 그 증거입니다)을, 레세콘 본체 스키마를 깨지 않고 받아 왔음을 읽을 수 있습니다.

6. tbl_onshi_kaku를 읽다 ── 한 번의 자격확인이 무엇을 남기는가

중심 테이블 tbl_onshi_kaku(정의는 record/tbl_onshi_kaku.db)를 읽으면, 한 번의 자격확인이 무엇을 기록하는지 구체적으로 알 수 있습니다. 정의 파일은 항목 이름과 형을 늘어놓은 텍스트일 뿐이고, 다음처럼 보입니다(전체 668행 가운데, 이후 설명에 나오는 곳만 뽑았습니다).

tbl_onshi_kaku {
	HOSPNUM				number(2,0);
	TBL_UUID     			varchar(36);
	AITE_UUID     			varchar(36);
	OYA_UUID     			varchar(36);
	KOUHI_UUID     			varchar(36);
	FUJYO_UUID     			varchar(36);
#---> PMHUID(2025-11)
	PMH_UUID     			varchar(36);
#---> 일괄 동의 식별(2024/12)
	PROCESS_CLASS			varchar(01);
	（중략）
#---> 이미지 파일명(2022/7)
	HKNOCR_FILENAME  		varchar(100);
	（중략）
	SHO_HKNJANUM			varchar(8);
	SHO_KIGO     			varchar(80);
	SHO_NUM     			varchar(80);
	SHO_EDABAN    			varchar(2);
	SHO_BIRTHDAY    		varchar(8);
	（중략）
	RES_HKNJANUM			varchar(8);
	RES_KIGO     			varchar(80);
	RES_NUM     			varchar(80);
	RES_EDABAN    			varchar(2);
	RES_HONKZKKBN	    		varchar(1);
	RES_HIHKNJANAME    		varchar(100);
	（중략）
	KENSHIN_DOUIFLG  	  	  varchar(1);
	KENSHIN_TIME  		  	  varchar(14);
	KENSHIN_KIGENYMD   	  	  varchar(14);
	YAKUZAI_DOUIFLG   	  	  varchar(1);
	YAKUZAI_TIME  		  	  varchar(14);
	YAKUZAI_KIGEN  		  	  varchar(14);
#---> 진료 동의 정보(2022/7)
	SHINRYO_DOUIFLG   	  	  varchar(1);

항목 이름의 접두사(SHO_/RES_/〜_DOUIFLG)와, #--->로 시작하는 추가 시기 코멘트만 주워도, 이 테이블의 구조와 역사가 대략 읽힙니다. 아래는 주요 항목군을 뽑아 설명합니다.

• UUID 묶음: TBL_UUID(이 레코드 자신) 외에, AITE_UUID·OYA_UUID·KOUHI_UUID(공비)·FUJYO_UUID(의료부조)·PMH_UUID(의료비 지원)처럼, 관련 레코드를 가리키는 uuid가 늘어서 있습니다. 자격확인·공비 확인·부조 확인·지원 정보가 별도 레코드로 등록되고, uuid 연쇄로 하나의 접수 이벤트에 묶이는 구조입니다. 4장의 의뢰 조립 API(onlinequa1)가 uuid 지정을 필수로 하는 것은 이 때문입니다.
• 조회에 쓴 검색 조건(SHO_*): 조회 때 지정한 보험자 번호·기호·번호·가지번호·생년월일 등입니다. 정의의 유래는 요청 쪽의 「자격확인 조회용 정보(QualificationConfirmSearchInfo)」이며, 「무엇을 조건으로 물어봤는지」의 기록입니다(마이넘버카드 카드면에는 보험자 번호나 기호 번호가 없으므로, 「카드면의 사본」이 아닙니다).
• 돌아온 자격 정보(RES_*): 보험자 번호·기호·번호·가지번호·본인가족구분·피보험자 성명 등입니다. 「온자 시스템이 무엇이라고 답했는지」의 기록입니다. 조회 조건(SHO)과 결과(RES)를 별도 항목으로 가지므로, 이미 파악하고 있던 기호 번호와 최신 자격의 어긋남(이직·이사 등에 의한 자격 변경)을 레코드 위에서 쫓을 수 있습니다.
• 결과와 상태: 처리 결과(RESULT_*), 오류 코드/메시지(ERR_*), 자격의 유효성(SIKAKU_YUKO), 피보험자증 구분(CARD_CLASS──정의의 유래는 InsuredCardClassification이며, 돌아온 자격 레코드의 구분입니다. 물리 카드의 종류가 아닙니다), 확인 일시, 환자 번호(PTID)로의 연결, 복수 해당 플래그(FUKUSU_GAITO) 등입니다.
• 동의 주변: 동의 플래그는 하나가 아니라, 정보 종류마다 나뉘어 늘어서 있습니다. 약제(YAKUZAI_DOUIFLG)·특정 건강진단(KENSHIN_DOUIFLG)·진료 정보(SHINRYO_DOUIFLG) 외에, 한도액적용인정증(GENDO_DOUIFLG)·특정질병요양수료증(SIKKAN_DOUIFLG), 나아가 수술·상병명·감염증·알레르기·검사·처방 같은 단위까지 세분되어 있습니다. 2장에서 말한 「동의에 따른 정보 열람」이, 무엇에 대한 동의인지를 종류마다 구별하는 형태로 테이블 항목에 구현되어 있는 셈입니다.

정의 파일의 코멘트에는 항목 추가 시기도 남아 있어, 보험증 OCR 파일명 항목에는 2022년 7월, PMH_UUID에는 2025년 11월 주석이 있습니다. 테이블 정의 자체가, 다음 장에서 볼 제도 대응 역사의 일부가 되어 있습니다.

7. 수정 이력은 제도의 연표다 ── 2020〜2026

지지난번에서 「COBOL 헤더의 수정 이력은 제도 개정의 연표가 되어 있다」고 썼습니다. 온자 관련 프로그램군은 그 가장 선명한 실례입니다. 4장 표의 작성 일자와 수정 이력을 제도 쪽 움직임과 나란히 놓습니다.

지지난번에는 「레세콘의 본질적인 어려움은 제도 추종을 수십 년 이어 가는 일」이라고 썼지만, 온자는 바로 그 일이 지금도 진행되는 모습입니다. 2020년의 신설부터 2026년까지, 거의 매년 API나 테이블이 늘고 있다──이 사실은, 온자 연계를 「한 번 만들면 끝」인 통합으로 봐서는 안 된다는, 실무상의 경고이기도 합니다(9장).

덧붙여, 공개 소스를 매달 diff하면, 이런 확장은 공식 안내 전후에 lddef와 record의 차이로 잡을 수 있습니다. 지난번에 제안한 월별 스냅샷 diff 감시가, 온자 영역에서 특히 유효한 이유입니다.

8. 환자 등록으로의 반영 ── 결과는 「그대로」 보험 정보가 되지 않는다

tbl_onshi_kaku에 쌓인 결과는, 마지막에 어떻게 환자 마스터로 반영될까요.

자격확인 결과 테이블을 참조하는 프로그램을 세면, 가장 많은 것은 환자 등록 업무(cobol/orca12/)의 16개이고, 접수 업무(orca11)나 조회 업무에서도 참조됩니다. 환자 등록의 중심 프로그램 ORCGP02.CBL의 절 코멘트만 주워도, 처리 흐름이 보입니다.

* 온라인 자격확인 UID 검색 처리
* 온라인 자격확인 데이터 환자 신규 처리
* 온라인 자격확인 정보 기본 정보 처리
* 온라인 자격확인 정보 주소 갱신 처리
* 온라인 자격확인 정보 보험 정보 처리
* 온라인 자격확인 정보 한도액 등 공비 추가 처리
* 온라인 자격확인 정보 공비 개시일 체크 처리

즉 니치레세는 자격확인 결과를 기계적으로 덮어쓰지 않고, 환자 등록 업무의 맥락에서 「신규 환자 작성」「성명·주소 갱신」「보험 정보 대조·갱신」「한도액 인정이나 공비 추가」「개시일의 타당성 점검」 같은 개별 판단으로 쪼개어 반영합니다. 온자의 결과는 판단 재료일 뿐, 최종적인 환자·보험 마스터의 정본은 어디까지나 환자 등록 업무가 쥐고 있습니다──1장의 2단계 구조는, 이 책임 분계를 위한 설계라고 읽을 수 있습니다.

전자차트나 접수 시스템을 만드는 쪽에 대한 함의는 분명합니다. 자격확인 결과를 자사 시스템 쪽에서 환자 마스터에 바로 반영하는 지름길을 만들면, 이 대조 로직을 건너뛰게 됩니다. 반영은 ORCA의 업무(또는 그에 준하는 API)를 통과시키는 것이 맞습니다.

9. 연계 시스템을 만드는 쪽의 실무 포인트

접수 시스템·전자차트·예약 시스템 등에서 온자 주변에 관여할 때의 요점을 정리합니다.

1. 접점은 두 곳이다. 자격확인 단말과의 접점(OQS 파일 연계)과, 레세콘과의 접점(니치레세 API)은 별개입니다. 니치레세 구성에서는 파일 연계와 가져오기를 onshi-tools가 맡으므로, 연계 시스템이 스스로 OQS 파일을 다뤄야 하는지, 아니면 니치레세에 들어온 뒤의 데이터(약제·특정 건강진단·진료 정보는 취득계 API, 환자·보험으로의 반영 결과는 통상의 환자 정보계 API)로 충분한지를 먼저 구분하십시오. 많은 경우에는 후자로 충분합니다.
2. uuid 연쇄를 설계에 넣는다. 자격확인·공비 확인·의료부조·의료비 지원은 별도 레코드로 uuid로 이어집니다(6장). 「한 번의 접수」를 복원하는 키 설계를, 처음에 소스의 record/ 정의로 확인해 두면 나중에 도움이 됩니다.
3. PushAPI 이벤트의 「의미」를 소스에서 확인한 뒤에 쓴다. push_onlinequa 이벤트는 존재하지만, 발행 지점을 읽는 한 주된 용도는 조회 의뢰(Rreq)의 지시이며, 결과 등록 API(onlinequa2/onlinequa3)는 발행하지 않습니다. onlinequa1도 결과를 돌려주는 API가 아니라 의뢰 조립 API입니다(4장). 접수 화면의 「자격확인 완료」 표시 같은 연동을 만들 때는, 결과 도착 통지가 니치레세에서 온다는 전제를 둘 수 없습니다. 결과 도착을 가장 먼저 아는 것은 결과를 등록하는 쪽(연계 프로그램)이므로, 연동이 필요하면 가져오기 경로와 같은 곳(등록 처리가 끝난 시점)에서 자사 시스템으로 통지를 내거나, 니치레세의 접수·환자 등록 업무에서의 반영을 전제로 화면을 설계하십시오.
4. 동의 상태를 종류마다 존중한다. 약제·특정 건강진단·진료 정보는 환자의 동의에 따라 흘러오는 정보이며, tbl_onshi_kaku에는 YAKUZAI_DOUIFLG·KENSHIN_DOUIFLG·SHINRYO_DOUIFLG 등 정보 종류마다의 동의 플래그가 있습니다. 취득계 API를 치면 돌아온다고 해서, 해당 종류의 동의 상태를 확인하지 않고 쓰는 설계로 만들지 않아야 합니다.
5. 「매년 늘어난다」는 전제로 유지보수를 설계한다. 7장에서 본 대로, 온자 관련은 API·테이블 모두 매년처럼 확장됩니다. 월별 공개 소스의 lddef/record diff 감시를 운영에 넣고, 제도 대응 릴리스 노트로 읽는 습관을 들이기를 권합니다.
6. 검증은 공식 도구부터. ORCA 공식은 연계 프로그램 외에, 검증용 패턴 파일이나 환경 점검 도구, 의료부조·방문 진료·온라인 진료용 일괄 취득 도구도 공개하고 있습니다. 스스로 테스트 데이터를 만들기 전에, 공식 검증 수단을 확인하십시오.

10. 정리

• 마이나보험증 접수는, 카드 리더→자격확인 단말→(파일 연계)→연계 프로그램→레세콘이라는 릴레이로 처리됩니다. 단말과 레세콘 사이는 OQS 명명의 XML 파일 주고받기가 기본이고, 니치레세에서는 공식 onshi-tools가 그 다리를 맡습니다.
• ORCA 쪽 진입점은 온자 관련 API 20개(등록계·의뢰 조립계·취득계)입니다. 자격확인 결과는 환자 마스터에 바로 쓰이지 않고, tbl_onshi_* 13개 테이블에 일단 쌓인 뒤, 환자 등록 업무가 대조·갱신 판단을 쥐는 2단계 구조입니다.
• tbl_onshi_kaku는 조회에 쓴 검색 조건(SHO_*)과 돌아온 자격 정보(RES_*)를 따로 가지고, 조회 조건과 최신 자격의 어긋남을 레코드 위에서 쫓을 수 있습니다. 관련 레코드는 uuid 연쇄로 묶입니다.
• 온자 관련 COBOL 수정 이력은, 2020년의 신설부터 얼굴 인증·OCR·진료 정보·의료부조·PMH·온라인 진료까지, 제도 확장의 연표 그 자체입니다. 온자 연계는 「만들고 끝」이 아니라, 매년의 확장에 따라가는 유지보수를 전제로 설계해야 할 영역입니다.
• 늘 그렇듯, 이들은 모두 공개 소스에서 1차 정보로 확인할 수 있습니다. 국가 사양서의 어휘(OQS의 XML 항목 이름)가 레세콘 API까지 관통하므로, 제도 자료와 소스를 같은 말로 맞춰 볼 수 있습니다.

시리즈 다음은 레셉트의 점검·사정 로직을 예정합니다. 의료기관 안의 데이터 점검(ORCA의 orca41 업무)과 심사 지급 기관 쪽의 컴퓨터 점검이 각각 무엇을 보는지를, 마찬가지로 소스와 공개 자료에서 분해합니다.

11. 참고 자료

• 온라인 자격확인에 대하여(의료기관·시술소 등, 시스템 벤더용) - 후생노동성
• 의료기관 등 종합 포털사이트(연계 애플리케이션 등의 기술 자료)
• 니치레세 온라인 자격확인 - 일의표준레셉트소프트 - ORCA Project(onshi-tools·OQS 파일 연계·검증용 자료)
• 온라인 자격확인 일괄 취득 도구 - 일의표준레셉트소프트 - ORCA Project
• 일의표준레셉트소프트의 온라인 자격확인 대응에 대하여 - 일본의사회 ORCA 관리 기구
• 니치레세 본체 5.2계열 소스코드(2026년 7월 공개 스냅샷) lddef/orca14.ld / lddef/orca71.ld / lddef/api01rv2.ld / cobol/orca14/ORAPION*.CBL / cobol/orca71/ORAPION*.CBL / record/tbl_onshi_*.db / record/xml_onlinequares1.db / record/push_onlinequa.db / cobol/orca12/ORCGP02.CBL 외 ── 본문의 API 목록·테이블 항목·수정 이력 서술은 모두 이 스냅샷에 근거합니다

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

마이나보험증으로 접수하면, 보험 자격 정보는 어떻게 레세콘에 들어가나요?

얼굴 인증 카드 리더로 본인 확인이 끝나면, 자격확인 단말이 사회보험진료보수지급기금·국민건강보험중앙회의 온라인 자격확인 등 시스템에 조회하고, 자격 정보를 XML 파일로 받습니다. 레세콘과의 사이는 공유 폴더를 통한 파일 연계가 기본이며, ORCA(니치레세)의 경우 공식 제공 연계 프로그램(onshi-tools)이 결과 파일을 가져옵니다. 가져온 결과는 니치레세 안의 온자 관련 테이블(tbl_onshi_kaku 등)에 쌓이고, 접수·환자 등록 업무에서 환자 정보·보험 정보로 반영됩니다.

온라인 자격확인으로 흘러오는 것은 보험 자격 정보뿐인가요?

자격 정보만이 아닙니다. 환자의 동의를 전제로, 약제 정보·특정 건강진단 정보·진료 정보도 의료기관 쪽에서 열람할 수 있습니다. ORCA 소스에도 자격확인 결과와는 별도로 약제 정보·특정 건강진단 정보·진료 정보(의과·치과) 각각의 등록 API와 전용 테이블이 있습니다. 나아가 의료부조(생활보호) 자격확인이나 의료비 지원 정보(PMH) 연계 등, 대상은 해마다 넓어지고 있습니다.

ORCA(니치레세)의 온라인 자격확인 관련 API는 몇 개인가요?

공개된 5.2계열 소스(2026년 7월 스냅샷)의 LD 정의를 세면, 온라인 자격확인 관련 엔드포인트는 20개입니다. 내역은 자격확인 결과나 약제·특정 건강진단·진료 정보를 니치레세에 등록하는 등록계, 연계 프로그램이 자격확인 단말에 보낼 조회 의뢰 데이터를 조립해 돌려주는 의뢰계, 전자차트 등이 축적 데이터를 가져가는 취득계입니다. 2020년 11월에 처음 3개가 만들어졌고, 이후 제도가 확장될 때마다 API가 늘어왔습니다.

온라인 자격확인 주변의 연계 시스템을 만들 때, 무엇에 주의해야 하나요?

먼저, 자격확인 단말과 레세콘 사이는 XML 파일 주고받기(연계 애플리케이션 방식)가 기본이라는 전제를 잡는 일입니다. 그다음 ORCA 연계에서는 uuid로 관련 레코드를 따라가는 설계라는 점, 등록계 API와 취득계 API의 역할 차이, 약제·특정 건강진단·진료 정보 열람에는 환자의 동의 상태가 걸린다는 점에 주의가 필요합니다. 또한 제도 대응으로 API나 테이블이 매년처럼 확장되므로, 월별로 공개되는 소스의 diff 감시를 운영에 넣는 것을 권합니다.

저자 프로필

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

Go Komura

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

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