260616 메딕스 내부 cso관리 디자인2
2026년 6월 16일 공유
시비 관리 기능은 CS고(CS Go) 화면에서 확인할 수 있으며, 별도의 메뉴뿐만 아니라 해당 화면 내에서도 동일한 기능을 사용할 수 있습니다. 계정 생성 시 중복 확인 기능이 필요하며, 한 번 입력하면 되돌릴 수 없는 특성을 고려하여 구현할 예정입니다. 특히 이메일 등 수정이 불가능한 필드에 대해서는 등록 시 안내 메시지를 통해 해당 사실을 명시하고, 등록 버튼 클릭 시 정보 확인을 위한 가드(확인 절차)를 추가하여 실수로 인한 등록을 방지할 계획입니다. 또한, 계정 생성 시 이름, 연락처, 이메일 외에 역할(Role) 정보를 입력할 수 있어야 하며, 이메일 항목 등 필수 입력 필드에는 필수 표시를 추가할 계획입니다. 한편, 시스템 내 데이터 등록 시 형식은 맞으나 실제 데이터가 정상적으로 처리되지 않는 문제(예: 특정 도메인 입력 시 등)가 확인되어, 데이터 등록 및 처리 과정에 대한 개선이 필요합니다. 계정 관리와 관련하여 단일 계정 사용뿐만 아니라 여러 계정이 동시에 로그인할 수 있도록 하는 방안이 논의되었습니다. 데이터 양이 방대한 화면의 경우, 라이크(Like) 검색 방식을 적용하여 효율적인 데이터 조회를 지원할 예정입니다. 향후 디자인 작업은 피그마(Figma)를 활용하여 진행하기로 하였으며, 관련 내용과 코멘트 등을 지속적으로 공유하며 관리할 예정입니다.
팝3(POP3) 계약서 관리와 관련하여, AI가 생성한 계약서 데이터를 활용할 예정입니다. 팝3는 계약서 관련 기능을 담당하게 됩니다. 또한, 특정 페이지의 경우 현재 페이지네이션이 존재하지 않는데, 향후 무한 스크롤(Infinite Scroll) 방식으로 구현할지에 대한 검토가 필요합니다. 데이터가 계속 늘어날 가능성이 있어 페이지네이션보다는 무한 스크롤 방식이 적합할 것으로 보이며, UX 통일성을 고려하여 구현 방식을 결정할 예정입니다. 다만, 모든 화면의 UX를 반드시 통일할 필요가 있는지에 대해서는 추가 논의가 필요합니다. 한편, 금액 업체와 약국에서의 조회 기능 필요성에 대해 확인이 필요하며, 직원별 배정 및 대표자 배정 기능에 대한 논의가 진행되었습니다.
CS고 화면 내 제작사 목록은 계약이 체결된 제작사들로 구성됩니다. 최근 대웅제약과 CSO 계약을 체결하였으며, 한국메딕스를 포함한 계약 구조를 가지고 있습니다. 또한, CSO가 다시 위탁을 주는 재위탁 구조도 포함됩니다. 현재 수탁사 등록 기능이 부재하여, 향후 상세 수정 화면 등을 통해 수탁사를 등록할 수 있는 기능을 추가할 예정입니다. 수탁사 등록 시 생성 버튼을 통해 리스트에 추가하는 방식으로 운영되며, CSO 등록 시 직거래처, 재위탁, 수탁 여부를 구분하며, 수탁사는 반드시 CSO에 먼저 등록되어 있어야 합니다. 위탁사와 수탁사 간의 관계는 명확히 구분하여 관리할 예정입니다. 화면 구성과 관련하여 위탁사, 수탁사, 원조 수탁사 항목이 포함되며, 현장사(제약사) 화면 내에서 관련 정보를 확인할 수 있습니다. 또한, 순방 신고 화면에서 신고 번호, 업체, 수탁사, 위탁사를 선택할 수 있도록 구현할 예정이며, 위탁사와 수탁사 리스트를 각각 보여주는 방식으로 구성할 계획입니다. 마스터 요한(관리사 요한) 정보가 위탁사 리스트 등에 포함되어야 한다는 논의가 있었습니다. CSO는 관리자 계정으로 접속하여 직접 정보를 입력하며, 수탁사 계정으로 접속할 경우의 권한 및 정보 입력 방식에 대해서는 추가 검토가 필요합니다. 수탁사 등록 시에는 신고 업체명, 사업자 번호, 대표자, 소재지, 통보자, 계약 체결일 등의 정보가 필요합니다. 또한, 관리자 전용 메뉴 및 회원사 등급에 따른 동의 절차 구현에 대한 논의가 진행되었습니다. 이와 관련하여 회원사 동의 절차를 간소화하는 방안이 논의되었습니다. 한편, CP(컴플라이언스 프로그램) 관리 메뉴는 재위탁 현황을 포함하는 구조로 운영될 예정이며, JTAG 현황 등에서 위탁사 및 수탁사 리스트를 업체명 하나로 통합하여 관리하는 방안이 논의되었으나, 정보 필드가 누락되지 않도록 업체명 하나로만 관리하지 않고 상세 정보를 모두 포함하는 구조로 구현하기로 결정되었습니다. 요양기관 정보는 국세청이나 신평원 등에서 데이터를 가져와 시스템에 자동으로 등록되도록 구현할 예정이며, 약품 등록 시에도 표준 코드를 활용하여 시스템에 등록되도록 할 계획입니다. 또한, 요양기관 정보 관리 시 표준 코드, 병의원명, 요양기관 번호, 의료인 정보 등을 포함하고, 지원 금액 등의 필드도 별도로 관리할 예정입니다. 의료인 정보는 대학병원 등 다양한 사례를 고려하여 직접 입력(input)하는 방식으로 구현할 계획이며, 시스템 내 필드 구성은 기존 기준을 따르되, 유형 구분 등 일부 불필요한 필드는 제외하고 관리할 예정입니다. 또한, 시스템 내 필드 구성은 기존 기준과 동일하게 통일하여 관리하기로 하였습니다. 한편, 데이터 수정 요청 시 체크박스 선택 대신 드롭다운 방식을 활용하는 방안이 논의되었으며, 수정 요청 사유란을 포함하여 관리할 예정입니다. 또한, 데이터 수정 방식과 관련하여 관리자가 직접 수정하는 방식과 반려 후 협력사가 다시 올리도록 하는 방식에 대한 논의가 진행되었습니다. 특히 반려 기능은 시스템을 잘 활용하는 업체를 대상으로 적용할 예정입니다. 견본품 제공 이력 관리에도 반려 기능을 포함해야 한다는 의견이 제시되었습니다. 견본품 및 영업활동 기업의 경우 인수증 미비나 이미 동의된 약품의 중복 제공 등 부적절한 사례 발생 시 반려 처리하는 기능이 필요하며, 영업활동 비용이 목적에 맞지 않거나 영수증이 잘못된 경우 등에 대해 수정 요청을 하거나 반려 처리할 수 있는 기능이 구현되어야 합니다. 현재는 이러한 반려 및 수정 요청을 메일이나 보고서로 처리하고 있어 시스템 내 기능이 부재한 상태이며, 향후 시스템 내에서 반려/수정 요청 시 상대방에게 메시지를 전달할 수 있는 기능 등에 대한 검토가 필요합니다. 특히 반려나 수정 요청 시 협력사 포털 내 알림을 제공하거나, 알림톡을 통해 수정 필요 사항을 전달하는 방안이 논의되었습니다. 또한, 제약 영업의 엄격한 관리 필요성에 따라, 동일 병원에 대해 견본품을 중복으로 제공하는 것을 방지하기 위해 '딱 하나만' 제공하도록 제한하는 로직 구현이 논의되었습니다. 추가로, 협력사 포털 내 설문 기능 및 관련 화면 구성에 대한 논의가 진행되었습니다. 설문 기능은 접속 시 바로 뜨도록 구현하여 설문을 완료하지 않으면 다음 단계로 진행되지 않도록 하는 방식이 논의되었습니다. 또한, CP 1차 및 2차 감찰과 관련하여 명담(명단)은 상세 화면을 통해 관리할 예정이며, 등록 버튼 클릭 시 화면 연결 방식이나 모달(modal) 창을 띄우는 방식에 대한 검토가 필요합니다. 분계약서 작성 시 계약 기간 및 유효기간 설정 확인이 필수적이므로, 관련 항목들을 개별적으로 등록할 수 있도록 구현할 예정입니다. 또한, 상세 정보 확인을 위해 별도의 상세 페이지를 추가하는 방안이 논의되었습니다. 면담 이력 등록 및 상세 조회 화면의 경우 정보량이 매우 많아, 프론트엔드 구성 시 대규모 모델(UI/UX) 적용에 대한 검토가 필요하며, 사용성 저하 우려에 따라 효율적인 화면 설계가 요구됩니다. 데이터 일괄 수정 의견에 대해서는 그 배경을 확인하기 위한 코멘트 기능을 추가하는 방안이 논의되었습니다. 한편, 비활성 항목의 클릭 가능 여부와 관련하여, Sunset 화면 진입은 가능하나 프렌저싱 데이터 생성 시 해당 데이터를 불러올 수 없는 문제가 확인되어 이에 대한 검토가 필요합니다. 또한, CL 및 EDI 입력/명령 등록 시 비활성 항목에 대한 클릭 제한 등 화면별로 상이한 접근 권한 및 클릭 가능 여부로 인해 혼선이 발생하고 있어, 입증업 관리 등에서 비활성 항목 처리 기준을 명확히 할 필요가 있습니다. 또한, '이정코드 수정'이라는 명칭이 실제 기능(연결 해제 등)과 부합하지 않는다는 의견이 있어, 명칭 변경이나 현황 관리 등 적절한 용어에 대한 재검토가 필요합니다. 특히 '수정'이라는 용어가 실제 기능과 맞지 않는 경우가 있어, '현황'이나 '연결관리' 등 적절한 명칭으로 변경하는 방안에 대한 재검토가 필요합니다. 현재 연결 관리 구조에서는 데이터를 삭제하고 다시 연결해야 하는 불편함이 있어, 연필 아이콘 등을 활용해 기존 연결을 수정하거나 변경할 수 있는 기능 개선이 논의되었습니다. 시스템 전반의 비활성 항목 처리 및 버튼 접근 권한(디세이블 처리 등)을 통일하여 관리할 필요성이 제기되었으며, 담당자 구성은 주담당, 부담당, CP담당 3인 체제로 운영될 예정입니다. 한편, 연결업체 모달 내 비고(비공) 항목의 필요성에 대해 논의되었으나, 별도의 비고 항목은 불필요한 것으로 의견이 모였습니다. 또한, 마스터(임시사장 등) 관련 정보의 관리 방식에 대해 추가 확인이 필요합니다. 제작사 관련 기능은 조속히 마무리하기로 하였습니다.
제약사별 화면 구성과 관련하여 상단에는 제약사별 쿠폰, 하단에는 혼합된 형태의 리스트를 배치할 예정이며, 제약사 우선순위(한진, 소울메디팜, 유한양행, 서울메디팜 등)를 고려하여 구현할 계획입니다. 특히 제약사별로 데이터를 분리하여 관리하는 구조가 필요하며, 제약사별로 화면을 쪼개어 구성하는 방안이 논의되었습니다. 주거래 병원 명칭 등 테이블상에서는 요약된 형태로 컬럼을 구성하고, 상세 화면으로 진입하여 상세 정보를 확인하는 방식으로 구현할 예정입니다. 위탁자 및 수탁자 리스트의 엑셀 다운로드 기능은 삭제될 예정이나, 데이터 규모를 고려할 때 엑셀 저장 기능의 필요성이 재검토되었습니다. 해당 리스트 내 수정 및 삭제 기능이 포함되어야 합니다. 또한, 미리 보기 버튼과 함께 상세 수정 및 비고 수정이 가능한 상세 화면을 구성할 예정입니다. 교육 이수증의 경우 기본정보에서 업로드한 파일을 가져오며, 해당 화면에서도 수정이 가능하도록 구현할 예정입니다. 이때 교육 이수증 수정 시 기존 이력을 포함한 전체 수정 이력이 모두 기록되어 관리되어야 합니다. 또한, 수정 이력 관리와 관련하여 수정 시마다 새로운 이력이 생성되는 구조를 유지하며, 비고란을 추가하여 조회할 수 있도록 구현할 예정입니다. 추가로 CP 관리 메뉴 화면에서도 교육 이수증의 등록 및 수정 기능이 동일하게 제공되어야 합니다. 한편, CP 관리 메뉴 내에서 교육 이수 대상 여부를 안내하는 기능은 현재 부재한 상태로, 교육 이수 필요성을 알리는 기능에 대한 논의가 필요합니다. 또한, 교육 이수 대상 여부 안내 및 관련 상태 관리를 위해 '미정거' 항목을 활용할 예정입니다. 교육 이수증의 유효기간은 교육 이수일을 기준으로 1년으로 설정하여 관리할 예정이나, 연도 내 이수 여부 등 유효기간 산정 기준에 대한 추가 논의가 필요하며, 교육 이수 인정 범위 및 형태에 대한 구체화가 요구됩니다. 특히 교육 이수 시점과 관련하여, 특정 주기를 강제하기보다 해당 연도 내에만 이수하면 인정되는 방안과 계약 체결일을 기준으로 1년으로 설정하는 방안 등이 논의되었습니다. 구체적인 운영 방식은 CP 담당자와 협의할 예정입니다. 교육 이수증 수정 이력 관리와 관련하여, 마지막 이력을 삭제할 경우의 처리 방식에 대해서도 논의가 필요하며, 현재는 삭제 기능이 부재하여 향후 삭제 기능 추가 여부에 대한 검토가 필요합니다. 한편, 교육 이수증 파일 삭제 기능과 관련하여 기존에 X 버튼을 통해 삭제가 가능했던 것으로 확인되었으며, 파일 삭제 시에도 수정 이력이 기록되어 교육 이수증이 없는 상태가 관리될 예정입니다. 이때, 삭제된 이력이 히스토리에 남아 오해를 불러일으킬 수 있는 문제에 대해서는 비고란을 통해 사람이 식별할 수 있도록 할 예정이나, 시스템적으로 이를 판단할 수 있는 방안에 대한 추가 검토가 필요합니다. 특히 비고란은 시스템이 직접 읽어 판단하기 어렵다는 점을 고려하여, 교육 이수증 유효기간과 계약 체결일 간의 관계 등 시스템적 판단 기준에 대한 추가 논의가 필요합니다. 교육 이수증 관리와 관련하여 계약 체결일과 교육 이수일은 구분하여 관리해야 하며, 연도를 선택하고 해당 연도에 맞는 교육 이수증을 별도로 업로드하는 방식이 논의되었습니다. 또한, 교육 이수증 등록 시 계약 서류 등록과 유사하게 모달(modal) 창을 띄워 확인하는 방식이 검토되었습니다. 교육 이수증 파일을 삭제할 경우 해당 연도의 데이터가 비어 있게 되어, 이를 통해 교육 이수를 받지 않은 상태임을 식별할 수 있는 방안이 논의되었습니다. 추가로, 교육 이수증 관리 화면에서 최근 3년간의 이력을 보여주는 기능이 포함될 예정이며, 한 화면에 20줄씩 표시하는 구성이 논의되었습니다. 교육 이수증 등록 시 사진 촬영을 통한 업로드 방식도 검토 중입니다. 또한, 잘못된 파일 업로드 시 삭제 대신 업데이트(수정)하는 방식을 기본으로 운영하고, 잘못 업로드된 경우 비고란에 사유를 기재하여 관리함으로써 수정 이력을 명확히 남기기로 하였습니다. 교육 이수증 관리와 관련하여, 비고란을 통해 수정 사유 등을 기재할 수 있으나, 시스템적으로 검색이 어렵다는 한계가 있어 이에 대한 보완 방안이 논의되었습니다. 교육 이수증 업로드 시 상단에 명칭을 명확히 표기하는 등의 방안이 검토되고 있습니다. 한편, 제이팟(J-Pot) 폴랑 화면 구성과 관련하여 최대 3명의 서포트 인원을 지원하는 구조가 논의되었습니다. 또한, 경제적 이익 지출 보고서(경제적 이익 보고)와 관련하여 경봉분 제공 내역 및 개별 요약 등록 기능이 필요하며, 이는 CSO가 직접 등록하는 방식으로 운영될 예정입니다. CSO는 제약사에서 나오는 신약 샘플을 병원에 제공하는 역할을 수행하며, 이때 의사로부터 샘플 수령 확인을 위한 인수증을 받아 제출해야 합니다. 이와 관련하여 인수증 수령 여부를 관리하는 기능이 필요하며, AI가 생성한 인수증 데이터를 활용할 예정입니다. 다만, 견본품 제공 이력은 확인 가능하나 인수증 확인 기능은 현재 부재하며, 협력사 포털을 사용하지 않는 CSO들은 메일이나 카톡으로 인수증을 전달받아 제출하고 있습니다. 이에 따라 인수증 관리 화면에서도 행마다 수정 버튼을 배치하여 관리하는 방안이 논의되었습니다. 또한, 견본품 제공 이력 등 시스템 내 병원 관련 항목들은 시스템에 등록된 병원만 선택 가능하도록 구현할 예정이며, 이를 위해 병원 등록 절차 및 검색 기능을 지원할 계획입니다. 인수증 관리와 관련하여 병원으로부터의 '요청일'은 불필요한 것으로 논의되었으며, '요청일'은 병원이 요청한 날짜, '배송일'은 물품을 보낸 날짜, '인수증 발급일'은 의사가 물품을 수령한 후 발급한 날짜로 정의하여 관리할 예정입니다. 또한, 인수증 관리 화면의 항목 구성은 기관 명칭(병원명)을 포함하여 기존 방식을 유지하기로 하였습니다. 추가로, 제이팟(J-Pot) 화면 구성 시 서포트 인원을 2명씩 배치하는 방안이 논의되었습니다. 견본품 제공 내역 등록 시 제품명 검색 기능을 지원하며, 제공 수량은 '박스 수'와 '박스당 포함된 수량'을 구분하여 입력하도록 구현할 예정입니다. 또한, 제공 수량과 관련하여 '박스 수'는 몇 박스를 제공했는지, '박스당 포함된 수량'은 한 박스 안에 몇 개의 제품이 들어있는지를 의미하도록 명확히 구분하여 관리할 계획입니다. 인수증은 이미지 및 PDF 파일 형태로 업로드 및 관리할 예정입니다. 견본품 제공 이력 항목에는 병의원, 요양기관번호, 품목명, 표준코드, 포장된 수량, 제공수량, 계획, 제공일자, 비고, 인수증 항목이 포함되어야 합니다. 한편, 견본품 및 영업활동 기업의 경우 인수증 미비나 이미 동의된 약품의 중복 제공 등 부적절한 사례 발생 시 반려 처리하는 기능이 필요하며, 영업활동 비용이 목적에 맞지 않거나 영수증이 잘못된 경우 등에 대해 수정 요청을 하거나 반려 처리할 수 있는 기능이 구현되어야 합니다. 현재는 이러한 반려 및 수정 요청을 메일이나 보고서로 처리하고 있어 시스템 내 기능이 부재한 상태이며, 향후 시스템 내에서 반려/수정 요청 시 상대방에게 메시지를 전달할 수 있는 기능 등에 대한 검토가 필요합니다. 특히 반려나 수정 요청 시 협력사 포털 내 알림을 제공하거나, 알림톡을 통해 수정 필요 사항을 전달하는 방안이 논의되었습니다. 견본품 제공 이력 관리에도 반려 기능을 포함해야 한다는 의견이 제시되었습니다. 한편, 현재 시스템 내 코너가 너무 많아 정리가 되지 않고 길을 잃은 코너들이 있다는 지적이 있어, 전체적인 코너 구성에 대한 정리가 필요합니다.