Besoin d’aide ? Toutes les réponses et ressources utiles pour les ENS

Le corpus documentaire associé au projet DRIM-M spécifie que les différents logiciels DRIMBox déployés doivent effectuer une récupération quotidienne du fichier de liste blanche mis à disposition par l'ANS. Suite à chacune de ces récupérations, le fichier de liste blanche obtenu doit être vérifié afin de prévenir d'éventuelles corruptions de celui-ci. 
Le processus de contrôle du fichier de liste blanche implique une vérification de la signature qui lui est associée . Pour cela, les informations mentionnées au sein du tag "X509Data" du document liste blanche doivent être exploitées. Ces données correspondent aux principales caractéristiques du certificat utilisé afin de signer le fichier de liste blanche ANS. 
Tel qu'indiqué au sein de la spécification projet DRIMBox, nous préconisons l'utilisation de l'outil eSignSanté afin de valider la conformité de la signature associée au fichier de liste blanche ANS (pour plus de précisions concernant cet outil, voir https://github.com/ansforge/esignsante). 
En complément, nous pouvons indiquer que dans le cadre de l'homologation SEGUR vague 2 DRIM-M, une preuve de mise en oeuvre du processus de vérification de la signature est demandée. Dans ce contexte, les informations suivantes peuvent permettre de répondre à certaines interrogations :   
* Autorité à l'origine de l'émission du certificat utilisé pour la signature de la liste blanche de test : http://igc-sante.esante.gouv.fr/AC%20TEST/ACI-EL-ORG-TEST.cer. 
* CRL associée au certificat  utilisé pour la signature de la liste blanche de test : http://igc-sante.esante.gouv.fr/CRL/ACI-EL-ORG-TEST.crl. 
* Le certificat à mettre en oeuvre afin de signer la preuve de vérification de la signature associée à la liste blanche de test doit être propre à chaque éditeur de solution DRIMBox. Ainsi, dans le cas où l'outil eSignSanté est utilisé, le fichier de configuration "config.json" doit être complété avec un certificat propriétaire au niveau de la section "proof". 

Le corpus documentaire associé au projet DRIM-M n’impose pas de mise en œuvre d’une fonctionnalité de filtrage IP dans le cadre de l’implémentation du service Healthcheck par les logiciels DRIMBox. 
Cependant, si pour des raisons de sécurité ou autre un éditeur de logiciel DRIMBox souhaite que cette opération de filtrage ait lieu, alors l’implémentation de celle-ci doit inclure une composante flexible afin de pouvoir suivre les évolutions liées au contenu de la whitlelist des adresses IP utilisées par les sondes healthcheck. 
Une mise à jour « dynamique » de la whitelist des adresses IP associées aux sondes healthcheck semble dont être la solution à privilégier. Afin d’implémenter ce processus, nous vous invitons à consulter la page de questions utilisateurs associée au service BetterStack : https://betterstack.com/docs/uptime/frequently-asked-questions/#looking-for-a-machine-readable-list. Il y est notamment indiqué que la whitelist des adresses IP peut être récupérée de manière automatique au format .txt ou .json. Ce fichier mentionne les adresses IPv4 de l'exhaustivité des sondes déployées par BetterStack.
En complément de ces informations, nous pouvons indiquer que dans le cas où un décalage entre la whitelist IP implémentée au sein du logiciel DRIMBox et la whitelist IP mise à disposition par Betterstack conduirait à l’affectation d’un statut « hors service » associé à la DRIMBox au sein de la météo des services ANS, alors l'ANS sera en mesure d’investiguer afin de déterminer si le processus d’actualisation de la whitelist IP est en cause. Dans ce cas, une discussion entre les acteurs institutionnels et l’éditeur de logiciel pourrait avoir lieu afin d’arbitrer cette situation.

Tel qu'indiqué au sein de la spécification projet DRIMBox et précisé par le Guide d'Intégration à l'Espace de Confiance DRIM-M, seule une constatation de l'absence de mention du logiciel DRIMBox au sein de la liste blanche récupérée implique une interruption de service de celui-ci. 
En cas d'indisponibilité de la liste blanche supérieure à 48h (serveur inaccessible ou document récupéré inexploitable), le logiciel DRIMBox conserve la possibilité d'utiliser la précédente version de la liste blanche archivée localement.

Trois phases peuvent être distinguées afin d'assurer la gestion du cycle de vie d'un examen d'imagerie au niveau de l'archive locale associée au logiciel DRIMBox :

1. Dans le cadre de la réalisation d'un examen d'imagerie, un compte-rendu d'imagerie ainsi qu'un ensemble d'images médicales sont produits. Ces informations, une fois envoyées à la fonctionnalité source du logiciel DRIMBox, permettent la création d'un document KOS mentionnant l'ensemble des informations à utiliser afin d'accéder ultérieurement aux images. Une fois le document KOS créé par le logiciel DRIMBox et publié au sein de l'environnement DMP (transaction TD2.1a du Guide d'Intégration DMP), une nouvelle entrée est ajoutée au sein de l'archive locale de la DRIMBox (pour plus de précisions, voir section 4.5.7 de la spécification projet DRIMBox).
2. Dans le cadre d'une modification de contenu d'un examen d'imagerie (suppression/ajout d'images médicales, changement de visibilité du compte-rendu d'imagerie, ou autre), le document KOS associé doit être mis à jour en conséquence par le logiciel DRIMBox et remplacé au sein de l'environnement DMP (transaction TD2.1b du Guide d'Intégration DMP). Une fois la mise à jour effectuée auprès de l'environnement DMP, celle-ci doit également être répercutée au niveau de l'archive locale associée au logiciel DRIMBox. Cet ajustement aura pour conséquence un remplacement du document KOS archivé, ainsi que du lot de soumission associé (fichier METADATA.xml).
3. Dans le cadre d'une dépublication d'un compte-rendu d'imagerie ou en cas de  suppression de l'intégralité des images associées à un examen d'imagerie médicale, alors le document KOS associé doit être dépublié de l'environnement DMP (transaction TD3.3c du Guide d'Intégration DMP). Conformément aux indications fournies en section 4.5.8.1 de la spécification projet DRIMBox, le document KOS sera alors être identifié comme dépublié au niveau du stockage local. L’objet DICOM KOS en tant que tel peut éventuellement être supprimé de la base d’archivage, mais son identification et statut doivent être tracés afin de fournir une réponse précise lors de la demande d’accès aux images qu'il référence. 

Afin de tester l'intégralité des mécanismes de contrôle implémentés par les Solutions DRIMBox candidates au référencement SEGUR DRIM-M, certaines situations "non-passantes" sont intégrées au sein des scénarios de test définis dans ce contexte.

Ces cas d'erreur peuvent résulter de l'exploitation de jeux de données volontairement corrompus ou d'interaction entre la solution DRIMBox et un simulateur présentant un défaut de configuration intentionnel.

Il est donc cohérent que pour ces situations l'utilisateur constate un résultat d'exécution non-passant au sein de l'interface du simulateur/validateur. 

Si vous effectuez un montage (utilisation d’une solution tierce déjà certifiée), vous n’avez pas à effectuer de demande de certification auprès du CNDA. Vous pouvez communiquer à l'ANS le NIL de cette solution tierce lors de votre demande de référencement.