Interfaces DEP

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 Patient Demographics Query, par exemple pour enregistrer ensuite l’identité locale.

Recherche d’un patient à l’aide de données personnelles de base:

Lien externe : PDQ V3

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.

Enregistrer le numéro local d’identification d’un patient et ses données personnelles de base auprès de la communauté:

Lien externe : PIX V3 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 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.

Demander les numéros d’identification des patients pour l’accès au DEP (c’est-à-dire MPI-PID et EPR-SPID):

Lien externe : PIX V3 Query

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 (Authenticate User), le renouvellement d’une Identity Provider User Session expirée mais renouvelable (IdP Renew) et la déconnexion (SSO Logout).

Authentifier un utilisateur:

Lien externe : Authenticate User

Renouvellement d’une déclaration de fournisseur d’identité:

Lien externe : IdP Renew

Déconnexion d’un utilisateur authentifié:

Lien externe : 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.

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é.

Émettre des assertions d’autorisation SAML 2.0:

Lien externe : Get X-User Assertion

Utiliser l’assertion SAML 2.0 pour l’autorisation de la transaction:

Lien externe : Provide X-User Assertion

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.

Interroger et afficher les métadonnées des documents:

Lien externe : Registry Stored Query

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.

Récupération des documents:

Lien externe : Retrieve Document Set

Introduire des documents dans le DEP:

Lien externe : Provide and Register Document Set

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 : Record Audit Event