Traçabilité des Dispositifs Médicaux Implantables
3.0.0 - ci-build
FRANCE
Traçabilité des Dispositifs Médicaux Implantables - version de développement local (intégration continue v3.0.0) construite par les outils de publication FHIR (HL7® FHIR® Standard). Voir le répertoire des versions publiées
La construction des flux se base sur le supplément RESTful ATNA. Cela consiste en la construction de requêtes et de réponses HTTP de l’API REST de FHIR.
Diagramme de séquence des flux
A noter que si l’implémentation est basée sur le profil ATNA, la construction des flux consiste en la construction des requêtes ou des réponses syslog (pour la transmission de trace) et HTTP (pour la consultation et la recherche de trace).
Les flux transmettant les informations de traçabilité d’un évènement sont les suivants :
Flux 22 – TransmissionTrace
Flux 1c - TracabiliteDemande
Flux 2a - TracabiliteReponse
Flux 5 - TracabiliteLivraisonValide
Flux 5a – TracabiliteLivraisonRejet
Flux 5c – TracabiliteEntreeStockDMI
Flux 5d – TracabiliteReceptionDMI
Flux 5e – TracabiliteRejetDMI
Flux 6a – TracabiliteSortieStock
Flux 7 – TracabiliteDelivranceSU
Flux 9 – TracabiliteTransportDMI
Flux 11 – TracabiliteEntreStock
Flux 12 – TracabiliteReceptionSU
Flux 13a – TracabiliteRefusDMI
Flux 14 – TracabiliteEchecPose
Flux 15 -TracabilitePose
Flux 16a – TracabiliteReassortDMI
Flux 18 – TracabiliteFacturationDMI
Flux 27 – TracabiliteCommande
Flux 28 – TracabiliteRejetDMI
Flux 30 - TracabiliteSortieStockSU
Ils sont construits selon les exigences de la transaction IHE ITI-20 « Record Audit Event » dans sa version HL7 FHIR où une seule trace est transmise à la fois : « Send Audit Resource Request Message - FHIR Feed Interaction ».
Ce flux se base sur l’interaction « create » de l’API REST de FHIR. Il s’agit d’une requête HTTP POST dont le corps de la requête est une ressource Bundle suivant le profil DMI_BundleTransmissionTraces :
POST [base]/Bundle Où [base] est le point de contact FHIR défini par le Gestionnaire de trace. |
|---|
Si la transaction a été correctement effectuée et donc que la création du cercle de soins est correctement effectuée, un code HTTP 200 ok est retourné. Un Bundle de type transaction-response doit être renvoyé dans le corps de la réponse. Ce dernier doit contenir les ressources telles qu’elles ont été créées par le gestionnaire ou, a minima, les identifiants logiques des ressources ayant été attribués par le gestionnaire (dans Bundle.entry.fullUrl et/ou Bundle.entry.resource.id).
Sinon, un code HTTP 500 Internal Server Error est retourné avec une ressource OperationOutcome contenant le détail des erreurs et avertissements résultant du traitement des entrées du Bundle.