오랫만에 셔터맨 알약계수기 개발

하드웨어에서 잡아 먹은 시간만큼이나, 소프트웨어에서도 시간을 잡아 먹는다. 그러는 동안 특허 심사도 진행중이다.

1.하드웨어

우선 하드웨어 부분을 종합해서 복기해보면, 제품이 생각보다 심플하다. 이에 더나가 하드웨어 개발자들은 행여 양산을 염두해두어 부품들을 모두 독자적 모듈라 규격으로 Push & Lock 으로 새롭게 디자인하고 있다. 즉 제품에 문제가 생겨 물리적 a/s가 발생할시에, 5분안에 해결을 할 수 있게끔 하드웨어 점검 시스템을 구축한다는 것이다. 현재의 수십개가 박혀 있는 나사들을 대부분 걸쇠 형식으로 변경하고 밀어서 잠궈버리는 형태로 새롭게 작업할 태세이다. 이는 약국이 복잡하고 바쁘기에, 이 제품 수리하는데 많은 시간이 소비되서는 안된다는 약사의 주장에 의해 새롭게 진행되는 것이다. 반사판의 백라이트의 경우 끝에 한면에서만 빛을 발사할 경우 육안으로는 판단 안되지만, 카메라에 맺힌 상을 보면 LED 모듈이 장착된 반대 쪽으로 갈수로 음영이 생기는것을 알게 되었다. 현재는 반사판 양쪽으로 쌍으로 LED 모듈을 장착하여 균일한 밝기를 내고 있지만, 이 부분에 대해서도 추후 한쪽에서만 빛을 내더라도 균일하게 퍼질수 있는 장비를 개발하겠노라 하였다. 부품 가격은 얼마 안하지만, 부품이 늘어나는것은 그만큼 고장 확률이 높아진다는 얘기이다. 또한 각 부품끼리 결합할 경우 모듈러화 되어 부품들을 전선 콘센트 꼽듯 그자리에 위치하면 자동으로 연결되게끔 작업하는것이 목표이다. 트레이에 올려진 약을 균일하게 펼쳐 줄 모터 충격장치도 여러 시행 착오와 테스트를 거쳐 최적의 충격 값을 도출했다.

2.소프트웨어

제품명을 팜.허브로 정했다. 현재는 이 제품이 수행할 가장 중요한 파트라고 할 수 있는 알약 계수에 관한 종합적인 솔루션을 제공하는데 의를 두고 있다. 하지만 이 제품이 일정 수준 보급이 된다면, 약국 전산 청구 프로그램과 연동하여, 종합 DB 구축과 물류시스템으로 확대시키려 한다. 또 일정 수준의 API를 제공하여 제 3 개발자들이 이 제품을 허브로 하여 약업계 관련 어플들을 출시할 수 있게끔 플랫폼화 시키는것이 최종 목표이다. Pharm.farm이라는 스토어를 오픈계획(?)을 갖고 있다. 하지만 현재는 기본적인 기능에 집중해야 하는 상황이다.

1)실시간 분석에 대한 서로 다른 입장들….

단순한 원리이다. 알을 올려 놓으면 이게 총 몇개인지를 실시간으로 분석하여 제공해주는 제품이다. 하지만 이 말에는 많은 정보가 빠져 있다. 이 약을 왜 세야 하는지에 대한 근본적인 이해가 필요하며, 이에 맞는 솔루션으로 접근해야 한다. 약사는 트레이에 올려 놓은 알약의 총량을 필요로 하는것인지, 혹은 타겟으로 하는 수량이 따로 있는지에 대한 고민이 우선 해결되어야 했다. 당연히 일반적인 약국에서는 후자인 타겟 카운팅이 더 빈번하게 쓰일거라 판단했다. 이 근본적인 작업의 형태로 인해, 알약 카운팅 기술을 정지된 이미지를 저장하여 분석하고 결과를 내어주는 방식으로 갈지, 아니면 지속적으로 영상을 촬영하며 실시간 분석하여 결과치를 제공해줘야 할지 판단해야 했으며, 우리는 힘들더라도 영상 분석으로 결정하였다. 트레이에 올려진 영상을 따로 저장하고 분석하는것이 아닌 실시간으로 추가되는 만큼 혹은 빼는 만큼 결과값을 모니터를 통해 제공하게끔 했다. 이로 인해 개발이 더 늘어지고 있다. 러프하게나마 개발된 엔진(모듈) 영상을 돌려보니, 이만하면 시장에 내놓아도 되겠다 생각들지만, 개발자의 생각은 좀 다르다. 카운팅 특성상 일부 약들이 stack화라고 하여, 위에 두약이 포개져 있을때도 있다. 이럴때는 트레이를 흔들어주거나, 혹은 진동 버튼을 누르라는 지시어를 프로그램에서 띄어주면 되는데, 이 작업까지 가지 않고 정밀도를 높이고 싶다고 하기에, 구경중이다. 개발 목표로 삼았던 미국 제품보다 정밀도가 훨씬더 뛰어난것 같은데(수치적으로), 개발자는 만족하지 않는 모양이다. 그리고 지속적인 데이터 수집을 통해서 수학적인 미분적분 얘기를 하는데… 뉴튼형은 여기서 왜 나오는지… 여튼 계산식을 지속적으로 업데이트하겠다고 한다. 아.. 전혀 못알아 듣는 말이다. 반면 정지된 영상을 분석해서 결과를 도출하는 방식의 카운팅 방식은 타겟 카운팅에는 조금 불편한 구조이다. 가령 150개를 세야 하는데, 트레이에 183개가 올려졌다고 친다면, 33개는 어짜피 수동으로 눈으로 세야 하는 구조이다. 150개 카운팅하는데 33개만 세도 된다고 하면 그것만으로도 의미 있는 진전이다. 하지만 우리는 아예 카운팅에 고민 자체를 안하게끔 하는 것을 목표로 삼았기에 실시간 분석 결과를 도출하는 영상 분석으로 결정한 것이다.

2) 여러 메뉴중 중심이 되는 Rx Count 화면

작업자의 로그와 제품명 그리고 유통기한등의 정보를 약병에 담긴 Data matrix 바코드를 리딩해서 정보를 얻고 이 결과값을 저장한다. 이때 프린터 버튼을 누르면 이 약에 대한 정보와 환자명, 약명과 EDI 코드, 그리고 용업에 대한 정보가 라벨지로 출력되어, 소분되어 나가는 통에 붙일수 있도록 제공된다. 특히 한국에서만 유독 많이 쓰이는 1/2정의 경우 제공되는 총 용량의 절반에 지나지 않지만, 카운팅상 두배의 갯수로 표시될 수 밖에 없다. 이리하여 총 용량과 총갯수를 분리하고 기록하여, 환자에게 제공된 정확한 알약수를 가늠하게끔 한다. 당연히 타겟 갯수가 지정된다면 화면상에 알약을 더 투입해야할지, 덜어내야 할지를 표시되게끔 한다. 많은 요구 조건을 최대한 심심하게 화면 구성하는것을 요구하였고, 기획자는 성공적으로 완수해냈다.

셔터맨은 태업중

이제 내가 할 일은 없다. 개발자와 디자이너가 서로 교류하면서 업무를 진행하고 있다. 충분히 현안과 해결방안과 최선책을 공유하고 있는터라 내가 나서서 이렇다 저렇다 말하는것은 꼰대다. 이따금씩 진행과정을 전달해주는데, 그 내용만으로도 진행 정도를 판단할 수 있기에, 부산을 떨며 챙겨볼 필요가 없어졌다.