1. Introduction
Medical device software must be more tightly controlled in safety and performance than software in other areas. For this, Korea and many countries in Europe have made surethat the research and development(R&D)of the product has been properly performed during the licensing of medical device software, and have enacted the international standard of IEC 62304 as a guideline for R&D. Therefore, medical device software manufacturers comply with standards related to medical device software including IEC 62304, and they are licensed through documents artifacts [1]. IEC 62304 is a standard for the medical device software life-cycle process [2]. It ensures the safety and performance of medical devices of tware through verification of software artifacts and validation of all software life cycle. In other words, this standard requires not only a testing-based activity represented by the V&V(Verification & Validation) model, but also all R&D procedures which are performed correctly. In addition, ISO / IEC 12207 international standard is a standard that developers refer to for research and development of medical device software. ISO / IEC 12207 is the standard for presenting life-cycle processes for general software [3], which is the basis of the contents of IEC 62304.
However, these international standards only abstractly describe the activity of the process, but do not specifically describe the methodor procedure for R&D documentation. That is, the developer knows the requirements of the life-cycle process from the standard, but does not provide the scope or method of the document artifacts that must becreated for licensing. In addition, research on s of twareengineering methodologies such as testing and configuration management required to fulfill the requirements of the standard is active [4, 5], and there is little research on documenting them. Therefore, manufacturers have difficulty in preparing R&D documents that meet the standard requirements. In addition, the evaluation of the written R& Ddocuments depends on the domain experts, and there is aneed for a method for manufacturers to perform qualitative evaluation of R&D documents themselves [6, 7].
This paper extracts the specification that requires documentation among the contents of the standard with the concept of 'R&D Documentation Guideline', and enablesmedical device software stakeholders to write and evaluate R&D documents that comply directly with the standards. Chapter 3 merges the configurations of IEC 62304 and ISO/IEC 12207 and defines the documentation guidelines from the documentation requirements. Chapter 4 proposes amethod for providing the defined R&D documentationguidelines, then we confirm the possibility of the proposed method by confirming that the developer has written andevaluated the record document through the guidelines. Following the documentation guidelines, developers can have technical documents that complies with all standards, and they can efficiently prepare the licensing procedures of medical device software.
2. Related Work
There is an ISO/IEC 15504 standard called ' Software Process Performance Evaluation Framework (SPICE)' forevaluating software R & D [8]. (MDevSPICE), which specializes in medical device software [9]. These studies assess the level of research and development processes by comparing requirements specifications and software artifacts based on ISO/IEC 12207 and IEC 62304 standards. However, it evaluates only the list of products such as codes and documents, but does not evaluate the contents of research and development documents qualitatively.
In addition, there is a study on the Standard Conformity Framework (SCF) that enables research and developmentrecords to be written in conformity with standards [10,11]. These studies provide a proper template for documentartifacts, allowing developer to create documents that conform to standards. However, because it is not a framework defined based on standards in the software field, there is a limitation that software life-cycle process requirements can not be covered.
Therefore, this paper suggests R&D documentationguidelines to overcome the limitation that the standard based R & D document can not be written through the previous studies. The requirements for documentation in therequirements of the standard are extracted as a guideline of the type presented in this study to enable the qualitativeassessment of whether the document meets the requirements of the standard as well as the R & D document .
3. Method for Extracting R&D Documentation Guideline
The IEC 62304 standard specifies five processes (development, risk management, configuration management, defect management, maintenance) in the medical devices of tware life cycle from Chapters 5 to 9. ISO/IEC 12207defines the life cycle process for general software R&D inchapters 6 to 7. They present the contents of s of tware research and development, and they are composed of ' Process-Activity-Task' levels. Task means ' requirements ' which is the minimum unit. This chapter identifies only theitems with the guidance of documentation among the standard requirements and extracts them in the form of documentationguidelines that provide only the core information.
3.1 Standard based R&D Specification
The framework proposed in this study allows medical device software developers to comply with two international standards (IEC 62304, ISO/IEC 12207). IEC 62304 is astandard established to reflect the characteristics of medical device software, and ISO/IEC 12207 is a standard for general purpose software that presents more abstract and comprehensive R&D requirements. This study presents the contents of a new R&D process reflecting the characteristics of these two standards. The list of Table 1 is the processes that merged the table of contents of IEC 62304 based on the contents of ISO/IEC 12207. Then the framework developed by this study presents the R&D specification of the twostandards to the developer as shown in this table.
(Table 1) Contents of ISO/IEC 12207 and IEC 62304
3.2 Documentation Requirement
IEC 62304 and ISO/IEC 12207 have 215 and 620 requirements, respectively, of which there are requirements to be specifically documented. In order to define the documentation guidelines, we extract requirements that contain the contents for recording activity result. This is done on the basis of the use of the words "document" or & quot; makerecord& quot; in the content of the requirement.In addition, & #39; M(Mandatory) / O(Optional)' attributes are given depending on whether the documentation requirements should be performed unconditionally. This is distinguished by whetherthe requirement has the word "shall" or "should". Table 2 shows the configuration for the documentation requirementsextracted from the standard, which indicates that the manufacturer must perform documentation by a total of 124 mandatory requirements. The following examples are therequirements of the two standards with thecharacteristics of the documentation requirements.
ex1) ISO / IEC 12207-6.4.1.3.5.1 The project shall record the stakeholder requirement.
ex2) IEC 62304-5.2.6 The MANUFACTURER shall verify and document that the software requirements:
(Table 2) Configurations of Documentation Requirements for Standards
3.3 Documentation Guideline
Documentation guidelines are descriptive texts that enable users to easily create and evaluate R&D documents through core information of the documentation requirements. The documentation guidelines are structured to providea variety of information on the requirements, as shown in Figure 1. Especially, the requirement has a ‘document keyword’information, which allows the user to create or evaluate adocument based on whether or not the document contentincludes keywords.
(Figure 1) Format and Example of Documentation Guideline
Figure 1 (a), the documentation guidelines have a total of four main information items.
-source of documentation guideline
: Indicates the source for the developer to see the contents of the standard directly if they want to read the detailed description.
- mandatorily / optionally
: Indicates whether the developer should document the contents of the guideline, and is used as important information to prepare for licensing of the product.
- target document
: Indicates the title of the document so that it can record research and development activities in the appropriate document from the list of documents the manufacturer has.
- document keyword: The developer will recommend keywords that should be included in the document so that they can write documents that meet the standard requirements after the R&D activities. In addition to providing information on document preparation, this item is used as a basis for document evaluation described below.
Figure 2 shows the flow diagram for usage of documentation guideline. The user follows the instructions of the documentation guidelines during the R&D. For example, in the case of Figure 1 (b), the developer must record R& Dactivities in the SRS, including the keyword 'System of medical device, System requirement'. Subsequently, the R&D documents are evaluated as to whether or not keywords are included in the content, and if not, the contents are revised to include all the keywords. This means that the evaluation of the document through the keyword canguarantee the conformity to the standard.
(Figure 2) Flow Diagram for using Documentation Guideline
4. Methods for Providing R&D Documentation Guideline
Through documentation guidelines, users can create andevaluate medical software R&D document that complies with the documentation requirements specified by IEC 62304. Figure 3 shows the scenarios according to the flow chart, details of whichare as follows:
① Documentation: During the research and development of medical device software, users can generate documents and compose a list of documents that conform to the standards without having to directly analyze the contents of the standards through the documentation guidelines.
② Evaluation: Documentation guidelines are evaluated by examining whether the document indicated by the keyword contains all of the keywords. This can be automated based on searching macro or similarity evaluations of the document content.
③ Revision: Evaluation result of document. Figure 4 shows that the keyword 'RISK' is missing from the keyword' ID, Performance, Requirement, Risk' in 'SRS'. The guideline has the attribute 'Mnadatorily', so the developermust document all keywords. Therefore, the developershould understand the details of the requirements through the standard source information, conduct research and development on 'RISK', and revise the document toinclude the keyword 'RISK'.
The process of ① through ③ is repeated until all researchand development documents meet the documentationguidelines, which enables manufacturers to efficiently provide high quality research and development documents.
(Figure 3) Scenario for applying Documentation Guideline
(Figure 4) Web-based R&D Documentation Guidelines Framework
Figure 4 is an example of a web-based framework provided to the user according to the scenario of Figure 3. The developer will proceed with the R&D in the order of the process composition table of the two standards in Table 1, and the contents of the requirements to be documented ineach list can be provided through the documentationguidelines. Once all the R&D documents have been written, the developer can perform document evaluation by checking that the document contains the keywords required by the documentation guidelines, and the resulting output is shown in Figure 4(a). The framework indicates how much documentation guidelines have been achieved for each document, which is the degree of conformity of the R& Ddocument.
In this example, the developer creates documents named ‘R&D Plan’ and ‘SRS’ into the documentation guidelineevaluation framework. The evaluation framework checks whether all the keywords required by the standard are included in the ‘R&D Plan’ document and checks whether all the keywords required by the standard are included in the & lsquo; SRS’ document. In the IEC62304 standard, there are a total of 36 documentation guidelines for the ‘R&D Plan’ and 27 documentation guidelines for ‘SRS’, which figure that we have satisfied the documentation specifications for 27 and 24 of these.
In addition, the developer can revise the document through the evaluation result. The framework shows the documentation guidelines that the user did not grasp and did not satisfy as shown in Fig. 4 (b). Developers will be able to modify their R&D documents to meet the standard requirements through the key information provided by the R&D documentation guidelines. The evaluation-revision process is repeated until all the documentation guidelines aresatisfied.
5. Conclusion and Further Research Issues
This paper defines the documentation guidelines by extracting the core information of the requirements fordocumentation so that the research and development documents can be produced according to the requirements of the two international standards, IEC 62304 and ISO/IEC12207. The documentation guidelines assist in the creation and evaluation of R&D documents through corekeywords of the requirements. This allows medical device s of twaremanufacturers to construct standards-compliant research and development documents and to have high-quality researchand development documentation to ensure the quality of medical device software and to provide the necessary records for licensing procedures.
Future research will include research on extracting R& Ddocumentation guidelines from standard requirements by applying text mining techniques. By automating the methodology presented in this study, we canautomatically extract the R&D documentation guidelines when the userenters the standard. And we will improve the method of evaluating the written R&D documents.
References
- Li, Wei, CW Jung, JT Park, "IoT Healthcare Communication System for IEEE 11073 PHD and IHE PCD-01 Integration Using CoAP," KSII Transactions on Internet & Information Systems, Vol. 12, No. 4, pp. 1396-1414, 2018. http://dx.doi.org/10.3837/tiis.2018.04.001
- IEC 62304. Medical Device Software Life-Cycle Processes, Geneva, 2006.
- ISO/IEC 12207:2008, Systems and software engineering- Software life cycle processes, Geneva, 2008.
- Baek DS, BJ Lee, JW Lee, "Content-based Configuration Management System for Software Research and Development Document Artifacts," KSII Transactions on Internet & Information Systems, Vol. 10, No. 3, pp. 1404-1415, 2016. http://dx.doi.org/10.3837/tiis.2016.03.027
- Amarmend Dashbalbar, SM Song, JW Lee, BJLee, "Towards Enacting a SPEM-based Test Process with Maturity Levels," KSII Transactions on Internet and Information Systems, vol. 11, no. 2, pp. 1217-1233, 2017. http://dx.doi.org/10.3837/tiis.2017.02.034
- Ryu TK et al. "A study on quality measures of patents for evaluating national research and development programs", Jinhan M&B, 2014
- Park SD, Jeong SK, Park SH, "Future Strategy Software Technology Development Project,"KISTEP, 2010
- ISO/IEC 15504-4:2004, Information technology - Process assessment -Part 4: Guidance on use for process improvement and process capability determination
- Lepmets, Marion, et al, "Development of MDevSPICE(R)-the medical device software process assessment framework," Journal of Software: Evolution and Process, Vol. 27, No. 8, pp. 565-572, 2015. https://doi.org/10.1002/smr.1731
- Cyra, Lukasz, Janusz Gorski, "Standards conformity framework in comparison with contemporary methods supporting standards application," Dependability of Computer Systems, 3rd Conference on. IEEE, 2008. https://doi.org/10.1109/DepCoS-RELCOMEX.2008.38
- Cyra, Lukasz, Janusz Gorski, "SCF-A framework supporting achieving and assessing conformity with standards," Computer Standards & Interfaces Vol. 33, No. 1, pp80-95, 2011. https://doi.org/10.1016/j.csi.2010.03.007