Migration 5.0 vers la 5.1

Guide de migration vers la nouvelle version 5.1

La version 5.1 apporte son lot de nouveautés, et est totalement compatible avec la 5.0.

Elle supporte néanmoins les évolutions définis dans les différents guides d’intégration 2.7, 2.8 et 2.9, mais également le support du volet CNAM-HR Historique de Remboursement (pour plus de renseignements rendez-vous sur la page dédiée)

[2.7] Support de la recherche FindDocumentByReferenceId nécessaire à la recherche de documents d’imagerie

Une nouvelle requête est disponible également pour la recherche FindDocumentByReferenceId permettant la recherche de documents DICOM :

[2.8] Prise en charge du mode EJ/EG en authentification indirecte

En fonction du déploiement, nous pouvons vouloir authentifier la structure Juridique de l’établissement pour un établissement géographique ou encore déployer que des certificats liés au FINESS Géographique. Le tableau ci-dessous reprend l’ensemble des exigences du GIE Sesam-Vitale en la matière

EJ_EG récapitulatif

Pour vous cet intégration sera toute simple,

Mode EG : Vous utilisez un certificat EG (Établissement Géographique) pour vous connecter, toutes les informations de l’établissement (DMPCStructureSante) pour l’alimentation du DMP et l’authentification (VIHF) seront déduites du certificat.

Mode EJ/EG (assouplissement): Vous utilisez un certificat EJ (Établissement Juridique) pour vous connecter et vous précisez dans le contexte d’appel, l’identifiant Finess Géographique de la structure du professionnel. Alors les différents identifiants (celui de l’EJ dans le certificat, et celui de l’EG donné dans le contexte) seront utilisés à bon escient dans les différents champs des transactions (VIHF, Soumission XDS, Document XDS, Document CDA, Document de signature XADES.

Passage de l’EG dans le contexte des requêtes :

{
    "author": {
        "structureSante": {
            "idNational": "10B0130811",
            ...
        }
        ...
    }
}

Mode EJ (déconseillé): Vous utilisez un certificat EJ (Établissement Juridique) pour vous connecter, si vous ne précisez rien dans le contexte d’appel (DMPCContext) ce sont les informations de ce certificat qui seront utilisées. Attention, toutefois ce mode EJ est fortement déconseillé dorénavant.

[2.9] Gestion des notes de vaccination en version 2023.1

Il s’agit ici d’une mise en conformité avec le Cadre d’intéropérabilité SIS. Ces modifications sont transparentes pour vous, vous soummettrez les mêmes notes de vaccination et retrouver les mêmes historiques de vaccination avec nos apis : /dmp/cda/vaccination.

[2.9] Gestion de la TD0.4 pour les CPE

La TD0.4 peut dorénavant être appelé via une CPE pour le compte d’un professionnel, dans ce cas le RPPS du professionnel de santé doit être passé dans la requête

https://bitbucket.org/devbox-sante/devbox-sante-apis/src/master/dmpc-api/src/main/java/fr/devboxsante/dmp/TD04Request.java

Tools : récupérer les informations du contexte d’appel.

Un nouvel endpoint a été rajouté, afin d’aider et comprendre les informations récupérées du certificat P12 ou de la carte CPS et insérées à la volée dans les appels vers le DMP.

Dans le cas d’une POST vide en mode securité P12 sur le endpoint /dmp/authenticationContext :

curl --location 'http://localhost:9999/dmp/authenticationContext' --data '{}'

la réponse est :

{
   "authorInfo": {
       "internalId": "UNKNOWN",
       "structureSante": {
           "idNational": "10B0130811",
           "nom": "CENTRE DE SANTE RPPS13081"
       }
   },
   "serverInfo": {
       "urlPrefix": "https://dev1.lps2.dmp.gouv.fr/si-dmp-server/v2/services",
       "urlWebPrefix": "https://ledmp.dmp.gouv.fr",
       "developement": true
   },
   "authenticationInfo": {
       "securityMode": "p12",
       "p12": true
   }
}

Dans le même cas dans un mode CPS :

{
    "authorInfo": {
        "rpps": "899700296140",
        "nom": "MED-CS RPPS0029614",
        "prenom": "ANNE",
        "role": "10",
        "roleCode": {
            "valeur": "10",
            "identifiantNomenclature": "1.2.250.1.71.1.2.7",
            "libelle": "Médecin",
        },
        "specialite": "G15_10/SM26",
        "specialiteCode": {
            "valeur": "G15_10/SM26",
            "identifiantNomenclature": "1.2.250.1.213.1.1.4.5",
            "libelle": "Médecin - Qualifié en Médecine Générale (SM)",
        },
        "secteurActivite": "SA05",
        "secteurActiviteCode": {
            "valeur": "SA05",
            "identifiantNomenclature": "1.2.250.1.71.4.2.4",
            "libelle": "Centre de santé",
        },
        "structureSante": {
            "idNational": "10B0156832",
            "nom": "CENTRE DE SANTE RPPS15683"
        }
    },
    "serverInfo": {
        "urlPrefix": "https://dev1.lps2.dmp.gouv.fr/si-dmp-server/v2/services",
        "urlWebPrefix": "https://dev1.ps.dmp.gouv.fr/ps/acces-web",
        "developement": true
    },
    "authenticationInfo": {
        "securityMode": "cps",
        "p12": false
    }
}

Ces informations sont utilisées pour la génération du VIHF (Vecteur d’Identification et d’Habilitations Formelles), et pour identifier le legalAuthenticator des requêtes.

Gestion des logs

Les logs CXF sont tracés en mode debug au lieu de info :

logging.level:

  org.apache.cxf.services: debug # pour tracer les messages soaps

Validation cda par schematron

La validation se fait par les outils du projet https://github.com/ansforge/TestContenuCDA-3-0 au lieu de l’ancien projet https://github.com/ansforge/TestContenuCDA

Pour la liste de toutes les autres demandes : Release note de la version 5.1