PRRC Korea

SPICE, 의료기기 소프트웨어 품질을 증명하는 보이지 않는 설계도

소프트웨어 공학에서 SPICE(Software Process Improvement and Capability dEtermination)는 단순한 프로세스 평가 도구가 아니라, 품질을 구조적으로 담보하기 위한 국제 표준 체계입니다. 특히 의료기기 산업에서는 이 표준이 단순한 선택이 아닌 필수 요소로 자리 잡고 있습니다. 의료기기 소프트웨어의 오류는 환자의 안전과 직결되기 때문에, 개발 과정의 신뢰성과 추적 가능성이 법적 요구사항 수준으로 관리되어야 합니다. SPICE는 ISO/IEC 15504에서 출발하여 현재 ISO/IEC 330xx 시리즈로 발전했으며, 프로세스의 성숙도를 객관적으로 평가할 수 있는 기준을 제공합니다. 의료기기 분야에서는 이를 기반으로 IEC 62304(의료기기 소프트웨어 생명주기 프로..

의료기기 개발, CMMI는 단순한 인증이 아니라 ‘프로세스의 근육’을 키우는 일!

의료기기 산업에서 품질과 신뢰성은 생명과 직결됩니다. 이러한 산업적 특성 속에서 조직의 개발 역량을 객관적으로 평가하고 지속적으로 개선하기 위한 도구로 CMMI(Capability Maturity Model Integration)는 중요한 의미를 가집니다. 많은 기업이 이를 ‘인증’으로만 인식하지만, 실제로는 조직의 개발 프로세스를 성숙하게 만드는 ‘경영 시스템’에 가깝습니다. CMMI는 미국 카네기 멜런 대학 소프트웨어공학연구소(SEI)가 국방성의 의뢰로 개발한 모델로, 현재는 소프트웨어뿐 아니라 의료기기, 항공, 국방, 자동차 등 다양한 분야에서 활용되고 있습니다. 특히 ISO 13485와 같은 품질경영시스템(QMS)과 병행할 때, 의료기기 개발 프로세스의 예측 가능성과 규제 대응력을 극대화할 수 있..

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

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

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

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

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

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

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