Pourquoi il ne faut pas ajouter les traits identités "nom utilisé, prénoms de naissance et prénom utilisé" dans les champs de l'appel contextuel comme les autres champs, plutôt que de les récupérer dans un des documents obtenus après un premier appel au DMP ?
Dans le cadre d'une solution logicielle DRIMBox, les trois éléments relevés ne sont effectivement pas véhiculés au sein de la requête d'appel contextuel émise par le RIS/DPI. Cela correspond à un arbitrage historique pris dans le cadre des travaux menés au sein du projet DRIM-M.
Cependant, il est à noter que le "workflow de démarrage" de la fonction consommatrice associé à la solution DRIMBox a été défini en tenant compte de cet aspect, pour rappel :
- Mise en oeuvre d'une transaction d'appel contextuel, initiée par le RIS/DPI à destination de la fonction consommatrice DRIMBox.
- Authentification de l'utilisateur via PSC (peut être transparente selon le cas de figure).
- Interaction TD3.1 entre la DRIMBox et le DMP permettant de récupérer les métadonnées XDS associées aux documents publiés sur le DMP. Cela s'applique implicitement en considérant l'exigence DB.CO.54 mentionnée au sein de la spécification projet DRIMBox.
- Ouverture de l'interface DRIMBox (fonction consommatrice) présentant les résultats de la transaction TD3.1.
Au sein du workflow présenté ci-dessus, l'étape n°3 permet notamment de traiter la récupération des traits INS stricts du patient. En effet, les métadonnées "sourcePatientId" et "sourcePatientInfo" mentionnent l'intégralité des traits INS requis pour l'affichage au sein de l'interface DRIMBox (certains étant redondants avec les éléments mentionnés dans la requête d'appel contextuel). Cette transaction étant réalisée en amont de l'ouverture de l'interface utilisateur, l'ensemble des traits INS du patient pourront y figurer.
Il est à noter que la spécification projet DRIMBox (section 4.6.1) définit la requête d'appel contextuel "nominale" applicable dans le cadre du processus d'homologation SEGUR vague 2 DRIM-M. Suite à cette étape, lors du déploiement de solutions DRIMBox en production, il est tout à fait envisageable d'étendre les requêtes d'appel contextuel générées par la DRIMBox en y ajoutant un ou plusieurs headers répondant à un contexte ou une architecture donnée.
En revanche, le contenu de la requête d'appel contextuel ne pourra être réduit (au sens de suppression de certains headers définis en section 4.6.1 de la spécification projet DRIMBox) entre les phases d'homologation et de production.
Cette réponse vous a-t-elle été utile ?
