안녕하세요. 덴탈비서입니다.

지난 글에서는 Denb EMR의 치료계획, 상담, 진료, 수납이 하나의 흐름으로 연결되는 과정과 치주조직검사, 예방관리 기능에 대해 소개해 드렸습니다.

그 이후에도 개발은 계속 진행되고 있습니다.

지금까지가 환자가 내원한 이후 어떤 과정을 거쳐 진료와 수납까지 이어지는지를 만드는 단계였다면,

최근에는 그 앞단의 예약, 치과 직원의 근무관리, 그리고 진료 이후 자연스럽게 이어져야 할 보험청구까지 개발 범위를 넓히고 있습니다.

하나의 화면을 더 만드는 것보다는 실제 치과의 하루가 어떻게 흘러가는지를 보고, 필요한 기능들을 차례대로 연결해 가는 과정이라고 할 수 있습니다.

이번 글에서는 최근 Denb EMR에 새롭게 추가되거나 구체화되고 있는 내용을 소개해 보겠습니다.

예약 기능 개발이 본격적으로 시작됐습니다

치과에서 환자의 진료는 예약에서 시작됩니다.

환자가 언제 방문할 예정인지, 어떤 진료를 위해 예약했는지, 담당 의료진은 누구인지에 따라 당일 데스크 업무와 진료실의 준비가 달라집니다.

그래서 Denb EMR에서도 예약 기능은 처음부터 중요한 개발 대상이었습니다.

다만 단순히 달력 화면에서 시간을 선택하고 환자를 등록하는 수준의 예약 프로그램을 만드는 것이 목표는 아닙니다.

예약된 환자가 실제 내원했는지, 예약이 변경되거나 취소됐는지, 예약 당시 어떤 치료가 예정돼 있었는지, 실제 진료와는 어떻게 연결됐는지를 하나의 데이터 흐름으로 관리할 수 있어야 합니다.

최근에는 이러한 예약 화면의 사용자 흐름을 구체화하고, 실제 개발에 필요한 예약 DB 구조 설계 작업을 진행했습니다.

예약 데이터를 어떤 단위로 저장할지부터 시작해,

• 예약 등록 및 변경

• 예약 취소

• 환자별 예약 조회 

• 날짜별 예약 조회

• 담당자 및 의료진별 예약

• 예약 상태 관리

• 예약과 실제 접수의 연결

등 앞으로 필요한 기능을 고려해 데이터 구조를 설계하고 있습니다.

화면보다 먼저, 예약 데이터를 제대로 설계하고 있습니다

예약 화면은 겉으로 보기에는 달력과 시간표가 중심인 비교적 단순한 기능처럼 보일 수 있습니다.

하지만 실제로는 여러 가지 상황을 고려해야 합니다.

예를 들어 환자가 예약 시간을 변경했을 때 기존 예약을 삭제할 것인지, 변경 이력을 남길 것인지부터 결정해야 합니다.

예약한 환자가 방문하지 않은 경우와 병원에서 예약을 취소한 경우도 구분할 필요가 있습니다.

예약 후 실제 내원한 환자는 접수 데이터와 연결돼야 하고, 이후 진료와 수납까지 자연스럽게 이어져야 합니다.

이러한 부분을 나중에 화면을 개발하면서 하나씩 추가하면 데이터 구조가 복잡해질 가능성이 높습니다.

그래서 Denb EMR에서는 화면 개발에 앞서 예약 테이블과 공통코드, 조회 기준부터 먼저 정리하는 방식으로 진행하고 있습니다.

DB 적용 과정 역시 바로 운영 데이터베이스를 변경하는 것이 아니라,

구조 설계 → 검토 → DDL 작성 → 사전 검증 → 적용 → 결과 확인 → 문제 발생 시 롤백

과정을 거치도록 개발 기준을 잡고 있습니다.

눈에 보이는 화면 개발만큼이나 보이지 않는 데이터 구조를 중요하게 생각하는 이유입니다.

예약과 접수는 결국 하나로 연결됩니다

Denb EMR에서 예약 기능을 별도의 프로그램처럼 만들지 않는 또 하나의 이유가 있습니다.

예약의 다음 단계가 바로 접수이기 때문입니다.

현재 Denb EMR에는 이미 환자 접수부터 진료, 상담, 수납으로 이어지는 기본적인 흐름이 구현돼 있습니다.

여기에 예약 기능이 연결되면 앞으로는 다음과 같은 흐름을 만들 수 있습니다.

예약 → 환자 내원 → 접수 → 진료 → 상담 → 수납 → 다음 예약

예를 들어 오늘 예약된 환자가 병원에 도착하면 예약정보를 기준으로 바로 접수할 수 있고, 진료가 끝난 뒤에는 필요한 다음 치료를 확인해 후속 예약으로 연결할 수 있습니다.

결국 예약 기능 역시 단순한 일정관리가 아니라 환자의 전체 진료 과정 중 하나가 됩니다.

향후에는 예약 데이터와 치료계획을 함께 활용해 아직 치료가 남아 있지만 다음 예약이 잡혀 있지 않은 환자를 확인하는 기능도 고려할 수 있습니다.

이렇게 각각의 기능을 연결할 수 있다는 것이 자체 EMR을 개발하는 가장 큰 이유 중 하나입니다.

직원 근무관리 기능도 함께 정비하고 있습니다

환자 예약을 제대로 관리하기 위해서는 또 하나 필요한 정보가 있습니다.

바로 직원의 근무 일정입니다.

담당 의사가 쉬는 날에 해당 의사의 진료 예약을 잡거나, 특정 시간에 근무

하지 않는 직원에게 업무를 배정해서는 안 됩니다.

Denb EMR에서는 기존 직원관리 기능을 바탕으로 직원별 휴무일과 근무정보를 관리할 수 있는 기능을 추가하고 있습니다.

관리자가 직원의 근무정보를 관리하는 화면과 직원 개인이 자신의 일정을 확인할 수 있는 구조를 나누고, 실제 치과에서 발생할 수 있는 운영시간과 휴무일의 예외 상황도 함께 검토하고 있습니다.

이 정보는 단순히 직원관리에만 사용되는 것이 아닙니다.

향후 예약 기능과 연결하면 해당 날짜에 실제 근무하는 의료진을 기준으로 예약 가능한 시간을 구성하는 것도 가능해집니다.

하나의 기능을 만들 때 다른 기능과 어떤 데이터를 공유할 수 있을지를 함께 고민하고 있습니다.

이제 보험청구를 준비하고 있습니다

지난 글에서 말씀드렸던 보험청구 기능도 조금씩 구체화되고 있습니다.

치과 EMR에서 보험청구는 단순히 마지막에 청구서를 출력하는 기능이 아닙니다.

환자가 어떤 진료를 받았는지, 어떤 상병이 적용됐는지, 어떤 치료재료가 사용됐는지, 보험수가가 얼마인지, 본인부담금이 얼마인지 등 진료 과정에서 발생한 여러 정보를 정확하게 연결해야 합니다.

따라서 보험청구 화면부터 만드는 것보다 먼저 전체적인 청구 구조를 이해하는 작업이 필요합니다.

현재는 실제 보험청구 화면 개발에 들어가기 위한 사전 단계로,

• 진료행위와 보험수가

• 상병과 진료행위의 관계

• 치료재료

• 본인부담금

• 공단 관련 정보

• 보험청구 데이터 생성 과정

• 청구 전 확인해야 하는 항목

등을 조사하고 있습니다.

특히 보험청구는 건강보험 기준이나 치과 특유의 청구 조건처럼 예외사항이 많은 영역이기 때문에, 화면을 빠르게 만드는 것보다

정확한 업무 흐름과 데이터 관계를 먼저 정리하는 데 중점을 두고 있습니다.

별도의 '청구 프로그램'이 아니라 진료기록에서 시작하는 보험청구

Denb EMR에서 만들고자 하는 보험청구의 방향도 기존의 데이터 연결 방식과 같습니다.

이미 진료 화면에서 입력한 내용을 보험청구를 위해 다시 입력하는 구조보다는 진료 과정에서 작성된 정보를 활용해 청구 데이터가 자연스럽게 만들어지는 구조를 목표로 하고 있습니다.

예를 들어 의사가 실제로 시행한 진료행위와 상병정보가 기록돼 있다면 이를 바탕으로 보험청구에 필요한 항목을 구성하고, 청구 전에 필요한 정보가 빠져 있는지를 확인할 수 있습니다.

장기적으로는

으로 발전시키는 것이 목표입니다.

이를 위해 현재의 진료 데이터 구조도 보험청구와 연결할 수 있도록 계속 검토하고 있습니다.

치과위생사 예방차트도 조금 더 구체화되고 있습니다

지난 글에서 소개했던 치과위생사 예방차트 역시 단순한 아이디어 단계에서 실제 프로그램 구조를 고민하는 단계로 넘어가고 있습니다.

교수진과의 간담회를 통해 확인한 요구사항을 바탕으로 1단계 MVP에서 어떤 기능이 필요한지를 정리하고 있습니다.

핵심은 치위생 업무 과정을

사정 → 진단 → 중재 → 평가

라는 하나의 흐름으로 기록하는 것입니다.

여기에 학생과 교수, 평가자의 역할을 구분하고 교수 평가와 채점, 결과지 출력 등의 기능을 포함하는 방향으로 데이터 구조를 검토하고 있습니다.

또한 Denb EMR에 이미 개발된 치주조직검사와 진료차트 데이터를 예방차트에서 활용할 수 있도록 연결하는 방법도 함께 고민하고 있습니다.

교육기관에서는 실습과 평가에 사용할 수 있고, 향후 실제 치과에서는 치과위생사의 예방관리 업무에 활용할 수 있는 구조를 목표로 하고 있습니다.

하나씩 만들지만, 결국 하나의 데이터가 됩니다

최근 Denb EMR 개발 내용을 보면 서로 다른 기능을 동시에 만드는 것처럼 보일 수도 있습니다.

예약을 만들고, 근무관리를 만들고, 보험청구를 준비하고, 예방차트를 기획하고 있습니다.

하지만 각각의 기능은 서로 떨어져 있지 않습니다.

직원의 근무정보는 예약과 연결됩니다.

예약은 환자의 접수와 연결됩니다.

접수는 진료와 연결되고, 진료는 치료계획과 상담으로 이어집니다.

진료가 끝나면 수납과 보험청구가 이어집니다.

그리고 치료가 완료된 이후에도 치주검사와 예방관리를 통해 환자와의 관계는 계속됩니다.

결국 Denb EMR이 만들고 있는 것은 개별적인 기능의 집합이 아니라,

환자가 치과와 관계를 맺는 전체 과정을 하나의 데이터로 연결하는 구조입니다.

조금씩 'EMR다운 EMR'이 되어가고 있습니다

처음 Denb EMR 개발을 시작했을 때는 직원관리, 환자관리, 접수, 진료, 수납처럼 전자차트에 반드시 필요한 기본 기능을 만드는 것이 우선이었습니다.

이후 치료계획과 상담을 연결하고, 치주조직검사를 추가하면서 실제 진료 흐름을 조금씩 완성해 왔습니다.

그리고 지금은 예약과 직원 근무관리, 보험청구, 예방관리처럼 치과 운영 전반을 연결하는 단계로 개발 범위가 확대되고 있습니다.

아직 해야 할 일은 많이 남아 있습니다.

하지만 기능 하나를 추가할 때마다 단순히 화면 하나가 늘어나는 것이 아니라, 이전에 만들어 놓은 데이터와 새로운 데이터가 연결되고 있습니다.

예약에서 시작해 접수, 진료, 상담, 수납, 보험청구, 그리고 예방관리까지.

치과에서 하루 동안 이루어지는 업무를 하나의 프로그램 안에서 자연스럽게 연결하는 것.

그것이 현재 Denb EMR이 만들어지고 있는 방향입니다.

다음 개발 이야기에서도 실제로 구현된 새로운 기능과 변화된 모습을 계속 소개해 드리겠습니다.