PRRC Korea

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

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

의료기기 소프트웨어를 개발하다 보면 의외로 많은 기능이 외부에서 가져온 코드에 의존하고 있다는 사실을 발견하게 됩니다. 운영체제, 데이터베이스, 그래픽 라이브러리, 네트워크 모듈, 심지어 보안 라이브러리까지 대부분이 이미 존재하는 소프트웨어 위에서 동작합니다. 이러한 외부 소프트웨어를 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. 보안 통제가 새로운 취..

MLMD(Machine Learning-based Medical Device)는 질병의 진단·예측과 같은 고도의 임상적 결정을 지원하기 위해 전자의무기록(Electronic Medical Record, EMR), 의료 문헌, 임상시험 데이터, 영상 데이터 등 다양한 출처의 훈련 데이터셋을 활용합니다. 이러한 데이터셋의 품질은 알고리즘의 성능뿐 아니라, 환자 안전과 직결되는 의료기기의 유효성 및 신뢰성에 직접적인 영향을 미칩니다. 따라서 제조자는 훈련 데이터셋의 수집, 관리, 검증, 갱신 등 전 과정에 걸쳐 체계적인 관리 절차를 갖추어야 합니다. 이는 단순한 연구 개발 관리가 아니라, 규제 준수(Regulatory Compliance)의 영역에 속합니다. 실제로 FDA(미국), EMA(유럽), MFDS(한..

최근 SaMD(Software as a Medical Device) 제품 가운데 ‘병원 내부에 워크스테이션을 설치하여 작동한다’는 요구사항을 명시하는 사례가 늘고 있습니다. 얼핏 보면 제조자가 장비까지 함께 공급한다는 의미로 읽히지만, 실제 규제 관점에서는 조금 더 신중한 해석이 필요합니다. SaMD는 본질적으로 ‘소프트웨어 그 자체’가 의료기기입니다. 다만 그 소프트웨어가 안정적으로 작동하기 위해서는 특정한 하드웨어 환경이 필요하며, 병원 내부 네트워크에서 운영되어야 하는 경우가 많습니다. 이는 의료정보보호, 데이터 접근성, 보안성 등의 이유로 외부 클라우드 환경을 제한하기 때문입니다. 따라서 ‘병원 내부 워크스테이션 설치’란 문구는 보통 해당 소프트웨어가 작동 가능한 환경의 위치와 형태를 명시한 것에..

의료기기 규제 분야에서 ‘파일의 무결성(integrity)’은 단순한 기술적 개념을 넘어, 환자의 안전과 직결되는 중요한 요소입니다. 개발자나 제조자가 배포하는 소프트웨어가 중간에 변조되지 않았음을 입증하는 것이 곧 ‘신뢰’의 기반이 되기 때문입니다. 이 신뢰를 지켜주는 핵심 도구가 바로 ‘해시(Hash)’입니다. 해시란, 특정 파일의 내용을 수학적으로 계산하여 얻은 고유한 값입니다. 파일 안의 단 한 글자, 한 비트만 달라져도 완전히 다른 해시 값이 생성됩니다. 이를 통해 우리는 파일이 원본 그대로인지, 혹은 누군가에 의해 변조되었는지를 손쉽게 구별할 수 있습니다. 의료기기 소프트웨어를 예로 들면, 제조자는 소프트웨어를 개발하고 검증한 뒤 그 버전에 대한 해시 값을 함께 제공합니다. 사용자는 이 해시를..

IEC 62304 5.7조항의 비고 1은 소프트웨어 의료기기(SaMD) 개발자에게 단순한 예외 조항이 아니라, 규제의 언어 속에 숨겨진 유연성의 신호로 읽힙니다. 이 문장은 전통적 개발 모델의 경직성을 완화하고, 현대적 개발 환경에 적합한 효율적 검증 체계를 인정하는 선언과도 같습니다. 비고 1이 허용하는 가장 핵심적인 변화는 두 가지입니다. 첫째, 통합 테스트와 시스템 테스트의 병합을 허용함으로써 실질적 개발 흐름과 문서화 요구 사이의 간극을 좁혔습니다. 실제 SaMD 프로젝트에서는 기능 단위의 검증과 전체 시스템 수준의 검증이 밀접하게 얽혀 진행됩니다. 이를 두 개의 독립된 절차로 강제하는 것은 불필요한 행정적 부담을 낳을 뿐 아니라, 반복적 테스트로 인한 비효율을 초래할 수 있습니다. 비고 1은 이..

최근 의료기기 사이버보안의 핵심 화두 중 하나로 떠오른 개념이 바로 SBOM(Software Bill of Materials)입니다. SBOM은 한마디로 소프트웨어의 ‘성분표’입니다. 제품에 어떤 오픈소스, 라이브러리, 프레임워크가 사용되었는지를 체계적으로 기록한 명세서로, 소프트웨어의 투명성을 확보하기 위한 필수 도구로 자리 잡고 있습니다. 의료기기 소프트웨어(SaMD)를 포함한 대부분의 현대 소프트웨어는 완전한 자체 개발보다는 다양한 외부 구성요소를 조합하여 만들어집니다. 이때 SBOM은 개발자와 규제기관 모두에게 다음과 같은 세 가지 측면에서 결정적인 역할을 합니다. 첫째, 보안 취약점 관리입니다. 각 구성요소의 버전과 출처를 명확히 기록함으로써, 특정 라이브러리에 취약점이 발견되었을 때 해당 문제..