Conformité CNDA

Quelques exemples de requêtes JSON des tests de conformité du CNDA

Les tests sont décrits dans le document SEL-GCONFORM_INSi_Vxx.xx.pdf.

Attention l’environnement de qualification pour les tests restitue bien les cas passants mais pas correctement les non passants.

Pour injecter les réponses souhaitées du document de vérification il faut configurer la DevBox-santé INSI avec le profil de test cnda

Précisions sur l’environnement de tests éditeurs :

Des erreurs « insi_101 » et « insi_102 » en sortie des opérations de recherche vont être restituées lors du déroulement des tests en environnement éditeurs. L’environnement de tests éditeurs ne gère qu’une base de tests RFI (régime général et régimes hébergés) mais pas de base SNGI (autres régimes : pour plus de détail voir le Guide d’intégration). Le service effectue une première recherche vers le RFI :

  • si le patient est trouvé, l’INS et les informations associées sont restitués : les cas passants que vous observez
  • si le patient n’est pas trouvé, le service effectue une recherche au SNGI avec les données de la requête. Comme en environnement de tests éditeurs il n’y a pas de branche SNGI, la recherche est en échec et l’erreur « insi_101 » ou « insi_102 » (selon l’opération) est restituée (il s’agit d’une erreur technique : branche SNGI indisponible), un code CR01 ne peut être restitué. Dans la configuration actuelle de l’environnement de tests, il n’est pas possible d’obtenir un CR01, c’est pour cela (et pour tester les cinématiques attendues dans le Guide d’intégration) que dans le package de tests sont fournis des fichiers xml à injecter dans le LPS, pour simuler les réponses du service que l’on ne peut obtenir dans notre environnement. En environnement de production, lorsqu’un INS ne sera pas trouvé c’est bien un CR01 qui sera restitué.

Déclaration à apporter lors de vos Tests

Dans certains cas de tests de conformités, certaines déclarations peuvent être nécessaires. Elles sont reprises ici

Exemples json

Voici quelques exemples json repris des tests :

WS_INS1

  • Cas du POST par lecture des données vitales en amont :

WS_INS2

Le connecteur devbox-santé-insi est conforme au niveau 1 de sécurité pour l’assertion PS. En effet, avant tout appel au TéléService INSi, la carte CPS est accédé afin de vérifier sa présence. Si une session pkcs11 est ouverte, cette dernière est utilisée pour générer l’assertion.

Dans le cas où plusieurs structures d’activité sont trouvées, il est demandé à l’intégrateur de fournir son identifiant National et une vérification de son existence sur la carte CPS est réalisée. L’attribut identifiantFacturation est demandé pour chaque requête de l’intégrateur

  • Test2_07

Cas 1 : Uniquement après le premier appel, injection du fichier (simulant une réponse du service) : REP_CR01.xml

Ce cas n’est pas réalisable avec l’injecteur CNDA développé. En effet, l’injecteur injecte pour l’ensemble des requêtes effectuées la réponse injectée. C’est cette dernière qui est retournée par le service à l’intégrateur. Jusqu’à présent, il suffit de reprendre les 2 premières trames envoyées et reçues par la DevBox-Santé pour preuve.

WS_INS3

  • test3_01.json

  • Test3_02 : Réponse de DEVCOOP au CNDA pour ce test

Le connecteur devbox-santé-insi est conforme au niveau 1 de sécurité pour l’assertion PS. En effet, avant tout appel au TéléService INSi, la carte CPS est accédé afin de vérifier sa présence, si une session pkcs11 est ouverte, cette dernière est utilisée pour générer l’assertion.

Dans le cas où plusieurs structures d’activité sont trouvées, il est demandé à l’intégrateur de fournir son identifiant National et une vérification de son existence sur la carte CPS est réalisée. L’attribut identifiantFacturation est demandé pour chaque requête de l’intégrateur

WS_INS4 

Déclarations

Déclarations lors de notre audit