Déclarations

Reprend les déclarations du Plan De Test CNDA CDT_DMP_20251127_2.10e.xlsx

Exigences Générales

EX_GEN-1180

Consigne

“L’éditeur doit mettre en œuvre dans les LPS homologués un dispositif d’affichage du ou des profils de DMP compatibilité homologués et de la date d’homologation (menu de type « à propos » par exemple). Ce dispositif d’affichage doit également faire apparaître le nom de l’éditeur, du LPS et la version du LPS.

Le nom du LPS doit correspondre à la donnée LPS_Nom alimentée dans le VIHF.

La version du LPS doit correspondre à la donnée LPS_Version alimentée dans le VIHF. Dans le cas d’une famille de produits, chaque produit doit porter un nom qui permette de le distinguer des autres produits de sa famille. Dans tous les cas, chaque produit doit porter une version qui permette de le distinguer des autres versions de ce produit.”

Déclaration du candidat

Exigence déléguée.

La Devbox-Santé DMP donne accès à un point d’entrée accessible en REST par la route /dmp/lpsInfo

EX_GEN-1190

Consigne

L’éditeur doit préciser dans la documentation de fonctionnement des LPS homologués les fonctions DMP intégrées, ainsi que celles qui ne le sont pas.

Déclaration du candidat

Exigence déléguée

EX_GEN-1221

Consigne

“Il est demandé à un LPS de prendre en compte rapidement le changement d’un nom de domaine (ou hostname) des URL Web Service. Le délai de mise à jour à respecter sera communiqué par le GIE SESAM-Vitale.”

Déclaration du candidat

Il s’agit d’un paramétrage du connecteur DevBox-Santé DMP, il est donc modifiable sur les différents sites de production en un bref délai , une fois informé.

devbox-sante.dmp:
  url.prefix: ${DEVBOX_DMP_URL:https://lps.dev1.dmp.gouv.fr/si-dmp-server/v2/services}

Informations complémentaires

/7.x/devbox-sante/installation/docker/configuration/#dmp

EX_GEN-1222

Consigne

“Il est demandé à un LPS de prendre en compte rapidement le changement de l’URL du fichier des paramètres. Le délai de mise à jour à respecter sera communiqué par le GIE SESAM-Vitale.”

Déclaration du candidat

L’url, du fichier de paramétrage est configurable dans un fichier de propriété :

devbox-sante.dmp.parametres:
        # Url du document xml contenant le paramétrage du DMP [FI-URL]
        url: https://www.dmp.fr/web/dmp/documents/param-lps

EX_GEN-1350

Consigne

“Chaque identifiant généré doit être mondialement unique. À cette fin, l’instance du LPS installé chez l’utilisateur ou dans la structure doit posséder un OID racine qui lui est propre. La présente spécification n’impose aucune règle de génération de cet OID racine (ni de la déclinaison de celui-ci), si ce n’est qu’il doit être unique par instance du LPS. Il appartient à l’éditeur de s’assurer de la rigueur de sa méthode de génération d’identifiants uniques d’objets et du respect de l’exigence.

Précision : Le candidat doit préciser la méthode de génération de cet OID et ses déclinaisons (uniqueId document et lot de soumission, HL7, etc.)”

Déclaration du candidat

Cas des installations serveurs :

Ces identifiants sont basés sur l’OID root de Devcoop obtenu auprès de l’AFNOR. Chaque site où sera déployé notre api sera alors identifié de manière unique par l’identifiant AFNOR concaténé avec une extension correspondant au numéro FINESS ou SIRET de l’établissement.

Cas des installers poste client :

Ces identifiants sont basés sur l’OID root de Devcoop obtenu auprès de l’AFNOR. Chaque site où sera déployé notre api sera alors identifié de manière unique par un identifiant interne de l’intégrateur concaténé avec une extension unique généré lors de l’installation.

Informations complémentaires

EX_GEN-1360

Consigne

Compte tenu du caractère évolutif des jeux de valeurs, ceux-ci doivent être paramétrables dans le LPS par l’éditeur. La modification d’un jeu de valeurs ne doit pas perturber le fonctionnement du LPS.

Déclaration du candidat

L’ensemble des nomenclatures sont chargés par la DevBox-Santé au démarrage du service, à partir des fichiers originaux disponibles sur l’espace integrateur.

La prise en compte des mises à jour se fait par paramètrage de l’application :

devbox-sante.dmp.nomenclature.resourceName: https://installers.devbox-sante.fr/installer/resources/industriels.sesam-vitale.fr/20240927-JDV_DMP_API_V2_XML_2025_07_25.zip

EX_GEN-1450

Consigne

“La structure de soins doit au préalable acquérir deux certificats logiciels de personne morale de l’IGC Santé de l’ANS Santé : • un certificat d’authentification pour personne morale (gamme élémentaire de type « ORG_AUTH_CLI ») pour établir la liaison TLS avec authentification mutuelle ; • un certificat de cachet pour personne morale (gamme élémentaire de type « ORG_SIGN ») pour réaliser la signature électronique du jeton VIHF.”

Déclaration du candidat

L’intégrateur doit demander à son client final d’obtenir ces deux certificats, afin de pouvoir configurer correctement le connecteur : Il doit utiliser un des modes d’authentificaton P12 de la DevBox-Santé. Comme le mode AuthInHeader en passant les certificats P12 et leurs mots de passe.

Informations complémentaires

/7.x/howtos/authentifications/#p12inheader

EX_GEN-1460

Consigne

“Quel que soit le profil de DMP-compatibilité choisi, le poste de travail (ou le « composant logiciel » communicant avec le système DMP s’il ne s’agit pas directement du poste de travail de l’utilisateur) doit être à l’heure, pour des problématiques d’horodatage des données médicales, de traçabilité et de pertinence de certains critères de recherche concernant la date.

Précision : Le candidat doit préciser la méthode et la fréquence de synchronisation”

Déclaration du candidat

L’ensemble des dates techniques créés lors des transactions avec le DMP sont gérés par un service de temps synchroniser via NTP à une fréquence de 10 minutes par défaut.

Les dates dites fonctionnelles sont délégués à l’intégrateur, un endpoint est mis à disposition à cette fin /dmp/time/iso

Informations complémentaires

Il est possible de reconfigurer le serveur de temps : devbox-sante.dmp.time.ntpServer ou $DEVBOX_DMP_NTP_SERVER

Ainsi que le cron de synchronisation : devbox-sante.dmp.time.cron ou $DEVBOX_DMP_TIME_CRON

EX_GEN-1490

Consigne

L’éditeur homologué à la DMP-compatibilité s’engage à garder secret le numéro d’homologation attribué par le CNDA et à se prémunir de la mise en oeuvre de ce numéro dans d’autres logiciels que ceux référencés dans la famille de produit homologuée à laquelle est rattaché ce numéro.

Déclaration du candidat

Exigence déléguée

EX_GEN-1530

Consigne

“Seuls les INS obtenus dans le respect du référentiel INS et des documents associés [REF-INS] doivent servir pour accéder aux DMP des patients. L’acquisition de l’INS du patient doit être effectuée sans rupture ergonomique pour l’utilisateur.”

Déclaration du candidat

Exigence déléguée

EX_GEN-1540

Consigne

“Le LPS doit s’actualiser avec les paramètres contenus dans le fichier des paramètres au moins une fois par semaine. Le fichier des paramètres est disponible en téléchargement sur une URL définie dans [FI URL]. Le LPS doit savoir gérer les redirections HTTPS 3xx pour le téléchargement de ce fichier.”

Déclaration du candidat

Une fois par 24 heures, le paramétrage du DMP est considéré obsolète (cf. EX_GEN-1222) . Il est donc téléchargé pour toute demande de ce paramétrage dans le connecteur après 24 heures.

L’accès au fichier de paramètres est configurable ainsi que son délai de rafraîchissement :

devbox-sante.dmp.parameters:
        # Url du document xml contenant le paramétrage du DMP[FI-URL]
        url: https://www.dmp.fr/web/dmp/documents/param-lps
        delayBetweenSyncInHours: 24

Les redirections https sont gérés via le HttpHelper.INSTANCE.getFinalURL en récupérant le header “Location” sur les responseCode 301, 302 et 303

EX_GEN-1550

Consigne

“Si le paramètre fonctions-gestion-mineurs contient la valeur true, le LPS doit déterminer si un patient est mineur avant d’accéder à son DMP. Un patient doit être considéré comme mineur si son âge (en années) est strictement inférieur à l’âge de la majorité défini dans le paramètre age-majorite. Cf. exigence EX_0.1-1100 au § 5.3.1.3 pour la connexion secrète. Cf. § 3.1.1 pour l’intégration de ces paramètres dans le LPS.”

Déclaration du candidat

Exigence déléguée La DevBox-Santé DMP récupère le paramétrage afin de remonter ces deux informations. Un endpoint est mis à disposition des intégrateurs : /dmp/parametres

Informations complémentaires

/7.x/devbox-sante/connecteurs/dmp/howtos/transactions/parametres/

Exigences de sécurité

EX_0.X-1031

Consigne

Le LPS doit supporter l’extension TLS “SNI” (Server Name Indication). Le SNI est décrit par la section 3.1 de la RFC 4366 Transport Layer Security (TLS) Extensions (https://tools.ietf.org/html/rfc4366#section-3.1 ).

Déclaration du candidat

SNI est supporté par Java depuis la version 7, la DevBox-Santé DMP 7 nécessite la version java 21 minimum et est fourni avec cette version.

Informations complémentaires

La version 7.1 de la DevBox-Santé porte la migration technique Spring-boot 4 et java 25.

EX_0.X-1055

Consigne

Pour garantir le fonctionnement du système, le LPS doit savoir gérer les redirections HTTPS 3xx émises par le système DMP.

Déclaration du candidat

Si besoin de récupérer l’url de redirection, une classe java utilitaire nous permet de récupérer l’url finale :

public String getFinalURL(String url) throws IOException {
        HttpURLConnection con = (HttpURLConnection) noCheckCertificateOpenConnection(url);
        con.setInstanceFollowRedirects(false);
        con.connect();
        con.getInputStream();

        if (con.getResponseCode() == HttpURLConnection.HTTP_MOVED_PERM
                || con.getResponseCode() == HttpURLConnection.HTTP_MOVED_TEMP
                || con.getResponseCode() == HttpURLConnection.HTTP_SEE_OTHER) {
            String redirectUrl = con.getHeaderField("Location");
            return getFinalURL(redirectUrl);
        }
        return url;
    }

Néanmoins, l’ensemble des clients HTTP java utilisés sont également configurés pour suivre les redirections. Comme par exemple celui d’Apache h5 pour récupérer les certificats et CRLs de l’IGC-Santé :

CloseableHttpClient httpClient = HttpClientBuilder.create()
                .setDefaultRequestConfig(REQUEST_CONFIG)
                .setRedirectStrategy(new DefaultRedirectStrategy())
                .build()

EX_0.X-1070

Consigne

Le LPS doit être en capacité de valider le certificat serveur du système selon la norme PKIX (voir RFC3280 sur http://tools.ietf.org/html/rfc3280 et RFC5280 sur http://tools.ietf.org/html/rfc5280).

Déclaration du candidat

La DevBox-Santé DMP utilise les mécanismes décrits ici : https://doc.devbox-sante.fr/7.x/devbox-sante/connecteurs/ms-sante/howtos/preuve_segur/

Pour résumé, dans la DevBox-sante a été développé un IGCSanteTrustoreManager spécifique afin de prendre en compte les différentes IGC-Santé définies sur http://igc-sante.esante.gouv.fr/PC/ . Tous les composants DevBox-Sante comme le DMP peuvent être configurés de manière à accepter les certificats d’une ou plusieurs gammes. Cette classe prend en charge le chargement des certificats des différentes gammes ansi que leurs CRLs. La mise à jour des CRLs est programmée par défaut à toutes les deux heures par un cron :

devbox-sante.igc-sante.fetch.cron:0 0 */2 * * *

EX_0.1-1025

Consigne

“L’identifiant interne de l’utilisateur doit : • être unique au sein de la structure de soins, pérenne et non réutilisable ; • être traité comme une chaîne de caractères indissociable et ne doit pas pouvoir être interprété par des applications ; • pouvoir être utilisé pour retrouver la personne réelle (traçabilité). "

Déclaration du candidat

Exigence déléguée

EX_0.1-1100

Consigne

“Le LPS doit permettre à l’utilisateur de mettre en œuvre une connexion secrète pour les mineurs, en concertation avec son patient. Cf. donnée confidentiality-code dans le VIHF. Les modalités de mise en œuvre : détermination de l’âge (cf. exigence EX_GEN-1550 au § 3.1.3) et proposition systématique, choix utilisateur,… devront être précisées par l’éditeur lors de son passage en homologation. NB : la formulation « connexion secrète » n’est pas imposée pour l’IHM du LPS. Il est nécessaire d’afficher un texte explicatif à l’utilisateur concernant cette fonctionnalité.”

Déclaration du candidat

Exigence déléguée.

La DevBox-Santé DMP prend en charge la possibilité d’ajouter le confidentialityCode dans le VIHF. Ainsi l’intégrateur peut appliquer une restriction d’accès aux ayants droits.

EX_0.1-1115

Consigne

“Afin d’éviter une sollicitation excessive du professionnel (par exemple : cas de prise en charge de très jeunes enfants), le LPS peut proposer un paramètre « âge minimum » en dessous duquel le LPS ne proposera pas systématiquement la connexion secrète pour un patient mineur. Dans le cas où cette fonctionnalité est proposée :

Le paramètre doit obligatoirement être défini à l’initiative du professionnel et sous sa responsabilité ;

Le LPS doit obligatoirement solliciter régulièrement le professionnel pour repositionner ce paramètre ;

Une information claire doit être délivrée au professionnel sur cette fonctionnalité ;

Elle ne doit pas interdire une connexion secrète à l’initiative du professionnel malgré ce paramètre positionné. Les modalités de mise en oeuvre d’une telle fonctionnalité doivent être précisées par l’éditeur lors de l’homologation”

Déclaration du candidat

Exigence déléguée

REC_0.X-1035

Consigne

Pour garantir la meilleure expérience utilisateur possible, le LPS doit gérer correctement la coupure du canal TLS par le système DMP (timer d’inactivité et timer de renégociation du canal TLS).

Déclaration du candidat

La DevBox-Santé DMP est stateless, chaque requête nécessite une renégociation TLS.

REC_0.X-1090

Consigne

Il est recommandé de faire un contrôle de révocation des certificats serveur du système DMP.

Déclaration du candidat

La DevBox-Santé à mis en place un contrôle de révocation des certificats. CF EX_0.X-1070

REC_0.X-1100

Consigne

Pour assurer la sécurité des applications intégrant des certificats d’AC, il est recommandé de comparer l’empreinte numérique des clés utilisées avec une source de confiance.

Déclaration du candidat

Non implémentée dans la DevBox-Santé.

Exigences liées à l’Authentification Indirecte Renforcée

EX_AIR-010

Consigne

Le mode AIR est réservé au profil « Consultation » et au profil « Consultation Web-PS en mode AIR » décrit dans la matrice des droits fonctionnels. Les autres profils sont à mettre en œuvre avec les modes d’authentification classiques (directe et/ou indirecte).

Déclaration du candidat

Exigence déléguée

EX_AIR-020

Consigne

Le mode AIR est réservé aux professionnels (PS ) référencés dans un répertoire national d’identité (SI RASS).

Déclaration du candidat

Exigence déléguée

EX_AIR-030

Consigne

Les applicatifs qui se connectent au serveur de jeton doivent s’authentifier. Seuls les applicatifs légitimes peuvent y accéder.

Déclaration du candidat

Une basic auth entre la DevBox-Santé responsable de la génération du VIHF et les appels TD010 des intégrateurs a été mise en place.

EX_AIR-040

Consigne

Le jeton VIHF généré au sein de la structure de soins possède une durée de vie de 30 secondes. Ce jeton ne peut être utilisé que pour une seule sollicitation.

Déclaration du candidat

Tous les appels au sein de la DevBox-Santé génére un nouveau jeton. Pour les appels issus de la TD010 , la responsabilité de générer le jeton avant l’appel est laissé à l’appréciation de l’intégrateur.

EX_AIR-050

Consigne

“Le jeton VIHF contient la méthode d’authentification primaire de l’utilisateur (cf. chapitre 5). Pour AIR Simplifié, une seule valeur ““CONF_EXI_PGSSIS”” est permise. Celle-ci précise la conformité de la solution aux exigences du PGSSIS. Cette valeur est à positionner obligatoirement par les éditeurs.”

Déclaration du candidat

La méthode d’authentification est choisie par l’intégrateur et est passée en paramètre à la devbox-santé responsable de la génération du jeton VIHF.

Exemple :


"context": {
  "author" : {
    "rpps" : "899700433156",
 ...
  },
  "authentificationIndirecteRenforcee" : true,
  "samlAuthnContext" : "urn:oasis:names:tc:SAML:2.0:ac:classes:Password"
}

EX_AIR-070

Consigne

Le système d’information de la structure de soins doit être en mesure de tracer la génération d’un jeton VIHF et son utilisation. Ces traces doivent permettre d’identifier clairement l’utilisateur et la structure de soins (cf. chapitre 7).

Déclaration du candidat

Exigence déléguée à l’intégrateur

En mode AIR dans le retour de la requête JSON on retrouve la trace demandée pour que l’intégrateur la sauvegarde :

{
  "trace": {
    "vihfId": "5dc92fc9-535c-40dc-b19f-2549e1477d49",
    "dateTime": "2024-11-04T08:43:45.888Z",
    "idNatStruct": "10B0182382",
    "idNatPs": "899700433156",
    "statut": "SUCCES",
    "transactionId": "TD0.10",
    "samlAuthContext": "urn:oasis:names:tc:SAML:2.0:ac:classes:Password"
  },
  "vihf": "PHNhbWxwOlJlc3BvbnNlIHhtbG5zOnNhbWxwPSJ1cm46b2F...",
  "url": "/AccesIndirectRenforce/TableauDeBord"
}

EX_AIR-080

Consigne

La liaison avec le système DMP est établie en authentification mutuelle avec un certificat d’authentification pour personne morale de l’IGC Santé de l’ANS. Ce certificat doit être valide et ne doit pas être révoqué.

Déclaration du candidat

Le certificat utilisé pour la liaison mTLS avec le DMP est le même que celui utilisé pour la génération du VIHF.

Ce dernier est validé de la même manière (vérification de la révocation, …) que dans le cas d’une authentification indirecte.

EX_AIR-085

Consigne

Les appels à la consultation en mode AIR sans que le PS utilisateur dans la structure soit authentifié ou qu’il ait connaissance de l’utilisation de son identité sont strictement interdits en mode d’authentification AIR. Seul le PS à l’origine de ces consultations en mode AIR doit pouvoir consulter les documents DMP des patients.

Déclaration du candidat

Exigence déléguée

EX_AIR-090

Consigne

Le système d’information de la structure de soins doit être en mesure de tracer les sollicitations du système DMP. Ces traces doivent permettre d’identifier clairement l’utilisateur et la structure de soins (cf. l’annexe 9).

Déclaration du candidat

Suite à l’appel de la génération du jeton VIHF, la DevBox-santé retourne le jeton VIHF à l’intégrateur, mais également les informations de traces demandées dans le chapitre 7. La persistance de ces données de trace est déléguée à l’intégrateur.

exemple réponse appel génération du jeton VIHF :

{
  "trace": {
    "vihfId": "992e669f-4980-42b3-b31a-adbc7ad5a244",
    "dateTime": "2024-10-29T10:38:25.094Z",
    "idNatStruct": "10B0182382",
    "idNatPs": "899700433156",
    "statut": "SUCCES",
    "transactionId": "TD0.10",
    "samlAuthContext": "urn:oasis:names:tc:SAML:2.0:ac:classes:Password"
  },
  "vihf": "PHNhb..",
  url": "/AccesIndirectRenforce/DossierPatient/277076322082910/1.2.250.1.213.1.4.10"
}

EX_AIR-100

Consigne

Le système d’information de la structure de soins doit être en mesure de respecter la durée légale de conservation des traces. Celle-ci est alignée sur la durée de conservation du DMP. Aujourd’hui, les traces doivent être conservées 10 ans après la clôture du DMP puis détruites.

Déclaration du candidat

Exigence déléguée

EX_AIR-110

Consigne

Le système d’information de la structure de soins doit être en mesure de garantir la confidentialité, l’intégrité et la complétude des traces.

Déclaration du candidat

Exigence déléguée

EX_AIR-120

Consigne

Sur demande de l’assurance maladie, le système d’information doit permettre à une structure de soins d’extraire et de fournir toutes les traces dématérialisées d’un PS ou de plusieurs PS sur une période donnée dans un délai de 7 jours ouvrables. Les modalités d’échanges des traces avec l’assurance maladie seront définies lors de la demande.

Déclaration du candidat

Exigence déléguée

REC_AIR-010

Consigne

Il est recommandé de proposer un serveur de jeton VIHF centralisé afin d’en garantir la sécurité logique et physique (spécialement pour les certificats X509).

Déclaration du candidat

La DevBox-santé centralise la création des jetons VIHF. Néanmoins la fourniture des certificats par le serveur de jetons est spécifique à l’intégrateur.

TD 0.2

EX_0.2-1020

Consigne

“Par défaut, le LPS ne doit pas afficher les traits d’identité retournés par la transaction TD0.2 dans le bloc patientPerson. L’affichage de ces données doit être activable par paramétrage accessible par l’éditeur et/ou le PS. Seuls les traits d’identité de l’INS font foi (cf. DMP_b).”

Déclaration du candidats

Certaines informations sont remontés par la DevBox-Santé lors de la transaction TD0.2. Elles peuvent éventuellement servir pour vérifier la cohérence entre les traits d’identité de la TD0.2 et de l’INS.

EX_0.2-1040

Consigne

Le mode « bris de glace » ne doit pas être persistant en dehors du temps de la session courante de l’utilisateur dans le LPS et pour le patient actuellement ouvert : il doit être désactivé une fois le dossier local du patient fermé (le LPS ne doit pas continuer à positionner ce champ à la valeur bris de glace).

Déclaration du candidat

Exigence déléguée

Du côté de la DevBox-santé DMP, chaque transaction (appel soap) est sans état.

EX_0.2-1050

Consigne

L’accès au DMP en mode « bris de glace » doit être affiché clairement à l’utilisateur du LPS pendant toute la durée de cet accès.

Déclaration du candidat

Exigence déléguée

EX_0.2-1100

Consigne

“Le LPS ne doit pas positionner systématiquement l’accord du patient concernant le consentement pour la consultation de son DMP par l’acteur de santé.

Cette action doit toujours se faire suite à une demande explicite ou à une action spécifique de l’utilisateur.

Pour le recueil du consentement du patient pour la consultation du DMP, le LPS doit afficher le texte suivant : « Le patient (ou son représentant légal), préalablement informé, consent au fait que j’accède à son DMP.

Avec le consentement patient, le logiciel pourra effectuer des requêtes de recherches de documents au nom de l’utilisateur authentifié sur le DMP et permettra de les consulter sur action manuelle. Ces interactions sont tracées avec l’identifiant national du professionnel authentifié et le patient sera notifié immédiatement de ces interactions. Toutes recherches et/ou consultations de ma part d’un document pour lequel le patient ne m’a pas autorisé et/ou je ne fais pas partie de l’équipe de soins m’expose à des poursuites. »

Le LPS doit permettre – à tout moment – de prendre en compte l’opposition du patient à l’alimentation de son DMP et l’absence de consentement pour la consultation de son DMP, si le patient en fait la demande explicite.

Le LPS doit tracer la non-opposition du patient pour l’alimentation de son DMP. La trace doit être gérée en local (= hors SI DMP) pour chaque structure de santé et/ou équipe de soins.

Le LPS doit tracer le consentement du patient dans le cas d’appels différés à la TD0.3, par exemple en cas d’une recherche et/ou d’une consultation d’un document par un membre de l’équipe de soins. "

Déclaration du candidat

Exigence déléguée

REC_0.2-1110

Consigne

“Les éléments de vocabulaire présentés dans les exemples d’IHM ci-dessous peuvent être intégrés au LPS. Exemple d’IHM en authentification directe pour un seul profil (consultation) : [Voir exemple dans le Guide d’intégration] Exemple d’IHM en authentification directe pour les deux profils (consultation et alimentation) : [Voir exemple dans le Guide d’intégration]

Précision : cette recommandation est également valable pour l’alimentation seule puisqu’elle fait référence à la ““non opposition à l’alimentation””. "

Déclaration du candidat

Recommandation déléguée

TD 0.3

EX_0.3-1010

Consigne

“Si l’autorisation d’accès en consultation du DMP d’un patient à un acteur de santé n’est pas définie ou si elle est expirée (EF_DMP04_01) et que le patient consent à la consultation de son DMP par l’acteur de santé (EF_DMP04_02), le LPS alimente automatiquement la donnée action avec la valeur AJOUT.

Cette exigence ne concerne que le profil consultation. Elle vaut également pour le mode AIR.”

Déclaration du candidat

Exigence déléguée

EX_0.3-1030

Consigne

“Le LPS ne doit pas appeler automatiquement la transaction TD0.3 après le recueil du consentement du patient concernant l’accès à son DMP. L’appel automatique de la transaction TD0.3 par le LPS doit faire suite à une demande explicite de consultation du DMP par l’utilisateur.

Exemple de cinématique de recueil du consentement du patient :

Le secrétariat médicale recueille le consentement du patient

Le LPS présente une alerte au PS précisant le consentement du patient

Lors d’une demande explicite de consultation par le PS, le LPS fait appel à la TD0.3 "

Déclaration du candidat

Exigence déléguée

EX_0.3-1040

Consigne

En cas de suppression du consentement du patient concernant l’accès à son DMP, le LPS doit appeler automatiquement et immédiatement la transaction TD0.3 pour supprimmer le(s) autorisation(s) d’accès préalablement accordée(s).

Déclaration du candidat

Exigence déléguée

TD0.4

REC_0.4-1010

Consigne

Le LPS vérifie lors de la réception de la liste, pour chaque INS de patient retourné, si cet INS de patient existe dans l’annuaire local et « marque » l’INS de patient local pour noter l’information « DMP existe et acteur de santé autorisé pour la consultation de ce DMP ». Les traitements de ces DMP par la structure autorisée pourront alors se faire en tenant compte de l’accord (non opposition pour l’alimentation ; consentement pour la consultation) des patients.

Déclaration du candidat

Recommandation déléguée

TD0.9

EX_GEN-1380

Consigne

Pour les LPS implémentant la transaction TD0.9 « Accès Web-PS contextuel», le poste de travail doit être équipé d’un des navigateurs compatibles avec les IHM Web-PS du DMP (voir annexe [DMP1-OS-NAVIGATEURS]).

Déclaration du candidat

Exigence déléguée

REC_0.9-1010

Consigne

“La fenêtre de navigateur peut être encapsulée dans le LPS (recommandation forte), ou lancée en « fenêtre externe » (Client lourd) en respectant les contraintes décrites ci-dessous. Dans le cas où une fenêtre externe est ouverte dans un navigateur, le LPS doit s’assurer qu’il n’existe pas, sur le poste de travail simultanément deux fenêtres DMP ouvertes de façon à éviter toute confusion entre « le patient local » au LPS et « le patient distant » sur le système DMP. Cela peut être réalisé par exemple en plaçant une constante dans le nom de fenêtre lors de sa création.”

Déclaration du candidat

Recommandation déléguée

Alimentation

EX_GEN-1060

Consigne

“Les règles de déclenchement de l’envoi des documents dans le DMP doivent être claires et paramétrables par le professionnel. Elles doivent s’intégrer dans le processus de validation médicale des documents.

Le LPS alimente le DMP automatiquement.

Le professionnel doit pouvoir retenir un envoi de document par une action manuelle.

L’envoi de documents vides ou n’ayant pas évolué (sans modification du contenu du document ni de ses métadonnées associées conformément au paragraphe 3.5.3.1) est interdit.”

Déclaration du candidat

Exigence déléguée

EX_GEN-1070

Consigne

Le choix des documents utiles à la coordination des soins à envoyer dans le DMP est défini réglementairement (code de la santé publique, notamment l’article L. 1111-15).

Déclaration du candidat

Exigence déléguée

EX_GEN-1377

Consigne

Il est nécessaire d’assurer la cohérence entre le secteur d’activité et le cadre d’exercice. Par exemple, on pourra associer un secteur d’activité « cabinet individuel » à un cadre d’exercice « Ambulatoire » et pas à un cadre d’exercice « établissement de santé ».

Déclaration du candidat

Exigence déléguée

EX_2.1-1010

Consigne

“Les documents d’expression personnelle du patient ne peuvent pas être créés via l’interface LPS :

classCode = 90, et les typeCode associés,

et/ou les typeCode commençant par « DOCPAT ».

Le document ““Données de remboursement”” ne peut être alimenté que par l’assurance maladie. Il ne peut donc pas être créé via l’interface LPS (classCode = 60, et typeCode = REMB).

Le document « historique de vaccinations » est unique par DMP. Il est créé automatiquement par le SI DMP lors de l’ajout d’une première vaccination (soit via WebPS, soit lors de l’alimentation d’une première note de vaccination en LPS, soit par le patient lui-même via « Mon espace santé » ou Web Patient ou application mobile pour les DMP non associés à « Mon espace santé »). Il ne peut pas être créé via l’interface LPS (classCode = 52, et typeCode = 11369-6). Un fonctionnement spécifique est défini dans le chapitre 6.1.”

Déclaration du candidat

La DevBox-Santé DMP effectue une vérification de ces types de document avant envoi vers le DMP.

EX_2.1-1030

Consigne

“Le titre d’un document doit en refléter le contenu médical (le titre est saisissable par le professionnel sauf si le titre est fixé dans le volet correspondant dans la couche « contenu » du CI-SIS).

Déclaration du candidat

Exigence déléguée

EX_2.1-1040

Consigne

Le titre d’un document doit être modifiable sauf si le titre est fixé dans le volet correspondant dans la couche « contenu » du CI-SIS. (*)

Déclaration du candidat

Exigence déléguée

EX_2.1-1050

Consigne

“A chaque alimentation du DMP à partir d’un LPS, l’acteur doit indiquer, pour chaque document :

si le document doit être masqué aux professionnels ou pas ;

si le document doit être visible au patient ou pas. NB : un document ne peut pas être à la fois non visible au patient et masqué au professionnel tant que le paramètre cumul-invisible_patient-masque_ps contient la valeur false (§ 3.1.1). NB2 : le passage d’un document au statut visible pour le patient ou pour ses représentants légaux est irréversible. • Lorsqu’un document initialement invisible au patient a été rendu visible au patient, il ne peut plus être rendu invisible au patient. De la même manière, un document qui a toujours été visible au patient ne peut pas être rendu invisible au patient. • Lorsqu’un document initialement invisible aux représentants légaux leur a été rendu visible, il ne peut plus leur être rendu invisible. De la même manière, un document qui a toujours été visible aux représentants légaux ne peut pas leur être rendu invisible Si la gestion des mineurs est activée (cf. paramètre fonctions-gestion-mineurs au § 3.1.1) et que le patient est mineur :

en cas de connexion secrète (cf. EX_0.1-1100 § 5.3.1.3), l’acteur ne peut déposer que des documents invisibles aux représentants légaux ;

en cas de connexion non secrète, l’acteur doit indiquer si le document est visible ou invisible aux représentants légaux.

Pour l’alimentation automatique, le masquage aux professionnels et la visibilité au patient peuvent être déterminés à l’aide de règles spécifiques à chaque contexte (type de document, type d’établissement, …).”

Déclaration du candidat

Exigence déléguée

EX_2.1-1070

Consigne

Le titre du document doit être compréhensible et ne peut être arbitrairement tronqué à la limite de taille (128 caractères).

Déclaration du candidat

Exigence déléguée

EX_2.1-1071

Consigne

“Tout document au format CDA R2 doit être conforme : • au standard CDA R2 utilisé pour les documents : vérification par le schéma xml CDA_extended.xsd. • aux spécifications de l’en-tête (Volet Structuration minimale des documents de santé) : vérification par le schématron ASIP-STRUCT-MIN-StrucMin.sch, • aux spécifications internationales IHE du corps (sections, entrées et jeux de valeurs) : vérification par le schématron IHE.sch, • aux spécifications françaises du corps (sections, entrées et jeux de valeurs) (Volet Modèles de contenus CDA) : vérification par le schématron CI-SIS_ModelesDeContenusCDA.sch, • aux spécifications des sections et entrées françaises du corps créées par l’ANS (sections et entrées créées par l’ANS pour les volets français) (Volet Modèles de contenus CDA) : vérification par le schématron CI-SIS_Modeles_ANS.sch, • aux spécifications du document si ce dernier est structuré (en-tête et corps) (Volet du document) : vérification par le schématron [nom_du_volet].sch, • aux terminologies utilisées dans le volet : vérification par le schématron terminologie.sch.

Tout écart détecté se traduit par la déclaration de non-validité du document. "

Déclaration du candidat

La DevBox-santé santé intègre dans la version 7 les différents composants du projet TestContenuCDA-3-0 Github de l’ANS, et propose la validation xsd et SCHEMATRON automatique par l’utilisation des feuilles de style xslt fournies dans le projet https://github.com/ansforge/interop-outil-cda-testcontenucda3.0-outil-validation-documents-cda. En cas de non validité un rejet de la transaction est effectuée avant envoi au DMP.

Elle intègre régulièrement les différentes versions taggées par l’ANS (https://esante.gouv.fr/actualites/versionning-schematrons-cda-outil-testcontenucda)

Informations complémentaires

EX_2.1-1090

Consigne

“Cette exigence ne concerne que les LPS de type EAI ou gérant la fonctionnalité PFI :

Les familles de produits contenant des LPS de type EAI doivent nécessairement réaliser des contrôles sur les documents CDA de conformité de tous les documents CDA R2 (cf. exigence EX_2.1-1071) avant envoi au DMP.

Pour les documents « note de vaccination » (typeCode = 87273-9), le contrôle schématron ne suffit pas. Il faut également respecter les exigences décrites dans le chapitre 6.1.”

Déclaration du candidat

Outre le respect des différentes exigences, concernant la “note de vaccination” c’est la DevBox-santé DMP qui génère le CDA à partir des règles définies dans le cahier des charges des différents volets. Les valeurs nécessaires en entrée pour la génération sont validées via le framework javax.validation.

Exemple :

 public static class SubstanceAdministration {

        @NotNull
        private DMPCCode code;
        @NotNull
        @NotBlank
        private String status;
        @NotNull
        private ZonedDateTime dateTimeAdministration;
        private RangeDateTime duree;
        @NotNull
        private Value doseAdministree;
        @NotNull
        private DMPCCode voieAdministration;
        @NotNull
        private DMPCCode regionAdministration;
        @NotNull(groups = {NoteVaccinationRequired.class})
        private Consommable consommable;
      ...
    }

EX_2.1-1115

Consigne

Pour des raisons de sécurité, un LPS alimentant le DMP avec des CDA auto-présentables ne doit pas inclure de script (balise HTML script) ni de lien vers des ressources externes (styles CSS externes, import de scripts, iframes, fenêtres surgissantes, liens, images, vidéos, etc.) dans la feuille de style couplée au document. Seules sont autorisées des ressources encapsulées dans la feuille de style (liens internes, styles CSS inclus dans le document, images encapsulées…). La feuille de style couplée au document doit être autonome en termes de visualisation à l’utilisateur.

Déclaration du candidat

La DevBox-Santé DMP ne permet pas l’envoi de documents CDA auto-présentables.

EX_2.1-1116

Consigne

Pour des raisons de sécurité, un LPS alimentant le DMP avec des documents CDA auto-présentables ne doit pas permettre à tous ses utilisateurs de modifier la feuille de style XSL des documents qu’il produit. Si le LPS permet de modifier des feuilles de style « modèles » utilisées par le LPS pour constituer les CDA auto-présentables envoyés au DMP, seuls des acteurs autorisés (de type « administrateurs ») doivent pouvoir le faire. Le LPS doit mettre en œuvre des moyens pour protéger et confiner en son sein les feuilles de style des documents CDA auto-présentables qu’il produit.

Déclaration du candidat

La DevBox-Santé DMP ne permet pas l’envoi de documents CDA auto-présentables.

EX_2.1-1130

Consigne

“Chaque document et lot de document(s) produit par un LPS doit être identifié par un identifiant universel (champ XDS uniqueId au format OID) : • soit le uniqueId est généré à partir d’un UUID (sous la branche OID 2.25), dans ce cas cet OID doit être stocké dans le LPS pour les recherches / remplacements futurs via ce même LPS ; • soit le uniqueId est généré à partir d’une racine propre à l’installation du LPS et d’un élément « variable » mais unique vis-à-vis de la racine de l’instance du LPS installée (par exemple horodatage, ou identifiant interne du document dans le LPS) ; il incombe au LPS de pouvoir retrouver ce uniqueId pour les recherches / remplacements futurs via ce même LPS (par exemple en stockant le uniqueId ainsi généré, ou la partie variable uniquement à condition de savoir reconstruire le uniqueId complet).

La longueur d’un uniqueId est limitée à 128 caractères.

Note : Le format d’un uniqueId de document peut être OID^Extension en XDS. Or, la version actuelle du DMP ne supporte pas le format OID^Extension pour cette référence. Il est donc demandé de n’utiliser pour les uniqueId de document que le format OID sans extension (ex. : « 1.2.850.2345.3245.13.58132 »). "

Déclaration du candidat

Une source au sens XDS est conformément à l’exigence EX_.GEN-1350 unique.

Au sein de chacune de ces sources des identifiants uniques sont alors générés. Cette génération est basée sur un timestamp et un compteur interne. Un identifiant unique pour une source unique garantit une unicité globale.

Un endpoint /dmp/document/uniqueId est rendu disponible à l’intégrateur afin de générer ces propres identifiants de documents conformes aux restes des identifiants.

Informations complémentaires

/7.x/devbox-sante/connecteurs/dmp/howtos/uniqueidgenerator/
/7.x/devbox-sante/installation/docker/configuration/#dmp voir la configuration lpsInfo et source.

EX_2.1-1140

Consigne

“L’association d’un document à son ou ses auteurs est assurée par la métadonnée XDS authorPerson ou legalAuthenticator (le responsable légal est donc assimilé à l’un des auteurs). Seul l’un des auteurs du document peut ajouter ce document ou le mettre à jour avec une nouvelle version (remplacement du document) ; cette règle est appliquée comme suit : • en authentification directe (hors CPE), le professionnel authentifié doit faire partie des auteurs (champ NameID du VIHF = composant « identifiant » de authorPerson ou de legalAuthenticator) ; • en authentification indirecte ou pour un personnel d’établissement (par CPE), la structure authentifiée (ou de laquelle dépend la CPE) doit être égale à la métadonnée authorInstitution de l’un des auteurs (champ Identifiant_Structure du VIHF = champ identifiant de authorInstitution).”

Déclaration du candidat

L’ensemble des informations concernant le professionnel authentifié, sont liées au contexte d’appel de chaque requete vers le DMP.

en authentification directe par carte CPS, les informations du professionnel sont récupérées des métadonnées de la carte CPx et sont forcées dans le contexte d’appel.
en authentification directe par carte ProSantéConnect, les informations du professionnel sont récupérées des métadonnées du jeton ProSantéConnect et sont forcées dans le contexte d’appel.
en authentification directe par carte CPE, les informations de structures sont récupérées des metadonnées de la carte CPx et sont forcées dans le contexte d’appel.
en authentification indirecte, les informations de structure sont directement lues du certificat d’authentification et sont forcés dans le contexte d’appel.

Dans la DevBox-santé DMP ce contexte d’appel permet de générer le VIHF les informations de l’auteur de la soumission, et le legalAuthenticator par défaut des documents …

EX_2.1-1190

Consigne

Le LPS doit implémenter une solution permettant à l’utilisateur d’identifier visuellement si des documents utiles à la coordination des soins peuvent être envoyés au DMP (message, icônes dans une liste de documents, etc.).

Déclaration du candidat

Exigence déléguée

EX_2.1-1260

Consigne

L’alimentation d’un document vers le DMP exige l’usage du MTOM avec optimisation XOP dans la requête envoyée (voir profil IHE XDS (ITI volume 2 / ITI-41 ProvideAndRegisterDocumentSet-b au § 3.41.4.1.2 Message Semantics) et [CI-TR-CLI-LRD] § 3.2.5).

Déclaration du candidat

La DevBox-Santé DMP utilise la librairie Apache CXF pour la gestion des messages SOAP. Elle active le support MTOM + XOP :

final DocumentRepositoryPortType endPoint = jaxwsFactory.createEndPoint(DocumentRepositoryPortType.class, "/repository");
SOAPBinding sb = (SOAPBinding) ((BindingProvider) endPoint).getBinding();
sb.setMTOMEnabled(true);

EX_2.1-2000

Consigne

“Précision : Concerne la note de vaccination en Alimentation

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é).”

Déclaration du candidat

Exigence déléguée

La DevBox-Santé DMP prend néanmoins en charge la note de vaccination afin de faciliter l’intégrateur la gestion de ce volet.

Informations complémentaires

/7.x/devbox-sante/connecteurs/dmp/cda/vaccination/

EX_2.1-2005

Consigne

“Il est interdit d’envoyer une note de vaccination avec un « confidentialityCode » possédant une valeur autre que N (Normal).

NB : il n’est pas possible d’envoyer une note de vaccination en connexion secrète.”

Déclaration du candidat

Exigence déléguée

EX_2.1-2010

Consigne

“Une note de vaccination ne peut contenir qu’une seule vaccination à des fins de granularité « unitaire » des actions de modification et de suppression de vaccination dans l’historique de vaccinations.

Un LPS peut néanmoins alimenter simultanément un DMP avec plusieurs notes de vaccination dans le même lot de soumission (1 seule requête vers le DMP contenant plusieurs notes de vaccination). Ceci doit être transparent pour l’utilisateur.

Il est exigé que ces notes soient toutes en version identique 2023.01.

Précision : pour les packages antérieurs à la 02.09.00 (02.07.00 et 02.08.00), les versions 2021.01 et 2022.01 de la note de VAC restent compatibles.”

Déclaration du candidat

Exigence déléguée

Si l’intégrateur s’appuie sur le support de la note de vaccination de la DevBox-Santé DMP, il ne sera possible de n’ajouter qu’une seule vaccination.

public class DMPCNoteVaccination extends DMPCDocument {

    @NotNull
    private Vaccination vaccination;

La DevBox-Santé supporte également la soumission multiple de documents, la note de vaccination comprise :

public class DMPCSoumission {

    @NotNull
    @NotEmpty
    @Singular
    private List<DMPCDocument> documents;

Les notes de vaccination sont en version 2023.01

EX_2.1-2020

Consigne

“Les acteurs « auteur de vaccination » et « vaccinateur » présents dans le contenu de la note de vaccination doivent (lorsque connus) également être ajoutés dans la liste des auteurs de la note de vaccination : cela permet à ces acteurs de pouvoir ensuite modifier ou supprimer la note de vaccination et donc les données de la vaccination dans l’historique de vaccinations.

L’acteur « vaccinateur » doit (lorsque connu) également être présent sous l’élément CDA documentationOf/serviceEvent/performer de l’acte principal documenté puisqu’il ne peut y avoir qu’une seule vaccination par note de vaccination.

Il est rappelé que les métadonnées présentes dans l’entête CDA doivent également être par cohérence présentes dans les métadonnées XDS (règle de DMP compatibilité), le nombre d’auteurs devra donc être identique entre la partie XDS et la partie entête CDA”

Déclaration du candidat

La DevBox-Santé permet le rajout automatique des acteurs de la vaccination dans la liste des auteurs du document (executant, et auteur de la vaccination).

EX_2.1-2035

Consigne

“Seule la version 2023.01 du 08/03/2023 du volet VAC (CI-SIS) doit être utilisée pour l’alimentation du DMP.

Précision : pour les packages antérieurs à la 02.09.00 (02.07.00 et 02.08.00), les versions 2021.01 et 2022.01 de la note de VAC restent compatibles.”

Déclaration du candidat

La DevBox-Santé DMP génère cette version 2023.01 depuis sa version 6

REC_2.1-1065

Consigne

“Les contraintes suivantes pourraient être levées dans le futur : • « un document ne peut pas être à la fois non visible au patient et masqué au professionnel » (cf. paramètre cumul-invisible_patient-masque_ps § 3.1.1) ; • « un document visible au patient ne peut pas être rendu invisible au patient » ; • « un document visible aux représentant légaux ne peut pas être rendu invisible aux représentant légaux ». Il est conseillé de pouvoir lever facilement les deux dernières contraintes, par exemple par paramétrage du logiciel.”

Déclaration du candidat

Recommandation déléguée

REC_2.1-1080

Consigne

Il est recommandé de prendre en compte dès la conception du LPS les tests à effectuer avec les schématrons. Les schématrons sont disponibles sur le site de l’ANS : Cf. [TEST-CONTENU-CDA].

Déclaration du candidat

Un module de validation est intégré à la debox-sante DMP qui valide le document avant tout envoi au DMP avec les contenus fournit dans [TEST-CONTENU-CDA].

La validation se fait en deux étapes :

Validation de la structure du document à l’aide du cda.xsd
Validation des régles sémantiques définies dans les schematrons (en fonction du format du document)

Informations complémentaires

REC_2.1-1100

Consigne

“Ni le standard CDA ni le Cadre d’Interopérabilité des SIS ne précisent la manière dont chaque valeur possible du confidentialityCode (Normal, Restreint, Très Restreint) doit être interprétée. Un document ayant un niveau renforcé de confidentialité (restreint ou très restreint), devrait être remis en mains propres, ou envoyé sous pli scellé ou par message direct à son destinataire. Il ne devrait pas être mis en partage. Si votre logiciel ne gère pas de niveau de confidentialité, il est recommandé de renseigner la donnée « confidentialityCode » avec la valeur N (Normal).

A noter que ce niveau de confidentialité du CDA n’est pas en lien avec le masquage patient/PS/représentant légal dont la donnée transite dans les métadonnées XDS.”

Déclaration du candidat

Exigence déléguée

La Devbox-santé DMP permet de renseigner les confidentialityCode à la discretion de l’intégrateur.

REC_2.1-1117

Consigne

Il est recommandé de respecter un format d’affichage A4 portrait pour les documents CDA auto-présentables.

Déclaration du candidat

La DevBox-Santé DMP ne permet pas l’envoi de documents CDA auto-présentables.

Consultation

EX_3.1-1070

Consigne

“Il est demandé d’afficher la date du document en heure locale : dans le cas d’une recherche de documents (TD3.1 - IHE ITI-18 Registry Stored Query XDS) : en se basant sur la métadonnée XDS, avec conversion dans la date locale avant l’affichage à l’utilisateur.”

Déclaration

Exigence déléguée

L’intégrateur doit pouvoir afficher les dates localement à l’utilisateur et les transmettre en UTC avant recherche.

EX_3.1-1075

Consigne

“Le LPS doit afficher une indication (texte ou image) informant l’acteur de santé qu’il est en cours de consultation du DMP de son patient (Mon espace santé). Les expressions « DMP » et « Mon espace santé » doivent faire partie de l’indication. Cette indication doit également s’afficher lors de la consultation des documents provenant du DMP de son patient (Mon espace santé). Cette indication ne doit pas apparaitre lors de la consultation des documents ne provenant pas du DMP de son patient (Mon espace santé).

Déclaration du candidat

Exigence déléguée

EX_3.1-1080

Consigne

“Lors de l’affichage des résultats à la suite de recherches de document, le LPS doit indiquer au professionnel l’état du document qui peut être : -« masqué aux professionnels »,

« non visible par le patient »,

« non visible par les représentants légaux »,

« archivé »,

« ancienne version obsolète ». Il n’y a pas de valeur spécifique pour un document « courant » (on ne précise pas d’état particulier).”

Déclaration du candidat

Exigence déléguée

EX_3.1-1090

Consigne

“Le LPS ne doit pas appeler automatiquement la transaction TD3.1 après une alimentation d’un DMP. La requête stockée GetDocuments en mode ObjectRef de la transaction TD3.1 est à appeler juste avant une action sur un document (supprimer, archiver ou remplacer). "

Déclaration du candidat

La DevBox Santé génère le uniqueId et l’entryUuid du document si il n’est pas renseigné par l’intégrateur lors de l’alimentation. Ces derniers sont retournés à l’intégrateur en réponse de la transactions.

C’est donc l’intégrateur pour les actions supprimer/archiver/remplacer, qui réalise les appels à la TD3.1 afin de recupérer la dernière version du document avant d’exécuter la mise à jour.

EX_3.1-2000

Consigne

L’implémentation de la recherche FindDocumentByReferenceId est obligatoire pour les LPS compatibles avec le partage d’imagerie.

Déclaration du candidat

Exigence déléguée

La Devbox-Santé DMP permet la recherche de document d’imagerie et supporte la requête FindDocumentByReferenceId.

EX_3.1-2030

Consigne

“Le LPS ne doit pas appeler automatiquement la transaction TD3.1 après une alimentation d’un DMP.

Le LPS doit limiter ses appels à la transaction TD3.1 lors de l’ouverture d’un dossier patient. Le LPS pourra commencer : • Soit par une recherche de base avec ou sans critère de recherche, • Soit par un premier groupe de requêtes pour supporter la recherche de documents depuis une date (Cf. EX_3.1-1020).

Les sollicitations suivantes à la TD3.1 doivent obligatoirement relever d’une demande explicite de recherche par l’utilisateur depuis l’IHM du LPS.”

Déclaration du candidat

Exigence déléguée

EX_3.1-2035

Consigne

“En cas d’erreur DMPAccessDeniedByExcededThreshold, le LPS ne doit pas bloquer le processus d’alimentation du DMP par l’utilisateur authentifié.

Cette erreur peut survenir en cas de sur-sollicitation du SI DMP par l’acteur de santé.”

Déclaration du candidat

Exigence déléguée

EX_3.2-1010

Consigne

“Le LPS ne doit pas réaliser de téléchargement systématique du contenu des documents (i.e. ne pas réaliser de TD3.1 suivi d’une TD3.2 systématique pour chaque document retourné par la TD3.1). Les documents DMP téléchargés à partir de la TD3.2 ne doivent, en aucun cas être conservés automatiquement en dehors du DMP. Une action manuelle du professionnel est obligatoirement requise pour l’enregistrement dans le LPS de chaque document. Sans action manelle du professionnel et après consultation, les documents DMP téléchargés à partir de la TD3.2 doivent être supprimés automatiquement. Le LPS doit clairement afficher la provenance (DMP) du document enregistré dans le LPS, ainsi que la date de son enregistrement.”

Déclaration du candidat

Exigence déléguée

EX_3.2-1025

Consigne

“La consultation d’un document invisible au patient (confidentialityCode = INVISIBLE_PATIENT), doit donner lieu à une information du professionnel par l’affichage d’un message d’alerte de type : ““Attention, ce document n’est pas visible du patient”” La consultation d’un document invisible aux représentants légaux (confidentialityCode = INVISIBLE_REPRESENTANTS_LEGAUX), doit donner lieu à une information du professionnel par l’affichage d’un message d’alerte de type : ““Attention, ce document n’est pas visible des représentants légaux pour préserver le secret du mineur titulaire du DMP”””

Déclaration du candidat

Exigence déléguée

L’ensemble de ces métadonnées sont retournées par l’API, à charge de l’intégrateur de les afficher à l’utilisateur.

EX_3.2-1030

Consigne

Le LPS doit permettre l’affichage des données d’en-tête du document CDA R2.

Déclaration du candidat

Exigence déléguée

La DevBox-santé DMP retourne le résultat html de la transformation xslt de la feuille de style fourni par l’ANS [TEST-CONTENU-CDA] (td32Response.htmlContent)

Le endpoint /cda/to/html permet de récupérer également cette transformation.

EX_3.3-1030

Consigne

Toute demande de masquage / démasquage doit donner lieu à une confirmation par l’utilisateur effectuant l’action : le LPS doit proposer un message de confirmation du masquage / démasquage.

Déclaration du candidat

Exigence déléguée

EX_3.3-1040

Consigne

“La fonction « Rendre un document visible au patient » est irréversible et ne permet pas de rendre invisible à nouveau un document visible. Le LPS doit afficher un message demandant à l’utilisateur de confirmer l’action. Il est conseillé de pouvoir facilement désactiver cet affichage, par exemple par paramétrage du logiciel. Cf. recommandation REC_2.1-1065.”

Déclaration du candidat

Exigence déléguée

EX_3.3-1045

Consigne

“La fonction « Rendre un document visible aux représentants légaux du patient » est irréversible et ne permet pas de rendre invisible à nouveau un document visible. Le LPS doit afficher un message demandant à l’utilisateur de confirmer l’action. Il est conseillé de pouvoir facilement désactiver cet affichage, par exemple par paramétrage du logiciel. Cf. recommandation REC_2.1-1065.”

Déclaration du candidat

Exigence déléguée

EX_3.3-1050

Consigne

“La fonction de suppression d’un document est irréversible et un utilisateur ne peut pas annuler une suppression. Le LPS doit afficher un message demandant au professionnel de confirmer la suppression. L’utilisateur doit confirmer sa demande de suppression.

Note : une exception à l’exigence EX_3.3-1050 concerne les documents au format KOS DICOM : la suppression de ces documents peut s’effectuer sans confirmation de la part de l’utilisateur.”

Déclaration du candidat

Exigence déléguée

EX_3.3-1060

Consigne

“La suppression des documents dans le DMP d’un patient sans autorisation d’accès est réservée au profil Alimentation.

Précision : la suppression doit toujours pouvoir se faire sans autorisation. Cette exigence concerne tous les LPS implémentant le profil Alimentation.”

Déclaration du candidat

Exigence déléguée

REC_3.1-1060

Consigne

Il est recommandé d’utiliser les termes indiqués ci-dessus en gras. L’éditeur peut aussi utiliser une icône représentant chacun de ces états.

Déclaration du candidat

Recommandtion déléguée

REC_3.2-1060

Consigne

Pour afficher le corps du document (organisé en structures XML), le LPS peut appliquer une feuille de style XSLT et afficher le résultat à l’utilisateur via un navigateur web, éventuellement encapsulé.

Déclaration du candidat

Recommandation déléguée

La DevBox-santé DMP retourne le résultat html de la transformation xslt de la feuille de style fourni par l’ANS [TEST-CONTENU-CDA] (td32Response.htmlContent). Donc si le document est un document structuré, le rendu html de la transformation contiendra le corps du document affichable à l’utilisateur.

Le endpoint /cda/to/html permet de récupérer également cette transformatïon.

REC_3.2-1080

Consigne

“Plusieurs documents peuvent être liés entre eux car ils constituent un ensemble cohérent pour un même épisode de soins. Lors de la consultation d’un document, il est conseillé d’afficher les documents qui lui sont liés. Cela permet notamment au médecin qui consulte un document d’identifier qu’il y a d’autres documents qui peuvent l’intéresser et d’y accéder beaucoup plus simplement. Dans le système DMP, • les documents soumis dans un même lot sont liés. • Un même document peut être référencé dans plusieurs lots de soumission. • Les documents peuvent être liés par referenceIdList. Cf. REC_2.1-1160 dans RG_2610 au § 3.4.1.1.5. Exemple de la fiche RCP : Lors de la consultation de la fiche RCP, le médecin doit pouvoir facilement identifier qu’il existe un CR-Opératoire et un CR-ACP liés. Ce lien existe dès lors que ces 3 documents ont été groupés dans le même lot de soumission à l’alimentation du DMP. "

Déclaration du candidat

Recommandation déléguée

Lors de la recherche par soumission puis des documents associés, le résultat est retourné groupé par soumission à l’intégrateur. L’intégrateur peut ainsi lier les documents entre eux.