确认理赔单证真的是那份单证

목표

청구 유형별 필수 서류를 규칙표로 점검하고, 파일 형식을 매직 바이트로 판정하고, 내용 해시로 다시 쓰인 서류를 찾아내고, 파일 이름의 개인정보와 제출 기한과 고아 파일까지 훑어 청구별 보완 요청 목록을 냅니다.

왜 중요한가

서류는 지급 판단의 근거인데, 그 파일이 정말 그 서류인지는 파일 이름이 말해 주지 않습니다. 스캐너가 만든 이미지에 pdf 확장자가 붙고, 같은 영수증이 이름만 바뀌어 두 청구에 쓰입니다. 접수 시점의 자동 점검은 값싸고, 지급 뒤에 발견하는 것은 아주 비쌉니다. 필요한 것은 규칙표 하나와 파일의 앞 몇 바이트, 그리고 해시뿐입니다. 이 접수함의 파일에는 NUL 바이트가 섞여 있습니다. grep 을 물리면 아무것도 못 찾거나 이진 파일이라는 말만 돌아옵니다. od 로 보거나 파이썬에서 바이트로 읽으세요.

단계

1. 재료 스크립트를 /root/docs/gen_docs.py 로 저장해 실행하고 /root/docs/claims.db 와 /root/docs/inbox 를 만듭니다.
2. 규칙표와 접수 기록을 맞대 빠진 서류를 /root/docs/missing.txt 에 적습니다.
3. /root/docs/sniff.py 로 형식을 판정하고 접수함 전체의 판정표를 /root/docs/filetypes.tsv 에 냅니다.
4. 내용 해시로 다시 쓰인 서류를 묶어 /root/docs/reuse.txt 에 적습니다.
5. 파일 이름에 실려 온 개인정보를 세어 /root/docs/namescan.txt 에 적습니다.
6. 제출 기한을 사고일에서 계산해 /root/docs/overdue.txt 에 적습니다.
7. 기록과 실물을 양방향으로 맞대 /root/docs/orphans.txt 에 적습니다.
8. 청구별 보완 요청 목록을 /root/docs/followup.json 에, 보고서를 /root/docs/docs_report.md 에 냅니다.

참고

• 형식 이름은 pdf, png, jpg, zip, unknown 다섯 가지만 씁니다. sniff.py 는 파일 경로 하나를 인자로 받아 형식 이름 한 줄을 냅니다.
• filetypes.tsv 는 한 파일에 한 줄이고, 탭으로 나뉜 세 칸입니다: 파일이름, 확장자(이름에서 뽑은 소문자), 판정한 형식.
• 제출 기한은 사고일부터 30일입니다. 이것은 이 실습의 가정이며 법정 기한이 아닙니다. 기한이 지났는지는 2026-09-17 을 오늘로 두고 셉니다.
• 파일 이름의 개인정보 판정 규칙: 한글 2자에서 4자가 들어 있으면 이름, 여섯 자리에 붙임표에 일곱 자리 숫자 모양이면 번호로 봅니다.
• sqlite3 는 sqlite3 -readonly /root/docs/claims.db "SELECT ..." 로 붙습니다. 접수함은 od -c /root/docs/inbox/K0001_claim_form.pdf | head -2 로 들여다봅니다.
• 흔한 실수: 확장자로 형식을 판정하기, 기한의 기산일을 접수일로 잡기, 기록과 실물을 한 방향으로만 맞대기, 보고서에 개인정보 값을 그대로 옮기기.

청구 표와 접수함 만들기

재료 스크립트를 /root/docs/gen_docs.py 로 저장해 실행하고 /root/docs/claims.db 와 /root/docs/inbox 를 만드세요.

먼저 /root/docs 를 만들고 그 안에서 python3 로 실행합니다. 표는 claim, doc_rule, submission 세 개이고 접수함에는 파일 189개가 생깁니다. 만들어진 파일은 고치지 마세요.

유형별 필수 서류 체크리스트 돌리기

규칙표와 접수 기록을 맞대 /root/docs/missing.txt 에 incomplete_claims·missing_docs·missing_inj·missing_ill·missing_med 를 적으세요.

doc_rule 은 청구 유형마다 필요한 서류 종류를 담고 있습니다. 청구마다 그 집합에서 submission 에 있는 종류를 빼면 빠진 것이 남습니다. 유형별 수는 빠진 서류가 있는 청구를 유형으로 나눠 센 값입니다.

확장자 말고 앞부분 바이트로 형식 가르기

/root/docs/sniff.py 를 만들고 접수함 전체의 판정표를 /root/docs/filetypes.tsv 에 내세요.

PDF 는 %PDF-, PNG 는 십진수 137 80 78 71 13 10 26 10, JPEG 는 FF D8 FF, ZIP 은 PK 03 04 로 시작합니다. 어디에도 맞지 않으면 unknown 입니다. 파일은 반드시 바이트로 여세요. 표는 파일이름, 확장자, 판정 세 칸을 탭으로 나눕니다.

같은 서류가 다시 쓰인 자리 찾기

내용 해시로 같은 파일을 묶어 /root/docs/reuse.txt 에 reused_groups·reused_files·affected_claims 를 적으세요.

파일 이름은 얼마든지 바꿀 수 있으니 sha256 으로 묶습니다. 두 개 이상인 묶음만 셉니다. 걸린 청구 수는 submission 의 filename 으로 되짚어 서로 다른 claim_id 를 센 값입니다.

파일 이름에 실려 온 개인정보 세기

/root/docs/namescan.txt 에 name_in_filename·rrn_in_filename·flagged_files 를 적으세요.

내용을 아무리 잘 가려도 파일 이름은 목록 화면과 백업 색인과 에러 로그에 그대로 남습니다. 한글 2자에서 4자가 들어 있으면 이름, 여섯 자리에 붙임표에 일곱 자리 숫자 모양이면 번호입니다. flagged_files 는 둘 중 하나라도 걸린 파일의 수입니다.

기한을 사고일에서 세기

/root/docs/overdue.txt 에 late_docs·late_claims·overdue_missing 을 적으세요.

기산일은 접수일이 아니라 사고일입니다. 사고일부터 30일을 넘겨 제출된 서류를 세고, 그런 서류가 하나라도 있는 청구를 셉니다. overdue_missing 은 빠진 서류가 있으면서 기한이 2026-09-17 이전에 지난 청구의 수입니다.

기록과 실물을 양방향으로 맞대기

/root/docs/orphans.txt 에 orphan_files·missing_files·claims_with_missing_file 을 적으세요.

접수함에만 있는 파일과 기록에만 있는 파일은 다른 사고입니다. 앞쪽은 누구의 것인지 모르는 개인정보가 남아 있는 것이고, 뒤쪽은 지급 근거가 비어 있는 것입니다. 집합 두 개의 차집합을 양쪽으로 구하세요.

청구별 보완 요청 목록 내기

/root/docs/followup.json 에 청구별 missing·no_file·reused·type_mismatch 를 담고, /root/docs/docs_report.md 에 다섯 절의 보고서를 쓰세요.

네 가지 사유를 한 청구 안에 갈라 적습니다. 사유가 하나도 없는 청구는 목록에 넣지 않습니다. 파일 목록은 정렬해 담으세요. 보고서 절 제목은 확인한 것, 빠진 서류, 형식과 재사용, 파일 이름의 개인정보, 권고 입니다. 보고서에는 개인정보 값을 옮기지 마세요.