청구 전 점검 (Claim Preflight)
청구 전 명세서 줄 단위 위험을 근거와 함께 표시하고, 우리 병원 심사결과로 삭감을 진단하고, 이의신청 초안을 씁니다
- 업무 단계
- C1청구·심사
- AI의 자리
- LM 핵심
- 진행 상태
- 기획
- 보는 방법
- 개념 영상
병목과 도입 전·후
삭감 사유는 심사결과에 다 적혀 옵니다. 다음 청구로 이어지지 않을 뿐입니다. 결국 같은 삭감이 또.
도입 전도입 후
반복 삭감
도입 전같은 사유로 또 삭감
깎였던 줄 사전 경고
담당자가 수정
바뀐 고시
도입 전옛 기준으로 청구
진료일 기준 검사
신구 비교 원문
이의신청
도입 전시간 없어 포기
이의신청 초안
병원이 제기
개념 단계라 라이브 데모 대신 소개 영상으로 보여 드립니다. 실제 화면은 병원별로 구축합니다.
지금 막히는 것
- 청구 점검이 담당 직원의 눈
- 삭감 사유를 봐도 다음 달에 같은 걸 또 틀림
- 이의신청은 시간이 없어 포기
- 고시가 바뀐 걸 모르고 옛 기준으로 청구
공급하는 기능
- 시행 기록 ↔ 청구안 대조
- 누락·상병 불일치·형식 오류, 진료일 기준 유효 코드·단가 검사
- 과거 삭감 사례 참조 (자기 병원 + 다른 병원 패턴)
- 삭감 진단 리포트: 과거 1~3년 심사결과를 코드·사유·금액으로
- 이의신청 초안 (조정사유 + 근거 고시 + 비고)
- 승인한 수정만 반영. 자동 제출 없음
AI와 사람의 역할
- AI가 하는 일
- 고시·심사기준 대조, 근거 인용, 위험 줄 설명, 이의신청 초안
- 사람이 정하는 일
- 수정·제출 결정, 이의신청 제기
쌓이는 데이터
고객 병원의 심사결과 줄 단위 데이터 (코드·조정사유·조정금액). 병원이 늘수록 다른 병원에서 깎인 조합도 미리 경고
전제와 주의
- 진행 여부는 고객 병원에서 과거 심사결과를 내보낼 수 있는지로 결정
- EMR 청구 모듈의 규칙 점검과 겹침 → 차별화는 근거 인용·사례·초안
- 4주 POC 선행 (도입 시 구축비 공제)