의료기기 소프트웨어 국제표준(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)란 통상 개발된 프로그램의 출시/발매 이후 버전을 가리킨다. 버전과 동일하게 할 수도 있지만, 동일 버전에 대한 수정 보완인 경우에는 그러한 사실이 구분되도록 표시하기도 한다.

 

Comments are closed.