KR20190113446A - 의료기기 소프트웨어 인허가를 위한 의료기기 소프트웨어 개발 표준 통합 프로세스 시각화 방법 및 그 장치 - Google Patents

Abstract

본 발명의 일 실시예에 따른 의료기기 소프트웨어 인허가를 위한 의료기기 소프트웨어 개발 표준 통합 프로세스 시각화 방법은, 사용자로부터 통합프로세스 순서정보, 요구사항정보 및 요구사항 속성을 입력받는 단계, 통합 프로세스의 관점에서 표준 내용이 저장된 데이터베이스에서 상기 입력된 정보에 대응하는 통합 프로세스 내용을 검색하는 단계, 상기 검색된 통합 프로세스 내용을 디스플레이 출력부를 통해 시각화하는 단계를 포함하되, 상기 요구사항정보는 표준정보 및 프로세스 정보를 포함하고, 상기 요구사항 속성은 필수여부, 문서화여부 및 안전등급을 포함한다.

Description

의료기기 소프트웨어 인허가를 위한 의료기기 소프트웨어 개발 표준 통합 프로세스 시각화 방법 및 그 장치{Method and Apparatus for visualizing an integrated process between medical software development standards for medical software licensing}

본 발명은 의료기기 소프트웨어 인허가를 위한 의료기기 소프트웨어 개발 표준 통합 프로세스 시각화 방법 및 그 장치에 관한 것이다.

의료기기는 다른 전자기기와 달리 사용자의 안전과 생명에 직결되는 특성을 가지고 있다. 이와 같은 특성 때문에, 일부 연구에서는 의료기기의 낮은 고장률에 대한 중요성을 제기하며 의료기기 위험관리의 필요성을 주장하고 있다.

최근에는 의료기기의 동작을 제어하는 방식이 기계식에서 전자식으로 바뀌면서 의료기기의 중요한 기능들을 소프트웨어가 수행하고 있다. 이에 맞추어, 소프트웨어로 인한 의료사고를 방지하기 위해 의료기기 소프트웨어 위험관리에 대한 중요성은 더욱 높아지고 있다.

한편, 식약처는 ‘전자의료기기에 대한 국제 표준, IEC 60601-1’을 기준으로 의료기기 소프트웨어 인허가를 수행하고 있다. 그러나, 국내 다수의 영세한 의료기기 제조업체는 국제 표준이 요구하는 높은 수준의 개발 활동을 준수하지 못하거나 이를 입증할 기록문서를 작성하지 못하여, 고가의 컨설팅 업체를 통해 인허가 절차를 수행하고 있다.

의료기기 소프트웨어 인허가에 관련된 주요 표준으로는 ‘전자의료기기에 대한 규격, IEC 60601-1’, ‘의료기기 소프트웨어 생명주기 프로세스에 대한 규격, IEC 62304’, ‘의료기기 위험관리에 대한 규격, ISO 14971’이 있다. 세 표준은 서로의 내용을 참조하는 형태로 구성되며, 도 1과 같이 의료기기 위험관리를 위한 표준들의 역할과 관계를 갖는다. IEC 60606-1는 소프트웨어가 포함된 모든 전자의료기기에 대한 규격, 시스템 수준에서의 규격으로, 소프트웨어에 대한 구체적인 요구사항은 IEC 62304를 참조하여 수행하도록 명시한다. IEC 62304는 의료기기 소프트웨어의 생명주기에 대한 규격, 소프트웨어 수준에서의 규격이다. ISO 14971는 의료기기에 대한 위험관리를 위한 규격이다. IEC 60601-1과 IEC 62304는 구체적인 위험관리 활동을 ISO 14971을 참조하여 수행하도록 명시한다. 세 표준은 의료기기 소프트웨어의 위험관리를 위해 각각의 목적에 부합하는 활동을 요구하는 것뿐만 아니라, 개발중에 같이 고려되어 수행해야 하는 관계로 맺어져있다. 결론적으로, 인허가의 기준이 되는 IEC 60601-1 표준이 갖는 관계로 인하여, 제조업체는 의료기기 소프트웨어의 인허가를 위하여 세 국제 표준을 모두 준수해야 한다.

이와 같이 의료기기 위험관리를 위한 표준이 다양해지고 서로가 상호의존적인 관계를 갖음으로써, 의료기기 개발자들은 더 많은 요구사항과 이를 입증할 광범위한 문서들을 고려해야한다. 그러나 표준들은 각 프로세스의 개별적인 목적에 부합하는 요구사항을 제시할 뿐, 개발 프로세스의 진행 중에 위험관리 프로세스를 동시에 진행할 수 있도록 보조하는 통합 프로세스가 부재하다. 이로 인해, 개발자들은 소프트웨어 개발 중에 직접 표준들의 연관성을 분석하여 위험관리를 수행하는 어려움을 겪고 있다. 즉, 주요 표준 간의 참조관계를 추상적으로 명시할 뿐, 구체적인 참조 방안은 제시하지 않고, 주요 표준의 내용을 하나의 Framework으로 통합하는 시도는 존재하나, 개발 관점에서 정의되지 않아 개발 진행에 따라 표준 준수가 어려운 문제가 있다.

또한, 의료기기 소프트웨어 인허가를 위한 주요 첨부자료 작성방안에 대한 가이드라인이 제공되고 있다. 예컨대, “의료기기 소프트웨어 허가·심사 가이드라인”이 의료기기심사부, 식약처에서 제공하고 있다. 하지만 표준이 제시하는 개발 프로세스 및 기타 관련 프로세스에 대한 실제 적용 방안이 없고, 이에 따라 제조업체는 개발이 진행됨에 따라 표준을 준수하고 산출물을 작성해내기 어려운 문제가 있다.

또한, IEC에서 ‘IEC 60601-1’의 ‘ISO 14971’적용 방안을 보조하기 위한 운용 규정 문서를 제공하여, 두 표준 간의 참조 관계에 대한 연관성 표를 제시하고 있으나, 개발프로세스 관점에서 정의되지 않고, ‘IEC 62304’의 내용이 없으므로 소프트웨어 개발에 대한 구체적인 보조가 불가능한 문제가 있다.

또한, 의료기기 소프트웨어 개발 관련 표준들의 프로세스와 이하 요소들을 MDevSPICE 모델로 통합하고, 제조업체의 의료기기 소프트웨어 개발 산출물이 MDevSPICE 의 요구사항 내용에 부합하는지 평가하고 있다. 그러나, 개발을 보조하는 관점이 아닌, 개발 이후에 평가하는 관점으로 정의된 모델이어서, 개발프로세스를 따라 표준을 준수하도록 보조할 수 없다.

살핀 바와 같이, 현재 의료기기 소프트웨어는 안전성과 성능이 보장되어야하는 필요성이 증가되어, 국내를 포함한 다수의 국가에서는 국제 표준(IEC 60601-1, 전자의료기기 안전규격)을 기준으로 의료기기 소프트웨어의 인허가 절차를 진행한다. 이때 ‘IEC 60601-1’은 의료기기 소프트웨어의 구체적인 개발 규격으로 ‘IEC 62304’를 참조하고, 구제척인 위험관리 활동을 위해 ‘ISO 14971’을 참조하여 표준을 준수할 것을 명시한다. 따라서 제조업체는 의료기기 소프트웨어의 인허가를 위해 세 주요 표준을 준수하며 개발을 수행해야 한다.

이에, 주요 표준의 내용이 개발 관점에서 단일한 프로세스로 재구성된 통합 프로세스가 필요하다.

본 발명이 해결하고자 하는 기술적 과제는 의료기기 소프트웨어 관련 표준을 제시하는 프로세스를 개발자 관점의 프로세스로 통합하는 통합 프로세서를 제공하는 것이다.

본 발명이 해결하고자 하는 다른 기술적 과제는 통합 프로세스의 진행 순서(10개의 Phase)에 따라 사용자가 각 순서의 요구사항 볼 수 있도록 시각화를 수행하는 것이다.

본 발명이 해결하고자 하는 다른 기술적 과제는 통합 프로세스의 진행 순서(10개의 Phase)에 따라 사용자가 각 순서의 요구사항 볼 수 있도록 시각화를 수행하는 것이다.

본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.

상기 기술적 과제를 해결하기 위한 본 발명의 일 실시예에 따른 의료기기 소프트웨어 인허가를 위한 의료기기 소프트웨어 개발 표준 통합 프로세스 시각화 방법은, 사용자로부터 통합프로세스 순서정보, 요구사항정보 및 요구사항 속성을 입력받는 단계, 통합 프로세스의 관점에서 표준 내용이 저장된 데이터베이스에서 상기 입력된 정보에 대응하는 통합 프로세스 내용을 검색하는 단계, 상기 검색된 통합 프로세스 내용을 디스플레이 출력부를 통해 시각화하는 단계를 포함하되, 상기 요구사항정보는 표준정보 및 프로세스 정보를 포함하고, 상기 요구사항 속성은 필수여부, 문서화 여부 및 안전등급을 포함한다.

본 발명에 따르면, 의료기기 소프트웨어 관련 표준의 내용이 단일한 프로세스로 재구성된 통합 프로세스를 정의함으로써, 제조업체는 통합 프로세스를 통해 개발 중 표준 간의 연관성을 분석할 필요 없이 모든 표준 내용을 준수할 수 있다. 또한, 제조업체는‘통합프로세스’정보를 통해 의료기기 소프트웨어의 개발 절차에 따라 모든 주요 표준의 내용을 준수하도록 보조받을 수 있다.

또한, 통합 프로세스의 진행 순서에 따라 사용자가 각 순서의 요구사항 볼 수 있도록 시각화함으로써, 통합프로세스를 사용할 때, 기존 주요 표준 시스템의 관점에서 다양하게 통합프로세스 정보를 파악할 수 있고, 요구사항의 속성에 따라서도 다양하게 통합프로세스 정보를 제공받을 수 있다.

또한, 본 발명을 통해 제조업체는 개발과 동시에 표준의 모든 내용을 준수 가능하며, 개발의 순서에 맞추어 해당하는 표준의 내용을 시각화로 제공받을 수 있다.

또한, 본 발명을 통해 의료기기 소프트웨어 제조업체는 통합프로세스의 각 Phase 및 이하 요소들을 시각적으로 제공받을 수 있고, 요구사항을 정보와 속성을 지정하여, 선택적으로 시각화할 수 있으며, 통합프로세스 및 기타 요소를 기준으로 하는 개발 진행도를 제공받을 수 있다.

본 발명의 효과들은 이상에서 언급한 효과들로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 아래의 기재로부터 통상의 기술자에게 명확하게 이해될 수 있을 것이다.

도 1은 의료기기 위험관리를 위한 표준 관계를 설명하기 위한 도면이다.
도 2 및 도 3은 의료기기 소프트웨어 인허가를 위한 주요 표준의 구성을 설명하기 위한 도면이다.
도 4는 PESS(Programmable Electronic Sub System) 기반 PEMS(Programmable Electrical Medical System) 개발주기 V-모델을 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 개발 프로세스에 대한 개발관련 프로세스들과의 연관성 분석을 설명하기 위한 도면이다.
도 6a 내지 도 6c는 본 발명의 일 실시예에 따른 개발 프로세스 기준 활동(Activity) 수준에서의 연관성 분석결과를 나타낸 도면이다.
도 7은 본 발명의 일 실시예에 따른 개발 프로세스 기준 연관성 분석 결과를 설명하기 위한 도면이다.
도 8은 본 발명의 일 실시예에 따른 통합 프로세스를 정의하기 위한 도면이다.
도 9는 본 발명의 일 실시예에 따른 통합프로세스의 각 Phase에 Requirement 및 Activity를 정의한 도면이다.
도 10은 본 발명의 일 실시예에 따른 통합프로세스를 시각화한 예시도이다.
도 11은 본 발명의 일 실시예에 따른 Zoom in-out을 통해 통합 프로세스를 선택적으로 시각화한 예시도이다.
도 12는 본 발명의 일 실시예에 따른 의료기기 소프트웨어 표준 통합 프로세스 시각화 제공 방법을 설명하기 위한 순서도이다.
도 13은 본 발명의 일 실시예에 따른 개발순서 선택 화면 예시도이다.
도 14는 본 발명의 일 실시예에 따른 표준선택 화면 예시도이다.
도 15는 본 발명의 일 실시예에 따른 프로세스 선택 화면 예시도이다.
도 16은 본 발명의 일 실시예에 따른 요구사항 속성 선택 화면 예시도이다.
도 17은 본 발명의 일 실시예에 따른 검색 결과 출력 화면의 예시도이다.
도 18은 본 발명의 일 실시예에 따른 기록문서 작성 화면의 예시도이다.
도 19는 본 발명의 일 실시예에 따른 의료기기 소프트웨어 표준 통합 프로세스 시각화를 위한 장치를 설명하기 위한 도면이다.

본 발명은 다양한 변경을 가할 수 있고 여러 가지 실시예를 가질 수 있는 바, 특정 실시예들을 도면에 예시하고 상세한 설명에 상세하게 설명하고자 한다. 그러나, 이는 본 발명을 특정한 실시 형태에 대해 한정하려는 것이 아니며, 본 발명의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다. 각 도면을 설명하면서 유사한 참조부호를 유사한 구성요소에 대해 사용하였다.

제1, 제2, A, B 등의 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되어서는 안 된다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다. 예를 들어, 본 발명의 권리 범위를 벗어나지 않으면서 제1 구성요소는 제2 구성요소로 명명될 수 있고, 유사하게 제2 구성요소도 제1 구성요소로 명명될 수 있다. 및/또는 이라는 용어는 복수의 관련된 기재된 항목들의 조합 또는 복수의 관련된 기재된 항목들 중의 어느 항목을 포함한다.

어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.

본 출원에서 사용한 용어는 단지 특정한 실시예를 설명하기 위해 사용된 것으로, 본 발명을 한정하려는 의도가 아니다. 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

다르게 정의되지 않는 한, 기술적이거나 과학적인 용어를 포함해서 여기서 사용되는 모든 용어들은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 가지고 있다. 일반적으로 사용되는 사전에 정의되어 있는 것과 같은 용어들은 관련 기술의 문맥 상 가지는 의미와 일치하는 의미를 가지는 것으로 해석되어야 하며, 본 출원에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.

의료기기 소프트웨어는 안전성과 성능이 보장되어야 하여, 국내를 포함한 다수의 국가에서는 국제 표준(IEC 60601-1, 전자의료기기 안전규격)을 기준으로 의료기기 소프트웨어의 인허가 절차를 진행한다. 이때 ‘IEC 60601-1’은 의료기기 소프트웨어의 구체적인 개발 규격으로 ‘IEC 62304(의료기기 소프트웨어 생명주기)’를 참조하고, 구제척인 위험관리 활동을 위한 ‘ISO 14971(의료기기 위험관리 규격)’을 참조하여 표준을 준수할 것을 명시한다. 따라서 소프트웨어가 포함된 의료기기를 개발하는 제조업체는 제품의 인허가를 위해 세 주요 표준(IEC 60601-1, IEC 62304, ISO 14971)을 준수하며 개발을 수행해야 한다. 세 표준 간에 존재하는 참조 연관성을 보조하기 위해 본 발명에서는 주요 표준의 참조 연관성을 반영하여 표준의 모든 내용을 단일한 프로세스로 재구성한 ‘통합 프로세스’를 정의하였고, ‘통합프로세스’의 시각화 및 제공 방법을 제안하여 제조업체가 ‘통합 프로세스’를 통해 개발 중 표준 간의 연관성을 분석할 필요 없이 모든 표준 내용을 준수할 수 있도록 한다.

또한, 본 발명에서는 제조업체가 ‘통합프로세스’의 요구사항이 갖는 정보(개발순서, 기존 표준, 기존 프로세스, 속성)를 통해 의료기기 통합프로세스가 제시하는 개발 절차에 따라 모든 주요 표준의 내용을 준수하도록 보조받을 수 있게 한다. 또한 ‘통합프로세스’를 사용할 때, 제조업체는 기존 주요 표준 시스템의 관점에서 다양하게 ‘통합프로세스’ 정보를 파악할 수 있고, 요구사항의 속성에 따라서도 다양하게 ‘통합프로세스’ 정보를 제공받을 수 있다. 이를 위하여 본 발명에서는 ‘통합 프로세스’가 갖는 다양한 정보를 의료기기 소프트웨어 제조업체에게 제공하기 위한 시각화 및 제공 방법을 제안한다.

이하에서는 본 발명에 따른 바람직한 실시예를 첨부된 도면을 참조하여 상세하게 설명한다.

도 2 및 도 3은 의료기기 소프트웨어 인허가를 위한 주요 표준의 구성을 설명하기 위한 도면이다.

의료기기 소프트웨어의 관련 3개의 국제 표준은 도 2와 같이 개발, 위험관리, 형상관리, 결함관리, 유지의 총 5개 프로세스로 구성되고, 도 3과 같이 Process > Phase > Activity > Task > Requirement의 계층으로 구성된다.

도 4는 PESS(Programmable Electronic Sub System) 기반 PEMS(Programmable Electrical Medical System) 개발주기 V-모델을 나타낸 도면이다.

도 4를 참조하면, PEMS 개발생명주기 프로세스와 위험관리 프로세스가 진행되는 것을 도식화하여 나타낸 것으로, 두 프로세스 간의 연관성을 확인할 수 있다.

먼저 PEMS 개발생명주기는 ①∼⑧의 순서에 맞게 단계별로 이루어진다. ①∼④에서 PEMS를 개발하기 위한 설계 과정으로, 해당 단계의 구성 단위에 맞추어 구조를 설계한다. ⑤∼⑧에서는 개발된 하위 레벨의 모듈을 상위 레벨로 통합하고, 각 레벨에서의 구현물에 대한 검증 절차를 수행하게 된다. 이를 위험관리 프로세스의 관점에서 분석하면, ①의 이전 단계에서 위험관리계획서를 작성한다. ①∼④에서는 위험분석을 통해 위험을 감소시키게 되고, ⑤∼⑧에서는 위험통제의 효과를 평가하고, 추가로 발생하는 위험을 통제한다. 이처럼, 의료기기 소프트웨어 개발 프로세스 중 위험관리 프로세스는 동시에 진행된다. 이에 관련하여 의료 소프트웨어 개발 프로세스에 대해 여러 표준의 규제 사항들을 통합시킨 프로세스 참조 모델의 개발이나 ISO 14971의 준수를 위한 구체적인 가이드라인과 같은 연구가 진행되고 있다. 그러나 참조 모델은 다양한 표준들의 명시적인 참조 관계만 제시하고 있어, 의료기기 소프트웨어 위험관리를 위한 구체적인 연관성은 파악할 수 없다. 또한 위험관리 가이드라인에서도 위험관리 프로세스 자체 내에서 사용되기 위한 방법론을 제안하고 있어, 개발 프로세스와의 연관성은 파악할 수 없다. 따라서 본 발명에서는 의료기기 소프트웨어의 개발 중 체계적인 위험관리를 위해 위험관리 프로세스 요구사항을 산출물 단위로 분석하였으며, 이를 개발생명주기와 대응시켜 절차별로 분석되어야 하는 항목들의 연관성을 제시한다. 이러한 연관성은 개발 과정에서 고려되어야 하는 위험관리 항목을 구체적으로 명시함에 따라, 의료기기 소프트웨어의 체계저인 위험관리를 가능케 한다.

의료기기 소프트웨어가 내장되어 있는 PEMS에 대한 개발생명주기와 위험관리를 위한 절차를 분석한다. 각각의 절차는 표 1 및 표 2와 같다.

[표 1]

[표 2]

한편, 개발 프로세스는 ‘V&V(Verification & Validation) 모델’이라고도 불리며, 의료기기 소프트웨어 개발의 진행 순서에 따라 내용이 구성되었지만, 나머지 4개의 개발 관련 프로세스들은 의료기기 개발 순서에 따라 내용이 구성되지 않는다. 따라서, 의료기기 제조업체는 개발 프로세스에 따라 개발을 진행할 때, 다른 프로세스와의 연관성을 분석하며 개발을 수행해야하는 어려움이 있다.

이에, 제조업체가 의료기기 소프트웨어 개발을 하며 세 주요 표준이 제시하는 모든 프로세스와 이하 내용들을 준수할 수 있도록 보조하기 위한 통합 프로세스가 필요하다.

도 5는 본 발명의 일 실시예에 따른 개발 프로세스에 대한 개발관련 프로세스들과의 연관성 분석을 설명하기 위한 도면, 도 6a 내지 도 6c는 본 발명의 일 실시예에 따른 개발 프로세스 기준 활동(Activity) 수준에서의 연관성 분석결과를 나타낸 도면, 도 7은 본 발명의 일 실시예에 따른 개발 프로세스 기준 연관성 분석 결과를 설명하기 위한 도면이다.

도 5를 참조하면, 통합 프로세스는 개발프로세스의 진행 순서를 기준으로, 각 순서에서 수행해야하는 세 표준의 모든 요구사항들이 통합된다. 예컨대, 통합프로세스는 10개의 개발진행순서로 구성된다.

통합 프로세스를 정의하기 위해, 개발 프로세스를 기준으로 삼아, 개발 프로세스의 각 순서에서 수행되어야 하는 주요 표준의 내용을 대응시키기 위한 연관성 분석을 수행한다. 이때 도 5와 같이 표준을 구성하는 상위 구성요소 수준부터 하위 구성요소까지 순차적으로 분석을 수행한다.

개발 프로세스 기준 연관성 분석은 개발 프로세스의 각 Phase에서 수행되어야 하는 내용을 분석하는 것을 의미한다. 이때, 분석 근거는 세 국제 표준의 참조 내용, IEC 82304, Od-2044 등의 표준 연관성 가이드라인 등을 포함할 수 있다. 개발 프로세스 기준 분석 순서는 개발 프로세스 vs 기타 프로세스, 개발 프로세스 vs Activity, 개발 프로세스 vs Requirement 등일 수 있다.

통합 프로세스의 각 순서에서 수행해야하는 주요 표준의 요구사항들이 대응되어 통합 프로세스가 정의되고, 이는 도 6a 내지 도 6c와 같은 개발 프로세스 기준 연관성 분석 결과를 획득할 수 있다. 도 6a 내지 도 6c는 활동(Activity) 수준에서의 분석결과일 수 있다. 도 6a 내지 도 6c에서 Process 항목의 값은 각각 D: 개발프로세스(Development), R: 위험관리프로세스(Risk), C: 형상관리프로세스(Configuration), P: 결함관리프로세스(Problem), M: 유지보수프로세스(Maintenance)의 값을 가진다.

제조업체는 통합 프로세스의 순서에 따라 순차적으로 개발을 수행하며, 표준 간의 연관성 분석을 할 필요없이 단일 프로세스를 통해 세 표준이 요구하는 모든 프로세스와 이하 내용들을 준수할 수 있다.

또한, 개발 프로세스 기준 연관성 분석 결과는 도 7과 같이 세 표준, 다섯 프로세스의 모든 내용이 개발 프로세스의 각 Phase로 대응한다.

한편, 통합 프로세스는 주요 표준의 내용이 재구성된 것이기 때문에, 통합 프로세스의 최하위 구성요소인 요구사항(Requirement)은 기존 시스템과의 다양한 추적 관계와 속성을 갖는다.

따라서, 통합 프로세스 정보는 통합프로세스 순서 정보, 요구사항 정보, 요구사항 속성을 포함하고, 각 요구사항은 개별적인 정보와 속성을 갖는다. 이때, 통합프로세스 순서 정보는 통합프로세스의 어느 순서에 속한 요구사항인지를 나타내는 것으로, ‘1~10’의 값 중 1개를 갖는다. 요구사항 정보는 통합프로세스를 정의하는 과정에서 기존 표준 내용의 재구성을 의미하고, 통합프로세스의 요구사항 정보는 표 3에 도시된 바와 같이 표준 정보, 기본 프로세스 정보를 포함한다. 표준 정보는 통합프로세스의 요구사항이 어느 주요 표준에 대한 요구사항인지를 나타내는 정보로, 예컨대, IEC 60601-1, IEC 62304, ISO 14971 중 하나일 수 있다. 기본 프로세스 정보는 통합프로세스의 요구사항이 어느 개발 관련 프로세스에 대한 요구사항인지를 나타내는 정보로, 예컨대, 개발, 위험관리, 형상관리, 문제해결, 유지보수 중 하나일 수 있다. 요구사항 속성은 요구사항 내용에 따라 속성 부여 가능함을 의미한다. 요구사항 속성은 표 4에 도시된 바와 같이 필수여부, 문서화 여부, 안전 등급을 포함한다. 필수여부(Mandatory/ Optional)는 필수 수행여부에 따른 속성을 의미하고, 문서화 여부 (Documented/ NotDocumented)는 수행기록 문서화 여부에 따른 속성을 의미하며, 안전 등급(Safety Class-A/B/C)은 소프트웨어 안전등급에 따른 속성을 의미하는 것으로, 요구사항마다 안전 등급이 달려있다.

[표 3]

[표 4]

도 8은 본 발명의 일 실시예에 따른 통합 프로세스를 정의하기 위한 도면, 도 9는 본 발명의 일 실시예에 따른 통합프로세스의 각 Phase에 Requirement 및 Activity를 정의한 도면이다. 개발 프로세스를 기반으로 통합프로세스 phase를 정의하면, 통합 프로세스 도 8과 같이 (1)위험관리, (2)요구사항 분석, (3)시스템 구조설계, (4)소프트웨어 구조설계, (5)소프트웨어 단위 구조 설계, (6)소프트웨어 단위 구현 및 검증, (7)소프트웨어 통합 및 검증, (8)시스템 통합 및 검증, (9)시스템 유효성 검증, (10)유지보수의 10개로 구성된다.

또한, 통합 프로세스는 기존 프로세스와 동일한 계층 구조(Phase -> Activity -> Task -> Requirement)이고, 도 9와 같이 통합프로세스의 각 Phase에 Requirement 및 Activity가 정의(연계, 대응)된다. 즉, 통합 프로세스의 각 순서에서 수행해야하는 주요 표준의 요구사항들이 대응되어 통합 프로세스가 정의된다. 제조업체는 통합 프로세스의 순서에 따라 순차적으로 개발 수행하며, 표준 간의 연관성 분석을 할 필요 없이 단일 프로세스를 통해 세 표준이 요구하는 모든 프로세스와 이하 내용들을 준수할 수 있다.

도 10은 본 발명의 일 실시예에 따른 통합프로세스를 시각화한 예시도, 도 11은 본 발명의 일 실시예에 따른 Zoom in-out을 통해 통합 프로세스를 선택적으로 시각화한 예시도이다.

도 10과 같이 통합프로세스가 시각화 될 때, 사용자의 요청에 따라 선택된 속성만을 갖는 요구사항들이 시각화되며 해당 시점에서의 개발 또는 표준 준수 진행도가 출력될 수 있다.

통합 프로세스를 시각화한 경우, Zoom in-out 을 통해 도 11과 같이 Phase-Activity-Task를 선택적으로 시각화할 수 있다. 이때, Tooltip을 통해 요구사항 내용 보여줄 수 있다.

사용자는 통합프로세스의 개발 순서 중 현재 개발 시점에 해당하는 순서를 선택하며, 그 순서에서 수행해야하는 주요 표준의 모든 요구사항이 주어진다. 이때, 사용자는 통합프로세스 정보에 따라 다양한 관점에서 통합프로세스를 시각화 시킬 수 있다.

도 12는 본 발명의 일 실시예에 따른 의료기기 소프트웨어 표준 통합 프로세스 시각화 제공 방법을 설명하기 위한 순서도, 도 13은 본 발명의 일 실시예에 따른 개발순서 선택 화면 예시도, 도 14는 본 발명의 일 실시예에 따른 표준선택 화면 예시도, 도 15는 본 발명의 일 실시예에 따른 프로세스 선택 화면 예시도, 도 16은 본 발명의 일 실시예에 따른 요구사항 속성 선택 화면 예시도, 도 17은 본 발명의 일 실시예에 따른 검색 결과 출력 화면의 예시도, 도 18은 본 발명의 일 실시예에 따른 기록문서 작성 화면의 예시도이다.

도 12를 참조하면, 사용자는 통합 프로세스 Phase에서 개발순서를 선택한다. 즉, 사용자는 도 13과 같은 개발순서 선택 화면을 통해 통합 프로세스 phase를 선택할 수 있다.

그런 후, 사용자는 의료기기 소프트웨어 표준을 선택한다. 이때, 사용자는 도 14와 같은 표준 선택 화면에서 IEC 60601-1, IEC 62304, ISO 14971 중 적어도 하나를 선택할 수 있다.

표준 선택 후, 사용자는 프로세스를 선택한다. 즉, 사용자는 도 15와 같은 프로세스 선택 화면에서 개발, 위험관리, 형상관리, 결함관리, 유지보수의 5개 프로세스 중에서 하나의 프로세스를 선택한다.

프로세스를 선택한 후, 요구사항 속성을 선택한다. 즉, 사용자는 도 16과 같은 요구사항 속성 선택 화면에서 필수여부, 문서화 여부, 안정 등급 등을 선택한다.

개발순서, 소프트웨어 표준, 프로세스, 요구사항 속성의 선택이 완료되면, 장치는 통합프로세스의 요구사항 중 사용자가 선택한 ?ㅊ? 와 ?憺?을 갖는 요구사항만 출력하도록 검색한다.

검색이 완료되면, 장치는 검색 결과를 도 17과 같이 출력하고, 문서화 요구사항의 경우 욕우사항에 따라 기록문서를 작성한다. 즉, 문서화 요구사항의 경우, 장치는 요구사항에 따라 기록문서를 작성할 수 있도록 도 18과 같은 기록문서 작성 화면을 제공할 수 있다.

도 19는 본 발명의 일 실시예에 따른 의료기기 소프트웨어 표준 통합 프로세스 시각화를 위한 장치를 설명하기 위한 도면이다.

도 19를 참조하면, 본 발명의 일 실시예에 따른 의료기기 소프트웨어 표준 통합 프로세스 시각화를 위한 장치는 사용자 요청 입력부(100), 검색부(200), DB부(300), 제어부(500), 디스플레이 출력부(600), 기록문서 작성부(700)를 포함한다.

사용자 요청 입력부(100)는 사용자 요구사항을 입력받는다. 통합 프로세스는 의료기기 소프트웨어 개발 표준들이 제시하는 복수의 개발 관련 프로세스와 요구사항들을 의료기기 소프트웨어 개발의 진행에 따라 수행할 수 있도록 재구성한 단일 프로세스이다. 따라서, 사용자는 사용자 요청 입력부(100)를 통해 통합 프로세스의 순서 중 하나의 개발 순서를 선택하고, 의료기기 소프트웨어 인허가를 위한 표준들 중 준수하기를 원하는 표준을 선택하며, 의료기기 소프트웨어 표준이 제시하는 여러 개발관련(개발, 위험관리, 형상관리, 문제해결, 유지보수) 프로세스 중 준수하기를 원하는 프로세스를 선택하고, 의료기기 소프트웨어 표준이 제시하는 요구사항 중 준수하기를 원하는 속성을 선택한다.

검색부(200)는 DB부(300)에서 사용자 요청 입력부(100)의 정보에 부합하는 통합 프로세스 내용을 식별한다.

DB부(300)에는 의료기기 소프트웨어 인허가의 기준이 되는 의료기기 소프트웨어 개발 표준들의 내용이 재구성 되어, 통합 프로세스의 관점에서 모든 표준 내용이 저장된다.

제어부(500)는 디스플레이 출력부(600)에서 사용자 요청 입력부(100)의 내용 입력받는 것을 제어한다. 또한, 제어부(500)는 디스플레이 출력부(600)에서 DB부(300)의 통합프로세스 내용 출력하는 것을 제어한다.

디스플레이 출력부(600)는 사용자와 시스템 간의 상호작용을 담당하는 구성으로, 사용자의 요청을 입력받고, 통합 프로세스 시각화 결과와 개발 진행도를 출력할 수 있다. 디스플레이 출력부(600)에서 사용자 요청 입력부(100)와의 상호작용을 통해 사용자에게 요청 받고, 사용자 요청에 따라 작업된 결과가 DB부(300)의 검색을 통해 디스플레이 출력부(600)로 출력된다.

기록문서 작성부(700)는 통합프로세스의 요구사항이 문서화 되어야 한다는 속성을 갖는 경우, 제조업체는 기록문서로 작성한다. 또한, 기록문서 작성부(700)는 각 요구사항에 해당하는 템플릿을 제조업체에게 제공하여 내용을 입력받고 저장한다.

한편, 본 발명에 따른 장치는 진행도 계산부(400)를 더 포함할 수 있다. 진행도 계산부(400)는 DB부(300)에서 통합 프로세스 요소들의 수행여부를 파악하여 의료기기 소프트웨어의 개발 및 표준 준수 진행도 계산한다. 또한, 진행도 계산부(400)는 통합 프로세스 요소들이 갖고 있는 표준 정보, 프로세스 정보, 속성 정보에 따라 다양한 관점의 진행도를 산출한다. 이때, 제어부(400)는 디스플레이 출력부(600)에서 진행도 계산부(400)의 개발 진행도 내용 출력하는 것을 제어할 수 있다.

상기와 같이 구성된 장치는 사용자 요청 입력부(100)의 사용자 입력에 따라 검색부(200)에서 DB부(300)에 저장되어 있는 통합 프로세스 정보를 식별하고, 식별된 정보는 제어부(500)를 통해 디스플레이 출력부(600)에서 출력된다.

또한, 진행도 계산부(400)에서는 DB부(300)의 통합 프로세스 정보들의 수행여부에 따라 의료기기 소프트웨어의 개발 진행도를 계산하고, 계산된 진행도 정보는 제어부(500)를 통해 디스플레이 출력부(600)에서 출력된다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

100 : 사용자 요청 입력부
200 : 검색부
300 : DB부
500 : 제어부
600 : 디스플레이 출력부
700 : 기록문서 작성부

Claims (1)

1. 사용자로부터 통합프로세스 순서정보, 요구사항정보 및 요구사항 속성을 입력받는 단계;
   통합 프로세스의 관점에서 표준 내용이 저장된 데이터베이스에서 상기 입력된 정보에 대응하는 통합 프로세스 내용을 검색하는 단계;
   상기 검색된 통합 프로세스 내용을 디스플레이 출력부를 통해 시각화하는 단계를 포함하되,
   상기 요구사항정보는 표준정보 및 프로세스 정보를 포함하고, 상기 요구사항 속성은 필수여부, 문서화여부 및 안전등급을 포함하는 것을 특징으로 하는 의료기기 소프트웨어 인허가를 위한 의료기기 소프트웨어 개발 표준 통합 프로세스 시각화 방법.
   

Images