Tag: medical device software

[단상] Verification 대 Validation

[단상] Verification 대 Validation

용어가 중요하다는 것은 누구나 안다.

학문의 세계에서는 전문가들이 자신의 논거를 확실하게 주장하기 위하여 용어를 엄밀하게 정의하여 사용하고, 때로는 신조어를 만들어 사용하기도 한다. 학자들도 학문적 교류를 위해 용어를 통일하기 위해 애쓴다. 기술의 세계에서도 용어를 중시한다. 어떤 기술적인 문서 또는 책자에서도 본론에 앞서 거의 예외 없이 용어 정의, 약어 설명 등이 자리를 차지한다. 그것은 용어가 해당 문서, 책자의 내용을 이해하고, 그 목적을 달성하는 데 그만큼 중요하다는 것을 반증한다.

그런데, 학문이든지 기술이든지, 어떤 경계를 벗어날 때 약간의 문제가 발생한다. 예를 들어, “경계”라는 낱말은 “한계”, “울타리”, “구획”, “지경” 등 여러 뜻으로 쓰일 수 있다. “경계를 벗어날 때”의 “경계”의 자리에 “한계”, “울타리”, “구획”, “지경” 등을 선택한다고 해도 특별히 부자연스럽지는 않다. 그러나, “한계”란 끝을 표현하는 데 유리하고, “울타리”란 물리적 형태 연상에 유리하고, “구획”이란 건축, 토지 설계 등의 표현에 유리하고, “지경”이란 큰 땅덩이의 표현에 유리하다. 유사한 뜻이므로 교환하여 사용할 수 있지만 이렇게 어감의 차이가 있듯이 특정한 학문 또는 기술 분야의 경계를 벗어난 용어의 의미는 서로 의미나 쓰임새가 달라질 수밖에 없다.

외국어인 경우, 문제는 좀 더 복잡해진다. 학문이든지 또는 기술이든지 앞선 이론 또는 앞선 기술을 가진 외국 전문가가 새로운 개념의 용어를 만들어 사용하는 경우, 그 개념에 대응되는 마땅한 우리말이 없는 경우가 비일비재하기 때문이다. 자국어를 가진 어엿한 나라가 학문 또는 기술 용어를, 외국어 그대로 수용한다는 것은, 여러 이유로 문제가 있을 수밖에 없기 때문에 불가피한 경우를 제외하고는 한글 용어를 발굴하여야 하는 것이다. 그러나, 어감 또는 표현의 선호도 때문에 한 용어를 다른 용어보다 앞세우는 다툼 또한 불가피하다.

이는 대체로 번역 문제와 궤를 같이 한다. 일반적으로는, 한 저자의 책을 여러 전문가가 공동 번역하는 것보다는 한 전문가가 번역하는 것이 일관성 측면에서 그 책을 이해하는 데 도움이 되는데, 외국 용어를 한글 용어로 바꾸는 일도 이와 유사성이 있다. 비록 최초의 선택이어서 의미를 담기에 다소 부족함이 있는 용어라도 최초 전문가의 수고를 인정하고 수용할 수만 있다면, 이후 좀 더 적합한 한글 용어가 등장할 때 일관성을 갖고 수정할 수 있겠고, 그렇게 될 수만 있다면 세월과 함께 깊이를 더해가는 발전도 기대할 수 있을 것이다.

그러나, 현실적으로, 기술 번역이란 얼굴 없는 번역이고, 전문가들의 용어 선호도 차이는 극복하기 어렵기 때문에 복수 용어의 동일 무대, 동시 등장은 불가피하다. 어떤 방식을 거쳤든지 간에 일단 등장한 용어를 퇴장시키는 일은 만만치 않다. 대다수의 여론은 자신들이 선호하는 용어만을 바라보거나, 어떤 용어를 사용하든지 결과만 만들면 된다는 쪽으로 기울기 때문에 용어의 통일은 부차적이고 중요하지도 않은 일이 되어버리는 것이다. 어떤 막강한 권력이 개입하여 강제로 하나의 손을 들어주기 전까지는 말이다.

그런데, 그것으로 문제가 끝나지는 않는다. 대다수의 실무자들은 서로 다른 용어 또는 부적절한 용어로 혼란을 겪느니 차라리 원어 쪽을 선택하기 때문이다. 그래서, 표면적으로는 한글 용어를 사용하지만, 실제로는 한글 용어를 사용하지 않는 일이 발생하는 것이다. 이러한 한글 용어에 대한 불신 또는 차별은 원어 의존성을 더욱 강화하게 되고, 그것은 또 다시 한글 용어와 번역의 불신으로 돌아오고, 그것은 필연적으로 한글 용어의 부실화와 한글 번역의 저질화라는 악순환의 고리를 형성한다.

서론이 길어졌다. 원래 용어의 선택에 주목하여 시작한 글이지만, 그렇다면 용어 선택은 그렇다 치더라도, 그 의미는 제대로 이해하고 활용하고 있는지를 베리피케이션(verification)과 밸리데이션(validation)이라는 용어와 필자의 실수 경험을 통해 생각해보기로 한다.

과거, 필자가 품질 보증 부서에 몸담고 있었을 때는 베리피케이션(verification)은 “검증”, 밸리데이션(validation)은 “확인”이라는 용어를 사용했던 것 같다. 현재, 의료기기 소프트웨어 분야에서는 베리피케이션(verification)은 “검증”으로, 밸리데이션(validation)은 “유효성확인”으로 하거나, 영어 발음 그대로 “밸리데이션”이라는 용어를 사용하기도 한다. 다른 전문 분야에서는 아마도 또 다른 한글 용어를 선택하여 사용할 것이다.

한글 용어가 서로 다르다고 해서, 베리피케이션(verification)과 밸리데이션(validation)이라는 영문 용어의 정의가 바뀐 것은 아니다. 예나 지금이나, 베리피케이션(verification)은 설계/개발 수명주기의 특정 단계에서 설계/개발 출력 결과가 해당 단계의 입력 요구사항에 적합한지를 확인하는 평가 절차이고, 밸리데이션(validation)은 최종 설계/개발 결과물이 사용자 요구사항과 사용 목적에 적합한지를 확인하는 평가 절차를 말한다. 이해를 돕기 위하여 베리피케이션(verification)은 제품을 올바르게 만들었는지(building the product right)를 확인하는 활동, 밸리데이션(validation)은 올바른 제품을 만들었는지(building the right product)를 확인하는 활동이라고 부연 소개되기도 한다.

필자는 지난 수십 년간, 이러한 정의에 따라 V&V(Verification and Validation)의 두 용어를 구분하여 사용하였고, 심지어 반드시 구분하도록 강조하기도 하였다. 실제로 과거에는 사용자 요구사항 중 몇 가지 중요 규격을 택하여 확인하는 테스트 과정을 시스템 시험이요, 밸리데이션 활동이라고 인식하고 수행에 참여하기도 하였다. 그러나, 최근에, 그 두 용어는 명확히 구분되지 않고, 동일한 활동이 베리피케이션(verification)과 밸리데이션(validation)에 동시에 포함될 수도 있다는 사실, 밸리데이션(validation)이 베리피케이션(verification)을 대리하기도 한다는 사실을 발견하고 혼란에 빠졌었다.

사실, 명확히 구분되는 적용 사례를 충분하게 많이 소개받지 못하는 상황에서 베리피케이션(verification)과 밸리데이션(validation)의 정의를 실제로 이해하는 일은 실무 담당자에게는 혼동되는 일일 것이다. 정의된 문장을 이해하지 못하는 바는 아니고, 또한 설계/개발 단계 모형을 놓고 설명하는 것도 어려운 일이 아니지만, 제3자, 특별히 규제 당국의 품질 심사원에게 실제로 이 두 활동을 구분하여 자료로써 입증하는 일은 너무나 막연한 일이다. 해당 품질 심사원이 베리피케이션(verification)과 밸리데이션(validation)의 용어 차이에 큰 의미를 두지 않는다면 큰 문제 없겠지만, 만일 필자처럼 거기에 큰 의미를 두는 사람이라면 설득하기가 만만치 않을 것이기 때문이다.

하지만, 폭포수 모형이든지 V자형 모형이든지 개발 모형을 놓고 곰곰이 생각해보면(아래 그림 참조) 모든 것이 자명해진다. 사용자 요구사항(user needs)은 설계/개발의 입력 조건이고, 베리피케이션(verification)은 중간 단계의 입력/출력 확인이며, 밸리데이션(validation)은 최종 단계의 사용자 요구사항 확인이다. 밸리데이션(validation)이 베리피케이션(verification)을 감싸는 구조이다. 화살표로 대응되는 관계에만 주목하기보다 전체 설계/개발 과정을 감싸고 있는 활동이 밸리데이션(validation)이고, 전체 설계/개발 과정 내에 포함되어 있는 활동이 베리피케이션(verification)이라는 사실에 착안한다면, 베리피케이션(verification)과 밸리데이션(validation)은 포함 관계이며, 전자가 후자에 포함되는 관계임을 확인할 수 있는 것이다.

그래서, 알고 나면 허무하지만, 왜 어떤 경우 동일한 시험처럼 보이는 것이 베리피케이션(verification)에 포함되기도 하고 밸리데이션(validation)에도 포함되기도 하는지, 베리피케이션(verification)처럼 보이는데 왜 어떤 경우에는 그것을 밸리데이션(validation)이라고 말하는지를 이해할 수 있게 된다. 그것은 바로, 밸리데이션(validation)이란, 마지막 단계에서 사용자 요구사항의 충족 여부를 확인하는 활동에 한정되는 것이 아니라 사용자 요구사항으로부터 비롯된 설계/개발 과정 전체를 포괄하는, 좀 더 큰 범위의 활동이 밸리데이션(validation) 활동이기 때문인 것이다.

 

 

 

 

 

 

 

 

 

(그림) FDA의 설계/개발 모형

2020년 2월 11일 최종 갱신

의료기기 소프트웨어 국제표준(IEC 62304:2006+AMD1:2015) 용어

의료기기 소프트웨어 국제표준(IEC 62304:2006+AMD1:2015) 용어 

아래 내용은 번역 중인 의료기기 소프트웨어 수명주기 프로세스에 관한 국제표준(IEC 62304:2006+AMD1:2015 CSV) 중 용어 부분입니다.

빨강색 글자체가 2015년 추가보충(추보)판에서 수정된 부분입니다. 읽는 방법을 예시하면 다음과 같습니다.

의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCTS)” 부분을 예로 들겠습니다. 이 부분은, 2006년 초판(ED1)의 “소프트웨어 제품(SOFTWARE PRODUCT)”이 2015년 추보(AMD1)에서 “의료기기 소프트웨어(MEDICAL DEVICE SOFTWARE)”로 바뀌었음을 뜻합니다. 즉, 빨강색 글자체 중 가운뎃줄 취소선 부분이 삭제된 곳임을 나타냅니다.  

아울러, 참고(주석) 표시와 그에 대응되는 초록색 주석 부분은 번역자(본인)가 임의로 추가한 주석입니다.

****************************************************************

3. 용어 정의

이 표준에서는 다음의 용어와 정의를 적용한다.

3.1 활동(ACTIVITY)
상호 연관된 또는 상호 작용하는 하나 이상의 단위업무

3.2 이상(ANOMALY)
요구사항 명세서(requirements specifications)1), 설계 문서, 표준 등에 기반하는 예상과 기대로부터 벗어나는 또는 기존의 인식이나 경험으로부터 벗어나는 상태. 이상(ANOMALIES)이란 의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCTS) 또는 관련 문건의 검토, 시험, 분석, 컴파일, 사용 중 발견할 수 있지만, 그것들에만 국한되지는 않는다.

비고  [IEEE 1044:1993, 정의 3.1]에 근거함.

3.3 아키텍처(ARCHITECTURE)
시스템(SYSTEM) 또는 구성요소의 조직 구조

[IEEE 610.12:1990]

3.4 변경 요구(CHANGE REQUEST)
의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCT)에 이루어져야 하는 변경을 문서화한 명세서 

3.5 형상 항목(CONFIGURATION ITEM)
주어진 기준점(reference point)에서 고유하게 식별할 수 있는 개체(entity)2)

비고  ISO/IEC 12207:1995 2008, 정의 3.6 4.7에 근거함.

3.6 산출물(DELIVERABLE)
활동(ACTIVITY) 또는 단위업무(TASK)의 요구된 결과 또는 출력(문서를 포함)


3.7 평가(EVALUATION)
대상으로 하는 개체가 규정한 기준을 만족하고 있음을 체계적으로 결정하는 행위

[ISO/IEC 12207:1995 2008, 정의 3.9 4.12]

3.8 위해(HARM)
사람과 건강에 미치는 신체적 상해, 장애 또는 재산이나 환경에 대한 피해

[ISO/IEC 가이드 51:1999, 정의 3.3 ISO 14971:2007, 정의 2.2]

3.9 위해요인(HAZARD)
위해(HARM)의 잠재적 원천

[ISO/IEC 가이드 51:1999, 정의 3.5 ISO 14971:2007, 정의 2.3]

3.10 제조자(MANUFACTURER)
의료기기(MEDICAL DEVICE)의 설계, 제조, 포장 또는 표시기재사항(labelling)을 책임지고, 하나의 시스템(SYSTEM)으로 조립하고, 또한 의료기기(MEDICAL DEVICE)를 출시 및/또는 서비스하기에 적합하게끔 만드는 역할을 그 자신이 직접 수행할 수도 있고 제3자로 하여금 대리 수행하도록 할 수도 있는 자연인 또는 법인

비고1  제조자에 관한 용어 정의는 국가 또는 지역별 관련 규정 조항들이 적용될 수 있다는 사실에 유의한다.3)

비고2  표시기재사항(labelling)의 용어 정의는 ISO 13485:2003, 3.6 참조.4)

[ISO 14971:2000 2007, 정의 2.6 2.8]

3.11 의료기기(MEDICAL DEVICE)
계기, 장치, 용구, 기계, 기구, 임플란트, 체외진단시약이나 표준물질, 소프트웨어, 소재 물질 또는 이와 유사하거나 연관된 여타의 완제품 등으로서 제조자(MANUFACTURER)가 아래에 제시한 한 가지 이상의 목적으로 사람에게 단독으로 또는 조합하여 사용하고자 하는 것
– 질병을 진단, 예방, 감시, 치료 또는 완화
– 부상을 진단, 감시, 치료, 완화 또는 보조
– 해부학적 또는 생리학적 프로세스(PROCESS)를 조사, 대체, 수복, 지원
– 생명을 지원 또는 유지
– 수태 조절
– 의료기기(MEDICAL DEVICE) 멸균
– 인체에서 채취한 검체를 체외 검사하여 의학적 목적으로 정보를 제공
그리고 인체 내에 또는 인체 상에 의도하는 주된 행위가 약리학적, 면역학적 또는 대사적 수단에 의하여 달성되지 않는 것으로서, 다만 그러한 수단으로 기능 실현을 보조할 수는 있는 것

비고1  이 정의는 의료기기관리제도국제조화위원회(GHTF: Global Harmonization Task Force)에서 개발하였다. 참조할 곳은 (ISO 13485:2003의) 참고문헌 [15].5)

[ISO 13485:2003, 정의 3.7]

비고2  각국 규정에서 사용되는 정의에는 차이가 있을 수 있다. 

비고3  IEC 60601-1:2005 및 IEC 60601-1:2005/AMD1:2012 표준과 관련, 여기에서의 “의료기기(medical device)” 용어는 (IEC 60601-1에 용어 정의된) ME 기기(EQUIPMENT) 또는 ME 시스템(SYSTEM)과 동일한 의미라고 가정한다.

3.12 의료기기 소프트웨어(MEDICAL DEVICE SOFTWARE)
개발 중인 의료기기(MEDICAL DEVICE)에 포함할 목적으로 개발하거나, 그 자체로 의료기기(MEDICAL DEVICE)로서 사용하고자 하는 소프트웨어 시스템(SOFTWARE SYSTEM)

비고  여기에는 그 자체로 의료기기(MEDICAL DEVICE)인 의료기기 소프트웨어 제품(MEDICAL DEVICE software product)을 포함한다.

3.13 문제(점) 보고(서)(PROBLEM REPORT)
사용자 또는 기타 관련자가 안전하지 않다고 믿거나, 의도한 용도(intended use)에 부적합하다든지 또는 명세(서)(specification)에 반한다고 믿는 의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCT)의 실제 또는 잠재적 동작특성에 관한 기록

비고1  이 표준은 모든 문제(점) 보고(서)에 대하여 의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCT)을 변경하도록 요구하지는 않는다. 제조자는 문제(점) 보고(서)를 오해, 오류, 경미한 사안으로 간주하여 거부할 수도 있다.

비고2  문제(점) 보고(서)는 이미 배포한 의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCT) 또는 현재 개발 중인 의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCT)에 적용 가능하다.

비고3  이 표준은 이미 배포된 제품과 관련된 문제(점) 보고(서)의 규제 사항에 대응하는 조치들을 확실하게 정하고 시행할 수 있도록 제조자로 하여금 가외의 의사결정 절차(6절 참조)를 수행할 것을 요구한다.

3.14 프로세스(PROCESS)
입력 요소를 출력 요소로 변환하는 상호 관계된 또는 상호 작용하는 활동(ACTIVITIES) 

[ISO 9000:2000, 정의 3.4.1]

비고  “활동(ACTIVITIES)”이란 용어는 자원의 이용도 포함한다.

3.15 회귀 시험(REGRESSION TESTING)
시스템 구성요소의 변경이 기능, 신뢰성, 성능에 악영향을 미치지 않고, 추가적인 결함을 초래하지 않는지를 판단하는 데 필요한 시험

[ISO/IEC 90003:2004, 정의 3.11] 

3.16 위험(RISK)
위해(HARM)의 심각성과 위해(HARM)의 발생 확률의 조합

[ISO/IEC 가이드 51:1999, 정의 3.2 ISO 14971:2007, 정의 2.16]

3.17 위험 분석(RISK ANALYSIS)
가용 정보를 체계적으로 활용하여 위해요인(HAZARDS)을 식별하고, 위험(RISK)을 추정하는 활동

[ISO/IEC 가이드 51:1999, 정의 3.10 ISO 14971:2007, 정의 2.17]

3.18 위험 통제(RISK CONTROL)
위험(RISKS)을 규정된 수준 이하로 저감하거나 또는 규정된 수준 이내로 유지하는 의사결정을 하고 관련조치를 실시하는 프로세스(PROCESS)6)

[ISO 14971:2000 2007, 2.16을 수정 2.19]

3.19 위험 관리(RISK MANAGEMENT)
위험(RISK)을 분석, 평가, 통제하는 단위업무(TASKS)에 대하여 관리 방침, 관리 절차, 관리 방법을 체계적으로 적용하는 활동

[ISO 14971:2000 2007, 2.18 2.22를 수정 – 원문에서 “감시(monitoring)”를 삭제]

3.20 위험 관리 파일(RISK MANAGEMENT FILE)
위험 관리 프로세스(RISK MANAGEMENT PROCESS)에 의해 작성되는 기록 및 문서로서 물리적으로 연속성이 있을 필요는 없음

[ISO 14971:2000 2007, 2.19 2.23]

3.21 안전(SAFETY)
허용불가 위험(RISK)이 없는 상태

[ISO/IEC 가이드 51:1999, 정의 3.1 ISO 14971:2007, 정의 2.24]

3.22 보안(SECURITY)
권한 없는 자 또는 권한 없는 시스템(SYSTEMS)이 정보 및 데이터를 읽거나 변경하지 못하게 보호하고, 권한 있는 자 또는 권한 있는 시스템(SYSTEMS)이 정보 및 데이터에 접근이 거부되지 않게 보호하는 활동 

비고  [ISO/IEC 12207:1995 2008, 3.25 4.39]

3.23 중상(SERIOUS INJURY)
직접적으로 또는 간접적으로 다음 결과를 야기하는 부상 또는 질병
a) 생명을 위협하는 부상 또는 질병
b) 신체 기능 또는 신체 구조에 대한 영구적인 손상 또는 장애를 유발하는 부상 또는 질병
c) 신체 기능 또는 신체 구조에 대한 영구적인 손상 또는 장애를 예방하기 위하여 내과적 또는 외과적 처치를 필요로 하는 부상 또는 질병

비고  영구적인 손상이란 신체 구조 또는 기능에 대하여 돌이킬 수 없는 손상 또는 장애를 말하며 경미한 손상 또는 장애는 제외한다. 

3.24 소프트웨어 개발 수명주기 모델(SOFTWARE DEVELOPMENT LIFE CYCLE MODEL)
요구사항의 정의 단계부터 양산을 위한 배포에 이르기까지 소프트웨어의 수명 전체를 나타내는 개념적 구조(conceptual structure)로서 다음 내용이 포함된다.
의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCT) 개발에 포함되는 프로세스(PROCESS), 활동(ACTIVITIES), 단위업무(TASKS)를 명확화한다.
– 활동(ACTIVITIES) 및 단위업무(TASKS) 사이의 순서와 상호의존성을 설명한다.
– 규정한 산출물(DELIVERABLES)들의 완성이 검증되는 일정을 명확화한다.

비고  ISO/IEC 12207:1995, 정의 3.11에 근거함

3.25 소프트웨어 항목(SOFTWARE ITEM)
원시 코드(source code), 목적 코드(object code), 제어 코드(control code), 제어 데이터(control data), 또는 이들의 집합과 같이 컴퓨터 프로그램에서 식별 가능한 부분

비고1  세 가지 용어를 사용하여 소프트웨어 구조를 분할한다. 최상위 수준은 소프트웨어 시스템(SOFTWARE SYSTEM)이다. 더 이상 분할할 수 없는 최하위 수준은 소프트웨어 유닛(SOFTWARE UNIT)이다. 최상위 및 최하위 수준을 포함하는 모든 수준의 구성 요소는 소프트웨어 항목(SOFTWARE ITEM)이라고 할 수 있다. 하나의 소프트웨어 시스템(SOFTWARE SYSTEM)은 하나 이상의 소프트웨어 항목(SOFTWARE ITEM)으로 구성되고, 각 소프트웨어 항목(SOFTWARE ITEM)은 하나 이상의 소프트웨어 유닛(SOFTWARE UNIT) 또는 분할 가능한 소프트웨어 항목(SOFTWARE ITEM)으로 구성된다. 소프트웨어 항목(SOFTWARE ITEM) 및 소프트웨어 유닛(SOFTWARE UNIT)에 관한 정의와 입도(粒度, granularity) 정보를 제공할 책임은 제조자(MANUFACTURER)가 부담한다.

비고2  [ISO/IEC 9003:2004, 정의 3.14, 수정] 및 ISO/IEC 12207:2008에 근거함

3.26 소프트웨어 제품(SOFTWARE PRODUCT)
컴퓨터 프로그램, 절차, 및 연관된 문건 및 데이터

[ISO/IEC 12207:1995 정의 3.26]

사용하지 않음 

3.27 소프트웨어 시스템(SOFTWARE SYSTEM)
특정한 기능 또는 일련의 복수 기능을 달성하기 위하여 조직된 소프트웨어 항목(SOFTWARE ITEMS)을 통합한 집합체

3.28 소프트웨어 유닛(SOFTWARE UNIT)
다른 항목으로 분할되지 않는 소프트웨어 항목(SOFTWARE ITEM)

비고  소프트웨어 유닛은 소프트웨어 형상 관리 또는 시험 목적으로 사용 가능하다. 소프트웨어 유닛의 입도는 제조자가 정의한다(B.3 참조).

3.29 개발과정 미상 소프트웨어
SOUP
(“software of unknown provenance”의 두문자)
이미 개발되어 일반적으로 사용 가능하지만, 해당 의료기기(MEDICAL DEVICE)에 포함할 목적으로 개발되지는 않은 소프트웨어 항목(SOFTWARE ITEM)(“시판용 소프트웨어(off-the-shelf software)”라고도 함) 또는 이전에 개발되어 개발 프로세스에 관한 적절한 기록이 남아있지 않은 소프트웨어 항목(SOFTWARE ITEM)

비고  의료기기 소프트웨어 시스템 자체를 SOUP라고 주장할 수는 없다.

3.30 시스템(SYSTEM)
하나 이상의 프로세스, 하드웨어, 소프트웨어, 설비, 및 사람으로 구성된 통합체로서 규정된 요구(need) 또는 목표를 충족할 수 있는 능력을 제공한다.

비고  [ISO/IEC 12207:1995 2008, 정의 3.31 4.48]에 근거함.

3.31 단위업무(TASK)
수행할 필요가 있는 단일 작업

3.32 추적성(TRACEABILITY)
개발 프로세스 중의 두 개 이상의 성과물(products) 사이에 성립할 수 있는 관계성의 정도

[IEEE 610.12:1990]

비고  요구사항, 아키텍처, 위험 통제 조치 등은 개발 프로세스(development PROCESS) 산출물(deliverables)의 예.

3.33 검증(VERIFICATION)
객관적 증거의 제공을 통하여 규정된 요구사항이 만족되었음을 확인하는 것

비고1  “검증된(Verified)”라는 용어는 위에 대응하는 상태를 가리킬 때 사용함.

[ISO 9000:2000, 정의 3.8.4]

비고2  설계 및 개발에서 검증(VERIFICATION)은 주어진 활동(ACTIVITY)에 대하여 규정되는 요구사항과의 적합성을 판단하기 위하여 해당 활동(ACTIVITY) 결과를 검사하는 프로세스(PROCESS)이다.

3.34 버전(VERSION)
특정 시점에 식별한 형상 항목(CONFIGURATION ITEM) 

비고1  의료기기 소프트웨어 제품(MEDICAL DEVICE SOFTWARE PRODUCT)의 버전(VERSION)이 수정되어 새로운 버전(VERSION)이 되는 경우, 소프트웨어 형상 관리 조치가 필요하다.

비고2  ISO/IEC 12207:1995 2008, 3.37 4.56에 근거함.

3.35 위해 상황(HAZARDOUS SITUATION)
사람, 재산 또는 환경이 하나 이상의 위해요인(HAZARD(S))에 노출되는 상황

[출처: ISO 14971:2007, 2.4]

3.36 레거시 소프트웨어(LEGACY SOFTWARE)
합법 출시된 의료기기 소프트웨어(MEDICAL DEVICE SOFTWARE)로서 지금도 유통되고는 있지만 이 표준의 현재 버전에 적합하게 개발되었다는 객관적 증거는 불충분한 소프트웨어

3.37 릴리스(RELEASE)7)
규정된 목적에 사용할 수 있는 특정 버전(particular VERSION)의 형상 항목(CONFIGURATION ITEM) 

비고  ISO/IEC 12207:2008, 정의 4.35에 근거함.

3.38 잔여 위험(RESIDUAL RISK)
위험 통제 조치(RISK CONTROL measures)를 취한 이후에도 남아있는 위험(RISK)

비고1  ISO/IEC 가이드 51:1999, 정의 3.9를 각색함.

비고2  ISO/IEC 가이드 51:1999, 정의 3.9는 “위험 통제 조치(RISK CONTROL measures)” 대신에 “보호 조치(protective measures)”라는 용어가 사용됨. 그러나, 이 국제표준의 문맥에서 보면, “보호 조치”는 [ISO 14971:2007]의 6.2에 규정했듯이 위험(RISK)을 통제하는 하나의 선택지에 불과함.

[출처: ISO 14971:2007, 2.15]

3.39 위험 추정(RISK ESTIMATION)
위해(HARM)의 발생 확률과 위해(HARM)의 심각도에 값(values)을 부여하는 데 사용하는 프로세스(PROCESS)

[출처: ISO 14971:2007, 2.20]

3.40 위험 평가(RISK EVALUATION)
추정한 위험(RISK)을 주어진 위험 판정기준(RISK criteria)과 비교하여 위험(RISK)의 수용(acceptability) 여부를 결정하는 프로세스(PROCESS)

[출처: ISO 14971:2007, 2.21]


<< 역주 >>

1) 역주: 소프트웨어 공학에서는 “specification”이라는 용어를 주로 “명세(서)”로 풀이하므로 여기에서는 대체로 “명세(서)”로 풀이하였다. 다른 분야에서는 “규격(서)”, “시방(서)”, “사양(서)” 등으로 풀이하는 사례가 많은데 “사양(서)”는 일본식 용어이므로 여기에서는 사용하지 않는다.

2) 역주: ISO/IEC 12207:2008의 정의에는 “개체” 부분이 “그리고 최종 사용 기능을 만족하는 형상 내의 개체(entity within a configuration that satisfies an end use function and)”로 풀이되어 있음.

3) 역주: 우리나라 규정(의료기기법)은 정의된 내용 없이 “의료기기취급자” 중 하나로서 “의료기기 제조업자”라는 용어를 사용하고, GMP 고시 규정에서도 “제조자”는 “제조의뢰자로부터 어떤 제품의 제조공정 전부를 수탁한 자”로만 사용하는 등 의료기기법 관리 대상으로서의 상대적 관계만 정의할 뿐, “제조자” 자체의 범위와 한계를 밝힌 정의는 사용하지 않고 있다.

4) 역주: ISO 13485:2016 개정판에는 3.8에 정의되어 있고, ISO 13485:2003 3.6에는 ‘labeling’으로 표기하였으나, ISO 13485:2016 개정판에서는 ‘labelling’으로 표기하였으며, 용어 정의 문장도 GHTF/SG1/N70:2011, Clause 4를 인용하여 수정됨.

5) 역주: ISO 13485:2003 표준의 [15]번 참고문헌은 “의료기기 용어 정의(Definition of the Term ”Medical Device”)”라는 제목의 2002년 2월 2일자 GHTF SG1 N029R11 문서를 가리키며, 이 문서 자체의 최종본은 2005년 5월 20일자 GHTF SG1 N29R16:2005 문서이고, 이 문서의 개정 최종판은 “의료기기 및 체외진단 의료기기 용어 정의(Definition of Terms “Medical Device” and “In Vitro Diagnostic Medical Device”)”라는 제목의 2012년 5월 16일자 GHTF SG1 N071:2012 문서임.

6) 역주: ISO 14971:2007 2.19를 인용하였다고는 했지만, 영문 원문에 실린 “그리고 관련조치를 실시하는” 부분이 누락되어 있으므로 이를 바로 잡음. 

7) 역주: 정의만으로는 혼동될 수 있으므로, 소프트웨어(프로그램)의 상태를 통상적으로 구분하면 다음과 같다. 버전(version)이란 한 프로그램의 성능과 개발/출시/발매 시기를 구분하는 수단으로서 출시 이전부터 이후까지 모두 포함할 수 있으며, 통상 점차 증가하는 숫자를 이용하여 버전 번호(version number)로 표시한다. 우리말로는 ‘판’에 해당한다. 빌드(build)란 통상 출시/발매하기 전 개발 중인 프로그램 상태를 구분하는 수단으로서 버전 번호와 동일하게 할 수도 있지만, 통상 빌드 번호(build number)를 부여하여 관리한다. 릴리스(release)란 통상 개발된 프로그램의 출시/발매 이후 버전을 가리킨다. 버전과 동일하게 할 수도 있지만, 동일 버전에 대한 수정 보완인 경우에는 그러한 사실이 구분되도록 표시하기도 한다.

 

미국, 21세기 치료법(21st Century Cures Act) 통과

미국, 21세기 치료법(21st Century Cures Act) 통과

과학기술의 혁신과 발전의 결실이 질병 치료로 신속하게 이어지도록 하자는 이른바 “21세기 치료법(21st Century Cures Act)”이, 지난 2015년 5월 발의된 이래,  여러 논의 과정 및  미국 의회의 표결을 거쳐,  지난 2016년 12월 13일, 오바마 미국 대통령이 법안에 서명함으로써 통과되었습니다.

마약성 진통제 남용 개선, 치매와 같은 정신 질환에 대한 서비스 개선, 미국 국립보건원이나 미국 식품의약품처 제도 개선 등을 담고 있는 이 법안에서 의료기기 분야와 관련하여 특기할 사항은 다음과 같습니다.

– “융/복합 제품(combination products)” 제도 개선
– 임상 시험 시 “공동(centralized)” 임상시험심사위원회(IRB: Institutional Review Board) 사용 허용
– “혁신(breakthrough)” 의료기기(여기에는 기허가 의료기기에 비해 월등한 우위를 가진 제품도 포함)를 위한 “우선 심사(priority review)” 제도
– 희소 의료기기(HUD: Humanitarian Use Device) 적용이 가능한 희귀질환자 기준을 현행 4000명에서 8000명으로 상향 조정
– I등급, II등급 의료기기 중 510(k) 면제(exemption) 범위 확대
– 의료기기 소프트웨어(medical device software)에 해당되지 않는 다섯 가지 범주(A, B, C, D, E)의 소프트웨어를 규정

그러나, 무작정 환영만 할 수는 없는 이유는, 진입 장벽이 높던 지난 날의 허가를 통과한 의료기기 중에서도 오랜 시간이 지난 후에야 허가 과정 중의 안전성/유효성 증거가 충분하지 않았음이 뒤늦게 드러나는 경우가 왕왕 있었기 때문에, 자칫 최소 요건만 갖춘 제품들의 시장 진입으로 말미암아 사람들의 건강권과 생명권이 훼손된다면, 의료기기의 안전성/유효성에 관한 일반 대중의 불신, 더 나아가 관련 산업계, 의료계에 대한 불신도 증가하게 될 것이기 때문입니다.

관련 동영상