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

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

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

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

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

이 글의 전제

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

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

목차

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

1. 먼저 결론 ── 자격확인은 ‘4가지 등장인물’의 릴레이다

마이나보험증을 태그한 뒤 자격정보가 레세콘에 실리기까지를 한 장으로 그리면, 등장인물은 4가지입니다.

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_*)에 일단 축적되며, 접수・환자등록업무가 여기서 환자정보・보험정보로 반영한다.

포인트는 자격확인 결과가 환자마스터에 직접 기록되는 것이 아니라, 전용 테이블에 일단 쌓인다는 것입니다. ‘조회 기록’과 ‘환자마스터로의 반영’이 분리된 이 이단 구조가, 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의 괄호 안 설명은 구현 내용에서 보충한 것입니다)

이 목록은 역할에 따라 3개 그룹으로 나뉩니다.

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장에서 언급한 이단 구조가 여기서 분명히 보입니다. 온자에서 유래한 데이터는 환자마스터(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) 등.
• 동의 관련: 동의플래그는 1개가 아니라, 정보종별별로 나뉘어 나열됩니다. 약제(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장의 이단 구조는 이 책임분계를 위한 설계라고 해석할 수 있습니다.

전자차트나 접수시스템을 만드는 쪽에서 볼 때 함의는 명확합니다. 자격확인 결과를 자사 시스템 측에서 환자마스터에 직접 반영하는 지름길을 만들면, 이 대조 로직을 그냥 지나쳐 버리게 됩니다. 반영은 ORCA의 업무(또는 그에 준하는 API)를 거치는 것이 올바른 순서입니다.

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

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

1. 접점은 2곳이다. 자격확인단말과의 접점(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개 테이블에 일단 축적되며, 환자등록업무가 대조・갱신의 판단을 쥐는 이단 구조로 되어 있습니다.
• 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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.