Le Forum des Dispositifs Médicaux

Veuillez pour créer des messages et des sujets de discussion.

Application de la règlementation à un logiciel en partie DM

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

 

 

 

 

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...

 

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.

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

 

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,

 

 

Bonjour @benoit-rousseau,

Vous pouvez m'envoyer un mail (Annuaire des Expert·e·s en Dispositifs médicaux)

Cdt,

Mathilde

Super useful l'annexe 😵

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.

C'est laquelle ta préférée ?

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....

 

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.

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

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.

 

 

 

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

 

 

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).

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 Benoit ROUSSEAU le 7 juin 2022, 17 h 08 min

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,

 

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.