「위탁처의 지속성」 그 다음 단계 — 의료 정보 시스템 안전 관리 가이드라인 제7.0판 '보수 위탁 기관 편'에서 보는 이중 위탁 구조

지금까지는 '누출'로 판단하기 전에 해야 할 일에 대해 다루었습니다. 정보 유출 대응은 먼저 '범위 특정'부터 시작하며, '시스템이 멈췄을 때' 의료 기기는 어떻게 계속 작동해야 하는지, 공격하는 측도 AI를 사용하는 시대에는 '현장의 지속성' 다음으로 '위탁처의 지속성'이라는 네 가지 글을 작성했습니다. 주어는 '자 조직(自組織)'에서 '직접 위탁처'까지 확장되었지만, 아직 한 단계 부족한 부분이 있습니다.

2026년, 후생노동성은 「의료 정보 시스템 안전 관리에 관한 가이드라인」을 제7.0판으로 개정했습니다. 이 버전에서 신설된 것이 전문 인력이 부족한 소규모 의료기관을 상정한 '보수 위탁 기관 편'입니다. 대상으로는 서버 보안 업데이트를 포함한 보수를 사업자에게 전면적으로 위탁하는 의료기관이 예상되며, 개요편에서는 클라우드 서비스(특히 SaaS형)의 채택에 따라 특별한 계약 없이도 해당 보수 위탁이 실현될 것으로 가정하고 설명하고 있습니다.

즉, 가이드라인 자체가 '의료기관 → 보수 위탁처 → 클라우드 기반 사업자'라는 이중 위탁 구조를 더 이상 예외가 아닌 전제로 삼고 있는 것입니다.

1. 논점 — '직접 위탁처'까지의 대비만으로는 부족하다

지난 글에서는 위탁처/외부 사업자 측에서 사고가 발생했을 때 발주처가 확인해야 할 관점으로 계약·책임 분담, 통지 체계, 업무 지속성 세 가지를 제시했습니다. 이들은 모두 '자 조직과 직접 계약한 위탁처'를 주어로 한 이야기입니다.

하지만 제7.0판이 보여주는 것은 그 위탁처 자신이 또 다른 사업자(클라우드 기반·SaaS 제공자)에 운영을 의존하고 있다는 구조입니다. 소규모 의료기관이 보수 위탁처를 선택할 때, 그 위탁처가 무엇을 사용해 보수를 실현하는지까지 의식하는 경우는 아직 많지 않습니다. 위탁처가 무너지거나 멈추는 시나리오뿐만 아니라, 위탁처가 의존하고 있는 기반 측 사정으로 인해 위탁처 자체의 서비스가 멈추는 시나리오 역시 같은 무게로 대비 대상에 포함할 필요성이 생기고 있습니다.

이는 특정 사업자를 의심하는 문제가 아니라, '보수를 클라우드를 통해 실현한다'는 운영 자체가 제도적으로 권장되고 가정되게 된 이상, 그 운영에 수반되는 리스크도 제도적으로 상정해야 한다는 구조적인 논점입니다.

2. 위탁처 선정 자체가 사실상

본 기사에서 참조한 내용은 후생노동성(厚生労働省)이 공표한 가이드라인의 구성과 이를 해설하는 공개된 기사에 한정됩니다. 어느 의료기관이 어떤 위탁처를 사용하고, 그 위탁처가 어떤 클라우드 사업자에 의존하고 있는지와 같은 비공개 정보는 당연히 다루지 않았습니다. 위탁처 선정 검토 시에도 마찬가지로, 구체적인 계약 내용이나 거래처의 구성을 외부 AI 도구에 입력하는 것은 피하고, 일반화된 확인 관점 부분만을 활용하는 것이 안전한 사용법이라고 생각합니다.

5. 결론 (おわりに)

'자체 조직', '직접 위탁처'를 거쳐 이번에는 '위탁처가 다시 의존하는 곳'이라는, 한 단계 더 나아간 이야기를 했습니다. 대비해야 할 범위는 한 번 넓혔다고 끝나는 것이 아니라, 위탁 구조 자체가 변화할 때마다 조금씩 확장되어 가는 것 같습니다. 보수 위탁 기관 편이 신설된 것은 그 변화를 제도 측면에서 따라잡기 시작했다는 하나의 증거라고 느낍니다.

같은 문제의식을 가진 분이 계시다면 댓글로 알려주시면 감사하겠습니다.

⚠️ 면책 조항 (免責)

본 기사는 필자의 현재 시점에서의 개인적인 견해이며, 법적 자문이 아닙니다. 의료·교육 분야 제품에 응용할 경우에는 반드시 소속 조직의 책임자, 정보 보안 부서, 전문가와 상담 후 판단하시기 바랍니다. 필자는 본 기사 이용으로 인해 발생하는 손실에 대해 책임을 지지 않습니다.

임상공학기술자 × AI 엔지니어. 11년 동안 병원의 의료기기 현장에 몸담아 왔습니다.

현재는 AI 엔지니어로 활동하며, 라쿠노 학원대학(酪農学園大学)의 연구생으로서 논문 박사 취득을 목표로 유전체 의학의 미래를 연구 주제로 삼고 있습니다.

토론 (Discussion)