플러스프로젝트 배경
문제 - 수납과 청구와 처방과 급여와 구매와 회계가 한 줄로 이어진 시스템에서는 한 곳을 고치면 다른 곳의 금액이 함께 움직입니다. 첫째, 보험청구와 본인부담금과 EDI 금액이 다를 때 마지막 숫자만 맞추면 다음 달에 같은 자리가 다시 어긋납니다. 둘째, 고시 해석은 업무 판단인데 개발이 대신 판정하면 대상 범위와 시행일에서 금액이 틀립니다. 셋째, 환자 수납일자와 미수코드와 선수금 변경은 요청자와 승인자가
프로젝트 성과
금액 단계별 대사와 승인 차단과 시행일 경계 판정과 배포 관문
정적 목업이 아닙니다. 도메인 단위 시험 83건과 실제 브라우저 클릭 E2E 88건(PC 1440, 태블릿 768, 모바일 390 세 폭)을 통과했고, 기하와 대비 검사 21개 조합에서 화면 밖 요
핵심 기능
금액 차이를 최초 발생 단계로 말하는 EDI 대사
원내 산정과 EDI 청구파일을 다섯 단계로 각각 계산하고 단계마다 빼서 처음 갈린 자리를 찾습니다
진행 단계
레퍼런스 실측과 판정 코어 설계와 화면 구현과 예외 검증
2026.08.
금액 차이를 최초 발생 단계로 말하는 EDI 대사 — 보험청구와 본인부담금과 EDI 프로그램의 금액이 다를 때 마지막에 보이는 숫자를 맞추면 다음 달에 같은 자리가 다시 어긋납니다. 그래서 진료행위
프로젝트 상세
사실 경계 - 이 자료의 환자 식별자와 금액과 고시 번호와 수가는 전부 지어낸 합성 예시입니다. 실제 환자 자료와 실제 병원 시스템과 실제 외부 연동을 쓰지 않았고 실제 서비스에 연결되어 있지 않습니다. 화면과 문서의 수치는 결정적 고정 자료에서 계산한 검증 데모 값이며 병원 운영 실적이 아닙니다. 진료비 산정과 청구의 최종 판단은 병원 업무 담당자와 심사기관에 있습니다. 실제 Delphi7 빌드 환경과 Sy
