=Paper=
{{Paper
|id=Vol-3612/QuASoQ_2023_Paper_03
|storemode=property
|title=Proposals for Improving the Assessment of Medical Device Software in Thailand
|pdfUrl=https://ceur-ws.org/Vol-3612/QuASoQ_2023_Paper_03.pdf
|volume=Vol-3612
|authors=Natsuda Kasisopha,Songsakdi Rongviriyapanish,Panita Meananeatra
|dblpUrl=https://dblp.org/rec/conf/apsec/KasisophaRM23
}}
==Proposals for Improving the Assessment of Medical Device Software in Thailand==
https://ceur-ws.org/Vol-3612/QuASoQ_2023_Paper_03.pdf
Proposals for Improving the Assessment of Medical
Device Software in Thailand
Natsuda Kasisopha1, Songsakdi Rongviriyapanish 1, and Panita Meananeatra 2
1 Thammasat University, 99 Phahonyothin Road, Khlong Nueng, Khlong Luang District, Pathum Thani 12120, Thailand
2 National Electronics and Computer Technology Center( NECTEC
) , 112 Phahonyothin Road, Khlong Nueng, Khlong Lu-
ang District, Pathumthani 12120, Thailand
Abstract
The registration of Medical Device Software (MDS) and Software as a Medical Device (SaMD) with the
Food and Drug Administration (FDA) is a prerequisite before entering the market. The FDA relies on
several international standards as regulatory benchmarks to ensure the quality of MDS. Key components
of this regulatory framework include IEC 62340 [1], ISO 14971 [2], and ISO 13485 [3]. Our experience
assessing MDS in Thailand highlighted common challenges manufacturers face during software evalua-
tion. Notably, clause 6 (Software Maintenance Process) and clause 8 (Software Configuration Manage-
ment Process) demonstrate the highest rates of evaluation failure. Clause 7 (Software Risk Management
Process) and clause 9 (Software Problem Resolution Process) closely follow, ranking as the second-
highest areas of concern regarding evaluation failures. The primary factor contributing to these soft-
ware evaluation challenges is a deficiency in knowledge and understanding of IEC 62304 [1]. To address
this issue, we propose a solution in the form of a chatbot designed to assist manufacturers in compre-
hending and generating IEC 62304-compliant documents.
Keywords
medical device software, software as a medical device, Thais’ medical device software assessor, medi-
cal device software obstacle, medical device software quality assessment. 1 0
1. Introduction clauses within the standard. For instance, sub-clause
4.2 (Risk Management) illustrates its correlation with
clause 7 (Software Risk Management Process). Sub-
In Thailand, Medical Device Software (MDS) and Soft-
clause 4.2 of IEC 62304 is also interconnected with ad-
ware as a Medical Device (SaMD) are required to regis- ditional standards, such as ISO 14971 [2]. Further-
ter with the Thailand Food and Drug Administration more, for manufacturers attaining ISO 13485 [3], ad-
(Thai FDA) [4]. The Thai FDA has established criteria herence to ISO 14971 [2] for risk management is im-
aligned with international standards, including mainly plicitly fulfilled. The visual representation of these in-
ISO/IEC 62304:2006 - "Medical device software - Soft- terrelations between standards is depicted in Figure 2.
ware life cycle processes" (IEC 62304) [1], ISO Moreover, IEC 62304 [1] establishes connections
14971:2019 - "Medical devices - Application of risk with IEC 60601 [5], clause 14, primarily through
management to medical devices" (ISO 14971) [3], ISO clauses 4.3 (Software Safety Classification), 5 (Soft-
13485:2016 - "Medical devices - Quality management ware Development Process), 7 (Software Risk Manage-
systems - Requirements for regulatory purposes" (ISO ment Process), 8 (Software Configuration Process),
13485) [3], and IEC 60601-1 clause 14 (IEC 60601), and 9 (Software Problem Resolution Process). The
which pertains to Programmable Electrical Medical standard comprehensively addresses aspects of Soft-
Systems (PEMS) for medical electrical devices ware Life Cycle Processes, encompassing Quality Man-
[5].These standards outline the processes, activities, agement Systems (QMS), Software Development Pro-
and configuration tasks that form a holistic framework cesses (SDP), Software Requirement Specification
for developing MDS. (SRS), Software Maintenance Process (SMP), Software
IEC 62304 [1] encompasses six processes outlined Risk Management (SRM), Software Configuration Man-
in clauses 4 to 9. Each clause specifies a breakdown agement (SCM), Software System Testing (ST), and re-
into sub-clauses, activities, and tasks. These sub- lated components, as well as the Software Problem
clauses are interconnected with other clauses and sub- Resolution Process (SPR). These elements are essen-
tial for the assessment of MDS.
QuASoQ 2023: 11th International Workshop on Quantitative
Approaches to Software Quality, December 04, 2023, Seoul, South
Korea
natsuda.kas@dome.tu.ac.th (N. Kasisopha); rongviri@tu.ac.th (S.
Rongviriyapanich); panita.meananeatra@nectec.or.th (P. Meananeatra)
© 2023 Copyright for this paper by its authors. The use permitted under
Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
60
step, "Product Registration," necessitates manufactur-
ers to submit comprehensive documentation about the
medical device. This includes details such as the device
description, intended use, indications, instructions for
use, storage conditions, shelf life, contraindications,
warnings, precautions, potential adverse effects, alter-
native therapy options, materials used, product speci-
fications, and the production development flow chart.
The submission must align with the essential princi-
ples of safety and performance of the medical device as
stipulated by the ASEAN Medical Device Directive, EU
regulations, Singapore standards, and other applicable
Figure 1: Interrelation between sub-clauses within guidelines.
Moreover, the submission should summarize veri-
IEC 62304. fication and validation, incorporating pre-clinical stud-
ies, clinical evidence, test reports, clinical evaluation
reports, and clinical data. Additionally, the marketing
history and safety declaration template documenta-
tion must be included. The inclusion of risk manage-
ment processes that comply with ISO 14971, such as
the risk plan, risk control measures, and the risk re-
port, is imperative. A valid certificate of compliance
with ISO 13485 or GMP for medical devices and ISO
9001 should be part of the submission. Lastly, the
package should also contain a declaration of conform-
ity and a letter of authorization.
Manufacturers must submit documentation to the
Thai FDA's E-Submission system to adhere to the prod-
uct registration process. The submitted documents
will be meticulously examined and evaluated in align-
ment with the risk classification of the medical device
to verify compliance with regulatory standards. In the
Figure 2: MDS Life Cycle [1]. event of uncertainties or the need for additional infor-
mation, the Thai FDA communicates with the manufac-
All MDS must undergo testing in adherence to these turer. This interaction serves the purpose of seeking
standards, following the stipulations of the Thai FDA clarification and ensuring that all requisite details are
[6] requirements. The procedure for registering MDS accurately furnished. Following a successful review
with the Thai FDA is detailed in Section 1.1 of the Reg- and approval, the Thai FDA issued a certificate for the
ulatory Framework for Medical Device Software in medical device. The type of certificate, whether
Thailand. Additionally, section 1.2 describes the MDS “listed”, “notified”, or “licensed”, depends on the risk
Software Quality Assurance and Assessment ecosys- classification assigned to the device. Subsequently, the
tem, providing a comprehensive overview of the pro- issued certification allows the manufacturer to gain
cesses and standards involved in ensuring the quality, authorization to manufacture or import the medical
safety, and regulatory compliance of MDS in the Thai device in Thailand [8].
context.
1.2. Medical Device Software Quality
1.1. Regulatory Framework for Medi- Assurance and Assessment Eco-
cal Device Software in Thailand system
The oversight of MDS falls under the scope of the Med- Medical Device Software Quality refers to the compre-
ical Device Control Division (MDCD) of the Thai FDA hensive set of characteristics, standards, and pro-
[6]. Thai FDA [6] relies on the Health and Science Au- cesses established to ensure that software integrated
thority (HSA) of Singapore [7]. The Thai FDA [6] man- into medical devices meets predefined quality criteria.
dates a two-step process for registering MDS and other This commitment encompasses various elements to
medical devices. In the first step, known as guarantee the software's safety, effectiveness, and re-
"Establishment Licensing," the medical device manu- liability.
The Medical Device Software Assessment Ecosys-
facturers must provide business registration docu-
tem functions as a holistic framework, orchestrating
ments, complete request forms, and submit other rele-
vant government documents. This step aims to verify crucial processes, adhering to standards, involving
stakeholders, and utilizing tools to evaluate software
the manufacturer credentials, enabling oversight of
integrated into medical devices' quality, safety, and
the quality of medical devices by restricting importa-
regulatory compliance. This complex ecosystem,
tion locations for production and storage. The second
which is based on established standards such as IEC
62304 [1], ISO 13485 [3], and ISO 14971 [2], provides
61
a solid foundation for assessment processes. Quality and deployment of MDS, contributing to the broader
Management Systems (QMS) are pivotal, overseeing landscape of healthcare technology.
the entire software development life cycle and ensur-
ing meticulous documentation and training. The eco-
system integrates robust risk management processes, 2. Literature Review
verification and validation (V&V) activities, and config-
uration management, as well as change control proce- The literature encompasses a diverse range of topics
dures. Internal and external audit mechanisms gauge related to regulatory compliance and software evalua-
adherence to quality standards, while post-market tion of MDS. Literature delves into the regulation’s
surveillance mechanisms monitor the real-world per- framework compliance to physical medical devices
formance of the software. and MDS in the EU. Furthermore, another piece of lit-
Before the release of the MDS to the market, the erature investigates the evaluation of MDS by the Aus-
manufacturer developed the medical device in compli- tralian Therapeutic Goods Authority (TGA) [9], em-
ance with established standards. Subsequently, the phasizing standards including IEC 62304 [1], ISO
documentation is forwarded to a testing laboratory for 14971 [2], and ISO 13485 [3].
verification and validation according to the IEC 62304 The study published by Granlund et al. [10] exten-
[1] standards. The resulting test report, upon release, sively explores medical devices under the CE mark
is utilized for submission to either the Certification [11] and the European Commission (EU) [12], focusing
Body (CB) or the Regulatory Body (RB). Once the MDS on the regulatory frameworks and challenges associ-
has successfully undergone registration procedures ated with their evaluation and development. The re-
from the Thai FDA [6], the manufacturer is then au- search highlights the reliance on the Council Directive
thorized to release the MDS to the market to the con- 93/42/EEC on Medical Devices (MDD) [13] and
sumer. MEDDEV [14] documents for a standardized applica-
tion within the CE mark [11] and EU [12]. The chal-
lenge organizations face in developing MDS to meet
the regulatory requirements of medical devices is that
there is no distinction between physical medical de-
vices and standalone software criteria, by classifying
Figure 3: MDS pre-market activities in Thailand.
both as medical devices.
The paper highlights several regulatory require-
The MDS assessment approach thoroughly exam- ment mismatches between physical medical devices
ines the MDS development processes through docu- and standalone MDS, such as the design change ap-
mentation examination. This process involves a de- proval process, the use of public cloud computing plat-
tailed analysis of the system's internal components, forms, the regulation of artificial intelligence and ma-
ensuring a systematic and comprehensive testing pro- chine learning, and the implementation of a quality
cess and other elements of the software life cycle men- management system. The authors emphasize the need
tioned in Section 1. However, manufacturers who fail for a more streamlined software development and cer-
to provide the mentioned elements or only partially of- tification process and precise AI/ML-driven systems
fer them may be required to request alterations to add guidelines. They also suggest that smaller manufactur-
information to the document. Manufacturers who do ers could benefit from cooperation or partnerships to
not give any information would fail the testing out- navigate the complexities of regulatory compliance in
come. the cloud computing environment.
The assessor evaluates three key components of Ceross and Bergmann's [15] study focuses on re-
the documents: completeness, accuracy, and con- calls and adverse events associated with Software as a
sistency of the submitted information. These criteria Medical Device (SaMD) in Australia. SaMD is distin-
ensure that the documentation adequately reflects the guished from medical devices with software, and data
development processes and meets IEC 62304 [1] in the is collected from three Australian Therapeutic Goods
assessment approach. Authority (TGA) [9] databases. The analysis reveals
The assessment report, also known as the test re- over ninety cases of recall and adverse events for
port, guarantees standard compliance during software SaMD, with fewer than thirty cases for medical devices
development through product release phases. This with software. The study identifies challenges in risk
verifies the safety of the system and confirms the evaluation associated with SaMD, citing limited regu-
proper functioning of the MDS. The guarantee empha- latory vocabulary for software defects as a key obsta-
sizes that the development process has been rigorous cle. The need for regulatory vocabulary support for
and thorough, ensuring that the MDS meets user re- software developers during early-stage research and
quirements and is fit for use. Additionally, it assures development is emphasized, and integration into com-
compliance with specified standards of accuracy, puter science courses is proposed.
safety, and regulatory requirements. This literature exposes regulatory challenges
The comprehensive MDS quality has highlighted across various SaMD types stemming from misinter-
the complete regulatory frameworks. The essential pretation and a lack of guidance. Existing regulatory
components of quality assurance and assessment eco- requirements do not adequately support diverse SaMD
systems require delving into the intricate development categories, including post-market development proce-
process, testing, and regulatory compliance. dures and AI MDS. Identifying these challenges under-
This work aims to gain insights into robust pro- scores the necessity for a tool to assist manufacturers
cesses and frameworks that govern the development in overcoming significant obstacles in MDS develop-
ment.
62
3. Medical Device Software system inputs and outputs, interfaces with other sys-
tems, software-driven alarms, warnings, and operator
Evaluation messages, security requirements, user interface re-
quirements implemented by software, data definition
The Software Quality Testing Laboratory (SQUAT) [16] and database requirements, installation and ac-
is Thailand's first software testing laboratory certified ceptance requirements at the operation and mainte-
with TIS 17025 (ISO/IEC 17025 [17]) (Certificate No.: nance site, requirements related to methods of opera-
19T016/0793) by the Thai Industrial Standards Insti- tion and maintenance, IT-network aspects, user
maintenance requirements, and regulatory require-
tute (TISI) [18], under the Ministry of Industry. Oper-
ments.
ating under the Software Engineering and Product
Testing Section (SEPT) at the National Electronics and
Computer Technology Center (NECTEC) [19], SQUAT
is dedicated to verifying system performance by fol-
lowing the criteria outlined in IEC 62304.
Having conducted many MDS evaluations at
SQUAT, the challenges encountered while evaluating
MDS became evident. Twenty-three MDS evaluation
cases from different manufacturers were analyzed,
comprising twenty systems classified as Software
Safety Class A and three systems classified as Software
Safety Class B. The evaluation results, categorized into
Pass and Fail for each IEC 62304 [1] clause, revealed
that six out of twenty-three manufacturers achieved a
fully-passed result. At the same time, the remaining Figure 4: Passed/failed results of MDS evaluations ac-
seventeen had a failed outcome. cording to IEC 62304.
Further analysis indicated a predominant trend of
more failed results than passed in each IEC 62304 [1] Moreover, in sub-clause 5.7 (Software System
clause across all cases. Notably, only clause 4 had a Testing), there is a failure to provide documentation in
higher pass rate, with twelve cases passing and eleven uniformity with a) reference to test case procedures
failing. However, clause 7 has the second highest pass showing required actions and expected results, b) the
rate, with ten cases passing and thirteen failing. The test result (pass/fail and a list of anomalies); c) the ver-
other four clauses resulted in a majority of failed as- sion of software tested; d) relevant hardware and soft-
sessments. Clauses 5 and 9 had eight passed cases and ware test configurations; e) relevant test tools; f) date
fifteen failed cases. Meanwhile, clauses 6 and 8 showed tested; and g) the identity of the person responsible for
similar patterns of seven passed and 16 failed results. executing the test and recording the test results. Lastly,
In clause 4, the documentation lacks details re- in sub-clause 5.8 (Software Release for Utilization at a
garding the decomposition of the software system into System Level), the manufacturer must establish proce-
software items. Moreover, when a software item is fur- dures to ensure the released MDS can be reliably deliv-
ther decomposed into additional software items, these ered without corruption or unauthorized change.
inherit the software safety classification of the original These procedures should address the production and
software item (or software system) unless the manu- handling of MDS media, including replication, media
facturer provides a rationale for classifying them dif- labeling, packaging, protection, storage, and delivery,
ferently. Additionally, the rationale should elucidate as appropriate.
how the new software items are separated to warrant In clause 6 (Software Maintenance Process), there
distinct classification. Suppose the software safety is a deficiency in having a software maintenance plan
class of a newly created software item differs from the to conduct activities and tasks related to receiving,
class of the software item from which it was decom- documenting, evaluating, resolving, and tracking. The
posed. In that case, the manufacturer must document usage of the software problem resolution process for
the safety class of each software item. Furthermore, analyzing and resolving issues that arise after the re-
there is often an absence of information regarding the lease of the MDS is often not adequately addressed. In
identification of legacy software, the rationale for its sub-clause 6.2 (Problem and Modification Analysis),
use, and the risk management associated with legacy the documentation and evaluation of feedback to as-
software. certain the existence of a problem in a released MDS is
In clause 5, specifically under sub-clause 5.1 (Soft- either not generated or inconsistently conducted. Ad-
ware Development Planning), the deliverables, which ditionally, there is a lack of effective implementation of
encompass documentation of activities and tasks, of- the software problem resolution process to generate
ten fall short of achieving the intended goals. The plan- problem reports. Consequently, the evaluation and ap-
ning related to software configuration and change proval of change requests based on the problem re-
management, including software configuration items, ports fail to be addressed appropriately. As a result,
system integration, verification and validation, risk there is a failure to identify the approved change re-
management, and the software development life cycle, quests that impact the released MDS.
exhibits a high incidence of failure. In sub-clause 5.2 In sub-clause 6.3 (Modification Implementation),
(Software Requirement Analysis), manufacturers fre- the manufacturer must modify the instructions out-
quently fail to identify all software requirements, such lined in clause 5. Additionally, the release of modifica-
as functional and capability requirements, software tions must align with the provisions specified in 5.8
63
(Software Release for Utilization at a System Level),
but these requirements are frequently not fulfilled.
4. Experience-based Solution
In clause 7 (Software Risk Management Process),
there is a failure to maintain the risk management of Based on experience, various solutions, including
software changes under sub-clause 7.4. The manufac- short course training (onsite training), information on
turer must identify hazardous situations, conduct risk websites, and other technologies, have been explored
analysis, and implement software risk control to address the challenges highlighted in the preceding
measures corresponding to those situations. This en- section.
sures an evaluation of potential hazards that may arise Short course training emerges as a promising solu-
following software changes. tion, offering instructors who elucidate the nature and
In clause 8 (Software Configuration Management ecosystem of IEC 62034 [1]. The exercises conducted
Process), most cases fail in sub-clause 8.2 (Change during these courses prove beneficial in helping train-
Control). Manufacturers must identify and perform ees grasp the concepts and context of IEC 62304 [1].
any activities that need to be repeated due to the However, the associated costs of short course training
change, including changes to the software safety clas- can be prohibitively high, and the inflexible location
sification of software systems and software items. and schedule may pose challenges for trainees. While
However, manufacturers often fail to verify the change, hiring a consultant is an effective solution, its afforda-
neglecting to repeat any verification invalidated by the bility remains a concern for manufacturers. Alterna-
change and failing to account for 5.7 (Software System tively, numerous websites provide information and ex-
Testing) and 9.7. Additionally, in sub-clause 8.3, most planations on IEC 62304 [1] but lack a structured out-
manufacturers fail to retain retrievable records of the line or instructions on applying the standards and pro-
history of controlled configuration items. ducing required documents.
For clause 9 (Software Problem Resolution Pro- A potential solution lies in the utilization of chat-
cess), most manufacturers failed to identify and pre- bots. These AI-powered tools offer a simple, quick, and
sent the process for problem reporting, investigating, flexible means of assisting manufacturers in creating
and evaluating emerging problems and communi- IEC 62304 [1] documentation. Embedding chatbots
cating the problem's existence to relevant parties, as into websites or instant messaging software can offer
appropriate. The manufacturer approves and imple- support for IEC 62304 [1] knowledge. The recent re-
ments all change requests, ensuring adherence to the lease of ChatGPT [20] provides an opportunity, alt-
requirements of the change control process. Further- hough developing a similar chatbot poses challenges.
more, the manufacturer maintains records of problem This chatbot can be divided into two parts: one for
reports and their resolution, including verification, learning user-entered keywords and sentences and
and updates the risk management file as appropriate. another for understanding the regulatory framework,
Additionally, the manufacturer analyzes to detect including IEC 62304 [1]. This involves training the bot
trends in problem reports. Conducting testing, retest- to fetch essential template links and files for users. The
ing, or regression testing of software items and sys- chosen technology for this endeavor is Botpress [21],
tems after changes is essential. The manufacturer is re- primarily because of its compatibility with WordPress
quired to include the following elements in the test websites, enabling seamless chatbot integration into
documentation: a) test results, b) anomalies found, c) an existing platform.
the version of software tested, d) relevant hardware The Botpress [21] architecture for addressing in-
and software test configurations, e) relevant test tools, quiries related to the IEC 62304 [1] standard is struc-
f) date of the test, and g) identification of the tester. tured to provide an intelligent and adaptable chatbot
The obstacles that resulted in unsuccessful MDS experience. Users interact with the system via a user
evaluations primarily stemmed from language transla- interface connected to the Botpress Core [21]. The In-
tion issues and a limited understanding of the inter- tegration with Generative AI [22], exemplified by mod-
connected nature of Software Engineering and IEC els like GPT-3 [23], enhances language understanding
62304 [1]. These challenges led to incomplete docu- and facilitates content generation. User inputs un-
ment submissions, generating uncertainty about the dergo Natural Language Processing (NLP) [24] to iden-
necessary content inclusion. Additionally, manufactur- tify intent and context, directing queries to the IEC
ers, mainly with an engineering background, encoun- 62304 Query Handler, which interprets and retrieves
tered difficulties comprehending the standard's con- relevant information from the knowledge base. Exter-
textual nuances. Lastly, adherence to IEC 62304 [1] nal resources are accessed through connectors, and an
guidelines faced constraints due to copyright limita- AI training interface ensures ongoing knowledge base
tions. updates. The architecture incorporates security
The challenges identified in the MDS evaluation measures, logging, analytics tools for user interactions,
process underscore the critical need for targeted solu- multi-channel support, and a continuous improvement
tions to enhance understanding, compliance, and effec- module that collects feedback for iterative enhance-
tive documentation, particularly in adherence to IEC ment. The workflow of Botpress [21] is illustrated in
62304 [1]. The issues identified, such as language Figure 5.
translation complexities, limited comprehension of In conclusion, exploring solutions based on a range
software engineering principles, and constraints re- of experiences emphasizes the potential of chatbots
lated to copyright, highlight the intricate landscape and generative AI to address challenges in compre-
that manufacturers navigate during the evaluation hending and applying IEC 62304 standards [1].
process.
64
User inputs an inquiry related to IEC 62304. [5] "IEC 60601-1:2005+AMD1:2012+AMD2:2020
1
CSV | IEC Webstore." https://webstore.iec.ch/
2
NLP processes the input and identifies the intent and entities. publication/67497.
The IEC 62304 Query Handler fetches relevant information from
[6] "Thai FDA" https://en.fda.moph.go.th/ home.
3 the knowledge base. [7] "Health Sciences Authority (HSA)."
Generative AI enhances language understanding and generates https://www.hsa.gov.sg (accessed 2022-08-23).
4 detailed responses. [8] "FDA THAI: Food and Drug Administration, Thai-
External resources are accessed and provided to the user. land." [Online]. https://en.fda.moph.go.th/entre-
5
preneurs-medical-devices/category/how-to-ap-
6
User feedback is collected for continuous improvement. ply-for-permission-on-medical-devices/.
[9] T. G. Administration. "Therapeutic Goods Admin-
Figure 5: Workflow of Botpress [21]. istration (TGA) | Australian Government Depart-
ment of Health." https://www.tga.gov.au/
[10] T. Granlund, T. Mikkonen, and V. Stirbu, "On med-
5. Conclusion ical device software CE compliance and conform-
ity assessment," in 2020 IEEE International Con-
In conclusion, the presented guidelines for improving ference on software architecture companion
MDS assessment in Thailand offer a comprehensive (ICSA-C), 2020: IEEE, pp. 185-191.
framework to enhance MDS's quality, safety, and regu- [11] "CE marking," https://single-market-econ-
latory compliance. The importance of adhering to in- omy.ec.europa.eu/single-market/ce-mark-
ternational standards, such as IEC 62304 [1], ISO ing_en.
13485 [3], and ISO 14971 [2], has been underscored [12] "European Commission, official website,"
throughout the guidelines, emphasizing the need for a 2023/11/15/ 2023. https://commission.eu-
robust quality management system. ropa.eu/index_en.
Incorporating innovative solutions, including inte- [13] CONSIL, (1993, 1993/06/14/). OJ L 169, Council
grating chatbots using technologies like Botpress [21], Directive 93/42/EEC of 14 June 1993 concerning
showcases a forward-looking approach to addressing medical devices.
challenges in understanding and implementing com- [14] "MEDDEV Guidance List - Download," in Medical
plex standards. By leveraging AI-driven tools, manu- Device Regulation, ed.
facturers can benefit from quick, flexible, and accessi- [15] A. Ceross and J. Bergmann, "Evaluating the pres-
ble support in creating IEC 62304 [1] documentation, ence of software-as-a-medical-device in the Aus-
ultimately contributing to streamlined processes and tralian therapeutic goods register," Prosthesis,
improved compliance. vol. 3, no. 3, pp. 221-228, 2021 2021.
Furthermore, the guidelines advocate for a contin- [16] "Software Quality Testing Laboratory (SQUAT)."
uous improvement mindset, focusing on ongoing train- https://www.squat.in.th/.
ing, user feedback, and data analysis to adapt to evolv- [17] "ISO - ISO/IEC 17025 — Testing and calibration
ing standards and industry best practices. The empha- laboratories," ISO, 2021/01/26/ 2021. [Online].
sis on multi-channel support, security measures, and Available: https://www.iso.org/ISO-IEC-17025-
the incorporation of generative AI highlights a commit- testing-and-calibration-laboratories.html.
ment to creating a comprehensive and user-friendly [18] "Thai Industrial Standards Institute (TISI)."
ecosystem for MDS assessment. https://www.tisi.go.th/home/en.
Overall, these guidelines provide a roadmap for [19] "Home - NECTEC: National Electronics and Com-
manufacturers, assessors, and regulatory bodies in puter Technology Center," ed, 2007.
Thailand to navigate the intricate landscape of MDS as- [20] "Introducing ChatGPT,". https://openai.com/
sessment, fostering a culture of quality, innovation, blog/chatgpt.
and regulatory adherence in the rapidly advancing [21] "Botpress | the Generative AI platform for
field of healthcare technology. ChatGPT Chatbots," https://botpress.com/.
[22] "Generative AI", Generative AI. https://genera-
tiveai.net.
References [23] "GPT-3," in Wikipedia, ed, 2023.
[24] "Natural language processing," in Wikipedia, ed,
[1] ISO. "IEC 62304:2006/Amd 1:2015 Medical de- 2023.
vice software - Software life cycle processes -
Amendment 1." https://www.iso.org/stand-
ard/64686.html.
[2] ISO. "ISO 14971:2019 Medical devices - Applica-
tion of risk management to medical devices."
https://www.iso.org/standard/72704.html.
[3] ISO. "ISO 13485:2016." https://www.iso.org/
iso-13485-medical-devices.html.
[4] "FDA THAI: Food and Drug Administration, Thai-
land." https://en.fda.moph.go.th/entrepreneurs-
medical-devices/category/how-to-apply-for-
permission-on-medical-devices/.
65