260623 메딕스 품목 디자인
2026년 6월 23일 공유
의약품 마스터 등록·조회 구조 협의
개요
콘텐츠 유형: 회의
- 의약품 품목 마스터 등록/조회 구조, 심평원 연동, 표준코드·대표코드·보험코드 매핑, 제약사 매칭, 검색 조건, 인센티브/수수료 이력 관리 방식 등을 정리한 회의다.
- 핵심 방향은 다음과 같다.
- 표준코드 기반 조회를 기본으로 한다.
- 여러 표준코드는 필요 시 대표코드 기준으로 묶어 관리한다.
- 등록 화면에서는 표준코드 조회 후 자동 채움 방식을 우선 적용한다.
- 디자인보다 기능 개발을 우선하고, 현업 피드백은 구현 후 반영한다.
참여자 및 역할
업무 담당자
- 품목 등록 정책, 필수값, 검색 항목, 인센티브/수수료 운영 기준 논의
개발/기획 담당자
- 심평원 API 연동, ERP 매칭, 화면 플로우, 코드 구조, 구현 우선순위 검토
현업 사용자(예상)
- 실제 등록/수정 흐름 검증 및 예외 케이스 피드백 제공 예정
결정 사항
1. 코드 및 등록 기준
표준코드를 등록과 조회의 핵심 기준으로 사용한다.
- 등록 화면에서 표준코드를 최상단에 배치한다.
- 사용자가 표준코드를 입력하고 조회 버튼을 누르면, 심평원 등 외부 데이터에서 가져올 수 있는 값을 자동으로 채운다.
표준코드만 필수값으로 우선 정리한다.
- 도움코드는 필수값이 아니며, 없을 수 있다.
EDI 코드는 외부 공공코드가 아니라 내부에서 생성한 코드로 정리한다.
2. 다중 표준코드 처리
- 하나의 품목에 표준코드가 여러 개 존재할 수 있음을 전제로 설계한다.
- 다만 정보를 전부 분리 관리하기보다, 같은 품목으로 볼 수 있으면 묶어서 관리하는 방향을 우선 검토한다.
- 묶는 기준으로는 대표코드를 활용하는 방안이 유력하다.
- 보험 여부와 무관하게 품목을 묶을 수 있는 대표코드가 존재하며, 이를 기준으로 품목군을 관리할 수 있다.
3. 보험코드·제품코드 관계
- 논의상 제품코드와 보험코드가 사실상 같은 개념으로 이해되었다.
제품코드 1개에 표준코드 여러 개가 연결될 수 있다.
- 동일 제품이라도 용량, 수량, 포장 단위에 따라 표준코드가 달라질 수 있다.
4. 품목 정보 관리 원칙
규격은 표준코드별로 다를 수 있으므로 세부 관리가 필요하다.
- 품목명도 표준코드마다 다를 수 있지만, 공통 정보가 많으면 지나치게 쪼개지 않도록 한다.
제형은 별도 관리가 필요하다.
- 예: 정제, 캡슐, 주사제 등
- 기존 데이터에는 제형과 단위가 혼재되어 있어 정제가 필요하다.
단위와 제형은 구분해서 관리한다.
- 예:
정,캡슐은 단위/표기 체계와 섞여 들어올 수 있으므로 재정의 필요
5. 제약사 매칭 방식
- 제품코드 조회 시 제조업체명을 받아올 수 있으며, 이를 제약사 정보로 활용할 수 있다.
- 현재 구조는 ERP에 등록된 제약사와 검색·매칭하는 방식이다.
- 제약사명 문자열만으로 자동 매칭하는 것은 위험하다고 판단했다.
- 따라서 제약사 매칭은 다음 중 하나가 필요하다.
- 코드 기반 매칭
- 수동 확인 절차
- 매칭 결과를 검토할 수 있는 별도 확인 장치
- 외부 API 검색 결과와 내부 ERP 제약사 정보를 연결하는 검증 단계가 필요하다.
6. 통합검색 기준
- 통합검색 대상 항목은 다음으로 정리했다.
- EDI 코드
- 품목명
- 보험코드
- 표준코드
- 성분
- 제약사
- ATC 코드
- 시리즈
- 오리지널 여부
상태, 보험약가 등은 통합검색 핵심 항목에서 제외하는 방향으로 논의했다.
- 검색 필터는 AND 조건 적용을 우선 고려한다.
- 통합검색은 기본 품목 정보 중심으로 구성한다.
7. 심평원 조회와 직접 입력
- 심평원 조회가 가능하면 조회 후 자동 입력하는 방식이 기본이다.
- 다만 자동으로 채워진 값도 사용자가 수정 가능해야 한다.
- 심평원 조회가 안 되는 경우에는 수동 등록도 가능해야 한다는 의견이 있었다.
- 한편 데이터 신뢰성 때문에 조회 수행을 사실상 필수 절차로 둘지 추가 검토가 필요하다.
8. 인센티브·수수료·이력 관리
인센티브 적용 여부, 품목군, 예외 여부 등은 내부 설정 성격이 강하다.
- 인센티브 이력은 단순 지급이력보다 다음 정보가 중요하다.
- 인센티브명
- 적용 시작월
- 종료월
- 해제월
- 판매금액
- 수량
수수료율은 변경 이력이 누적되는 로그형 관리가 필요하다.
- 특정 월의 수수료율을 미리 등록해 두고, 이후 정산 시 기본값으로 적용하는 구조를 검토한다.
- 지급이력은 별도 수기 등록보다, 인센티브 운용 과정에서 자동 조회되도록 구현하는 방향이다.
9. 병의원/지역 정보 등록
- 지역 관련 정보는 현재 직접 입력 비중이 높다.
- 병의원 관련 등록에서는 다음 필수값이 논의되었다.
- 정식 명칭
- 주소
- 사업자번호
- 기타 1개 필수 항목 포함 총 4개 기준
- 연락처는 필수 여부를 추가 검토했고,
- **좌표(XY)**는 선택값으로 보는 의견이 우세했다.
- 조회 기능만으로 충분한지, 직접 입력 케이스를 유지할지 재검토가 필요하다.
10. 개발 우선순위
- 화면과 UX를 오래 조정하기보다 우선 개발 후 시연하는 방식으로 진행한다.
- 현업 피드백을 기다리면 일정이 지연될 가능성이 높아, 먼저 구현하고 수정하는 방향으로 합의했다.
- 디자인보다 기능 개발 우선 원칙을 적용한다.
- 남은 주요 마스터 항목도 빠르게 개발해 현업에 보여주기로 했다.
액션 아이템
- 표준코드 조회 기반 등록 화면 설계 및 개발
- 표준코드 상단 배치
- 조회 버튼 클릭 시 자동 입력
- 대표코드 기준 묶음 관리 구조 검토
- 제약사 매칭 검증 방식 구체화
- 코드 기반 가능 여부 확인
- 수동 확인 UI 필요 여부 검토
- 제형/단위 데이터 정제 규칙 정의
- 통합검색 필드 및 필터 조건 확정
- 심평원 조회 실패 시 수동 등록 플로우 정리
- 인센티브/수수료 이력 화면 구조 설계
- 병의원/지역 등록 필수값 최종 확정
- 현업 피드백 전이라도 우선 개발 가능한 5~6개 마스터 기능 먼저 구현
논의 사항
코드 구조 관련
- 내부 시스템 코드가 2개 있으며, 일부 6자리 코드 생성 오류 가능성을 점검해야 한다.
- 보험약가, 보험코드 등은 심평원에서 불러오는 방향으로 정리했다.
- 표준코드가 여러 개인 경우, 이를 행 단위로 분리할지, 하나의 품목으로 묶어 표현할지가 주요 쟁점이었다.
- 결론적으로는 공통 정보가 많다면 과도한 분리보다 통합 관리가 낫다는 의견이 우세했다.
시리즈·오리지널 관리
- 시리즈, 오리지널, 카피약 개념도 품목 검색/분류에 포함할 필요가 있다.
- 동일 성분/브랜드군 내 관계를 보여주는 정보로 활용 가능하다.
- 다만 원본 데이터 출처와 정확한 기준 정의는 추가 확인이 필요하다.
계열 분류 및 기타 속성
- 계열 분류, 원급여 여부, 동일 품목군, 제형, 규격 등은 품목 속성으로 관리할 필요가 있다.
- 일부 속성은 심평원 데이터에서 확인 가능하나, 일부는 내부 설정값으로 관리해야 한다.
- 한약 관련 데이터 포함 여부와 적용 범위도 별도 확인이 필요하다.
수정/삭제 정책
- 일부 항목은 등록보다 수정 중심으로 운영된다.
- 예: 수수료율, 예외 병의원 등
- 삭제 기능은 필요한 곳에 한해 별도로 제공하는 방향으로 논의했다.
- 약가나 상세정보 수정 시에는 상세 데이터 반영 구조가 필요하다.
운영 방식
현업 피드백을 기다리기보다 먼저 개발해 보여주고, 이후 수정하는 방식이 일정 관리에 유리하다.
- 메뉴 내부 구조를 계속 바꾸기보다, 기능 단위로 빠르게 구현해 사용성을 검증하는 방향이다.
- 향후 수정 리스크는 감수하되, 큰 틀의 구조를 먼저 확정하는 것이 우선이다.