# Envoie d'un document sur le DMP ### /sendsubmissionset La route /sendsubmissionset permet l'envoie d'un document ou d'une liste de documents sur le DMP d'une personne ``` { "EsUser": {}, "s_dmpUrl": "", "i_timeout": 30, "s_dmpEsId": "", "AdditionalPatientIdentifiers": [ // (Optionnel) : Permet de spécifier des identifiants secondaires pour le patient (IPP, NIP, ...) { "s_extension": "", "s_root": "" } ], "Documents": [], "ReferencedDocuments": [], // (Optionne)l Liste des documents à référencer dans ce lot de soumission. Ce sont des documents qui doivent exister dans le DMP. Chaque référence est définie par : "Identity": {}, // (Optionnel) Permet de spécifier l’identité du patient "s_birthPlaceCode": "", (Optionnel) Code du lieu de naissance (COG INSEE). Obligatoire si l’envoi contient des pièces jointes et que les informations du patient n’ont pas été spécifiés avec Identity. "i_disablePdfa1Conversion": 0, // (Optionnel) Si vrai (1) la conversion des documents PDF en PDF/A‐1 est désactivée. Il est alors de la responsabilité de l’éditeur de s’assurer que les documents PDF sont bien au format PDF/A‐1. "i_pdfa1IgnoreTransparency": 0, // (Optionnel) Si vrai (1) la transparence est ignorée lors de la conversion en PDF/A‐1. Ceci accélère le processus mais peut générer des documents illisibles. "i_pdfa1ImageResolution": 0, // (Optionnel) Indique en dpi la résolution des images à utiliser lors de la conversion en PDF/A‐1. Par défaut cette valeur est fixée à 200dpi. "i_forceSchematronsValidation": "", (Optionnel) Par défaut, la validation par schématrons est désactivée pour les documents non structurés (txt, rtf, pdf, jpg et tiff), garantis conformes par le connecteur. Si i_forceSchematronsValidation est vrai (1) alors la validation par schématrons est aussi active sur ces documents. "i_getCdaContent": 0, // (Optionnel) Permet d’activer la sortie de chaque document envoyé au format CDA en retour de la fonction. "i_getDocumentContent": 0, // (Optionnel) Permet de récupérer le contenu haut niveau des documents envoyés. "i_getVihf": 0, // (Optionnel) Si vrai (1), le VIHF de la transaction DMP TD2.1 est retourné. "i_getXdsMetadata": 0, // (Optionnel) Si vrai (1), les métadonnées XDS de la transaction DMP TD2.1 est retourné. "i_retrieveDocumentUuid": 0, // (Optionnel) Permet, en effectuant une transaction supplémentaire par document, d’obtenir l’identifiant tech‐ nique (UUID) de chaque document envoyé. "i_transcodeTypeCode": "", // (Optionnel) Si vrai (1) le code de catégorie des documents (champ s_category) est transformé avant l’envoi afin de garantir que les codes utilisés sont toujours les plus à jour. (Par défault : off). "i_automaticPdfCopyEmbedding": 0, (Optionnel) Si vrai (1) le connecteur génère et ajoute automatiquement une version PDF (une « copie ») de chaque document CDAr2 N3 dans une section structurée de type FR-Document-PDF-copie. "s_healthcareSetting" : "", // Cadre de soin lors du dépôt de document. (Cf. Cadre de soin (Healthcare settings) dans la documentation des jeux de valeurs). "s_ins" : "" "s_localPatientId" : "", // (Optionnel) Identifiant (unique) du patient dans le SI local. "s_localPatientRootOid" : "", // (Optionnel) Racine des OID des Id des patients dans le SI local. "s_submissionSetDescription" : "", // (Optionnel) Description du lot de soumission. "s_submissionSetOid" : "", // (Optionnel) OID du lot de soumission. A utiliser dans le cas où l’établissement possède sa propre racine d’OID. "s_submissionSetTitle" : "" //(Optionnel) Titre du lot de soumission } ``` Si on ne conserve que les champs obligatoires, on obtiens cela : ``` { "EsUser": {}, "s_dmpUrl": "", "i_timeout": 30, "s_dmpEsId": "", "Documents": [], "s_ins" : "" } ``` Concernant le champ "Documents", voir [la page concernant la structure des documents](https://ambroise.reconnect.fr/books/icanopee/page/structure-document) ### Retour : L'appel retourne cette structure de données : ``` { "UniqueIds" : [], // La liste des identifiant locaux (UniqueId) des documents déposés (dans le même ordre que celui des documents en entrée). "Uuids" : [], // Seulement présent si l’option i_retrieveDocumentUuid est active. Il s’agit de la liste des identifiants techniques (UUID) des documents déposés (dans le même ordre que celui des documents en entrée). "CdaContentsInBase64" : [], // Seulement présent si l’option i_getCdaContent est active : la liste des documents envoyés au format CDA en base64 (dans le même ordre que celui des documents en entrée). "DocumentsContent" : [], // Seulement présent si l’option i_getDocumentContent est active. Pour chaque document déposé, sa structure haut niveau est retournée. L’ordre est identique à celui des documents en entrée. La structure haut niveau est identique au retour de la fonction /getDocumentFromCda (Cf. /getdocumentfromcda). "i_vihfInBase64" : "", // Seulement présent si l’option i_getVihf est active. Contient le VIHF. Le champ est encodé en base64. "i_xdsMetadataInBase64": "", // Seulement présent si l’option i_getXdsMetadata est active. Contient les métadonnées XDS de l’envoi DMP. Le champ est encodé en base64. "s_status" : "OK" } ``` ### Notes : ##### ****Dans le cas où un document est défini à partir de son CDA complet (i.e.**** \[via le champ s\_cdaContentInBase64) il est nécessaire que l’utilisateur connecté (i.e. EsUser.HP) soit l’un des auteurs du document. La vérification est effectuée côté serveur et porte à minima sur les champs suivants :\] - Nom du professionnel (EsUser.HP.s\_hpName) - Prénom du professionnel (EsUser.HP.s\_hpGiven) - Identifiant du professionnel (EsUser.HP.s\_hpInternalId et EsUser.HP.i\_hpInternalIdType) - Nom de la structure du professionnel (EsUser.PracticeLocation) - Identifiant de la structure du professionnel (EsUser.PracticeLocation. s\_practiceLocationStructureId ou identifiant du certificat d’authentification) Si au moins l’un des champs ne correspond pas alors le document est rejeté par le serveur. ##### ****Dans le cas où l’ajout d’une copie PDF du document est demandée (option i\_automaticPdfCopyEmbedding) alors :**** - celle‐ci est effectuée à partir de la feuille de style de l’ANS; - elle n’est effectuée que pour des documents structurés CDAr2 N3 (ex : VSM, CrBio). ##### ****Afin d’être conforme avec le référentiel INS, depuis la version 1.9.0 du connecteur, le code du lieu de naissance (COG INSEE) est obligatoire en entrée.**** Le code peut être spécifié de deux façons : - Dans le bloc Identity (champ s\_birthPlace). - Dans le champ s\_birthPlaceCode si le champ Identity n’est pas utilisé. ##### ****Les identifiants doivent être conservés en cas de suppression des dits documents**** ##### ****Si la structure Identity est fournie et si le connecteur dispose de l’extension INSI**** - alors les données du patient spécifiées dans les documents sont obtenues à partir de cette structure. Dans le cas contraire, les données du patient sont obtenues à l’aide de la transaction DMP TD0.2 (automatiquement appelée avant l’envoi des documents). Les données issues de l’INSi incluent en particulier la liste des prénoms, contrairement à la TD 0.2 qui ne retourne qu’un seul prénom. ##### ****Les serveurs DMP limitent la tailles des documents CDA à 8 Mo.**** - Si le CDA fait plus de 8 Mo alors une erreur XDSRepositoryOutOfResources est retournée. - La taille maximale est celle du CDA, c’est‐à‐dire celle du document et des métadonnées CDA. - Dans le cas d’un document brut (JPEG, RTF, PDF), le corps du CDA est constitué d’une version encodée en base64 du document à envoyer. Du fait de l’encodage base64, la version envoyée au DMP est 4/3 plus grande que celle du document. Ainsi, la limite pour le document brut est réduite approximativement à 6 Mo (aux métadonnées CDA près). - Dans le cas d’un PDF, le connecteur effectue une conversion en PDF/A1 par défaut, or cette conversion peut produire un document plus gros que le document original.