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
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.
Pas de commentaires