실습 연결
전산 화면에 보냄이라고 뜹니다. 이제 환자가 다음 진료를 받으리라 생각하기 쉽습니다. 그러나 ‘의뢰를 전송했다’는 사실과 ‘상대 서비스가 받았고, 환자에게 일정이 잡혔다’는 사실은 다릅니다. 영국 HSSIB는 전자 의뢰가 잘못된 상태 선택이나 시스템 설계 문제로 취소·누락될 수 있는 위험을 조사했습니다.
발송 이후의 접수·추적·문의 경로
가상의 병동에서 퇴원 환자에게 전문 진료 의뢰를 넣었다고 해 봅니다. 화면에 전송 시각만 있다면 세 가지를 더 물어야 합니다. 상대 팀이 실제로 접수했나요? 미접수라면 누가 언제 확인하나요? 환자가 연락을 받지 못했을 때 어디로 문의하나요? 이 질문은 개별 직원의 기억력을 시험하는 것이 아닙니다. 의뢰가 실제로 접수되고 후속 안내까지 이어졌는지 확인하는 과정입니다.
누락을 찾는 상태 표시·접수 확인·책임·환자 안내
HSSIB 보고서는 알림과 응답 추적의 부족이 의뢰 손실을 알아차리기 어렵게 할 수 있다고 설명합니다. 영국 NHS의 환자안전사건 대응 틀은 사고를 개인 탓으로 단정하기보다 과정과 시스템에서 배우도록 권고합니다. 누락이 발견되면 누가 버튼을 눌렀는지만 추궁하지 않고 상태 표시, 접수 확인, 재연락 책임과 환자 안내가 어디서 끊겼는지 함께 살핍니다.
- 화면에는 ‘보냄’
- 의뢰 요청이 전산에서 나갔음을 나타낼 뿐, 접수 완료를 뜻하지는 않습니다.
- 실제 연결 확인
- 접수 여부와 일정, 환자에게 전달된 후속 안내를 별도로 확인합니다.
전산 입력과 실제 진료 연결의 차이
전산에 입력된 기록과 의뢰가 상대 팀에 도달한 사실은 구별해야 합니다. 의뢰 기록만 있고 수신 확인이나 후속 담당자가 비어 있다면 완결된 인계라고 판단하기 어렵습니다. 실제 전산 상태명과 확인 주기는 의료기관마다 다르므로 소속 기관의 절차를 우선합니다. 결과를 기다리는 환자에게도 확인 경로가 명확해야 한다는 점을 함께 기억해 봅니다.
환자에게도 ‘언제까지 연락이 없으면 어디에 물을지’를 안내하면 시스템의 마지막 확인점이 됩니다. 그렇다고 추적 책임을 환자에게 전부 넘겨서는 안 됩니다. 의뢰를 낸 팀과 받은 팀의 책임 경계를 기록하는 일이 먼저입니다.