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.
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.
Le graphique peut être téléchargé au format PDF en cliquant sur ce lien.
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 issues de la base de données UPI de la Centrale de compensation 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 l’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 Patient Demographics Query, 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 Patient Identity Feed.
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 le numéro d’identification du patient EPR-SPID et MPI-PID à l’aide de l’identité locale du patient en exécutant la transaction PIXV3 Query.
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 de son fournisseur d’identité (Identity Provider) en utilisant une identité électronique 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 (Authenticate User), le renouvellement d’une Identity Provider User Session expirée mais renouvelable (IdP Renew) et la déconnexion (SSO Logout).
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 Get X-User Assertion. 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 Provide X-User Assertion 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 Provide and Register Document Set. 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 Registry Stored Query et affiche une liste de résultats à l’utilisateur.
Dans un second temps, le système primaire utilise la transaction Retrieve Document Set 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.
