화면 조회도 운영상 확인해야 할 사건입니다
환자 기록을 변경한 이력만 남기면 누가 어떤 기록을 열람하거나 내려받았는지 조사하기 어렵습니다. 의료진·상담자·관리자의 역할에 따라 필요한 접근 행위를 정리하고 목적, 대상과 결과를 남길 범위를 합의합니다. 감사 이력을 위해 건강 데이터 원문을 중복 저장하면 민감한 정보가 더 퍼질 수 있어 필요한 필드부터 선정해야 합니다.
업무 변경 이력과 접근 이력을 연결합니다
FHIR AuditEvent는 시스템의 보안 관련 사건을 표현하는 참고 구조입니다. 내부에서는 사용자·기관·역할, 대상 식별자, 수행 행동과 시각을 연결할 수 있습니다. 실패한 접근과 권한 변경도 조사에 도움이 됩니다. 로그를 조회하는 관리자에게도 별도 권한을 적용하고 감사 기록 자체의 변경·삭제 절차와 보관 기준을 정합니다.
환자 한 명의 기록 열람 경로를 재현합니다
기관 A의 사용자가 허용된 기록을 조회하고 기관 B의 기록 조회는 거절되는 상황을 시험합니다. 정상과 거절 사건에서 조사에 필요한 정보가 남는지 확인하세요. 다운로드 파일의 생성과 실제 수령 시점은 다를 수 있으므로 두 사건을 연결하면 사고 조사에 유용합니다. 운영 담당자가 비정상적인 대량 접근을 발견했을 때의 확인·회수 절차도 준비합니다.
검수 후 남겨둘 자료
감사 이력 표본에는 행위자·기관·대상·행동·결과·시각과 요청 식별자를 담습니다. 일상 운영 화면에서 건강 원문 전체를 보여주지 않고 필요한 사건만 조회할 수 있는지 검토하세요. 권한을 가진 조사자가 기간과 대상을 제한해 조회하고, 그 조회 자체도 추적 가능한지 검수하면 운영 인수의 기준이 구체적이 됩니다.
프로젝트에서 확인할 항목
- 열람·수정·다운로드·권한 변경을 구분하는가
- 감사 로그에 불필요한 건강 원문이 들어가지 않는가
- 기관 경계를 넘는 접근 시도와 결과가 남는가
참고 자료
자료 확인일: 2026.10.11 · 본문의 적용 예시와 체크리스트는 참고 자료를 바탕으로 정리한 실무 제안입니다.
기술 동작은 아래 공식 문서를 참고했습니다. 적용 조건과 지원 버전은 프로젝트 환경에 맞게 확인하세요.
작성팀 소개
TOPPING 편집팀 · IoT·헬스케어 개발 콘텐츠
공식 기술 문서를 바탕으로 개발 범위, 데이터 연동과 검수 기준을 정리합니다. 글에 제시된 적용 예시는 프로젝트 검토를 위한 제안이며, 특정 고객사의 구축 실적이나 의료적 판단을 의미하지 않습니다.
