260618 메딕스 내부 위클리 및 병의원관리 디자인 리뷰
2026년 6월 18일 공유
병원·약국 등록 API 및 CSO/수수료 설계 논의
개요
콘텐츠 유형: 회의
병원·약국·도매상 등 거래처 등록 구조와 심평원 API 연동 방식, 사업자/요양기관 식별 로직, CSO 등록 UX, 수수료율 처리 방식을 중심으로 논의했다.
핵심 목적은 사람이 수기로 입력하는 정보를 최소화하고, 심평원 데이터를 최대한 활용해 정확한 자동 등록·자동 식별 체계를 만드는 것이다.
참석자 및 역할
기획/현업 담당자
- 심평원·국세청 조회 방식, 병원/약국 등록 정책, 수수료 요구사항 설명
개발/기술 검토 담당자
- API 명세 확인, 자동화 가능 여부, 요청 파라미터/식별키 검토
디자인/UX 담당자
- 등록·수정 화면 구조, 체크박스/삭제 버튼, 단계 통합 등 UX 검토
결정 사항
심평원 API 중심으로 조회 가능 여부를 우선 확인한다.
- 국세청을 별도로 반드시 거쳐야 하는지 재검토
- 심평원 API 안에서 사업자번호 정상 여부, 개·폐업 여부까지 확인 가능한지 확인 필요
사람이 직접 입력하는 방식보다 자동 조회를 우선한다.
- 요양기관번호, 연락처, 주소, 기관명 등은 가능한 한 심평원에서 자동 반영
병원/약국 리스트에는 요양기관번호를 포함한다.
- 중복 기관명 문제를 줄이기 위한 핵심 식별값으로 사용
병원 유형 리스트를 정리한다.
- 예: 종합병원, 병원, 의원, 한의원 등
등록/수정 UX는 단순화 방향으로 검토한다.
- 수정 화면에서 불필요한 단계 축소
- 체크박스보다 개별 삭제 버튼(X) 방식이 더 적합한지 검토
CSO 계약/교육 관련 일부 영역은 후순위 처리한다.
- 모두싸인 연동 등 미정 요소가 많아 우선순위를 낮춤
액션 아이템
심평원 API 2종의 기능 차이 재확인
- 사업자번호 단독 조회 가능 여부
- 개업/폐업/휴업 상태 조회 가능 여부
- 폐업일자 제공 여부
사업자번호만으로 조회 가능한지 기술 검토
- 가능하면 리스트 조회 불필요
- 불가능하면 기관명+지역 기반 리스트 조회 구조 유지
병원/약국/도매상/제약사 구분 규칙 정리
- 어떤 메뉴에서 어떤 사업자 유형을 등록할 수 있는지 명확화
원내약국 여부 처리 로직 검토
- 병원 등록 시 원내약국 존재 여부를 약국 관리와 어떻게 연결할지 정의
병원 검색/리스트 항목 확정
- 기관명, 요양기관번호, 사업자번호, 지역, 진료과목, 주소, 연락처, 원장명 등
CSO 등록/수정 화면 UX 재정리
- 등록과 수정의 차이
- 기존 등록값 노출 방식
- 추가/삭제 방식
수수료율 요구사항 재확인
- 원내/원외 약국별 차등 수수료
- 기본 수수료와 예외 수수료 조합 방식
현업과 추가 회의에서 해석 확인
- 현재 이해한 수수료 로직이 맞는지 검증
논의 내용
1. 심평원 API와 국세청 조회 역할
- 현재 논점은 사업자 상태 확인을 국세청과 심평원 중 어디서 처리할지다.
- 현업 인식상 심평원에서도 사업자등록번호 기반으로 다음 정보를 확인할 수 있을 가능성이 있다.
- 사업자 정상 여부
- 개업/폐업 여부
- 기관 기본 정보
- 만약 심평원 API 하나로 충분하다면:
- 국세청 연동을 별도로 유지할 필요가 줄어듦
- 조회 절차가 단순해짐
핵심 쟁점은 심평원에서 사업자번호 단독 조회가 가능한지 여부다.
- 다만 현재 확인된 바로는 심평원 API가 기관명, 지역, 상태값 등을 조합해 요청해야 할 가능성도 있다.
- 이 경우:
- 동일 명칭 기관이 여러 개일 수 있으므로
- 리스트 조회 후 요양기관번호로 식별하는 방식이 필요하다.
2. 심평원 API 식별 방식과 자동화 이슈
- 심평원 API는 최소 2종류가 있는 것으로 보이며, 기능이 다르다.
- 한 API는 단순 정보조회에 가깝고,
- 다른 API는 개업/폐업/휴업 상태를 조회할 수 있는 구조로 보인다.
- 상태 조회 API는 요청 형식이 다소 특이하며 다음 조건이 언급됐다.
- 기준연월
- 기관 유형
- 개업/폐업/휴업 구분값
- 자동화 시 주요 이슈:
- 개업 목록 조회 후 현재 기관이 있는지 대조
- 없으면 폐업 목록을 다시 조회할지
- 아니면 즉시 폐업 처리할지 정책 결정 필요
식별키
요양기관번호를 유니크 키처럼 활용하는 방향이 유력
- 특히 폐업 케이스에서 기관명보다 요양기관번호 기준 식별이 안정적임
3. 병원·약국·도매상 등록 구조
- 사업자번호를 기준으로 등록할 때, 시스템이 해당 사업자가
- 병원인지
- 약국인지
- 도매상인지
- 제약사인지를 구분할 수 있어야 한다.
- 약국 관리 화면에 도매상 사업자번호를 등록하려는 경우가 발생할 수 있어, 메뉴별 허용 범위를 분명히 해야 한다.
원내약국 처리
- 병원 등록 시 원내약국 여부를 함께 다뤄야 한다는 논의가 있었다.
- 병원에 사업자번호가 있는데, 약국 관리에도 별도 등록이 필요해 보일 경우:
- 중복 등록을 막고
- 병원/약국 관계를 자동 식별하는 로직이 필요하다.
- 방향성은 수동 처리보다 시스템 자동 처리 우선이다.
4. 병원 데이터는 최대한 자동 입력
수기 입력으로 인한 문제를 줄이기 위해 다음 정보는 가능하면 심평원에서 자동으로 가져오기로 했다.
- 요양기관번호
- 기관명
- 사업자번호
- 주소
- 연락처
- 진료과목
- 원장명
- 지역 정보
자동화가 중요한 이유:
- 사람 입력 시 오입력·누락 위험이 큼
- 심평원은 변경 신고 의무가 있어 상대적으로 최신 데이터 유지 가능성이 높음
- 이후 신고/정산 과정에서 데이터 불일치를 줄일 수 있음
단, 예외 상황은 열어둔다.
- 심평원에 없는 정보
- 연동 실패
- API 응답 불안정
이 경우에만 예외적으로 수기 입력 허용
5. 병원 검색/리스트 구성
병원 조회 화면에는 다음 항목이 필요하다는 의견이 나왔다.
- 병원명
- 요양기관번호
- 사업자번호
- 병원 구분
- 지역 구분
- 진료과목
- 주소
- 연락처
- 원장명
검색 방식은 다음처럼 정리되는 방향이다.
- 통합검색: 코드, 요양기관번호, 기관명, 내부 명칭, 사업자번호 등
- 일부 항목은 드롭다운 필터로 분리 가능
또한 연락처는 다른 화면과 통일성 있게 포함하는 방향으로 논의됐다.
6. 병원 폐업 처리 관점
- 병원도 폐업은 존재하며, 특히 동네병원/개인병원은 폐업 사례가 적지 않다.
- 다만 약국·CSO처럼 세무 목적의 잦은 개폐업과는 성격이 다르다.
- 병원은 일반적으로
- 세무 목적 반복 개폐업보다는
- 실제 운영 종료 성격이 강하다는 점이 다르다.
따라서 병원 폐업 상태는 관리하되, 약국/CSO와 같은 방식으로 단순 비교하면 안 된다는 취지다.
7. CSO 등록/수정 UX
CSO 화면에서는 등록과 수정의 목적을 분리해야 한다는 논의가 있었다.
등록
- 아직 연결되지 않은 CSO를 새로 추가
수정
- 이미 등록된 CSO 목록을 먼저 보여주고
- 다음 작업을 수행
- 삭제
- 적용률 변경
- 기타 속성 수정
UX 검토 포인트
- 수정 화면에서 기존 등록값이 기본 노출되어야 함
- 체크박스로 일괄 처리할지, 각 행의 삭제 버튼(X) 로 단순화할지 검토
- 초기 설계의 1단계/2단계 구조는 합칠 수 있음
- 내부 담당자 영역은 수정 화면에서 불필요할 가능성이 있음
8. 적용일/해제일은 단순 표시값이 아님
- 적용일/해제일은 메모용이 아니라 정산 로직에 직접 영향을 주는 값이다.
- 예시:
- 적용일 이전 데이터에는 수수료를 반영하면 안 됨
- 해제일 이후 데이터에도 반영하면 안 됨
- 소급 적용 시에도 날짜 기준 판단 필요
즉, 이 값은 표시용이 아니라 실제 계산 조건이다.
9. CSO 품목 등록 방식
CSO가 다루는 범위를 어떤 단위로 등록할지 논의했다. 최소 3가지 방식이 필요하다.
- 제약사 단위 등록
- 예: 셀트리온 전체 품목
- 개별 품목 등록
- 특정 품목 하나씩 선택
- 품목군 단위 등록
- 예: 당뇨, 안과 등
제약사 단위 등록의 의미
- 특정 제약사를 선택하면 해당 제약사의 신규 품목이 나중에 추가되어도 자동 반영될 수 있어야 한다.
- 따라서 단순히 현재 품목 목록만 붙이는 방식보다, 등록 단위 자체를 유지하는 UI/데이터 구조가 필요하다.
표현 방식 검토
- “제약사 전체”
- “모든 품목”
- “품목군”
- “개별 품목”
이런 위계가 명확히 보이도록 UI를 재구성할 필요가 있다.
10. 수수료율 설계: 원내/원외 + 기본/예외
가장 복잡한 논의 중 하나는 수수료율 조합 구조였다.
요구사항
- 동일 품목이라도 원내약국 / 원외약국에 따라 수수료율이 다를 수 있음
- 또한 각 경우에 대해
- 기본 수수료율
- 예외 수수료율적용 여부가 달라질 수 있음
즉, 개념적으로는 다음 조합이 생긴다.
- 원내 + 기본
- 원내 + 예외
- 원외 + 기본
- 원외 + 예외
현재 이해한 방향
- 보통은 품목에 등록된 기본 수수료율을 따른다.
- 다만 특정 병원/CSO/상황에서는
- 원내만 예외값 적용
- 원외만 예외값 적용 같은 케이스가 생길 수 있다.
예시 개념:
- 기본 수수료율이 20%
- 원외는 기본 20% 유지
- 원내는 예외 23% 적용
또는 반대로 설정될 수도 있다.
아직 확정되지 않은 점
- “기본을 따라간다”는 값과 “예외값을 직접 입력한다”는 구조를 UI에서 어떻게 표현할지
- 값이 비어 있으면 자동으로 기본 수수료를 따르게 할지
- 원내/원외 구분 정보를 어떤 시점에 확정할지
이 부분은 현업 요구사항 재확인이 필요하다.
현재 가장 큰 미확정 사항 중 하나는 원내/원외 수수료율 조합 로직의 최종 UI/정산 반영 방식이다.
11. 병원 화면에 현황 탭 추가 가능성
- 병원 관리 화면도 CSO처럼
- 기본 정보 탭
- 현황 탭구조가 필요할 수 있다는 의견이 나왔다.
- 원래는 레포트 영역에 넣으려던 내용을 병원 상세 내부의 현황 탭으로 넣는 방안이 언급됐다.
- 아직 최종 확정은 아니며, 우선 필드 구조를 마련하는 수준으로 보인다.
12. 계약/교육 문서 영역
- CSO 관련 계약서, 교육이수증, 부속 문서 등의 구조는 일부 재정의가 필요하다.
- 특히 모두싸인 연동 구조가 아직 미정인 부분이 많아, 계약 문서 영역은 우선순위를 낮추고 후속 정리하기로 했다.
- 교육 관련 정보는 연도 기반 별도 관리보다, 외부 시스템 데이터 연동 구조를 다시 보는 방향이 언급됐다.
논의 포인트 정리
- 심평원 API만으로 사업자 상태와 기관 정보를 충분히 조회할 수 있는가
- 사업자번호 단독 조회가 가능한가
- 불가능하다면 기관명+지역 기반 리스트 조회 후 요양기관번호 식별로 가야 하는가
- 병원/약국/도매상/제약사 구분을 시스템이 자동 판별할 수 있는가
- 원내약국 여부를 병원 등록 로직에 어떻게 녹일 것인가
- CSO 등록 화면에서 등록/수정 UX를 얼마나 단순하게 가져갈 것인가
- 수수료율에서 원내/원외 + 기본/예외 구조를 어떻게 데이터화할 것인가
결론
이번 논의의 중심은 심평원 기반 자동화와 복잡한 현업 규칙을 시스템 구조로 바꾸는 방식이었다.
특히 다음 3가지가 핵심 후속 과제다.
- 심평원 API의 실제 조회 가능 범위 확정
- 병원/약국/CSO 등록 UX 단순화
- 원내·원외 수수료율 규칙의 명확한 모델링
이 세 가지가 정리되어야 병원·약국 등록 기능과 CSO/수수료 관리 기능을 안정적으로 설계할 수 있다.