사정(査定)과 반려(返戻)는 어디서 일어나는가 ── 레셉트 점검 로직을 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

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

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

목차

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

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

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

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에 익숙하지 않아도 이 3가지만 알면 읽을 수 있습니다.

업무의 구성

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계 테이블의 설계

데이터 체크가 가진 “무엇이 옳은가”에 대한 지식은 저장 위치가 2가지로 나뉘어 있습니다.

• 규칙표(체크마스터)가 갖는 것: 적응병명・금기・병용산정 등, 의약품과 진료행위의 대응관계. COBOL에 하드코딩되어 있는 것이 아니라 테이블군에 데이터로 들어 있습니다.
• 프로그램 코드가 갖는 것: 보험・기호번호・실일수의 정합성 등 제도의 기본 구조에 관련된 체크. 배치군(ORCDTCHK*)에 직접 구현되어 있으며, 수정 이력에도 「가지번호 데이터 체크 대응」「노동보험번호 데이터 체크 대응」 같은 코드 쪽의 추가가 늘어서 있습니다.

즉, “체크마스터를 정비하면 모든 규칙이 바뀐다”는 이해는 잘못입니다. 규칙표가 담당하는 것은 전자의 영역뿐이며, 후자는 프로그램 개수(改修)로만 바뀝니다.

이 전제로 테이블 목록(lddef/orcadb.inc)에서 관련 테이블을 추려내면:

규칙의 구조는 record/tbl_chk.db와 COPY구 cobol/copy/CPCHK.INC(항목에 일본어 주석 있음)로 확인할 수 있습니다. 본질만 뽑아내면 규칙 1행은 다음과 같은 형태입니다.

체크 구분(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. 관문③④ 심사지급기관의 컴퓨터 체크와 부합・종람점검

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

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

이름에 주목해 주십시오. 지급기금 측도 「체크마스터」라는 용어를 사용하고 있습니다. 고시・통지 기반의 규칙과 첨부문서 기반의 규칙을 나누어 관리하는 구조는, ORCA가 점수 산정 규칙을 프로그램에, 의약품의 적응을 체크마스터에 갖는 구조와 정확히 대응합니다.

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

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

8. 양측 모두 “규칙표+엔진”이다 ── 엔지니어를 위한 조감도

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

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

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

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

의료기관의 시스템 담당자나 연계 벤더 입장에서 짚어 두어야 할 점을 정리합니다.

1. 체크의 다단계 구조를 운용에 대응시킨다. 입력 시(병용금기 API 등)→월별(데이터 체크)→제출 전(레세덴 체크)의 3단계는 역할이 다릅니다. “월말에 한 번 데이터 체크를 돌리는” 운용이라면, 상류의 두 단계를 살릴 여지가 있습니다.
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 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.