Référencement Phase 1 : Prérequis
Déroulement
- Récupérer le cahier de test à jour et prendre connaissance de la NOTICE
- Filtrer l’onglet Phase 1 sur les trois premières colonnes : Profil DMP-C, Authentification, Transaction en fonction de vos annexes remplies des conditions particulières.
- Fournir à DEVCOOP pour chaque code de test un répertoire contenant la trame d’exécution ainsi que si besoin une ou deux impressions écrans pour illustration. Pour une preuve : Fournir une trame soap d’envoi depuis les logs, plus de renseignements pour récupérer les trames :/dmp/howtos/logs/
- Une fois les trames validées par DEVCOOP, fournir les informations suivantes concernant votre logiciel
- NIL
- Nom
- Version
- Système d’exploitation
- DEVCOOP fournit l’attestation de réalisation des prérequis signé.
Code prérequis pour Tous
Indication concernant les différents tests prérequis.
PRE_GEN
L’éditeur a pris connaissance du Guide d’Intégration DMP et de la totalité des exigences qui concerne le périmètre de son LPS.
Effectivement, suivre cette documentation ne vous dispense pas de lire attentivement le guide d’intégration “Service DMP intégré aux LPS” (SEL-MP-037) dans la version du package cible. Ce document est disponible sur l’espace industriel de Sesam-Vitale : https://industriels.sesam-vitale.fr/group/dmp-compatibilite
PRE_ERR
Le LPS affiche correctement les différents messages d’erreurs et codeRetour (soapFault…) et adapte sa cinématique en fonction.
Toute erreur provenant du serveur DMP, est interprété puis transformé en une Exception java typé en fonction de l’erreur remontée.
Le message initial avec son code provenant du serveur DMP est toujours récupéré afin de fournir le bon message à l’intégrateur. Il faut veiller à remonter à l’utilisateur cette information.
PRE_TPS
Le LPS se synchronise via un serveur de temps a minima toutes les 24h.
Toutes les dates techniques (VIHF, dates de création si non renseignées) sont gérées par la DevBox-Santé, les autres dates doivent faire l’objet d’une synchronisation via NTP. Pour cela il est possible d’utiliser le TimeManager de la DevBox-santé DMP.
En java :
// injection du bean spring
@Autowired
private TimeManager clock;
// Usage dans le code
ZonedDateTime now = clock.getLocal();
En REST :
curl -X 'GET' 'http://localhost:9999/dmp/time/iso'
PRE_MODE_CNXSC
Des tests ont été faits en mode Connexion Secrète pour un patient mineur.
Pour toute information sur la mise en place de la connexion secrète avec la DevBox-santé DMP : /dmp/howtos/transactions/#gestion-de-la-connexion-secrète
Authentification directe
PRE_DIR_MED, PRE_DIR_AUX, PRE_DIR_PHA, PRE_DIR_SPE, PRE_DIR_CPF, PRE_DIR_REMPL, PRE_DIR_CPF
Des tests ont été faits en Authentification DIRECTE avec une carte :
- MEDECIN
- PHARMACIEN
- SPECIALISTE
- AUXILIAIRE
- CPE anonyme et non anonyme
- CPF
- REMPLAÇANT
Il faut réaliser un test par type de cartes CPx. La DevBox-Santé DMP gère tous les types de cartes CPx
Pour obtenir les différents types cartes CPx de test : /dmp/howtos/gestioncertificat/#proc%C3%A9dure-administrative
PRE_TD03
L’éditeur a testé la modification de l’autorisation du PS sur un DMP.
Tout sur la transaction TD0.3 /dmp/howtos/transactions/#td03–modifier-lautorisation-dacc%C3%A8s-etou-le-statut-m%C3%A9decin-traitant-dmp-ou-passer-en-mode-dacc%C3%A8s–bris-de-glace–depuis-version-20
PRE_TD03_BDG
L’éditeur a testé un accès BDG en cas d’urgence.
Mise en œuvre du bris de glace dans la DevBox-santé : /dmp/howtos/transactions/#gestion-du-bris-de-glace
PRE_TD04
L’éditeur a testé l’affichage de la liste des patients ayant une autorisation pour l’acteur authentifié.
Mise en œuvre de la td0.4 : /dmp/howtos/transactions/td0.4
PRE_TD04_CPE
L’éditeur a testé l’affichage de la liste des patients ayant autorisé un PS donné à consulter leur DMP, et ce depuis une authentification faite avec une CPE.
Idem PRE_TD04 avec une CPE
PRE_TD09
L’éditeur a testé l’appel au WebPS.
Il faut pouvoir accéder au webDMP des PS, comme par exemple :
La DevBox-santé DMP permet de générer les urls d’acccès.
Authentification indirecte
PRE_IND
Des tests ont été faits en en Authentification INDIRECTE.
Il faut valider une connexion en spécifiant les différents certificats utilisés. Plus d’information, sur la configuration des certificats : /dmp/configuration/#authentification-indirecte
Ces certificats auront été obtenus préalablement auprès de l’ANS. Pour plus d’informations, sur l’obtention des certificats : /dmp/howtos/gestioncertificat/
PRE_IND_PSMS
Des tests ont été faits en Authentification INDIRECTE avec un PSMS (professionnel du secteur médico-social = RPPS+).
Authentification Indirecte Renforcee
PRE_AIR
Des tests ont été faits en Authentification INDIRECTE RENFORCEE.
PRE_TD010
L’éditeur a testé l’appel au WebPS en AIR.
Le support de la TD0.10 a été rajoutée en 6.0, pour une description de la transaction : TD010
Profil Alimentation
PRE_ALIM_NIV1
L’éditeur a testé le dépôt d’ un document CDA-R2 de niveau 1 sur le DMP d’un patient.
Il faut mettre en œuvre la transaction : /dmp/howtos/transactions/td2.1
PRE_ALIM_RECH
L’éditeur a testé la recherche de l’identifiant technique d’un document à partir de son identifiant local (fonctionnalité TD 3.1b) afin de remplacer ou dépublier un document.
Il faut mettre en œuvre la transaction : /dmp/howtos/transactions/td3.1b
PRE_ALIM_RPLC
L’éditeur a testé le remplacement d’un document déjà présent sur le DMP d’un patient (TD 2.1b).
Il faut mettre en œuvre la transaction d’alimentation avec les informations des identifiants des documents remplacés. Plus d’informations : /dmp/howtos/transactions/td2.1#remplacement
PRE_ALIM_SUPPR
L’éditeur a testé la dépublication (suppression) d’un Document (Statut Deleted) à partir de la fonctionnalité TD 3.3c.
Il faut mettre en œuvre la transaction : /dmp/howtos/transactions/td3.3
PRE_ALIM_VAC
L’éditeur a testé le dépôt, la modification, la validation et la suppression d’un document Note de Vaccination (NOTE-VAC).
Les conditions du support de la vaccination dépend des professions pris en charge par le LPS intégrateur :
EX_2.1-2000 La prise en charge de cette évolution est obligatoire pour les LPS destinés aux médecins (médecine générale et pédiatrie), aux pharmaciens, aux sages-femmes, aux infirmiers ou aux infirmiers psychiatriques (code profession 10, 21, 50, 60 ou 69) en secteur libéral (y compris centres de santé) .
Il faut mettre en œuvre la transaction d’alimentation mais d’un document NoteVaccination, plus d’informations : /dmp/cda/vaccination/
PRE_ALIM_NIV3
L’éditeur a testé le dépôt d’un document CDA-R2 de niveau 3 sur le DMP d’un patient.
Si vous supportez la note de vaccination, vous remplissez les conditions du support d’un dépôt de document de CDA-R2 de niveau 3. Mais également si vous prenez en charge un autre volet du CI-SIS.
Plus d’informations sur les différents volets spécifiés par l’ANS : https://esante.gouv.fr/offres-services/ci-sis/espace-publication
Plus d’informations sur les différents volets (documents CDA-R2 N3 supportés) par la DevBox-santé, nativement : /dmp/cda
Profil Consultation
PRE_CONS_RECH
L’éditeur a testé la recherche d’un document dans le DMP d’un patient avec les critères AvailabilityStatus et/ou TypeCode.
Il faut réaliser cette recherche en utilisant la transaction de recherche : /dmp/howtos/transactions/td3.1
PRE_CONS_SUB
L’éditeur a testé la recherche d’un document dans le DMP d’un patient avec comme critère la date de soumission.
Il faut réaliser cette recherche en utilisant la transaction de recherche : /dmp/howtos/transactions/td3.1
PRE_CONS_CONS
L’éditeur a testé la consultation d’un document présent dans le DMP d’un patient et l’affichage des métadonnées d’entête CDA.
Il faut mettre en œuvre la transaction : /dmp/howtos/transactions/td3.2
PRE_CONS_MSQPS
L’éditeur a testé le masquage/démasquage d’un Document aux PS (confidentialityCode) à partir de la fonctionnalité TD 3.3a.
Il faut mettre en œuvre la transaction : /dmp/howtos/transactions/td3.3
PRE_CONS_INV
L’éditeur a rendu visible un Document au patient/représentant légaux (confidentialityCode) à partir de la fonctionnalité TD 3.3b.
Il faut mettre en œuvre la transaction : /dmp/howtos/transactions/td3.3
PRE_CONS_ARCH
L’éditeur a testé l’archivage/désarchivage d’un document à partir de la fonctionnalité TD 3.3d.
Il faut mettre en œuvre la transaction : /dmp/howtos/transactions/td3.3