Raccordement DEP

Interfaces pertinentes

Les institutions de santé s’affilient à une communauté. En cas d’intégration en profondeur du DEP dans un système primaire, celui-ci doit être raccordé non seulement à la communauté, mais aussi au fournisseur d’identité de la communauté pour permettre l’authentification des utilisateurs. Dans ce cas, c’est la communauté qui assure en arrière-plan l’ensemble de la communication avec les autres communautés ou avec les services fédéraux.

Ce niveau s’adresse aux responsables techniques qui veulent savoir quelles interfaces et quelles exigences de sécurité ils doivent implémenter afin de pouvoir raccorder ultérieurement leur système primaire à la plateforme DEP de leur communauté. À chaque désignation des interfaces sont associées des informations détaillées à l’intention des développeurs d’interfaces.

Cette offre sur GitHub est continuellement complétée et élargie.

Lien externe : Vers GitHub

Vue d'ensemble des composants et interfaces DEP pertinents

Le graphique ci-dessous illustre les cas d’application requis (voir les flèches entre le système primaire et la communauté ou le système primaire et le fournisseur d’identité) avec les composants techniques pertinents.

Lien externe : Le graphique des interfaces pertinentes peut être téléchargé au format PDF. (416 KB, 30/10/23)

Les cas d'utilisation et les interfaces en détail

Les cas d'utilisation et les interfaces pertinentes sont décrits ci-dessous.

1. Gérer un patient

Pour qu’un professionnel de la santé ou son auxiliaire puisse accéder à un DEP, le système primaire doit enregistrer le patient auprès de la communauté.

Pour ce faire, le système primaire envoie l’identité locale du patient, avec les données démographiques, précédemment demandées, issues de la base de données UPI de la Confédération, au Master Patient Index (MPI) de la communauté.

Veuillez contacter votre communauté si vous voulez savoir comment obtenir les données démographiques de la base UPI.

Une fois qu’il a réussi à enregistrer le patient auprès de la communauté, le système primaire peut, en utilisant son identité locale du patient, obtenir les identifiants nécessaires pour pouvoir accéder aux données dans le DEP.

1.1 Rechercher un patient

Si le patient est déjà enregistré dans le MPI de la communauté, le système primaire peut le rechercher sur la base d’informations démographiques (nom, prénom ou date de naissance, p. ex.) au moyen de , par exemple pour enregistrer ensuite l’identité locale.

1.2 Enregistrer un patient

Pour enregistrer un patient dans le MPI de la communauté, le système primaire envoie les informations personnelles tirées de la base de données UPI et l’identité locale du patient au moyen de la transaction .

1.3 Consulter l’identité d’un patient

Une fois le patient enregistré dans le MPI de la communauté, le système primaire peut consulter l’identité du patient pour l’accès au DEP (EPR-SPID et MPI-PID) à l’aide de l’identité locale enregistrée du patient en exécutant la transaction .

Rappel : pour des raisons juridiques, le numéro EPR-SPID ne doit pas être stocké de manière permanente dans le système primaire et doit donc faire l’objet d’une nouvelle requête à chaque fois.

2. Authentifier un utilisateur DEP

Le professionnel de la santé ou l’auxiliaire s’authentifie auprès du fournisseur d’identité (Identity Provider) en utilisant une identité électronique (E-ID) depuis son système primaire. Le fournisseur d’identité confirme à la communauté qu’il s’agit de la bonne personne et ouvre une Identity Provider User Session.

Trois interfaces sont requises à cet effet : l’authentification de l'utilisateur (), le renouvellement d’une Identity Provider User Session expirée mais renouvelable () et la déconnexion ().

Dans le contexte du DEP, l’utilisation du SAML 2.0 Artifact Binding sur HTTP avec un XML SOAP Webservice Backchannel est obligatoire. L’authentification se fait en deux temps : transfert de tokens abstraits par HTTP dans un premier temps, puis consultation d’informations relatives à l’utilisateur (Claims) par le biais d’un service web sécurisé dans un second temps.

3. Autoriser un utilisateur DEP

Une fois authentifié auprès du fournisseur d’identité, le professionnel de la santé ou l’auxiliaire précise le contexte de son accès au DEP, par exemple son rôle d’utilisateur ou le niveau de confidentialité pour la consultation de documents. Il envoie ces informations au X-Assertion Provider en utilisant la transaction . En réponse, il reçoit une SAML 2.0 User Assertion confirmant les informations fournies.

Pour toutes les interfaces qui sont également protégées par un contrôle des droits d’accès (cela concerne surtout la gestion des documents), cette SAML 2.0 Assertion doit être envoyée au moyen de la transaction en plus d’un message spécialisé.

4. Gérer des documents dans le DEP

Les cas d’application pour la mise à disposition, la recherche, la consultation et la mise à jour de documents et de métadonnées de documents dans le DEP sont expliqués ci-dessous.

4.1 Mettre à disposition des documents

Le système primaire enregistre et stocke les documents dans sa propre communauté au moyen de la transaction . Il transmet ainsi un ou plusieurs documents avec les métadonnées correspondantes (auteur, domaine de spécialisation de l’auteur, classe du document, etc.). Le Document Repository reçoit la demande, enregistre l’identité du document et les métadonnées dans le Document Registry central et classe le document.

4.2 Rechercher et consulter des documents

La recherche de documents s’effectue généralement en deux temps.

Dans un premier temps, le système primaire interroge les métadonnées de tous les documents d’un patient, en utilisant des filtres si nécessaire. Il exécute à cet effet une et affiche une liste de résultats à l’utilisateur.

Dans un second temps, le système primaire utilise la transaction pour obtenir un ou plusieurs documents sélectionnés et affiche le contenu dans les interfaces utilisateur ou enregistre les documents localement.

5. Communication sécurisée et historisation

Pour la communication sécurisée, le système primaire utilise TLS. Il s’authentifie à l’aide de son certificat client (authentification mutuelle).

Pour chaque communication, le système primaire écrit un Audit Log et le transmet à la communauté au moyen d’un Record Audit Event. Un schéma XML particulier est défini comme format. Les détails des messages d'audit sont donnés dans les interfaces sur GitHub.

Lien externe : Vers GitHub