PRRC Korea

의료기기 설계개발 파일 구성과 규제 대응을 위한 문서 체계의 이해

의료기기 개발 과정에서는 단순한 기술 개발뿐 아니라 규제 요구사항을 충족하기 위한 체계적인 설계개발 문서 관리가 필수적입니다. 국제 규격인 ISO 13485와 IEC 62304, IEC 62366, ISO 14971 등의 요구사항을 반영하면 설계개발 파일은 단순한 문서 목록이 아니라 설계 입력부터 검증·검증, 사용성, 사이버보안, 위험관리까지 전 과정을 연결하는 체계로 구성됩니다. 일반적으로 설계개발 파일은 Design & Development Plan을 기반으로 시작합니다. 해당 문서에서는 개발 단계, 책임, 검토 시점, 산출물 등을 정의합니다. 이후 Design & Development Input 문서를 통해 사용자 요구사항(User Requirement Specification), 소프트웨어 요구사..

심사가 필요한 디지털의료기기소프트웨어 변경사항

디지털의료기기 소프트웨어는 특성상 지속적인 업데이트와 개선이 이루어집니다. 개발자에게는 자연스러운 개선일 수 있지만, 규제 관점에서는 작은 수정 하나가 허가사항 변경으로 이어질 수 있습니다. 실제로 많은 제조사가 “기능 개선” 또는 “운영환경 업데이트” 정도로 생각했던 변경이 규제상 변경허가 또는 변경신고 대상이 되는 사례가 반복적으로 발생합니다. 문제는 대부분의 변경이 기술적으로는 작아 보이지만, 안전성·유효성 또는 사용적합성에 영향을 줄 가능성이 있는지 여부로 판단된다는 점입니다. 디지털의료기기 소프트웨어에서 가장 대표적인 변경은 성능 또는 기능의 변화입니다. 예를 들어 진단 보조 기능이 추가되거나, 기존 알고리즘의 판단 기준이 조정되거나, 새로운 분석 지표가 도입되는 경우에는 단순한 기능 개선으로 ..

IEC 62304 Class A/B/C 등급별 요구사항 정리

5.1 Software Development PlanningClause내용Class AClass BClass C5.1.1Software development plan✔✔✔5.1.2Keep software development plan updated✔✔✔5.1.3Reference to system D&D✔✔✔5.1.4Development standards, methods, tools planning✖✖✔5.1.5Integration & integration test planning✖✔✔5.1.6Software verification planning✔✔✔5.1.7Software risk management planning✔✔✔5.1.8Documentation planning✔✔✔5.1.9Configurati..

EU MDR Class IIa로 분류되는 디지털치료제(디지털치료기기)

EU 의료기기 규정(MDR)이 시행된 이후 디지털 헬스 업계에서는 자주 들리는 말이 있습니다. 이제 Class I 소프트웨어는 사실상 사라졌다는 이야기입니다. 특히 디지털 치료제(DTx)나 의료 소프트웨어 분야에서는 MDR Rule 11이 대부분의 제품을 Class IIa 이상으로 끌어올렸다는 해석이 널리 퍼져 있습니다. 그러나 규정의 실제 취지를 들여다보면, Class I이 사라졌다기보다 의료 소프트웨어의 정의와 역할이 보다 명확하게 정리되었다고 보는 것이 더 정확합니다. 과거 MDD 체계에서는 상당수의 의료 소프트웨어가 Class I으로 분류될 수 있었습니다. 특히 단순 건강관리 앱이나 데이터 기록용 소프트웨어도 의료 목적을 주장하는 경우가 있었고, 제조자가 스스로 적합성을 선언하는 방식으로 시장에 ..

의료기기 소프트웨어는 왜 ‘버그 수정’과 ‘알고리즘 변경’을 다르게 볼까?

의료기기 소프트웨어를 개발하거나 운영하다 보면 “이 정도 수정은 그냥 업데이트 아닌가요?”라는 질문을 자주 듣습니다. 일반 IT 소프트웨어라면 단순 업데이트로 넘어갈 수 있는 변화도 의료기기 영역에서는 전혀 다른 의미를 가질 수 있기 때문입니다. 규제 관점에서 보면, 무엇이 단순 유지보수이고 무엇이 성능 변경인지 구분하는 일은 생각보다 훨씬 중요합니다. 먼저 소프트웨어 업그레이드로 보지 않는 대표적인 사례는 유지보수 수준의 변경입니다. 예를 들어 사용 중 발견된 결함이나 오류를 제거하거나 시스템 안정성을 개선하기 위한 수정은 일반적으로 기능이나 성능을 변화시키지 않기 때문에 경미한 변경으로 간주됩니다. 사용자 환경을 개선하기 위해 UI를 조정하거나 메뉴 구조를 변경하는 경우도 마찬가지입니다. 이러한 변경..

의료기기 소프트웨어의 밸리데이션 (화이트박스와 블랙박스 접근법)

밸리데이션은 소프트웨어가 의도한 대로 유효하고 효과적으로 작동하는지 확인하는 과정입니다. 이 과정은 의료기기 소프트웨어의 안전성과 신뢰성을 보장하는 데 필수적입니다. 초기 단계 (화이트박스 접근법): 밸리데이션의 첫 단계는 소프트웨어의 설계 요건과 구조를 고려하여 코딩하는 것입니다. 이 단계에서는 개별 모듈이 의도대로 정확하게 작동하는지 확인합니다. 이 과정에서 화이트박스 접근법이 사용됩니다. 화이트박스 접근법은 소프트웨어의 내부 구조와 작동 방식을 상세히 이해하고 검증하는 방식입니다. 이를 통해 각 모듈이 정확하게 코딩되었는지 확인하며, 오류를 사전에 식별하고 수정합니다. 통합 및 최종 검증 (블랙박스 접근법): 모든 모듈의 검증이 완료되면, 이들을 통합하여 전체 소프트웨어를 구성합니다. 이후에는 전체..

소프트웨어 의료기기 (SaMD) 위험관리 방법

소프트웨어의 사용목적 및 안전성 관련 특성 식별 소프트웨어의 사용목적과 적용 범위를 명확히 정의해야 합니다. 소프트웨어가 사용목적을 달성하는 데 어떠한 역할을 하는지 파악해야 합니다. 이를 통해 필요한 소프트웨어의 기능적 특성을 식별하고, 이들 중 안전성에 영향을 미치는 요소를 파악해야 합니다. 위해요인 분석 제조자는 위험관리 프로세스에 따라 정상 및 고장 상태에서 발생 가능한 위해요인을 분석해야 합니다. 오작동, 측정 오류, 과도한 출력, 데이터 손실 등이 발생할 수 있는 위해요인을 파악하고 이에 대한 대책을 마련해야 합니다. 소프트웨어의 사용목적과 적용범위를 명확히 하여 이를 달성하기 위한 소프트웨어의 역할을 정확히 이해하고 위해요인을 분석하는 것이 중요합니다.

의료기기 소프트웨어의 가장 위험한 친구, SOUP를 아십니까

의료기기 소프트웨어를 개발하다 보면 의외로 많은 기능이 외부에서 가져온 코드에 의존하고 있다는 사실을 발견하게 됩니다. 운영체제, 데이터베이스, 그래픽 라이브러리, 네트워크 모듈, 심지어 보안 라이브러리까지 대부분이 이미 존재하는 소프트웨어 위에서 동작합니다. 이러한 외부 소프트웨어를 IEC 62304에서는 SOUP(Software of Unknown Provenance)라고 부릅니다. 직역하면 출처를 알 수 없는 소프트웨어이지만, 실제 의미는 조금 다릅니다. 개발자가 직접 개발하지 않았거나 개발 과정에 대한 충분한 기록을 확보하지 못한 소프트웨어를 의미합니다. 많은 사람들이 SOUP를 단순히 오픈소스 소프트웨어로 이해하기도 하지만 이는 정확한 해석은 아닙니다. 상용 소프트웨어, 서드파티 라이브러리, 운..

의료기기 분야에서 AI 기반 기술의 도입은 이미 필연적인 흐름이 되었습니다. 그러나 현장의 규제 담당자(RA) 입장에서 보면, 여전히 개발팀과의 언어적 간극이 큽니다. 특히 AI 모델 검증, 소프트웨어 툴 체인, Docker 등 기술적 개념은 단순히 ‘검토 대상 문서’로만 보기 어렵습니다. RA가 이해하지 못한 기술은 곧 ‘리스크’가 되기 때문입니다. 최근 AI 의료기기 허가를 추진하는 과정에서 느낀 점은, 개발팀이 사용하는 툴과 검증 방법론을 RA가 직접 이해해야 한다는 점입니다. 단순히 제출용 문서에 의존해서는 실제 구현 수준의 안전성과 성능을 제대로 설명할 수 없습니다. 예를 들어 Docker나 SaMD(SW as a Medical Device) 환경에서의 재현성, 검증 로그 관리, 버전 관리 체계..

1. 위협 모델에서 위험 및 통제 항목을 도출한다. 2. 완화 전/후 점수를 평가할 수 있는 방법을 제공한다. 3. 위험에 대한 수용 기준을 포함한다. 4. 안전 위험 평가로 이관하는 방법을 제공한다. 5. 발생 확률보다 공격 가능성(Exploitability) 에 초점을 맞춘다. 6. 알려진 취약점을 예견 가능한 위험으로 평가한다. 7. 취약점 평가 시 TPLC (Total Product Life Cycle) 를 고려한다. 8. 장치의 사이버 위험을 더 큰 시스템의 맥락에서 평가한다. 9. 주요 CISA KEV (Known Exploited Vulnerabilities) 취약점을 설계 단계에서 제거한다. 10. 최악의 상황을 가정하거나 공격 가능성에 대한 근거를 제시한다. 11. 보안 통제가 새로운 취..