사정(査定)과 반려(返戻)는 어디서 일어나는가 ── 레셉트 점검 로직을 ORCA의 소스코드와 공개 자료로 분해한다

의료기관이 창구에서 받는 수입은 일부에 지나지 않고, 수입의 대부분은 한 달에 한 번 하는 레셉트 청구로 결정됩니다. 그래서 현장에서는 “사정됐다”, “반려가 왔다”는 말이 무겁게 다가옵니다. 그런데 시스템을 다루는 엔지니어에게는 사정·반려가 어디서, 어떤 로직으로 발생하는지가 의외로 잘 보이지 않는 주제입니다.

시리즈 1회에서는 레세콘의 역할을, 2회에서는 니치레세 API를, 3회에서는 온라인 자격확인을 다뤘습니다. 이번에는 레셉트 업무의 핵심인 점검·심사의 로직을, 레셉트가 지나가는 “관문”을 한 줄로 늘어놓는 방식으로 분해합니다.

• 반려·사정·재심사라는 용어의 정확한 의미
• 의료기관 안의 체크 ── ORCA의 데이터 체크 업무와 체크마스터 구현
• 제출 전의 레세덴 데이터 체크
• 심사지급기관 쪽의 체크 ── 컴퓨터 체크·대조점검·종람점검
• 레세콘 쪽과 심사 쪽이 구조적으로는 같은 “규칙표+엔진”이라는 점

제도에 관한 서술은 지급기금·의사회 등의 공개 자료에, ORCA 구현에 관한 서술은 공식 공개된 니치레세 본체 5.2계 소스(2026년 7월 1일 공개 스냅샷) 를 실제로 읽고 확인한 결과에 근거합니다.

용어의 최소 세트 ── 이것만 알면 읽을 수 있습니다

의료 업계 약어가 이어지므로, 먼저 최소한만 고정합니다. 이후 본문은 이 의미로 읽어 주십시오.

관계를 한 장으로 그리면, 레셉트와 금전은 다음과 같이 흐릅니다.

flowchart LR
    PT["환자"] -->|"진료·본인부담금"| MED["의료기관<br/>(레세콘으로 레셉트 작성)"]
    MED -->|"레셉트(청구)"| SSK["심사지급기관<br/>(지급기금·국보련)"]
    SSK -->|"심사 완료 청구"| HKN["보험자"]
    HKN -->|"지급"| SSK
    SSK -->|"지급"| MED
    SSK -.->|"반려·사정 통지"| MED

이 글이 다루는 것은 가운데의 “레셉트가 의료기관에서 심사지급기관을 지나가는 동안, 어디서 무엇이 체크되는가” 입니다.

대상 독자는 의료기관용 시스템을 다루는 엔지니어(레세콘 연계, 전자차트, 부문 시스템)와 원내 정보시스템 담당자입니다. 의료사무 실무 경험은 전제로 하지 않습니다. 시리즈를 이미 읽었다는 것도 전제로 하지 않습니다. 다만 다음 회를 읽어 두면 배경을 이해하기 쉬워집니다.

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

목차

1. 먼저 결론 ── 레셉트는 “4개의 관문”을 통과합니다
2. 용어를 짧게 정리합니다 ── 반려·사정·증감점·재심사
3. 관문① ORCA의 데이터 체크 업무를 소스로 읽습니다
4. 체크마스터라는 규칙표 ── tbl_chk계 테이블의 설계
5. 입력 시점의 체크와 API ── 점검은 월말만이 아닙니다
6. 관문② 레세덴 데이터 체크 ── 청구 데이터의 점검
7. 관문③④ 심사지급기관의 컴퓨터 체크와 대조·종람점검
8. 양쪽 모두 “규칙표+엔진”입니다 ── 엔지니어를 위한 구조도
9. 실무 포인트 ── 점검 정밀도를 높이기 위해 시스템 쪽에서 할 수 있는 일
10. 정리
11. 참고 자료

1. 먼저 결론 ── 레셉트는 “4개의 관문”을 통과합니다

레셉트 한 건이 의료기관의 입력에서 지급에 이르기까지 지나가는 주요 체크포인트를 한 장으로 그리면 다음과 같습니다.

flowchart LR
    subgraph clinic["의료기관 안"]
        NYU["매일의 입력<br/>(입력 시점 체크)"]
        DC["① 데이터 체크 업무<br/>(ORCA: orca41)"]
        REC["② 레세덴 데이터 체크<br/>(청구 데이터 점검)"]
        NYU --> DC --> REC
    end
    subgraph SHINSA["심사지급기관(지급기금·국보련)"]
        CC["③ 컴퓨터 체크<br/>+ 대조점검·종람점검"]
        JIN["④ 직원 점검<br/>+ 심사위원회"]
        CC --> JIN
    end
    REC -->|"온라인 청구"| CC
    JIN -->|"심사 완료 청구"| HOKEN["보험자"]
    HOKEN -.-> PAY["지급<br/>(심사지급기관을 거쳐 의료기관으로)"]
    JIN -.-> RET["반려(반송)·사정(감점)<br/>(의료기관에 통지 → 수정·재청구로)"]

• 관문①(내용 점검): 레세콘이 “병명과 약이 맞는지”, “산정 누락은 없는지”처럼 진료 내용의 정합성을 검사합니다. ORCA에서는 데이터 체크 업무가 이 역할을 맡습니다.
• 관문②(청구 데이터 점검): 제출할 전자 레셉트(레세덴 파일)를 청구 데이터로서 검사합니다(기록 형식부터 코멘트 기재 요건까지). ORCA에서는 레세덴 데이터 체크입니다.
• 관문③(기계에 의한 심사): 심사지급기관의 컴퓨터 체크가 고시·통지나 의약품 첨부문서에 근거한 규칙으로 레셉트를 기계적으로 훑고, 의심스러운 항목에 표시를 붙입니다. 동일 환자의 의과·조제 레셉트를 맞춰 보는 대조점검, 과거 월의 레셉트와 비교하는 종람점검도 여기에 포함됩니다.
• 관문④(사람에 의한 심사): 기계가 붙인 표시를 바탕으로 직원이 점검하고, 최종적으로는 심사위원회가 판단합니다. 그 결과가 반려나 사정으로 의료기관에 통지됩니다.

엔지니어로서 잡아야 할 본질은, 관문①과 관문③이 “같은 종류의 검사”를 양쪽에서 하고 있다는 점입니다. 의료기관 쪽은 “심사에서 걸릴 청구를 제출 전에 찾고 싶다”, 심사 쪽은 “규칙에 맞지 않는 청구를 찾고 싶다”. 이 대칭성은, 뒤에서 보듯이 구현 구조의 유사(양쪽 모두 규칙표+엔진)로 나타납니다.

2. 용어를 짧게 정리합니다 ── 반려·사정·증감점·재심사

제도 용어를 짧게 정리합니다.

중요한 점은, 반려는 “다시 하기”, 사정은 “감액의 확정”이라서 영향의 무게가 다르다는 것입니다. 그리고 대조점검·종람점검은 레셉트 한 장만 보고는 잡을 수 없는 오류(월을 넘는 횟수 제한, 의과와 조제의 어긋남)를 잡습니다. 다만 성질은 다릅니다. 다른 기관의 레셉트와 맞춰 보는 일(대조)은 의료기관 안에서는 원리적으로 할 수 없는 반면, 자기 병원의 과거 월과 비교하는 일(종람에 해당)은 자기 병원 데이터 범위에서 가능합니다. 이 선을 이해한 다음 “안에서 잡을 수 있는 것은 전부 안에서 잡는다”가 점검 업무의 목표가 됩니다.

3. 관문① ORCA의 데이터 체크 업무를 소스로 읽습니다

소스를 구하는 방법과, 이 글을 읽는 순서

여기서부터 소스를 읽습니다. 같은 일은 누구나 자기 환경에서 할 수 있으므로, 먼저 길을 적어 둡니다.

• 구하는 방법: ORCA Project의 기술정보 페이지에서 소스가 공개되어 있습니다. 매월 1일에, 전월 1일 시점의 소스가 tar볼(zip)로 공개되는 형태이며, 5.2계 본체는 https://ftp.orca.med.or.jp/pub/src/jma-receipt.r_5_2_branch.zip입니다(디렉터리 목록 표시는 되지 않으므로, 기술정보 페이지의 링크로 받아 주십시오).
• 이 장 이후에서 여는 파일: 업무 구성은 lddef/orca41.ld, 화면은 screen/D0x.glade, 검사 처리는 cobol/orca41/와 cobol/orcabt/, 규칙표 정의는 record/tbl_chk*.db와 cobol/copy/CPCHK.INC입니다.
• 따라가는 방법: 일본어 검색은 문자 인코딩에 좌우되므로, 우선 영숫자 식별자를 단서로 삼는 편이 확실합니다.

# 데이터 체크 업무의 구성(화면·배치·API 목록)
less lddef/orca41.ld

# 검사 로직 본체의 배치 군
ls cobol/orcabt/ORCDTCHK*.CBL

# 규칙표 정의와, 일본어 주석이 붙은 항목 정의
less record/tbl_chk.db
less cobol/copy/CPCHK.INC

파일 종류의 이름도 먼저 잡아 둡니다. COBOL이나 GTK에 익숙하지 않아도, 이 셋만 알면 읽을 수 있습니다.

업무의 구성

ORCA의 데이터 체크는 업무 메뉴 41번이며, 소스에서는 cobol/orca41/ 디렉터리와 lddef/orca41.ld가 대응합니다. LD 정의를 보면 구성이 그대로 보입니다.

• 화면 쪽: D01“레셉트 체크 지시”를 기점으로, D02“개별 지시”·D03“확인 항목 설정 등록”·D04“오류 내용 확인”으로 각각 갈라지고, D05“예외 설정 목록”은 D04에서 호출됩니다(분기는 ORCGD01.CBL·ORCGD04.CBL의 화면 전환 처리이며, 화면 이름은 각 screen/D0x.glade의 제목으로 확인할 수 있습니다).
• 엔진 쪽: 검사 로직의 본체는 화면이 아니라 배치 프로그램 군 cobol/orcabt/ORCDTCHK000〜011.CBL에 있습니다. 화면에서는 ORCGDSUB02.CBL이 잡(셸 ID ORCBSD1)으로 이 배치를 띄우는 구조라서, 대화 화면과 검사 처리가 분리되어 있습니다.
• API 쪽: bindapi "datacheckv3"로 데이터 체크를 외부에서 실행하는 API(ORCGDAPI01)가 바인드되어 있습니다.

API의 요청 정의(record/xml_data_checkv3req.db)가, 이 업무의 입력 사양을 가장 짧게 보여 줍니다.

data_checkv3req {
    Request_Number             varchar(02);   -- 00=정보 취득 / 01=체크 실행 / 02=상태 확인
    Karte_Uid                  varchar(36);   -- 호출 측 식별(실행 시 필수. 비어 있으면 오류)
    Orca_Uid                   varchar(36);   -- 잡 식별(상태 확인 시 필수. 실행 시 응답으로 받음)
    Perform_Month              varchar(07);   -- 대상 진료 연월
    Start_Day / End_Day        varchar(02);   -- 날짜 범위
    InOut                      varchar(01);   -- 입원·외래 구분
    Check_Insurance_Information { Id; }[6];   -- 대상 보험(최대 6)
    Check_Item_Information    { Id; }[22];    -- 확인 항목 ID(최대 22)
    Patient_Information { Patient_ID; }[100]; -- 대상 환자(최대 100)
};

(Request_Number 값의 의미는 ORCGDAPI01.CBL의 상수 정의와 분기에서, Karte_Uid·Orca_Uid의 필수 검사는 ORCGDAPI01S01.CBL·ORCGDAPI01S02.CBL에서 확인할 수 있습니다. 실행(01)은 잡으로 돌아가고, 실행 응답으로 받은 Orca_Uid를 붙여 상태 확인(02)으로 진행을 따라가는 비동기 설계입니다)

눈에 띄는 점은 Check_Item_Information이 22개 요소의 배열이라는 것입니다. 데이터 체크는 단일 검사가 아니라 “확인 항목”이라 부르는 검사의 집합이며, 실행 때 무엇을 돌릴지 고르는 구조입니다. 오류 내용 확인 화면(D04.glade)에는 예외 등록 장치도 있어, 개별 오류를 “체크하지 않음(당월)”, “체크하지 않음(항상)”으로 막을 수 있습니다(예외는 테이블 tbl_chkreigai에 저장됩니다). 오탐을 운용으로 줄여 갈 수 있는, 실용적인 규칙 엔진의 형태입니다.

참고로 D04.glade에는 샘플 데이터로 “폰타르”(해열진통제)와 “위궤양”, 체크마스터 구분 “1 약제와 병명”이 들어 있습니다. 화면 정의의 샘플에까지, 다음 장에서 볼 “약제와 병명의 대응 체크”라는 대표적인 쓰임새가 새겨져 있는 셈입니다.

4. 체크마스터라는 규칙표 ── tbl_chk계 테이블의 설계

데이터 체크가 가진 “무엇이 옳은가”에 대한 지식은, 두는 곳이 둘로 나뉩니다.

• 규칙표(체크마스터)가 갖는 것: 적응 병명·금기·병용 산정처럼 의약품과 진료행위의 대응 관계. COBOL에 하드코딩되어 있지 않고, 테이블 군에 데이터로 들어 있습니다.
• 프로그램 코드가 갖는 것: 보험·기호번호·실일수의 정합성처럼 제도의 기본 구조에 관한 체크. 배치 군(ORCDTCHK*)에 직접 구현되어 있고, 수정 이력에도 “가지번호 데이터 체크 대응”, “노동보험번호 데이터 체크 대응”처럼 코드 쪽의 보강이 이어집니다.

즉, “체크마스터를 손보면 모든 규칙이 바뀐다”는 이해는 잘못입니다. 규칙표가 맡는 것은 앞의 영역뿐이고, 뒤의 영역은 프로그램을 고치지 않으면 바뀌지 않습니다.

이 전제로 테이블 목록(lddef/orcadb.inc)에서 관련 테이블을 뽑으면 다음과 같습니다.

규칙의 구조는 record/tbl_chk.db와 COPY 구 cobol/copy/CPCHK.INC(항목에 일본어 주석이 붙어 있음)에서 확인할 수 있습니다. 본질만 뽑으면 한 줄의 규칙은 이런 모양입니다.

체크 구분(CHKKBN) + 진료 코드(SRYCD) + 유효기간(YUKOSTYMD〜YUKOEDYMD)
  → 대응하는 코드의 집합(CDKBN + CD), 입원·외래 구분, 처리 구분

즉 “진료 코드 X에는, 기간 Y 안에서, 코드 집합 Z 중 하나가 대응해야 한다(혹은 함께 있어서는 안 된다)“는 선언적 규칙입니다. 어떤 종류의 규칙이 있는지는 체크마스터의 장표 출력 화면(screen/X91.glade)에 열거되어 있습니다.

• 약제와 병명 / 병명과 약제(적응 병명의 대응)
• 진료행위와 병명 / 병명과 진료행위
• 약제와 병용 금기
• 투여 금기 약제와 병명
• 진료행위의 병용 산정(같은 날 안·같은 월 안·같은 회계 안)
• 진료행위끼리의 산정 누락
• 산정 횟수 체크

“약제와 병명”과 “병명과 약제”가 짝을 이루는 점이 재미있습니다. 방향이 바뀌면, 검출하려는 대상도 바뀝니다.

다만 구현상으로는 한 표를 거꾸로 찾는 것이 아닙니다. 장표 프로그램(cobol/orca103/ORCHXLST.CBL)을 읽으면, 위 표대로 다른 테이블·다른 키로 관리되고 있어, 한쪽 방향을 등록했다고 반대 방향까지 적용되는 것은 아닙니다. 유효기간을 갖는 이유는 2년마다의 진료보수 개정이나 약가 등재·삭제에 규칙 쪽이 따라가기 위해서이며, 1회에서 본 “제도를 따라가는 것이야말로 레세콘의 본질”이 규칙표 설계에도 관통합니다.

또한 모든 규칙이 위의 한 모양에 들어가는 것은 아닙니다. tbl_chksnd·tbl_chk005에는 병명 문자열(BYOMEI)이나 의심 병명 취급을 가진 모양이, tbl_chktrd에는 같은 날·같은 월 구분(DAYMONTHKBN)을 가진 모양이 있어, 체크 종류에 따라 규칙 테이블 자체가 다른 모양으로 정규화되어 있습니다. “규칙표”라고 해도 단일 스키마가 아니라는 점은, 구현을 읽을 때의 주의점입니다.

5. 입력 시점의 체크와 API ── 점검은 월말만이 아닙니다

데이터 체크는 월별 배치 점검이지만, 체크는 그것만이 아닙니다. 소스에서는 더 상류──매일의 입력 시점──에서 움직이는 장치도 확인할 수 있습니다.

• 병용 금기 체크 API: /api01rv2/contraindicationcheckv2(담당 프로그램 ORAPI021R4V2 “병용금기약제정보반환”, 헤더의 작성 날짜는 2016년). 환자와 약제를 넘기면 병용 금기 해당 정보를 돌려주는 API이며, 전자차트가 처방 입력 시점에 니치레세에 묻는 연계를 만들 수 있습니다.
• 데이터 체크 API: 앞 장의 datacheckv3. 월별 배치를 화면 조작 없이 띄울 수 있어, “매일 밤 당월분을 자동 체크하고 다음 날 아침 오류 목록을 낸다”와 같은 운용을 짤 수 있습니다.

여기에는 설계상의 보편적인 교훈이 있습니다. 오류는 발생원에 가까울수록 싸게 고칠 수 있습니다. 월말 데이터 체크에서 찾은 오류는 한 달치를 한꺼번에 고치게 되지만, 처방 입력 시점에 병용 금기를 알아채면 몇 초 만에 대처할 수 있습니다(다만 이 API가 보는 것은 병용 금기입니다. 적응 병명 누락 같은 대응 관계 체크는 월별 데이터 체크 쪽의 영역이며, 입력 시점이 대신해 주는 것은 아닙니다). ORCA의 체크 장치가 “입력 시점(API)→월별(데이터 체크)→제출 전(레세덴 체크)”로 여러 단인 것은, 이 원칙의 구현입니다.

6. 관문② 레세덴 데이터 체크 ── 청구 데이터의 점검

데이터 체크가 “진료 내용의 정합성”을 보는 반면, 제출 직전에는 레세덴 데이터 체크라는 다른 체크가 기다립니다. 대상은 전자 레셉트(레세덴) 파일이며, 기록 형식이나 필수 기록의 유무처럼 청구 데이터로서의 옳음을 검사합니다.

이 체크의 조건은 ORCA 공식 사이트에서 “레세덴 데이터 체크 체크 조건 사양”으로 PDF 공개되어 있습니다(의보·산재·애프터케어 3종). 즉 ORCA는 내용 체크(체크마스터는 장표나 CSV로 확인할 수 있음)뿐 아니라, 레세덴 체크의 조건 사양도 문서로 공개하고 있어, “무엇이 체크되는가”를 1차 자료로 확인할 수 있습니다.

다만 레세덴 체크를 “형식만의 검사”로 보는 것은 정확하지 않습니다. 소스를 보면, 레셉트 코멘트의 기재 요건을 체크하는 서브프로그램(cobol/common/ORCSRECECOMCHK.CBL, 2018년 신규)이나, 온라인 진료료 등에 관련된 관리료·지도료의 산정 이력 체크(ORCSRECESRCHK.CBL)가 레세덴 처리 쪽에 구현되어 있고, 월별 처리 Ruby 스크립트(저장소에서는 scripts/monthly/receden_check.rb.in. 설치 때 receden_check.rb로 배치되는 템플릿)는 점수 마스터·병명 마스터와의 정합성 검증까지 합니다(COBOL 세계에 Ruby가 같이 있는 것도, 이 소스의 재미있는 점입니다). 큰 그림으로는 “데이터 체크=진료 내용, 레세덴 체크=청구 데이터”라는 분담이지만, 경계는 엄밀하지 않고, 의미 쪽 체크의 일부는 레세덴 체크가 맡습니다──여기를 단순하게 잘라 이해하면 오류의 출처를 잘못 봅니다. 둘을 통과해야 비로소 “심사에 낼 수 있는 레셉트”가 된다는 점이 실무상의 요점입니다.

7. 관문③④ 심사지급기관의 컴퓨터 체크와 대조·종람점검

제출된 레셉트는 심사지급기관(피용자보험은 지급기금, 국보·후기고령자는 국보련)의 심사로 들어갑니다. 여기서 중요한 것은, 심사 쪽의 체크 규칙도 일부가 공개되어 있다는 점입니다.

지급기금의 “컴퓨터 체크에 관한 공개” 페이지에서는, 공개 대상으로 두 종류의 파일이 제공됩니다(모두 CSV 형식, 단계적으로 확대 중).

이름에 주목해 주십시오. 지급기금 쪽도 “체크마스터”라는 말을 씁니다. 고시·통지 기반의 규칙과 첨부문서 기반의 규칙을 나눠 관리하는 구조는, ORCA가 점수 산정 규칙을 프로그램에, 의약품의 적응을 체크마스터에 두는 구조와 잘 대응합니다.

한편 공개되지 않는 체크도 있습니다. 공개 페이지에는, 적요란 기재 사항을 확인해야 하는 사례, 의학적 판단이 필요한 사례, 의약품·진료행위의 적응에 관한 사례 등은 공개를 신중히 검토한다고 명시되어 있습니다. 또한 지급기금은, 컴퓨터 체크는 의심스러운 항목에 표시를 붙이는 것이며, 기계적으로 사정하는 것이 아니라 직원의 점검과 심사위원회의 판단을 거친다는 위치를 반복해서 설명합니다. “컴퓨터 체크=자동 사정”이 아니라는 점은, 시스템 쪽 사람도 정확히 이해해 두어야 할 부분입니다.

그리고 2장에서 다룬 대조점검·종람점검. 2012년부터 본격화된 이 둘은, 레셉트 단표의 검사가 아니라 레셉트 사이 관계의 검사입니다. 여기서 경계선을 정확히 그어 둡니다. 대조점검(동일 환자의 의과 레셉트와 조제 레셉트를 맞춰 보는 일)은 조제약국이라는 다른 기관의 레셉트가 상대이므로, 의료기관 안의 점검으로는 원리적으로 대체할 수 없습니다. 반면 종람점검(동일 환자의 당월과 과거 월의 비교)에 해당하는 일은, 자기 병원의 청구 이력 범위라면 원내에서도 가능합니다. 횟수 제한이 있는 산정의 관리나, 원외 처방에 대응하는 병명의 관리를 자기 병원 데이터 범위에서 엄밀히 해 두는 것이, 대조·종람에서의 지적을 줄이는 현실적인 대책이 됩니다.

8. 양쪽 모두 “규칙표+엔진”입니다 ── 엔지니어를 위한 구조도

여기까지를 한 장으로 접으면, 레셉트 점검의 세계는 다음과 같이 보입니다.

구조는 같은 형이고, 차이는 규칙의 망라 범위와 검사 범위에 있습니다. 여기서 엔지니어가 끌어낼 수 있는 결론은 셋입니다.

1. 규칙은 데이터, 엔진은 프로그램이라는 분리가, 제도 개정에 20년 이상 따라가기 위한 필수 조건이었습니다. 규칙이 코드에 묻혀 있었다면, 개정 때마다 전면 수정이 됩니다.
2. 체크마스터 연동형 영역(적응 병명·금기 등)에서는, 의료기관 쪽의 점검 정밀도는 엔진의 똑똑함보다 규칙표의 충실도로 정해집니다(보험·실일수처럼 코드 구현 쪽 체크는, 프로그램 자체의 범위가 그대로 검출력이 됩니다). ORCA의 체크마스터에는 제공 분(tbl_chk_master)과 사용자 등록 분(tbl_chk_user)의 두 계통이 있어, 자기 병원에서 규칙을 더할 수 있는 설계입니다. 시판 레셉트 점검 소프트웨어의 가치도, 끝까지 가면 독자 규칙표의 충실도에 있습니다.
3. 심사 쪽 규칙의 일부가 공개된 지금, “심사 쪽의 공개 규칙을 자기 병원 점검에 어떻게 넣을 것인가”가 새로운 실무 주제가 되고 있습니다. 공개 CSV라는 기계 가독 형식으로 제공된다는 의미는, 엔지니어라면 놓치지 말아야 합니다.

9. 실무 포인트 ── 점검 정밀도를 높이기 위해 시스템 쪽에서 할 수 있는 일

의료기관의 시스템 담당이나 연계 벤더 입장에서, 잡아 두고 싶은 점을 정리합니다.

1. 체크의 다단 구조를 운용에 옮깁니다. 입력 시점(병용 금기 API 등)→월별(데이터 체크)→제출 전(레세덴 체크)의 세 단은 역할이 다릅니다. “월말에 한 번 데이터 체크를 돌리기만 하는” 운용이라면, 상류의 두 단을 살릴 여지가 있습니다.
2. 데이터 체크는 API로 자동화할 수 있습니다. datacheckv3로 확인 항목·대상 환자를 지정한 정기 실행을 짤 수 있습니다. 야간 배치+아침 오류 목록의 형태로 두면, 월말 점검 부하를 매일로 나눌 수 있습니다.
3. 예외 등록을 “규칙의 튜닝”으로 다룹니다. 오탐을 내버려 두면 오류 목록이 읽히지 않게 됩니다. 예외(tbl_chkreigai)와 자기 병원 규칙(tbl_chk_user)을 계획적으로 유지보수하고, 오류 목록의 신호 대 잡음비를 유지하는 일이 점검 업무의 생명선입니다.
4. 반려·사정 결과를 분석 루프로 되돌립니다. 증감점연락서의 사유를 집계하고, 자주 나오는 패턴을 체크마스터의 자기 병원 규칙이나 입력 시점의 운용에 반영하는 일──이것이 “규칙표를 키우는” 일이며, 심사 쪽과의 인식 차이를 줄이는 유일한 방법입니다.
5. 심사 쪽의 공개 자료를 정기적으로 봅니다. 지급기금의 컴퓨터 체크 공개는 계속 갱신되고 있습니다. 대조·종람점검 해설을 포함해, 심사 쪽이 “무엇을 보는가”를 공식으로 설명하는 시대에, 그것을 읽지 않을 이유는 없습니다.

10. 정리

• 레셉트는 ①레세콘의 내용 체크→②레세덴 데이터 체크→③심사 쪽의 컴퓨터 체크(+대조·종람점검)→④직원·심사위원회라는 여러 단의 관문을 통과합니다. 반려는 반송, 사정은 감점이며, 다른 기관의 레셉트와 맞춰 보는 대조점검은 의료기관 안에서는 대체할 수 없습니다(자기 병원의 과거 월과 비교하는 일은 원내에서도 가능합니다).
• ORCA의 데이터 체크는 orca41 업무로 구현되어 있고, 적응 병명·금기·병용 산정 등의 규칙은 체크마스터에 데이터로 둡니다(보험·실일수 등의 기본 정합성은 코드 쪽). 확인 항목을 골라 실행하고, 예외 등록으로 오탐을 막으며, datacheckv3 API로 외부에서도 돌릴 수 있습니다──공개 소스로 여기까지 확인할 수 있습니다.
• 심사 쪽도 본부점검조건+체크마스터라는 규칙표를 CSV 공개하고 있어, 의료기관 쪽과 심사 쪽은 같은 형의 “규칙표+엔진” 구조를 갖습니다. 차이는 규칙의 망라 범위와 검사 범위입니다(모든 기관·모든 월을 볼 수 있는 것은 심사 쪽뿐입니다).
• 점검 정밀도를 정하는 것은 엔진이 아니라 규칙표의 충실도와 운용입니다. 예외 등록·자기 병원 규칙·사정 결과의 분석 루프·심사 쪽 공개 규칙의 반영이 실무의 요점이 됩니다.

시리즈 다음 회 이후에는, ORCA의 데이터베이스 스키마를 직접 읽는 “DB편”이나, 월별 소스 공개를 자동으로 따라가는 diff 감시의 실운용 등을 예정하고 있습니다.

11. 참고 자료

• 컴퓨터 체크에 관한 공개 - 사회보험진료보수지급기금(본부점검조건·체크마스터의 CSV 공개)
• 대조점검·종람점검 - 사회보험진료보수지급기금
• 레셉트의 점검, 심사, 반려, 사정, 재심사청구 등 - 도쿄도의사회 “개업의를 위한 보험진료의 요점”
• 일의표준레셉트소프트 외래판 매뉴얼(데이터 체크 관련) - ORCA Project
• 레세덴 데이터 체크 체크 조건 사양 - ORCA Project
• 기술정보 - ORCA Project(소스코드의 월별 공개·데이터베이스 테이블 정의서)
• 니치레세 본체 5.2계 소스코드(2026년 7월 공개 스냅샷) lddef/orca41.ld / cobol/orca41/ORCGD*.CBL / cobol/copy/CPCHK.INC / record/tbl_chk*.db / record/xml_data_checkv3req.db / screen/D01.glade / screen/D04.glade / screen/X91.glade / lddef/api01rv2.ld(contraindicationcheckv2) 외 ── 본문 중 구현에 관한 서술은 모두 이 스냅샷에 근거합니다

관련 기사

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

관련 토픽

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

이 주제와 연결되는 서비스

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

자주 묻는 질문

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

사정과 반려는 어떻게 다른가요?

둘 다 심사지급기관(사회보험진료보수지급기금·국민건강보험단체연합회)의 심사에 관련된 용어이지만 의미는 다릅니다. 반려는 레셉트가 의료기관으로 되돌아오는 것으로, 기재 미비나 자격 오류 등을 수정해 다음 달 이후 재청구할 수 있습니다. 사정은 심사 결과로 점수가 증감(실무상으로는 거의 감점)되는 것으로, 청구금액이 그만큼 줄어듭니다. 사정에 이의가 있는 경우에는 재심사청구라는 절차가 있습니다.

레셉트는 제출까지 몇 번이나 체크되나요?

크게 나누어 다단계의 체크를 거칩니다. 의료기관 내에서는 레세콘에 의한 내용 체크(ORCA라면 데이터 체크 업무)와, 전자 레셉트 파일을 청구 데이터로서 검사하는 레세덴 데이터 체크. 제출 후에는 심사지급기관의 컴퓨터 체크(고시·통지 기반의 점검 조건과 의약품 첨부문서 기반의 체크마스터), 동일 환자의 의과·조제 레셉트를 맞춰 보는 대조점검, 과거 청구월과 비교하는 종람점검을 거쳐 직원과 심사위원회에 의한 심사가 이루어집니다.

ORCA(니치레세)의 레셉트 체크는 어떻게 구현되어 있나요?

데이터 체크 업무(업무 메뉴 41)로 구현되어 있으며, 공개 소스코드로 구현을 확인할 수 있습니다. 의약품·진료행위의 대응 관계 규칙(약제와 병명, 진료행위와 병명, 약제와 병용금기 등)은 '체크마스터'라 불리는 테이블군에 데이터로 갖고 있으며, COBOL 프로그램이 이를 해석해 환자 데이터를 검사하는 '규칙표+엔진' 구조입니다. 보험이나 실일수의 정합성 같은 기본 체크는 프로그램 쪽에 직접 구현되어 있습니다. 오류의 예외 등록(이 오류는 체크하지 않는다)이나, 외부 시스템에서 데이터 체크를 실행하는 API(datacheckv3)도 마련되어 있습니다.

심사지급기관의 체크 규칙은 공개되어 있나요?

일부가 공개되어 있습니다. 지급기금은 '컴퓨터 체크에 관한 공개'로서, 고시·통지에 기반한 본부점검조건과 의약품 첨부문서에 기반한 체크마스터를 CSV 파일로 공개하고 있으며, 단계적으로 대상을 넓히고 있습니다. 또한 대조점검·종람점검의 구조도 공식 사이트에서 해설되어 있습니다. 다만 적요란 확인이나 의학적 판단을 요하는 사례 등, 공개 대상 외의 체크도 있습니다.

저자 프로필

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

Go Komura

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

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