Migration 4.7 vers la 5.0

La version 5.0 apporte son lot de nouveautés, et tend vers une intégration la plus souple avec le DMP mais aussi les autres téléservices de santé.

Cette version supporte encore les anciennes requêtes mais déprecient certaines notions.

Une nouvelle collection postman est disponible dans l’espace public Postman : https://www.postman.com/universal-satellite-657415/workspace/devbox-sante-exemples

Note et Historique de vaccination

Tout d’abord, nous avons ajouté le support de la note et historique de vaccinations, pour plus d’information consulter la documentation à ce sujet : /dmp/cda/vaccination

Gestion de l’INS améliorée

Pour être en conformité avec l’INSi et simplifier l’intégration entre les deux composants DMP et INSi, dans tous les objets faisant référence à un INS, le couple identifiant/autorité est dorénavant utilisé au lieu de spécifier cette autorité dans le contexte de la requête.

Par exemple, une requête (td0.2 test d’existence) en version 4.7 :

devient en 5.0 :

Bien sur, l’ancienne forme est encore supporté sur cette version mais il est fortement conseillé d’adopter la nouvelle forme.

Le même exemple en java, un test d’existence en 4.7 :

context.setInsNirAutorite(DMPCContext.DMPCInsNirAutorite.TEST);
TD02Response response = client.td02Exist(context, new TD02Request("277076322082910"));

devient en 5.0

var response = client.td02Exist(
                    context,  
                    TD02Request.builder()
                        .matriculeINS(Identifiant.builder()
                            .valeur("277076322082910")
                            .identifiantSysteme(Oids.ANS_1_2_250_1_213._1_4_10_INS_NIR_TEST.val())
                            .build())
                        .build()
                    );

Validation

Les messages de validation ont été améliorés en contextualisant la plupart des validations (en soumission, en récupération). Mais aussi plus finement, comme par exemple, la vérification qu’un code d’un document est bien dans son jeu de valeurs spécifique.

Quelques exemples de validations effectuées sur un DMPCDocument :

public class DMPCDocument {
...
    @CodeValid(jeuValeurs = DMPCCode.JeuxValeursDMP.FORMAT_CODE, groups = {OnSubmit.class})
    private DMPCCode formatCode;
...
    @NotNull(groups = {BinaryRequired.class})
    private byte[] content;
    
    @NotNull(groups = {OnRetrieve.class})
    private String entryUuid;

Exemple de message obtenu dorénavant pour un classCode erronné dans le document :

 "message": "Code 55 inexistant dans la nomenclature JDV_J57-ClassCode-DMP.tabs"

Par conséquent, certains contrôles sont plus sévères, et donc certains cas passant peuvent ne plus l’être. Par exemple, il n’est plus possible d’identifier un Personnel de santé avec un internalId sans préciser son identifiant de structure. Ou encore, une vérification du format des RPPS est effectué dans les documents envoyés.

Consulter, les sources pour visualiser les contrôles possibles : https://bitbucket.org/devbox-sante/devbox-sante-apis/src/master/dmpc-api

Ajout de la TD0.4

La documentation sur cette nouvelle transaction est ici

Autres évolutions

• Suppression de la TD0.0

• Meilleur gestion des cartes CPF (en formation)

• Gestion multicertificats

• Suppression de la transaction TD1.5

• Suppression du statut Médecint Traitant (TD0.3)

• Contrôle des formats d’identifiant (RPPS, FINESS …)

• … et d’autres encore cf. le release note