PRRC Korea

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를 단순히 오픈소스 소프트웨어로 이해하기도 하지만 이는 정확한 해석은 아닙니다. 상용 소프트웨어, 서드파티 라이브러리, 운..