Déclarations

Déclarations lors de notre audit

Test 1.02

Le cas 2 n’est pas reproductible dans notre cas, car la requête est transmise directement après la sélection du bénéficiaire.

Deux possibilités de sélectionner le bénéficiaire :

la première par l’utilisation d’une popup du choix du bénéficiaire (SELECT_INDIVIDU.png).
le programme appelant connaît le bénéficiaire par un appel préalable aux apis vitales, le numéro de série de la carte vitale et l’index de l’invidu sont donc passés en paramètre (Appel_avec_numSerie_index_individu.png). Ces paramètres permettent de sélectionner les informations lues da la carte vitale avant la génération de l’assertion.

Test 1.03

Le connecteur devbox-santé-insi est conforme au niveau 1 de sécurité. En effet, avant tout appel au TéléService INSi, la carte vitale est lue et une nouvelle assertion est générée. Donc si la carte dans le lecteur a été changé, la sélection de l’individu bénéficiaire est demandé à l’utilisateur et la recherche se fera sur l’individu séléctionné de la carte vitale insérée. Il n’y a donc pas d’erreur mais une invitation à choisir l’individu sur la carte.

Toutefois, il est laissé à l’intégrateur, dans le cas où la carte vitale a déjà été lue en amont, la possibilité de spécifier le numéro de série de la cartevitale ainsi que l’index du bénéficiaire. Donc dans ce cas, le connecteur devbox-santé-insi vérifie que ces deux paramètres correspondent aux informations lues sur la carte vitale avant de générer l’assertion. Cela permet de ne pas redemander à l’utilisateur de sélectionner le bénificiaire.

La vérification retourne une erreur dans le cas où les paramètres spécifiés par l’appelant ne correspondent pas :

fr.devboxsante.insi.client.INSiException: La numéro de série de la carte ne correspond pas.
	at fr.devboxsante.insi.client.INSiClientImpl.ins1RechercheAvecVitale(INSiClientImpl.java:62) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
	at fr.devboxsante.insi.proxy.INSiProxy.ins1RechercheAvecVitale(INSiProxy.java:32) ~[classes/:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:na]
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:na]
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:na]
	at java.base/java.lang.reflect.Method.invoke(Method.java:566) ~[na:na]

Test 1.07 :

Configuration de insi-api-proxy-rest de manière à injecter en réponse le fichier REP_CR01.xml. Cette configuration est possible seulement si le proxy-rest est lancé avec le profil CNDA activé. Cette configuration est accessible par un endpoint REST supplémentaire

Cas 1 : À la réception de l’erreur du téléservice de test est injecté dans le proxy la réponse du fichier REP_CR01.xml et est retourné en réponse (Test1.07-réponse_lionel_léonard_damien.png)

Cas 2 :À la réception de l’erreur du téléservice de test est injecté dans le proxy la réponse du fichier REP_CR01.xml et comme un prénom usuel différent est trouvé sur la carte, l’insi-api-rest-proxy relance une recherche avec le nom usuel pour nom de naissance (REQUETE_LEONARD_2_LPS.xml)

Cas 3: Idem que 1 (Test1.07-réponse_lionel_léonard_damien.png)

Remarque : toutes les réponses données dans le répertoire sont les réponses d’origine du téléservice.

Test 2.01

la carte n’est pas présente [NO_CARD]
le code pin n’est pas saisie [NO_PIN]
la carte a été changée. [NO_PIN]

Dans tous les cas un message approprié est affiché à l’utilisateur pour qu’il puisse faire les actions nécessaires.

Test 2.02

Le secteur d’activité et l’identification de facturation sera paramétrable par l’intégrateur. Le code profession sera renseigné pour une CPS/CPF médecin. Il ne sera pas pour une CPE ou les CPS non médecin qui n’ont pas le champ specOrdRpps renseigné sur la carte.

Test 2.03

Les régles de formattage concernant les différents champs sont appliqués avant envoi de la requête vers le téléservice INSi.Le prénom saisie est Une fois ces transformations effectuées une expression régulière vérifie qu’il ne subsiste pas des caractères interdits.

Dans le connecteur devbox-sante-insi a été mis en place le framework javax.validation afin d’éviter la non saisie des champs obligatoires, et de vérifier certains formats de champs. Exemple :

    /**
     * EF_INS10_01
     * Nom de naissance
     */
    @NotNull
    private String nomNaissance;
	
	@Size(min=5, max = 5, message =
            "Ce code doit être issu du Code Officiel Géographique (COG) de l’INSEE.\n" +
            "Il ne s’agit pas du code postal de la commune de naissance du patient.")
    private String lieuNaissance;

Si une erreur est remonté par le téléservice, cette erreur génére une exception dans le connecteur devbox-sante-insi et est remonté à l’intégrateur.

Cas 3

Une tentative d’envoi avec les paramètre du cas 3, déclenchera tout d’abord une exception :

fr.devboxsante.insi.client.INSiException: D’ÆION contient des caractères interdits
	at fr.devboxsante.insi.client.INSiRequeteMappers.mapNom(INSiRequeteMappers.java:169) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
	at fr.devboxsante.insi.client.INSiRequeteMappers.lambda$from$0(INSiRequeteMappers.java:82) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[na:na]
 	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654) ~[na:na]

Une fois le nom naissance modifié en “D AEION”, une nouvelle tentative déclenchera une nouvelle exception :

fr.devboxsante.insi.client.INSiException: CŒUR contient des caractères interdits
	at fr.devboxsante.insi.client.INSiRequeteMappers.mapNom(INSiRequeteMappers.java:169) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
	at fr.devboxsante.insi.client.INSiRequeteMappers.lambda$from$0(INSiRequeteMappers.java:83) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[na:na]
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1654) ~[na:na]

Une fois le prénom modifié en “Coeur” , une nouvelle tentative déclenchera une exception :

fr.devboxsante.insi.client.INSiException: Mauvais format du lieu de naissance 2B020
	at fr.devboxsante.insi.client.INSiRequeteMappers.checkLieuNaissance(INSiRequeteMappers.java:228) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
	at fr.devboxsante.insi.client.INSiRequeteMappers.mapLieuNaissance(INSiRequeteMappers.java:222) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
	at fr.devboxsante.insi.client.INSiRequeteMappers.lambda$from$0(INSiRequeteMappers.java:80) ~[insi-impl-1.0-SNAPSHOT.jar:1.0-SNAPSHOT]
    at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[na:na]

Test 2.07

Une difficulté peut apparaître pour ce test où l’on vous demande de faire des appels successifs en passant une liste de prénoms dans la requête. En injectant, le fichier REP_CR01.xml vous aurez toujours la même réponse déclenchée, c’est à dire celle du fichier. Il vous faut donc manuellement lancer le premier appel avec le fichier injecté, faire un clean de l’injection et poursuivre les appels.

Test3.01

Comme pour le test 2.01

la carte n’est pas présente [NO_CARD]
le code pin n’est pas saisie [NO_PIN]
la carte a été changée. [NO_PIN]

Dans tous les cas un message approprié est affiché à l’utilisateur pour qu’il puisse faire les actions nécessaires.

Test3.02:

Comme pour le Test2.02

Le secteur d’activité et l’identification de facturation sera celui de la structure sélectionnée. Le code profession sera renseigné pour une CPS/CPF médecin. Il ne le sera pas pour une CPE ou les CPS non médecin qui n’ont pas le champ specOrdRpps renseigné sur la carte.

Test 3.03

Le prénom saisie est transformé(normalisé) afin de supprimer tous les accents et mis en majuscule. Une fois ces transformations effectuées une expression régulière vérifie qu’il ne subsiste pas des caractères interdits.

Test 3.04

Utilisation de javax.validation p ur vérifier les champs obligatoires, les champs optionnels peuvent ne pas être renseigné et n’empêche pas l’appel au téléservice.

Test 3.05

Pour les cas 1 et 2 la réponse retournée au client est l’erreur générée par le message Soap. Il n’est pas possible d’injecter la réponse TEST_2.03_cas1.xml ou encore TEST_2.05.xml car les formats des réponses soaps entre les deux téléservices (WS_INS2 et WS_INS3) sont différents.

Test 4.01

la carte n’est pas présente [NO_CARD]
le code pin n’est pas saisie [NO_PIN]
la carte a été changée. [NO_PIN]

Dans tous les cas un message approprié est affiché à l’utilisateur pour qu’il puisse faire les actions nécessaires.

Test 4.02

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’utilisateur de choisir. Le secteur d’activité et l’identification de facturation sera celui de la structure sélectionnée. Le code profession sera renseigné pour une CPS/CPF médecin. Il ne sera pas pour une CPE ou les CPS non médecin qui n’ont pas le champ specOrdRpps renseigné sur la carte. L’identifiant de facturation sera celui associé de la structure d’activité choisie sur la carte CPS.

Test 4.03

Les formats et contrôles de chaque requête unitaire pour un lot sont identiques à celles pour une vérification unitaire qui sont :

“Le prénom saisie est transformé(normalisé) afin de supprimer tous les accents et mis en majuscule. Une fois ces transformations effectuées une expression régulière vérifie qu’il ne subsiste pas des caractères interdits.”

Test 4.05 :

Une fois le dépôt effectuée et obtenue la réponse du téléservice, la devbox-santé INSi convertit le délai donné en secondes d’attente. Nous préférons laisser le choix à l’intégrateur de notre solution de la manière leur application attend avant de récupérer le résultat (appel non bloquant privilégié). Toutefois, nous proposons un service qui réalise l’appel du dépôt et essaye de récupérer le résultat après chaque nouveau délais retourné par le téléservice INSi (appel bloquant).

Trace d’exécution mettant en œuvre l’injection du CR_02 :

2021-09-17 11:44:09.553 DEBUG 32560 --- [           main] f.d.insi.client.INSiClientImpl           : Délai d'attente pour la réponse : 60 secondes.
2021-09-17 11:45:22.084 DEBUG 32560 --- [           main] f.d.insi.client.INSiClientImpl           : Nouveau délai d'attente pour la réponse : 180 secondes.
2021-09-17 11:48:24.913 DEBUG 32560 --- [           main] f.d.insi.client.INSiClientImpl           : Nouveau délai d'attente pour la réponse : 180 secondes.

Test 4.06

Dans la Devbox-santé INSi , le paramétrage des tailles de lot est initialisé de la manière suivante :

@Value("${devbox-sante.insi.lot.minSize:1}")
private int lotMinSize;

@Value("${devbox-sante.insi.lot.maxSize:100}")
private int lotMaxSize;

Il est possible de modifier ce paramétrage au travers d’un fichier de configuration.