주제 1.6 — 임상 안전 및 위험 관리

한 문장으로: 임상 안전이란 디지털 기술이 환자에게 해를 끼칠 수 있는 경로를 찾아내고, 그 위험 요인이 누군가에게 닿기 전에 통제하는 규율 있고 입증된 실천이며, 가동 직전에 덧붙이는 것이 아니라 첫 스케치부터 설계에 내장된 안전이다.

보건·돌봄에서 이것이 중요한 이유#

대부분의 부문에서 소프트웨어 결함은 불편이다. 페이지가 로드되지 않고, 주문이 중복되고, 보고서가 늦는다. 보건·돌봄에서는 같은 종류의 결함이 사람을 죽일 수 있다. 소수점을 잘라 내는 약물 입력란, 엉뚱한 환자를 보여 주는 결과 화면, 어떤 증상을 조용히 표시하지 않게 된 분류 알고리즘, 알레르기 기록을 소리 없이 떨어뜨리는 통합이 모두 소프트웨어 버그이면서 동시에 중대한 피해나 사망을 일으킬 수 있는 임상적 위험 요인이다. 그래서 임상 안전은 좋은 엔지니어링 위에 얹는 품질의 장식이 아니다. 자체 표준, 역할, 증거를 가진 별개의 규제되는 학문 분야다.

위험은 비대칭적이고 흔히 보이지 않는다. 디지털 시스템이 제대로 작동할 때는 그것이 막은 피해를 아무도 보지 못하고, 실패할 때는 누군가 패턴을 알아차리기 전에 피해가 치명적이고, 지연되고, 수천 명의 환자에게 분산될 수 있다. 결과가 크고, 가시성이 낮으며, 영향 범위가 넓은 이 조합은 사용자가 문제를 잡아내거나 사고가 모든 것을 가르쳐 줄 것이라고 기대할 수 없다는 뜻이다. 배포 전에 선제적으로 피해를 추론하고, 가동 중에도 계속 추론해야 한다. 영국에서는 이 선제적 추론이 선택이 아니다. NHS 조직과 그 공급업체는 계약상으로나 전문직으로나 국가 임상 위험 관리 표준을 적용하고 그 과정을 보여 줄 수 있어야 한다. 이를 제대로 하는 일은 근거(주제 1.3 — 근거 기반 의사결정 참조), 정보 거버넌스와 사이버 보안(주제 1.7 — 정보 거버넌스, 데이터 보호 및 사이버 보안 참조), 그리고 서비스가 가동된 이후의 운영 방식(주제 3.8 — 서비스 관리 및 라이브 운영 참조)과 분리할 수 없다.

핵심 개념#

환자 안전과 위험 관리. 환자 안전은 돌봄으로 인한 환자 피해의 예방, 감소, 보고, 분석이다. 임상 위험 관리는 위험을 식별하고, 평가하고, 우선순위를 정하고, 통제하는 위험 관리의 일반 규율을 보건 IT 시스템이 환자 피해에 어떻게 기여할 수 있는가라는 구체적 질문에 적용한다. 잉글랜드에서 이를 규율하는 두 가지 국가 표준은 DCB0129와 DCB0160이다(DCB는 Data Coordination Board의 약자이며, Health and Social Care Act 2012에 따라 의무화된 Standardization Committee for Care Information, 곧 SCCI 표준이다). DCB0129는 보건 IT 시스템의 제조업체 또는 공급업체에게 의무를 부과하고, DCB0160은 이를 도입해 사용하는 보건 조직에게 의무를 부과한다. 둘은 상호 보완적이다. 공급업체의 깨끗한 안전 사례가 도입하는 트러스트의 구성, 업무 흐름, 맥락이 만들어 내는 위험 요인을 평가할 의무를 면제해 주지는 않는다.

임상 안전 책임자(CSO). 두 표준 모두 임상 위험 관리 활동을 책임지고 안전 사례를 직접 승인할, 인정받은 임상 안전 교육을 이수한 현직 등록 임상의인 적합한 자격과 경험을 갖춘 임상 안전 책임자를 지정하도록 요구한다. CSO 역할은 역량 요건이지, 시간이 나는 아무에게나 부여할 수 있는 직함이 아니다. CSO는 위험 요인이 식별되었고 허용 가능한 수준으로 통제되었음을 승인하며, 이는 전문직 책임을 수반하는 전문직 판단이다.

임상 위험 관리 산출물. 세 문서가 이 학문의 닻이다. 임상 위험 관리 파일은 시스템의 모든 안전 증거를 담는 용기다. **위험 로그(hazard log)**는 식별된 모든 위험 요인과 그 원인, 결과, 위험 등급, 통제, 잔여 위험의 살아 있는 등록부다. 임상 안전 사례는 시스템이 의도된 맥락에서 의도된 용도에 허용 가능하게 안전하다는 증거로 뒷받침된 구조화된 논증이며, 승인을 위해 논증을 요약한 안전 사례 보고서가 함께 간다. 이는 서류 작업을 위한 서류 작업이 아니라 안전에 대한 추론을 명시적이고, 검토 가능하며, 오래가게 만드는 방법이다.

위험 요인 분석: 식별, 분석, 평가, 통제. 핵심 순환은 이렇다. 위험 요인 식별(워크숍, 임상 워크스루, 고장 모드 분석을 통해 시스템이 피해에 어떻게 기여할 수 있는지 체계적으로 상상하기), 위험 분석(피해의 심각도와 발생 가능성 추정), 위험 평가(추정된 위험을 수용 기준과 비교), 위험 통제(설계 변경, 경보, 교육, 절차 같은 조치를 도입해 허용되지 않는 위험을 줄인 뒤 잔여 위험을 재평가)다. 위험은 합리적으로 실행 가능한 한 낮게(ALARP) 줄인다. 추가 감소가 얻는 이익에 비해 극도로 불균형해질 때까지 계속 통제한다.

의료기기 규제, MHRA, 의료기기로서의 소프트웨어(SaMD). 일부 디지털 보건 기술은 규제되는 의료기기다. 진단, 예방, 모니터링, 예측, 치료라는 의료 목적을 지닌 소프트웨어는 그 자체로 의료기기, 곧 의료기기로서의 소프트웨어(SaMD)가 될 수 있다. 영국에서는 Medicines and Healthcare products Regulatory Agency(MHRA)가 SaMD를 포함한 의료기기를 규제하며, 소프트웨어 수명주기 표준 IEC 62304가 그런 소프트웨어를 어떻게 개발해야 하는지 규율한다. 기술이 규제되는 기기인지 판단하는 일은 큰 결과를 낳는 문턱 질문이며, DCB0129/0160 임상 위험 관리와는 별개이지만 나란히 놓인다.

Digital Technology Assessment Criteria(DTAC). DTAC는 NHS와 사회적 돌봄 조직이 조달 전에 디지털 제품을 평가하는 국가 기준선으로, 임상 안전(DCB0129 준수 증거), 데이터 보호, 기술적 보안, 상호운용성, 사용성을 아우른다. 임상 위험 관리를 대체하지 않고, 공급업체가 그것을 했는지 점검한다.

인적 요인과 안전 문화. 인적 요인(인간공학)은 피로, 방해, 인지 부하, 경보 피로 같은 실제 조건에서 사람이 시스템과 어떻게 상호작용하는지에 대한 과학적 연구다. 대부분의 디지털 피해는 "잘못된" 코드에서 오는 것이 아니라, 안전한 행동은 어렵게 하고 위험한 행동은 쉽게 하는 설계에서 온다. 안전 문화는 비난 없이 위험을 드러내고, 보고하고, 배우려는 조직의 헌신이며, 아차사고를 숨기는 팀과 그것을 개선의 광맥으로 캐내는 팀의 차이다.

사고 보고와 학습. 잉글랜드에서 **Learn from Patient Safety Events(LFPSE)**는 환자 안전 사건을 기록하는 국가 서비스이고, **Patient Safety Incident Response Framework(PSIRF)**는 NHS 조직이 사고에 어떻게 대응하고 배울지를 규정하며 비난보다 비례적이고 체계 기반의 근본 원인 분석을 강조한다. 가동 중인 시스템은 새로운 위험 요인을 만들어 내므로, 사고 피드백이 위험 로그로 들어가면서 임상 안전은 가동 이후에도 계속된다.

모범 사례#

1. 적합한 임상 안전 책임자를 지정하고 실질적 권한을 부여하라. 범위에 있는 모든 시스템에 대해 인정받은 임상 안전 교육을 이수한 현직 등록 임상의를 CSO로 지정하고, 그의 승인이 출시 전날 도달하는 고무도장이 아니라 진짜 관문이 되게 하라. CSO는 "아직 아니다"라고 말할 수 있어야 하고 그 말이 받아들여져야 한다. 이는 그의 시간, 독립성, 프로그램 이사회 내 지위를 보호하는 것을 뜻한다. 전달 압박에 번번이 뒤집히는 CSO는 거버넌스의 허구다.

2. 임상의를 자리에 앉히고 위험 요인 식별을 일찍 하라. 가동 직전이 아니라 디스커버리와 설계에서 위험 요인 워크숍을 시작하라. 가장 저렴하고 효과적인 통제는 무엇이든 만들어지기 전에 이루어지는 설계 변경이기 때문이다(주제 3.5 — 딜리버리 수명주기 참조). 분석가만이 아니라 일선 임상의를 참여시키라. 방해, 우회책, 새벽 3시에 화면을 읽는 방식 등 일이 실제로 어떻게 이루어지는지를 그들이 알기 때문이다. 현실적인 임상 시나리오를 따라가며 끈질기게 물으라. "이 시스템이 환자가 해를 입는 데 어떻게 기여할 수 있는가?"

3. 출시일의 문서가 아니라 살아 있는 위험 로그를 유지하라. 위험 로그를 디스커버리에서 열고 시스템이 가동 중인 한 결코 닫지 않는 지속적 등록부로 다루라. 각 위험 요인은 원인, 잠재적 피해, 초기 위험 등급, 적용한 통제, 통제 후 잔여 위험을 기록한다. 사고, 변경, 아차사고가 새로운 위험 요인을 드러내면 그것이 로그에 들어가 같은 순환을 거친다. 로그는 여러분의 안전 추론에 대한 기억이다.

4. 공급업체가 규정을 준수하더라도 도입 조직이 DCB0160을 소유하라. 공급업체의 DCB0129 안전 사례는 만들어진 제품을 다룬다. 여러분이 어떻게 구성하는지, 어떤 업무 흐름을 그 주위에 두르는지, 어떤 집단이 사용하는지는 다룰 수 없다. 지역의 위험 요인, 곧 다른 시스템과의 통합, 데이터 품질, 임상 경로에 대해 자체 DCB0160 평가를 수행하고 자체 위험 로그를 보유하라. 공급업체의 보증이 우리 맥락을 다룬다고 가정하는 것은 흔하고 위험한 지름길이다.

5. 위험 통제를 비례적으로 하고 경고보다 설계를 선호하라. 통제를 강도 순으로 서열화하라. 위험 요인을 설계로 제거하는 것(제약, 기본값, 강제 기능)이 화면 경보보다 낫고, 화면 경보는 교육 매뉴얼의 한 줄보다 낫다. 가장 무거운 보증은 결과가 가장 큰 위험 요인에 남겨 두고, 진정으로 저위험인 변경에는 더 가볍고 빠른 프로세스를 적용하라. 비례성이 안전이 전달과 보조를 맞추게 해 준다. 위험을 ALARP까지 줄이고 잔여 위험이 왜 수용 가능한지 기록하라.

6. 인적 요인을 염두에 두고 설계하고 경보 피로를 존중하라. 사용자가 바쁘고, 방해받고, 패턴으로 판단한다고 가정하고, 안전한 행동이 쉬운 기본 행동이 되도록 설계하라. 경보 과부하를 경계하라. 너무 자주 울리는 경보는 무시되므로, 추가되는 모든 경고는 자리를 얻어야 하며 그렇지 않으면 중요한 경고들을 약화시킨다. 현실적 조건에서의 사용성 테스트는 단순한 디자인 부가 활동이 아니라 임상 안전 활동이다.

7. 규제상 지위를 의도적으로 판단하라. 소프트웨어가 의료기기 또는 SaMD의 정의를 충족하는지 일찍 묻고, 그렇다면 MHRA 요건과 IEC 62304를 늦게 의무를 발견하는 대신 처음부터 따르라. 분류를 잘못하는 일은 양방향으로 비싸다. 등록되지 않은 기기는 법적이고 안전상의 실패이고, 단순한 도구를 과분류하면 희소한 보증 역량을 낭비한다. 의심스러우면 규제 자문을 구하고 추론을 문서화하라.

8. DTAC를 결승선이 아니라 바닥으로 삼으라. Digital Technology Assessment Criteria를 조달되는 모든 디지털 제품의 최소 입구 점검으로 다루어, 임상 안전, 데이터 보호, 보안, 상호운용성, 사용성이 다뤄졌는지 확인하라. DTAC를 통과했다는 것은 공급업체가 일을 했다는 뜻이지 제품이 우리 맥락에서 안전하다는 뜻이 아니므로, 자체 DCB0160 평가와 실시간 모니터링과 짝지우라.

9. 라이브 사고에서 위험 로그로 순환을 닫으라. 사고 보고, 곧 LFPSE 제출, PSIRF 조사, 지역 아차사고 보고를 임상 위험 관리에 되먹임하여 실세계의 피해와 아차사고가 위험 요인과 통제를 갱신하게 하라. 가동 이후 다시 보지 않는 안전 사례는 썩는다. 라이브 시스템, 통합, 임상 실무가 모두 표류하기 때문이다(주제 3.8 — 서비스 관리 및 라이브 운영 참조). 학습은 체계 기반이고 비난을 인식하는 것이지, 처벌할 사람을 찾는 일이 아니다.

10. 공정한 보고 안전 문화를 구축하라. 아차사고를 보고하고 안전을 이유로 출시에 이의를 제기하는 일을 안전하고 기대되는 것으로 만들라. 듣지 못한 위험 요인은 통제할 수 없는 위험 요인이기 때문이다. 리더는 나쁜 소식에 비난이 아니라 호기심과 개선으로 응답하고, CSO의 신중함을 방해가 아니라 가치 있는 것으로 대함으로써 이 기조를 정한다. 문화는 여기 있는 다른 모든 실천이 기대는 토대다.

팀과 논의할 질문#

1. 우리의 현재 포트폴리오에서 사실은 우리가 책임져야 할 위험을 공급업체의 안전 보증이 다뤄 줄 것이라고 어디서 기대고 있는가? 이 질문은 팀이 일상적으로 흐리는 DCB0129/DCB0160의 구분을 파고든다. 공급업체의 DCB0129 안전 사례는 제조된 제품을 다루지만, 여러분이 구성하고, 다른 시스템에 연결하고, 지역 업무 흐름을 그 주위에 두르고, 특정 환자 집단에 적용하는 순간 공급업체가 평가하지 않았고 할 수도 없었던 위험 요인을 도입한다. 정직한 긴장은 자체 DCB0160 평가가 희소한 임상 및 분석 시간을 들이고, 공급업체의 깨끗한 보증과 DTAC 통과를 충분하다고 취급하고 싶어진다는 점이다. 운영 중이거나 임박한 도입 사례를 구체적으로 따져 보라. 이 시스템의 지정 CSO는 누구인가, 우리 자체 위험 로그가 있는가, 제품 자체가 아니라 순전히 우리 지역 맥락에서 생기는 위험 요인은 무엇인가? 좋은 답은 지역 평가가 얇은 구체적 시스템을 명명하고, 제품 위험 요인과 도입 위험 요인을 구별하며, 후자가 다뤄졌다고 가정하는 대신 자신이 소유하겠다고 약속한다.

2. 우리의 임상 안전 프로세스는 얼마나 비례적인가 — 저위험 변경은 서류에 파묻고, 결과가 큰 변경은 기세에 밀려 통과시키고 있지는 않은가? 주제는 보증이 임상 위험에 맞춰 조정되어야 한다고 주장한다. 결과가 가장 큰 위험 요인에 가장 무거운 검토를, 위험이 진정 낮은 곳에는 더 가볍고 빠른 프로세스를. 이 질문은 조직이 실제로 조정하는지 하나의 뭉툭한 설정을 적용하는지를 시험한다. 두 방향의 실패는 모두 실재하고 비싸다. 균일하게 무거운 프로세스는 팀이 임상 안전을 관료적 세금으로 보고 우회하도록 가르치고, 균일하게 가벼운 프로세스는 약물 용량 계산 변경이 도움말 페이지 변경과 같은 노력으로 통과하게 둔다. 더 미묘한 위험은 위험이 아니라 기세가 검토 수준을 결정하는 것이다. 경영진의 관심을 받는 대표 프로그램은 불가피하다는 분위기를 얻어 CSO가 "아직 아니다"라고 말하기를 주저하게 할 수 있다. 위험 수준이 분명히 다른 최근 변경 두세 개를 살펴 들인 노력이 피해 가능성에 맞았는지, 눈에 띄는 변경의 속도를 늦출 수 있다고 느낀 사람이 있었는지 물으라. 정직한 답은 프로세스가 어느 방향으로든 잘못 조정된 곳을 인정하고, 비례성을 반사적 반응이 아니라 변호 가능한 명시적 판단으로 다룬다.

3. 우리의 디지털 시스템에서 무언가 거의 잘못될 뻔했을 때 실제로 그다음에 무슨 일이 있었으며, 일선 임상의는 그것을 제기하는 것이 안전했다고 말하겠는가? 이 질문은 안전 문화와 사고 학습 순환, 곧 천명한 헌신이 현실을 만나는 곳을 살펴본다. 임상 안전은 아차사고를 듣는 데 달려 있지만, 사람들은 보고가 안전하고 가치 있게 느껴질 때, 그리고 그것이 비난이 아니라 변화로 이어지는 것을 볼 때만 보고한다. 긴장은 전달과 평판의 압박 아래에서 아차사고를 설명으로 덮고, 빨리 닫고, 넘어가려는 본능이 생긴다는 점이다. 특히 완전히 드러내면 출시가 지연되거나 고위 후원자가 난처해질 때 그렇다. PSIRF의 체계 기반이고 비난을 인식하는 접근은 정확히 이 때문에 있다. 책임을 물을 개인을 찾는 일은 필요한 보고를 억누르고 실제의 체계적 원인을 놓친다. 구체적인 최근 아차사고나 사고에 논의의 뿌리를 두라. 기록되었는가, 위험 로그에 도달했는가, 비례적 조사가 이루어졌는가, 실제로 무언가 바뀌었는가? 좋은 답은 보고가 안전하게 느껴졌는지에 솔직하고, 진정한 학습과 서류상의 종결을 구별하며, 다음에 위험 요인을 본 사람이 목소리를 내도록 리더가 채택할 구체적 행동을 명명한다.

4. 우리 제품 중 어떤 것이 규제되는 의료기기인지 정직하게 판단했는가 — 그리고 그 결정에 누가 책임지는가? 규제상 지위는 불균형적으로 큰 결과를 낳는 문턱 질문이며, 답하는 일이 불편할 수 있어서 답하지 않은 채로 두기 쉽다. 진단, 예측, 모니터링 또는 치료를 하는 소프트웨어는 그 자체로 의료기기로서의 소프트웨어일 수 있으며, DCB0129/0160 임상 위험 관리와 별개로, 그리고 추가로 MHRA 의무와 IEC 62304 수명주기 표준을 끌어들인다. 긴장은 양방향으로 흐른다. 과소 분류하면 등록되지 않은 기기를 출시하게 되는데, 이는 규모에서 파국적으로 드러날 수 있는 법적이고 안전상의 실패이며, 단순한 행정 도구를 과분류하면 다른 곳에 필요했던 희소한 보증 역량을 태운다. 위험은 분류가 역할 사이로 떨어진다는 것이다. 임상의는 엔지니어가 결정했다고 가정하고, 엔지니어는 규제 또는 상업 팀이 결정했다고 가정하며, 아무도 추론을 실제로 적어 두지 않았다. 포트폴리오에서 선에 가장 가까운 제품, 곧 분류 규칙, 위험 점수, 경보 알고리즘이 있는 모든 것을 구체적으로 살펴 누가 기기 판정을 내렸는지, 어떤 근거로, 문서화되고 기능이 바뀜에 따라 재검토되는지 물으라. 정직한 답은 경계선 제품을 명명하고, 각각에 대한 기록된 변호 가능한 근거를 가리키며, 결정이 실제로 내려진 적 없는 곳에 솔직하다.

5. 우리는 위험 요인을 설계로 제거하고 있는가, 아니면 임상의가 이미 무시하는 법을 배운 경보와 경고를 조용히 쌓고 있는가? 주제는 통제를 강도 순으로 서열화한다. 위험 요인을 설계로 제거하는 것이 화면 경보보다 낫고, 경보는 교육 매뉴얼의 한 줄보다 낫다. 그러나 경보는 가장 저항이 적은 길이다. 경고를 추가하는 일은 빠르고 책임감 있게 느껴지는 반면, 업무 흐름을 재설계하는 일은 느리고 논쟁적이기 때문이다. 시간이 지나면 이 편향이 경보 피로로 누적된다. 너무 많은 경고가 울려 임상의가 중요한 경고를 포함해 모두를 패턴으로 지나치게 되고, 그래서 새 경보 하나가 오히려 안전을 줄일 수 있다. 실제 긴장은 불필요한 모든 경보에는 어떤 사고 뒤에 선의로 그것을 추가한 후원자가 있어서, 시스템을 약화시키고 있을 때조차 경고를 없애기가 정치적으로 어렵다는 점이다. 인적 요인이 여기서의 학문이다. 바쁘고 방해받는 사용자가 새벽 3시에 화면을 읽을 때 안전한 행동이 쉬운 기본 행동이 되도록 설계하며, 현실적 조건에서의 사용성 테스트는 디자인의 부가 요소가 아니라 임상 안전 활동이다. 팀이 실제로 쓰는 시스템을 살펴 임상의가 전형적 과업에서 경보를 몇 번 만나는지, 그중 어느 것이 행동을 정말 바꾸는지, 강제 기능이나 더 나은 기본값이 경고를 아예 대체할 수 있었던 곳은 어디인지 물으라. 좋은 답은 또 하나의 경보를 추가하려는 반사에 저항하고, 경보 부하를 그 자체로 측정 가능한 위험 요인으로 다루며, 더는 자리를 얻지 못하는 경고를 기꺼이 제거한다.

6. 라이브 시스템, 통합, 임상 경로가 시간이 지나며 표류할 때, 우리의 안전 사례가 여전히 유효하다는 것을 어떻게 아는가? 임상 안전은 가동으로 끝나지 않는다. 라이브 시스템은 새로운 위험 요인을 만들고, 시스템을 둘러싼 세계는 계속 움직인다. 상류 통합이 데이터를 바꾸고, 임상 경로가 재설계되고, 공급업체가 업데이트를 내놓고, 새 환자 집단이 도구를 쓰기 시작한다. 2년 전에 승인된 안전 사례는 더는 존재하지 않을 수 있는 시스템과 맥락을 서술하므로, 질문은 위험 로그가 살아 있는 등록부인지 한 번 서명되어 썩도록 내버려진 문서인지다(주제 3.8 — 서비스 관리 및 라이브 운영 참조). 긴장은 가동 후 안전 추론을 유지하는 일이 새 전달과 같은 희소한 CSO 및 임상 시간을 두고 경쟁하며, 표류는 점진적이고 눈에 띄지 않아 무언가 실패하기 전에는 거의 주목받지 못한다는 점이다. 구체적 접근은 구성이나 통합이 바뀔 때 위험 요인 평가를 다시 촉발하는 변경 통제, 결과가 가장 큰 위험 요인의 주기적 검토, 통제가 조용히 퇴화하는 것을 실제로 탐지할 모니터링이다. 1년 이상 가동 중인 시스템을 골라 위험 요인이 마지막으로 검토된 때, 승인 이후 그 밑에서 무엇이 바뀌었는지, 핵심 통제가 작동을 멈추면 누가 알아차릴지 물으라. 정직한 답은 진정한 지속적 안전 관리가 있는 시스템과 낡은 안전 사례에 기대어 관성으로 가는 시스템을 구별하고, 달력만이 아니라 실제 변화와 연동된 비례적 검토 주기를 약속한다.

실제 사례: 보건·돌봄 예시#

한 통합 돌봄 시스템(ICS)이 일반의가 환자를 지역사회 서비스로 직접 의뢰할 수 있게 하는 공유 e-의뢰 도구를 도입하며, 이 도구에는 긴급 사례를 더 빠른 대기열로 보내는 분류 규칙 집합이 내장되어 있다. 전달 중심 접근이라면 공급업체의 DCB0129 안전 사례를 가져오고, DTAC를 통과하고, 이사회가 약속한 날짜를 맞추려 가동할 것이다.

대신 프로그램은 임상 안전 교육을 받은 현직 일반의를 임상 안전 책임자로 지정하고 설계 시작 시점에 임상 위험 관리 파일과 위험 로그를 연다. 일반의, 지역 간호사, 행정 직원과의 초기 위험 요인 워크숍은 공급업체의 제품 수준 사례가 전혀 다루지 않은 여러 위험 요인을 드러내는데, 모두 지역 도입에서 생기는 것이다. 최악은 분류 규칙이 ICS 자체의 서비스 정의에 맞춰 구성되었고, 매핑 오류가 긴급한 피부암 의뢰를 몇 주를 기다려야 하는 일반 피부과 대기열로 보낼 수 있다는 점이다. 이 위험 요인은 심각도 높음, 발생 가능성 그럴듯함으로 평가된다.

위험 통제 순환을 돌리며 팀은 경고보다 설계를 선호한다. 긴급 임상 표시가 라우팅 로직에 의해 조용히 뒤집힐 수 없도록 강제 기능을 추가하고, 임상의가 매일 검토하는 대조 보고서를 두며, 서열상 가장 낮은 교육 안내문을 둔다. 잔여 위험은 재평가되어 수용 가능하고 ALARP인 것으로 판단되고, CSO가 그 이유를 기록한다. 도구는 라우팅만 하고 스스로 진단하지 않으므로 팀은 SaMD 문턱을 충족하지 않는다고 평가하고, 그 추론을 문서화해 보관한다. 인적 요인 테스트는 별개의 문제를 잡아낸다. 지나치게 열성적인 "중복 의뢰" 경보가 너무 자주 울려 일반의들이 이미 무시하고 있어서, 진짜 중복에만 작동하도록 재설계된다.

가동 시 DCB0160 안전 사례는 프로그램 책임자가 아니라 CSO가 승인한다. 3주 뒤 LFPSE 보고서와 접수 담당자가 표시한 아차사고가 새로운 위험 요인을 드러낸다. 라우팅이 보지 못하는 긴급 정보를 몰래 끼워 넣는 데 쓰이는 자유 텍스트 입력란이다. PSIRF에 따라 비례적이고 체계 기반의 검토가 진행되고, 위험 요인이 로그에 들어가고, 설계 변경이 예정되며, 임시 통제가 같은 주에 전달된다. 안전 사례는 살아 있는 논증이고, 기록은 각 위험 요인이 어떻게 추론되었는지를 정확히 보여 준다. 이것이 점검관, 검시관, 또는 2년 뒤의 새 CSO가 필요로 할 것이다.

부문별 관점#

모두가 임상 위험을 통제할 같은 의무를 지지만, 그 기계 장치, 유인, 압력은 조직에 따라 크게 다르다.

스타트업#

디지털 보건 스타트업은 임상 안전을 조달 관문으로 처음 만나는 경우가 많다. NHS 구매자가 DTAC와 DCB0129 안전 사례를 요구하고 허둥지둥한다. 이기는 수는 첫 스프린트부터 임상 위험 관리를 내장하는 것이다. 백로그 옆의 위험 로그, 접근 가능한 임상 안전 책임자(고용이 아니라 계약인 경우가 많지만 진정으로 유능하고 권한이 있는)다. 완성된 제품에 안전 사례를 뒤늦게 얹는 일은 느리고, 비싸고, 설득력이 없기 때문이다. 창업자는 또한 SaMD 질문을 정직하고 일찍 마주해야 한다. 규모를 키우는 도중에 제품이 등록되지 않은 의료기기임을 발견하는 것은 존재를 위협하는 법적이고 안전상의 위험이기 때문이다. 잘 하면 성숙한 임상 안전 산출물은 NHS 영업 주기를 단축하는 상업적 자산이 된다.

소규모 사업체#

확립된 소규모 제공자 — 일반의 진료소, 지역 약국, 요양원, 재가 돌봄 기관, 단일 사업장 클리닉, 또는 수익 이전 단계를 지난 소규모 보건 기술 공급업체 — 는 디지털 시스템을 도입하고 구성할 때 대형 트러스트와 같은 DCB0160 의무를 지지만 이를 수행할 여유 역량이 전혀 없다. 급여를 받는 전담 CSO나 안전 분석가는 거의 없으므로, 현실적인 길은 유능한 현직 임상의를 계약으로 들이고, 의무가 적용되지 않는 척하는 대신 간소하지만 진짜인 위험 로그를 유지하는 것이다. 가장 날카로운 지역 위험 요인은 대개 구성과 업무 흐름에 관한 것이다. 공유 기록을 어떻게 설정하는지, 긴급 표시를 어떻게 처리하는지, 파트타임 행정 직원 한 명의 우회책이 어떻게 라우팅 위험이 되는지로, 공급업체의 DCB0129 사례가 결코 다루지 않는 바로 그 위험 요인들이다. 비례성이 여기서 소규모 제공자의 친구다. 가진 얼마 되지 않는 보증 시간을 결과가 가장 큰 위험 요인에 집중하고, 제품을 고를 때 DTAC와 공급업체의 안전 사례를 바닥으로 삼으며, 전체 체계를 혼자 구축하려 하기보다 ICS 임상 안전 지원 같은 공유 자원에 기대라.

대기업#

NHS 트러스트나 ICS는 이중의 책임을 진다. 남의 시스템을 DCB0160에 따라 도입하고, 자체 시스템을 DCB0129에 따라 구축하거나 크게 구성하는 경우가 많다. 전형적인 실패는 제도적이다. 가동일에 정치적 무게가 실린 대표 전자 환자 기록 프로그램에서 CSO의 신중함이 조용히 장애물로 취급된다. 바로잡는 길은 구조적이다. CSO에게 독립성과 실질적 거부권을 주고, 출시일 문서 더미 대신 자산 전체에 걸친 살아 있는 위험 로그를 유지하며, LFPSE와 PSIRF의 학습을 상시 프로세스로서 임상 위험 관리에 다시 연결하라. 대기업 규모에서 가장 큰 위험 요인은 어떤 공급업체의 보증도 다루지 않는 통합과 구성 위험 요인이므로 지역의 소유는 타협할 수 없다.

정부#

NHS England, MHRA, 보건사회부, NICE 같은 국가 기관은 다른 이들이 충족해야 할 표준을 정하므로, 그 업무 방식이 시스템 전체를 형성한다. DCB0129/0160, DTAC, SaMD 규제는 인구 규모 안전의 수단이다. 여기서의 결정은 규제, 의회, 대중의 감시를 받으며, 잠재적 위험 요인을 안고 있는 전국적으로 의무화된 시스템은 누군가 패턴을 보기 전에 수백만 명에게 그 피해를 분산시킨다. 의무는 공개된 표준에서의 명시적 비례성, 잔여 위험에 대한 투명성, 그리고 기술, 특히 AI가 앞질러 갈 때 규제 틀을 최신으로 유지하는 것이다(주제 8.4 — AI 및 신기술 거버넌스 참조). 이 규모의 독특한 위험은 체계적이다. 빈약한 안전 근거로 기술을 자산 전체에 의무화하면 위험 요인이 어디서나 한꺼번에 굳는다.

흔한 실패 양상#

• 마지막에 덧붙인 안전. 관문을 충족하려고 가동 일주일 전에 안전 사례를 만들어 내는 것. 해독제: 디스커버리에서 위험 로그를 열고 가장 큰 위험 요인을 설계로 제거한다.
• 지역 안전으로 오인된 공급업체 보증. DCB0129 사례와 DTAC 통과가 우리의 도입을 다룬다고 취급하는 것. 해독제: 자체 DCB0160 평가와 지역 위험 로그를 소유한다.
• 고무도장 CSO. "아직 아니다"라고 말할 시간, 독립성, 권한이 없는 임상 안전 책임자. 해독제: 역할을 보호하고 승인을 진짜 관문으로 만든다.
• 죽은 위험 로그. 한 번 쓰고 출시 이후 다시 보지 않는 문서. 해독제: 살아 있게 유지하고 사고와 변경을 거기에 반영한다.
• 경보 과부하. 너무 많은 경고로 임상의가 중요한 것을 포함해 모두를 무시하는 것. 해독제: 인적 요인 설계. 모든 경보는 자리를 얻어야 한다.
• 비난 문화. 아차사고를 개인에게 책임지워 보고가 말라 버리는 것. 해독제: PSIRF에 맞춘 공정하고 체계 기반의 문화.
• 놓친 규제 문턱. SaMD를 규제되는 기기로 인식하지 못하고 출시하는 것. 해독제: 의료기기 지위를 일찍 평가하고 문서화한다.

성숙도 모델#

체크리스트#

• 각 시스템마다 "아직 아니다"라고 말할 시간과 권한을 가진 유능하고, 현직이며, 교육받은 임상 안전 책임자가 지정되어 있다.
• 범위에 있는 각 시스템에 임상 위험 관리 파일, 살아 있는 위험 로그, 임상 안전 사례가 있다.
• 위험 요인 식별이 일선 임상의를 참여시킨 채 디스커버리에서 시작되었다.
• 도입 조직이 공급업체의 DCB0129 사례를 수용하는 데 그치지 않고 자체 DCB0160 평가를 수행했다.
• 위험 통제가 설계로 제거 > 경보 > 교육 순을 선호하며, 잔여 위험이 ALARP까지 줄고 정당화되어 있다.
• 의료기기 / SaMD 지위가 평가되고 문서화되었으며, 관련된 경우 MHRA / IEC 62304 의무가 다뤄진다.
• DTAC가 바닥으로서 완료되었고 지역 임상 위험 관리와 짝지워져 있다.
• 현실적 조건에서의 인적 요인 및 사용성 테스트가 수행되었고 경보 부하가 통제된다.
• 라이브 사고(LFPSE)와 PSIRF 학습이 상시 프로세스로서 위험 로그에 되먹임된다.
• 아차사고를 보고하고 안전을 이유로 출시에 이의를 제기하는 것이 눈에 띄게 안전하고 기대된다.

주요 출처#

• NHS England — DCB0129: Clinical Risk Management: its Application in the Manufacture of Health IT Systems.
• NHS England — DCB0160: Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems.
• NHS England — Clinical Safety Officer training 및 임상 위험 관리 지침.
• NHS England — Digital Technology Assessment Criteria (DTAC).
• MHRA — Software and Artificial Intelligence (AI) as a Medical Device 지침.
• IEC — IEC 62304: Medical device software — software life cycle processes.
• ISO — ISO 14971: Application of risk management to medical devices.
• NHS England — Learn from Patient Safety Events (LFPSE) 서비스.
• NHS England — Patient Safety Incident Response Framework (PSIRF).
• World Health Organization — Global Patient Safety Action Plan 2021–2030.

참고문헌#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan