Le Forum des Dispositifs Médicaux
Application de la règlementation à un logiciel en partie DM
Citation de Benoit ROUSSEAU le 5 février 2021, 8 h 48 minBonjour,
Je voulais avoir votre avis sur le cas suivant :
Nous avons un logiciel d'aide à la prescription qui tombe dans la règlementation du DM car il possède un élément logiciel dit "ordonnance".
Cet élément logiciel utilise directement une unité logicielle "Données physiologiques" d'un autre élément logiciel "Patient".
Peut-on appliquer la stratégie suivante :
Application de la règlementation uniquement à ces 2 éléments logiciels (Ordonnance et Patient), en justifiant que les autres éléments logiciels n'ont pas d'impact sur ces 2 là et ne contiennent aucune fonction DM.
Ou bien, à partir du moment où un logiciel tombe dans la réglementation DM, faut-il appliquer la règlementation à tous les éléments logiciels de ce dernier, avec la différenciation des classes possibles. Les autres EL seront de classe A alors que les 2 EL concernés seront de classe C.
Merci par avance pour vos retours et avis sur cette question.
Cordialement,
Benoit
Bonjour,
Je voulais avoir votre avis sur le cas suivant :
Nous avons un logiciel d'aide à la prescription qui tombe dans la règlementation du DM car il possède un élément logiciel dit "ordonnance".
Cet élément logiciel utilise directement une unité logicielle "Données physiologiques" d'un autre élément logiciel "Patient".
Peut-on appliquer la stratégie suivante :
Application de la règlementation uniquement à ces 2 éléments logiciels (Ordonnance et Patient), en justifiant que les autres éléments logiciels n'ont pas d'impact sur ces 2 là et ne contiennent aucune fonction DM.
Ou bien, à partir du moment où un logiciel tombe dans la réglementation DM, faut-il appliquer la règlementation à tous les éléments logiciels de ce dernier, avec la différenciation des classes possibles. Les autres EL seront de classe A alors que les 2 EL concernés seront de classe C.
Merci par avance pour vos retours et avis sur cette question.
Cordialement,
Benoit
Citation de Alexandre CR le 5 février 2021, 11 h 15 minBonjour,
Oui c'est possible, un guide du MDCG en parle : https://ec.europa.eu/docsroom/documents/37581?locale=en
Maintenant la question délicate est de savoir comment on isole au maximum le module concerné du reste du système ?
Comme vous dites, vous devez justifier que les autres éléments, n'impactent pas les performances et la sécurité du module pour lequel la règlementation des DM s'applique. C'est quelque chose qui me semble assez complexe à mettre en oeuvre. Aussi, j'aurais tendance à penser qu'il est préférable de faire certifier le système complet quitte à séparer, comme vous dites, les différents modules en fonction des classes de sécurité.
Mais ça reste un avis personnel...
Bonjour,
Oui c'est possible, un guide du MDCG en parle : https://ec.europa.eu/docsroom/documents/37581?locale=en
Maintenant la question délicate est de savoir comment on isole au maximum le module concerné du reste du système ?
Comme vous dites, vous devez justifier que les autres éléments, n'impactent pas les performances et la sécurité du module pour lequel la règlementation des DM s'applique. C'est quelque chose qui me semble assez complexe à mettre en oeuvre. Aussi, j'aurais tendance à penser qu'il est préférable de faire certifier le système complet quitte à séparer, comme vous dites, les différents modules en fonction des classes de sécurité.
Mais ça reste un avis personnel...
Citation de Benoit ROUSSEAU le 5 février 2021, 16 h 42 minMerci beaucoup pour cette réponse et pour le pointage vers ce MDCG que je n'avais pas encore lu.
Je pense en effet que tout dépend de la capacité de l'éditeur à justifier de la séparation des modules DM et non DM. Lorsque la séparation n'est pas claire et nette, il vaut mieux appliquer le règlement à tout le système.
Merci beaucoup pour cette réponse et pour le pointage vers ce MDCG que je n'avais pas encore lu.
Je pense en effet que tout dépend de la capacité de l'éditeur à justifier de la séparation des modules DM et non DM. Lorsque la séparation n'est pas claire et nette, il vaut mieux appliquer le règlement à tout le système.
Citation de Clémence Piquart le 5 février 2021, 17 h 07 minil vaut mieux appliquer le règlement à tout le système.
C'est la tendance du PR IEC 62304 ed2.0 (actuellement en enquête publique) qui concerne le Health software au sens large, pointe un certain nombre de normes Health IT.
Je vous invite à lire PR IEC 62304 2021: Table C.1 – Useful SECURITY standards pour vous aider à borner les limites de votre health software.
Cdt,
Mathilde
il vaut mieux appliquer le règlement à tout le système.
C'est la tendance du PR IEC 62304 ed2.0 (actuellement en enquête publique) qui concerne le Health software au sens large, pointe un certain nombre de normes Health IT.
Je vous invite à lire PR IEC 62304 2021: Table C.1 – Useful SECURITY standards pour vous aider à borner les limites de votre health software.
Cdt,
Mathilde
Citation de Benoit ROUSSEAU le 20 avril 2021, 15 h 45 minBonjour Mathilde (@valotec ),
Je reviens sur votre dernière réponse, un peu tardivement, mais toujours d'actualité.
Je n'ai pas pu accéder au PR IEC 62304 2021: Table C.1 – Useful SECURITY standards, savez-vous s'il est disponible en accès libre ou s'il faut se procurer une licence de la norme, même si elle est toujours en projet ?
Merci par avance,
Bonjour Mathilde (@valotec ),
Je reviens sur votre dernière réponse, un peu tardivement, mais toujours d'actualité.
Je n'ai pas pu accéder au PR IEC 62304 2021: Table C.1 – Useful SECURITY standards, savez-vous s'il est disponible en accès libre ou s'il faut se procurer une licence de la norme, même si elle est toujours en projet ?
Merci par avance,
Citation de Clémence Piquart le 20 avril 2021, 16 h 14 minBonjour @benoit-rousseau,
Vous pouvez m'envoyer un mail (Annuaire des Expert·e·s en Dispositifs médicaux)
Cdt,
Mathilde
Bonjour @benoit-rousseau,
Vous pouvez m'envoyer un mail (Annuaire des Expert·e·s en Dispositifs médicaux)
Cdt,
Mathilde
Citation de Guillaume Promé le 21 avril 2021, 6 h 01 minSuper useful l'annexe 😵
Super useful l'annexe 😵
Citation de Clémence Piquart le 21 avril 2021, 6 h 58 minET pas que ...
Table C.1 – Useful SECURITY standards SECURITY standard Description 1 AAMI TIR 57 [41] Provides guidance on methods to perform information SECURITY RISK MANAGEMENT for a MEDICAL DEVICE in the context of the SAFETY RISK
MANAGEMENT PROCESS required by ISO 14971. The TIR incorporates the expanded view of RISK MANAGEMENT from IEC 80001-1 by incorporating the same key properties of SAFETY, effectiveness and data and SYSTEMS SECURITY with annexes that provide PROCESS details and illustrative examples.AAMI TIR 97 [43] Provides guidance on methods to perform postmarket security risk management for a medical device in the context of the Safety Risk Management process required by ISO 14971. This TIR is intended to be used in conjunction with AAMI TIR57:2016 2 IEC 80001-1 [11] Recognizing that MEDICAL DEVICES are incorporated into IT-networks to achieve desirable benefits (for example, interoperability), defines the roles, responsibilities and activities that are necessary for RISK
MANAGEMENT of IT-networks incorporating MEDICAL DEVICES to address
SAFETY, effectiveness and data and SYSTEM SECURITY (the key properties). It applies to responsible organizations, MEDICAL DEVICE MANUFACTURERS and providers of other information technology for the purpose of RISK
MANAGEMENT of an IT-network incorporating MEDICAL DEVICES as specified by the responsible organization.3 IEC TR 80001-2-2 [12] Creates a framework for the disclosure of SECURITY-related capabilities and RISKS necessary for managing the RISK in connecting MEDICAL
DEVICES to IT-networks and for the SECURITY dialog that surrounds the IEC 80001-1 RISK MANAGEMENT of IT-network connection. This SECURITY report presents an informative set of common, high-level SECURITY-related capabilities useful in understanding the user needs, the type of SECURITY controls to be considered and the RISKS that lead to the controls.4 IEC TR 80001-2-8 [13] Provides guidance to health delivery organizations (HDOs) and MEDICAL DEVICE MANUFACTURERS (MDMs) for the application of the framework outlined in IEC TR 80001-2-2. The report presents the 19 SECURITY capabilities, their respective "requirement goal" and "user need" (identical to that in IEC TR 80001-2-2) with a corresponding list of SECURITY controls from a number of SECURITY standards. IEC 80001-5-1 [44] Defines the secure Lifecycle requirements for development and Maintenance of Health Software. The set of Processes, activities, and tasks described in this document establishes a common framework for secure Health Software Lifecycle Processes. 5 ISO/IEC 15408-1 [24] ISO/IEC 15408-1 is the introduction to the ISO/IEC 15408 series. It defines general concepts and principles of IT SECURITY EVALUATION and presents a general model of EVALUATION. ISO/IEC 15408-1 also presents constructs for expressing IT SECURITY objectives, for selecting and defining IT SECURITY requirements, and for writing high-level specifications for products and SYSTEMS. In addition, the usefulness of each part of the ISO/IEC 15408 series is described in terms of each of the target audiences. 6 ISO/IEC 15408-2 [25] ISO/IEC 15408-2 defines the content and presentation of the SECURITY functional requirements to be assessed in a SECURITY EVALUATION using the ISO/IEC 15408 series. It contains a comprehensive catalogue of predefined SECURITY functional components that will meet most common SECURITY needs of the marketplace. These are organized using a hierarchical structure of classes, families and components, and supported by comprehensive user notes. 7 ISO/IEC 27001 [34] Describes best practice for an information SECURITY management system (ISMS). 8 ISO/IEC 27002 [35] Outlines guidelines for organizational information SECURITY standards and information SECURITY management practices including the selection, implementation and management of controls taking into consideration the organization's information SECURITY RISK environment(s). 9 ISO 27799 [19] Defines guidelines to support the interpretation and implementation in health informatics of ISO/IEC 27002 and is a companion to that standard. It specifies a set of detailed controls for managing health information
SECURITY and provides health information SECURITY best practice guidelines.SECURITY standard Description 10 ISO/IEC 27005 [36] Supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information SECURITY based on a RISK MANAGEMENT approach. 11 IEC TS 62443-1-1 [6] Defines the terminology, concepts and models for industrial automation and control systems (IACS) security. 12 IEC TR 62443-3-1 [7] Provides a current assessment of various cybersecurity tools, mitigation counter-measures, and technologies that can effectively apply to the modern electronically based IACSs. 13 IEC 62443-4-1 [8] Specifies the PROCESS requirements for the secure development of products used in industrial automation and control systems (IACSs).
The life cycle description includes SECURITY requirements definition, secure design, secure implementation (including coding guidelines), VERIFICATION and VALIDATION, defect management, patch management and product end-of-life. These requirements can be applied to new or existing PROCESSES for developing, maintaining and retiring hardware, software or firmware.14 IEC 62443-4-2 [9] Provides detailed technical control SYSTEM component requirements associated with the seven foundational requirements described in
IEC TS 62443-1-1 including defining the requirements for control SYSTEM
capability SECURITY levels and their components.15 UL 2900-2-1 [45] Describes the method by which the SECURITY RISK CONTROLS of healthcare SYSTEM components shall be evaluated and tested for known vulnerabilities, software weaknesses and malware while also establishing a foundational set of VERIFICATION activities intended to reduce the likelihood of exploitable weaknesses that could be vectors of zero day vulnerabilities that can affect the component.
ET pas que ...
| Table C.1 – Useful SECURITY standards | ||
| SECURITY standard | Description | |
| 1 | AAMI TIR 57 [41] | Provides guidance on methods to perform information SECURITY RISK MANAGEMENT for a MEDICAL DEVICE in the context of the SAFETY RISK MANAGEMENT PROCESS required by ISO 14971. The TIR incorporates the expanded view of RISK MANAGEMENT from IEC 80001-1 by incorporating the same key properties of SAFETY, effectiveness and data and SYSTEMS SECURITY with annexes that provide PROCESS details and illustrative examples. |
| AAMI TIR 97 [43] | Provides guidance on methods to perform postmarket security risk management for a medical device in the context of the Safety Risk Management process required by ISO 14971. This TIR is intended to be used in conjunction with AAMI TIR57:2016 | |
| 2 | IEC 80001-1 [11] | Recognizing that MEDICAL DEVICES are incorporated into IT-networks to achieve desirable benefits (for example, interoperability), defines the roles, responsibilities and activities that are necessary for RISK MANAGEMENT of IT-networks incorporating MEDICAL DEVICES to address SAFETY, effectiveness and data and SYSTEM SECURITY (the key properties). It applies to responsible organizations, MEDICAL DEVICE MANUFACTURERS and providers of other information technology for the purpose of RISK MANAGEMENT of an IT-network incorporating MEDICAL DEVICES as specified by the responsible organization. |
| 3 | IEC TR 80001-2-2 [12] | Creates a framework for the disclosure of SECURITY-related capabilities and RISKS necessary for managing the RISK in connecting MEDICAL DEVICES to IT-networks and for the SECURITY dialog that surrounds the IEC 80001-1 RISK MANAGEMENT of IT-network connection. This SECURITY report presents an informative set of common, high-level SECURITY-related capabilities useful in understanding the user needs, the type of SECURITY controls to be considered and the RISKS that lead to the controls. |
| 4 | IEC TR 80001-2-8 [13] | Provides guidance to health delivery organizations (HDOs) and MEDICAL DEVICE MANUFACTURERS (MDMs) for the application of the framework outlined in IEC TR 80001-2-2. The report presents the 19 SECURITY capabilities, their respective "requirement goal" and "user need" (identical to that in IEC TR 80001-2-2) with a corresponding list of SECURITY controls from a number of SECURITY standards. |
| IEC 80001-5-1 [44] | Defines the secure Lifecycle requirements for development and Maintenance of Health Software. The set of Processes, activities, and tasks described in this document establishes a common framework for secure Health Software Lifecycle Processes. | |
| 5 | ISO/IEC 15408-1 [24] | ISO/IEC 15408-1 is the introduction to the ISO/IEC 15408 series. It defines general concepts and principles of IT SECURITY EVALUATION and presents a general model of EVALUATION. ISO/IEC 15408-1 also presents constructs for expressing IT SECURITY objectives, for selecting and defining IT SECURITY requirements, and for writing high-level specifications for products and SYSTEMS. In addition, the usefulness of each part of the ISO/IEC 15408 series is described in terms of each of the target audiences. |
| 6 | ISO/IEC 15408-2 [25] | ISO/IEC 15408-2 defines the content and presentation of the SECURITY functional requirements to be assessed in a SECURITY EVALUATION using the ISO/IEC 15408 series. It contains a comprehensive catalogue of predefined SECURITY functional components that will meet most common SECURITY needs of the marketplace. These are organized using a hierarchical structure of classes, families and components, and supported by comprehensive user notes. |
| 7 | ISO/IEC 27001 [34] | Describes best practice for an information SECURITY management system (ISMS). |
| 8 | ISO/IEC 27002 [35] | Outlines guidelines for organizational information SECURITY standards and information SECURITY management practices including the selection, implementation and management of controls taking into consideration the organization's information SECURITY RISK environment(s). |
| 9 | ISO 27799 [19] | Defines guidelines to support the interpretation and implementation in health informatics of ISO/IEC 27002 and is a companion to that standard. It specifies a set of detailed controls for managing health information SECURITY and provides health information SECURITY best practice guidelines. |
| SECURITY standard | Description | |
| 10 | ISO/IEC 27005 [36] | Supports the general concepts specified in ISO/IEC 27001 and is designed to assist the satisfactory implementation of information SECURITY based on a RISK MANAGEMENT approach. |
| 11 | IEC TS 62443-1-1 [6] | Defines the terminology, concepts and models for industrial automation and control systems (IACS) security. |
| 12 | IEC TR 62443-3-1 [7] | Provides a current assessment of various cybersecurity tools, mitigation counter-measures, and technologies that can effectively apply to the modern electronically based IACSs. |
| 13 | IEC 62443-4-1 [8] | Specifies the PROCESS requirements for the secure development of products used in industrial automation and control systems (IACSs). The life cycle description includes SECURITY requirements definition, secure design, secure implementation (including coding guidelines), VERIFICATION and VALIDATION, defect management, patch management and product end-of-life. These requirements can be applied to new or existing PROCESSES for developing, maintaining and retiring hardware, software or firmware. |
| 14 | IEC 62443-4-2 [9] | Provides detailed technical control SYSTEM component requirements associated with the seven foundational requirements described in IEC TS 62443-1-1 including defining the requirements for control SYSTEM capability SECURITY levels and their components. |
| 15 | UL 2900-2-1 [45] | Describes the method by which the SECURITY RISK CONTROLS of healthcare SYSTEM components shall be evaluated and tested for known vulnerabilities, software weaknesses and malware while also establishing a foundational set of VERIFICATION activities intended to reduce the likelihood of exploitable weaknesses that could be vectors of zero day vulnerabilities that can affect the component. |
Citation de Guillaume Promé le 21 avril 2021, 7 h 33 minC'est laquelle ta préférée ?
C'est laquelle ta préférée ?
Citation de Benoit ROUSSEAU le 21 avril 2021, 8 h 06 minOuuuf, il y a à boire et à manger dans tout ça ! Si avec ça, les logiciels ne sont pas secure ;-)
Merci Mathilde pour la table des normes. Y en a-t-il une en particulier que vous me conseillez pour ma question d'isolement de E.L au sein d'un même système logiciel ?
Je connais déjà les règles classiques : pas de mémoire partagée ou processeur différent mais je cherche d'autres potentielles techniques lorsque ces 2 là ne sont pas possibles....
Ouuuf, il y a à boire et à manger dans tout ça ! Si avec ça, les logiciels ne sont pas secure ;-)
Merci Mathilde pour la table des normes. Y en a-t-il une en particulier que vous me conseillez pour ma question d'isolement de E.L au sein d'un même système logiciel ?
Je connais déjà les règles classiques : pas de mémoire partagée ou processeur différent mais je cherche d'autres potentielles techniques lorsque ces 2 là ne sont pas possibles....
Citation de Martin Brochu le 21 avril 2021, 11 h 51 minBonjour Monsieur Rousseau,
je n'ai pas de normes qui peuvent répondre à cette question mais éventuellement un guidance FDA qui pourrait vous donner des pistes sur les methodes de séparation à appliquer en page 6 et 7 du guidance ci après:
https://www.fda.gov/media/112671/download
En espérant que ce document pourra vous aider.
Bonjour Monsieur Rousseau,
je n'ai pas de normes qui peuvent répondre à cette question mais éventuellement un guidance FDA qui pourrait vous donner des pistes sur les methodes de séparation à appliquer en page 6 et 7 du guidance ci après:
https://www.fda.gov/media/112671/download
En espérant que ce document pourra vous aider.
Citation de Guillaume Promé le 21 avril 2021, 11 h 57 minY en a-t-il une en particulier que vous me conseillez pour ma question d'isolement de E.L au sein d'un même système logiciel ?
Malheureusement ces normes ne donnent pas de conseils techniques, elles vous diront de gérer les risques et de bien concevoir l'architecture
Y en a-t-il une en particulier que vous me conseillez pour ma question d'isolement de E.L au sein d'un même système logiciel ?
Malheureusement ces normes ne donnent pas de conseils techniques, elles vous diront de gérer les risques et de bien concevoir l'architecture
Citation de Benoit ROUSSEAU le 21 avril 2021, 12 h 32 minMerci Martin pour ce document qui en effet va me permettre d'avancer sur mes réflexions de séparation de modules logiciels.
Entre autre, j'aime bien la page 10 qui donne quelques questions classiques à se poser en posant une analyse de risque spécifique pour déterminer si l'isolement d'un module est suffisant.
Merci Martin pour ce document qui en effet va me permettre d'avancer sur mes réflexions de séparation de modules logiciels.
Entre autre, j'aime bien la page 10 qui donne quelques questions classiques à se poser en posant une analyse de risque spécifique pour déterminer si l'isolement d'un module est suffisant.
Citation de Clémence Piquart le 21 avril 2021, 13 h 20 minBonjour,
Cette liste de normes à la Prévert pour illustrer la 80001-1 Family c'est à la fois trop dense, répétitif et pas très orientée prêt à l'emploi. Cependant elles vont toutes -bien que maladroitement- dans le sens de bien spécifier, bien concevoir, documenter, tester, retester, surveiller "un ensemble cohérent de boites blanches ou gris très claires'. Investir du temps en début de projet pour décrire l'effort pour construire un logiciel en base boites blanches, c'est une pratique d'expérience assez rentable.
La suggestion de généraliser une logique de découpage en EL, me semble judicieuse. Cependant, de ma connaissance, la partie Logiciel DM aura une granularité mailles fines, alors que la partie Health IT se composera de moyennes et grosses mailles.
- bien déterminer les interfaces entre bloc Health IT
- spécifier tôt le plan de test, et itérer pour intégrer au fil de l'eau les démarches de tests fiabilisés.
- (pas obliger de dérouler toute la 62304 si déjà une archi bien bornée par le test a été définie pour la partie Health IT - on reste sur l'équivalent classe A)
J'utilise les guides blancs type DevOps appliqué au IT de santé pour identifier les bonnes pratiques du test-driven development . En fait je m'inspire des bonnes pratiques généralistes de robustification du logiciel- Approche logiciel 'craftman' en basant sur ce qui a fait ses preuves sur le terrain.
Merci @m-brochu pour la guidance.
Cordialement,
Mathilde
Bonjour,
Cette liste de normes à la Prévert pour illustrer la 80001-1 Family c'est à la fois trop dense, répétitif et pas très orientée prêt à l'emploi. Cependant elles vont toutes -bien que maladroitement- dans le sens de bien spécifier, bien concevoir, documenter, tester, retester, surveiller "un ensemble cohérent de boites blanches ou gris très claires'. Investir du temps en début de projet pour décrire l'effort pour construire un logiciel en base boites blanches, c'est une pratique d'expérience assez rentable.
La suggestion de généraliser une logique de découpage en EL, me semble judicieuse. Cependant, de ma connaissance, la partie Logiciel DM aura une granularité mailles fines, alors que la partie Health IT se composera de moyennes et grosses mailles.
- bien déterminer les interfaces entre bloc Health IT
- spécifier tôt le plan de test, et itérer pour intégrer au fil de l'eau les démarches de tests fiabilisés.
- (pas obliger de dérouler toute la 62304 si déjà une archi bien bornée par le test a été définie pour la partie Health IT - on reste sur l'équivalent classe A)
J'utilise les guides blancs type DevOps appliqué au IT de santé pour identifier les bonnes pratiques du test-driven development . En fait je m'inspire des bonnes pratiques généralistes de robustification du logiciel- Approche logiciel 'craftman' en basant sur ce qui a fait ses preuves sur le terrain.
Merci @m-brochu pour la guidance.
Cordialement,
Mathilde
Citation de Benoit ROUSSEAU le 22 avril 2021, 9 h 31 minMerci beaucoup Mathilde (@valotec) pour votre réponse détaillée et très pertinente.
Je ne connaissais pas cette approche logicielle 'craftman', très intéressant ! Je suis toujours avide de connaitre de nouvelles méthodes de développement logiciel qui peuvent améliorer la qualité de la production des applis. Je peux ainsi conseillé mes clients qui au mieux, applique du Scrum, que j'essaye d'adapter à la 62304 (en particulier sur les blocs de classe C).
Merci beaucoup Mathilde (@valotec) pour votre réponse détaillée et très pertinente.
Je ne connaissais pas cette approche logicielle 'craftman', très intéressant ! Je suis toujours avide de connaitre de nouvelles méthodes de développement logiciel qui peuvent améliorer la qualité de la production des applis. Je peux ainsi conseillé mes clients qui au mieux, applique du Scrum, que j'essaye d'adapter à la 62304 (en particulier sur les blocs de classe C).
Citation de Benoit ROUSSEAU le 7 juin 2022, 17 h 08 minPour rouvrir ce sujet, j'ai trouvé une nouvelle piste côté FDA sur la séparation de fonctions DM et non DM : https://www.fda.gov/media/112671/download
Avez-vous déjà appliquer ce guide, en particulier pour un logiciel qui contient des modules DM et d'autres non DM ?
Cordialement,
Pour rouvrir ce sujet, j'ai trouvé une nouvelle piste côté FDA sur la séparation de fonctions DM et non DM : https://www.fda.gov/media/112671/download
Avez-vous déjà appliquer ce guide, en particulier pour un logiciel qui contient des modules DM et d'autres non DM ?
Cordialement,
Citation de Martin Brochu le 8 juin 2022, 8 h 04 minCitation de Benoit ROUSSEAU le 7 juin 2022, 17 h 08 minPour rouvrir ce sujet, j'ai trouvé une nouvelle piste côté FDA sur la séparation de fonctions DM et non DM : https://www.fda.gov/media/112671/download
Avez-vous déjà appliquer ce guide, en particulier pour un logiciel qui contient des modules DM et d'autres non DM ?
Cordialement,
Bonjour @benoit-rousseau,
c'était en effet le document dont j'avais parlé en avril 2021, pour pouvoir l'utiliser il faut avoir lors de la conception du logiciel avoir eu recours à l'ingénierie logiciel, et avoir une architecture logiciel qui sépare les fonctions DM des fonctions non DM.
Citation de Benoit ROUSSEAU le 7 juin 2022, 17 h 08 minPour rouvrir ce sujet, j'ai trouvé une nouvelle piste côté FDA sur la séparation de fonctions DM et non DM : https://www.fda.gov/media/112671/download
Avez-vous déjà appliquer ce guide, en particulier pour un logiciel qui contient des modules DM et d'autres non DM ?
Cordialement,
Bonjour @benoit-rousseau,
c'était en effet le document dont j'avais parlé en avril 2021, pour pouvoir l'utiliser il faut avoir lors de la conception du logiciel avoir eu recours à l'ingénierie logiciel, et avoir une architecture logiciel qui sépare les fonctions DM des fonctions non DM.