Les profils d’intégration du domaine IT-Infrastructure

Overview Notification of Document Availability (NAV) Retrieve Form for Data Capture (RFD) Retrieve Information for Display (RID) Cross-Enterprise Document Media Interchange (XDM) Cross-Enterprise Document Reliable Interchange (XDR) Cross-Enterprise Clinical Documents Sharing (XDS) Cross-Enterprise Document Sharing of Scanned Documents (XDS-SD) Patient Administration Management (PAM) Patient Demographics Query (PDQ) Patient Identifier Cross-referencing for MPI (PIX) Patient Synchronized Application (PSA) Audit Trail and Node Authentication (ATNA) Consistent Time (CT) Digital Signature (DSG) Enterprise User Authentication (EUA) Cross Enterprise User Authentication (XUA) Personnel White Pages (PWP)

Résumé des profils IT-I XDS* (partage documents), NAV (notification), XDR/XDM (échange documents), Fédération XDS RID (accès documents), XDS-SD (documents scannés) RFD (formulaires) Dossier médical PIX (rapprochement identités), PDQ HL7v3 PAM (identités, séjours), PDQ (recherche patient) PSA (synchro patient) Identité patient PWP (annuaire PS), DSG (signature), XUA (assertions), gestion des risques ATNA (sécurité), CT (date/heure) EUA (single sign-on) Sécurité, Annuaires Système de santé Etablissement Poste de travail Niveau / Fonction

4 Types de profil pour IT-Infrastructure Gestion des identifiants PAM, PDQ, PIX, PSA Accès au dossier électronique NAV, RFD, RID, XDM, XDR, XDS, XDS-SD Sécurité ATNA, DSG, CT, EUA, XUA, PWP

Gestion des Identifiants Patient Identifier Cross-referencing for MPI (PIX) Patient Administration Management (PAM) Patient Demographics Query (PDQ) Patient Synchronized Application (PSA)

Patient Identifier Cross-Referencing for MPI (PIX)

Patient Identifier Cross-referencing for MPI Permettre le partage d’identifiant patient Chacun des participants gardant le contrôle des identifiants dans son domaine d’identification Permet l’interrogation En option permet la notification lors de la mise à jour des identifiants

Patient Identifier Cross-referencing for MPI Permet la centralisation des identifiants des patients Ne définit pas l’algorithme de rapprochement Compatible avec les standards et les transactions déjà utilisées par IHE Solution économique de synchronisation de données Il n’est pas nécessaire de changer les identifiants pour que les systèmes puissent communiquer

Patient Identifier Cross-referencing for MPI Transaction Diagram Patient Identity Source Patient Identity Consumer ↓Patient Identity Feed [ITI-8] ↑PIX Query [ITI-9] ↑PIX Update Notification [ITI-10] Patient Identity Cross- Reference Manager

ITI-8 Patient Identity Feed Document Repository Or Patient Identifier Cross Reference Manager Patient Identity Source Admit/Register or Update Patient: HL7 ADT^* * -A01, A04, A05, A08 Patient Identity Merge: HL7 ADT^A40

ITI-8 Patient Identity Feed L’acteur Patient Identity Source transmets les données démographique du patient ainsi que les identifiants du patient aux acteurs PIX Cross Reference Manager et XDS Document Registry Le XDS Document Registry utilise ses informations pour identifier les patients qui sont membres du domaine d’affinité Le PIX Cross Reference Manager utilise les informations pour rapprocher les identifiants multiples entre domaines

Cross-reference Consumer ITI-9 PIX Query Patient Identifier Cross-reference Consumer Patient Identifier Cross-reference Manager Get Corresponding Identifiers: HL7 QBP^Q23 Return Corresponding Identifiers: HL7 RSP^K23

ITI-9 PIX Query Le PIX Cross Reference Consumer interroge l’acteur PIX Cross Reference Manager pour un identifiant de patient Possibilité de préciser le(s) domaine(s) souhaité(s) dans la réponse Le PIX Cross Reference Manager répond avec les identifiants correspondants au même patient dans d’autres domaines

ITI-10 PIX Update Notification Patient Identifier Cross-reference Consumer Patient Identifier Cross-reference Manager Update Person Information: HL7 ADT^A31

PIX Update Notification Le PIX Cross Reference Manager informe le PIX Cross Reference Consumer des modifications de mise en correspondance d’identifiant pour un patient donné L’acteur PIX Cross Reference Manager doit implémenter cette transaction La transaction est optionnelle pour l’acteur PIX Cross Reference Consumer

Patient Identifier Cross-referencing for MPI Process Flow Showing ID Domains & Transactions

Patient Identifier Cross-referencing for MPI B:X456 C: ? B:X456 C: 2RT Identity Patient Cross References

PIX Implementation Considerations Le domaine d’identification des patients est renseigné dans le composant assigning authority du data type CX De domaine d’identification du Patient est spécifié dans le champ Assigning Authority du data type HL7 CX : PID|||290011^^^DAAD^PI||Smith^John||19800101|M|||Via del Lavoro, 17^^Bologna^BO^40127|||||||||0|||Bologna||||||||||20060425153546 290011 is the patient ID DAAD is the assigning authority PI from is the Type of identifier (table HL7 0203) Utilisation de PIX dans le contexte du profil XDS Le champ Assigning authority doit être spécifié comme Universal Id et Universal Id Type Universal Id doit être un OID (ce qui implique Universal Id Type == ISO) PID|||460023^^^HIMSS2005&1.3.6.1.4.1.21367.2005.1.1&ISO^PI~123456^^^A&1.2.3.4.5.1&ISO^NH^^^^^A||SMITH^JOHN^^^^^D||19700519|M|||34 rue des test^^ABANCOURT^^59265^100^H||0380234576^PRN^PH|||S|||||||DIJON

PIX: Considérations pour l’implémentation Il est possible de spécifier le domaine de retour : Utilisation du QPD-4 pour spécifier de manière explicite la liste des domaines pour lesquels un identifiant est souhaité. Si on ne spécifie aucun domaine dans le QPD-4… Le PIX Cross Reference Manager retournera les identifiants pour tous les domaines connus. Attention, il peut être retourné plusieurs identifiants pour un domaine donné. Le Client doit être capable de traiter tous les identifiants retournés par le serveur, ou il doit les ignorer tous. Ceci afin que le client soit en mesure de présenter les informations complètes au sujet du patient

PIX: Considérations pour l’implémentation De l’intérêt de l’utilisation du PIX Update Notification Utile lorsque le client veut constituer un cache local des identifiants mis en correspondances Exemple: l’acteur XDS Document Source dans un hôpital qui souhaiterait maintenir une liste d’identifiant des patient au sein de l’institution et leur correspondance dans le domaine d’affinité XDS Mécanisme du PIX Update Notification L’acteur PIX Consumer indique la liste des domaines pour lesquels il est intéressé de recevoir les notifications. L’acteur PIX Cross Reference Manager notifie l’acteur PIX Consumer des changement de mise en correspondance des identifiants de patient pour les domaines spécifiés Typiquement cela résulte en un message de type Patient Identity Feed

PIX: Considérations pour l’implémentation Obligation relatives à ATNA Patient Identity Feed est un événement de type Patient Record en tant que tel il doit être suivi d’une transaction d’audit :ATNA Record Audit Event transaction L’acteur Patient Id Source est responsable de générer le message d’audit. PIX Query est un événement de type Query event en tant que tel il doit être suivi d’une transaction Record Audit Event Les acteurs PIX Consumer et PIX Cross Reference Manager sont responsables de générer les messages Query audit PIX Update Notification est un événement de type Patient Record event en tant que tel il doit être suivi d’une transaction d’audit :ATNA Record Audit Event transaction PIX Cross Reference Manager est responsable de la génération du message d’audit Patient Record

PIX Considérations pour l’implémentation L’acteur PIX Cross Reference Manager doit maintenir une liste de PIX Consumers clients du service PIX Update Notifications Pour chaque client, il doit connaître la liste de domaine d’intérêt. IHE ne précise pas comment transmettre cette information entre le client et le serveur

Patient Demographics Query (PDQ)

Patient Demographics Query Objectif Fournir un accès à la demande aux données démographiques : Utile pour les systèmes/clients ne nécessitant pas une synchronisation continue des informations d’admission des patients Appareillages connectés au réseau de manière intermittente Appareillages à mémoire réduite : (voir LPOCT)

Patient Demographics Query : la Solution Permet d’interroger un serveur d’identité sur des critères de nom, d’identifiant, de contacts et/ou de visite. Permet de sélectionner le “bon” patient dans une liste, même si l’identification complète du patient n’est pas disponible Accès limité à un sous ensemble des données concernant l’identité et/ou le séjour

Patient Demographics Query : la Solution Permettre la recherche sur des données partielles ou complètes Ne pas se limiter à un seul domaine Retourner les résultats approchants (homonymes,…)

Patient Demographics Query Diagramme des Transactions Patient Demographics Supplier  Patient Demographics Query [ITI-21]  Patient Demographics and Visit Query [ITI-22] Patient Demographics Consumer

ITI-21 Patient Demographics Query Patient Demographics Consumer Patient Demographics Supplier Patient Demographics Query: QBP^Q22 Patient Demographics Response: RSP^K22

ITI-21 Patient Demographics Query Interrogation sur des données démographiques partielles La Réponse est une liste de patients correspondants, incluant Données démographiques Identifiants Exemple MSH|^~\&|XPLORE|EDL|ADT_DATAPROCESSING|ADT|200604280927||QBP^Q22|20060428092725|P|2.5||||||8859/1 QPD|QRY_PDQ_1001^Query By Name^IHEDEMO|QRY20060428092725|@PID.5.1^M*||||| RCP|I|4^RD| MSH|^~\&|ADT_DATAPROCESSING|ADT|XPLORE|EDL|20060428092718||RSP^K22|1680|P|2.5 MSA|AA|20060428092725||||0^Message accepted QAK|QRY20060428092725|OK|QRY_PDQ_1001^Query By Name^IHEDEMO|6|6 QPD|QRY_PDQ_1001^Query By Name^IHEDEMO|QRY20060428092725|@PID.5.1^M* PID|||PDQ113XX03^^^HIMS2005&1.3.6.1.4.1.21367.2005.1.1&ISO^PI||MOHR^ALICE||19580131|F|||820 JORIE BLVD.^^OAK BROOK^IL^60523|||||||||0|||||||||||||20060424122602 PID|||PDQ113XX05^^^HIMSS2005&1.3.6.1.4.1.21367.2005.1.1&ISO^PI||MOONEY^STAN||19780920|M|||100 TAYLOR^^ST LOUIS^MO^63110|||||||||0|||||||||||||20060424122610 PID|||PDQ113XX04^^^HIMSS2005&1.3.6.1.4.1.21367.2005.1.1&ISO^PI||MOODY^WARREN||19780820|M|||1000 CLAYTON RD^^CLAYTON^MO^63105|||||||||0|||||||||||||20060424122712 PID|||PDQ113XX01^^^HIMSS2005&1.3.6.1.4.1.21367.2005.1.1&ISO^PI||MOORE^CHIP||19380224|M|||10 PINETREE^^WEBSTER^MO^63119|||||||||0|||||||||||||20060424122242 DSC|1680-1

ITI-22 Patient Demographics and Visit Query Patient Demographics Consumer Patient Demographics Supplier Patient Demographics and Visit Query: QBP^ZV1 Patient Demographics and Visit Response: RSP^ZV2

ITI-22 Patient Demographics and Visit Query Cette transaction est optionnelle pour les acteurs Patient Demographics Consumer et Patient Demographics Supplier

Considérations sur l’Implémentation de PDQ Identification de la source d’ Information Patient Un acteur patient demographics supplier peut contenir des informations pour des patients provenant de sources multiples. La requête PDQ doit être évaluée dans le contexte d’une source d’information patient donnée L’acteur PDQ Consumer utilise les champs MSH-5/6 Receiving Application/Facility pour identifier le contexte de la requête.

Considérations sur l’Implémentation de PDQ Identification des domaines demandés pour les identifiants de patient QPD-8 utilisé pour identifier la liste des domaines pour les identifiants retournés Si aucune valeur n’est spécifiée dans QPD-8, alors on retourne tous les domaines associés à une source d’identification de patient Patient information source identifié en MSH-5/6 Utilisation de PDQ dans le contexte XDS : on spécifie le domaine d’affinité en QPD-8

Considérations sur l’Implémentation de PDQ Continuation protocol Utilisé pour retourner/recevoir les réponses par paquets de « n » L’acteur PDQ Consumer utilise le champ RCP-2 pour indiquer le nombre de réponses souhaitées Toutes les réponses sont retournées si RCP-2 est vide !!! L’acteur PDQ supplier renvoie continuation pointer dans le segment DSC (si il reste des réponses à retourner) L’acteur PDQ consumer retourne la valeur du DSC afin d’obtenir les réponses suivantes Cancel query doit être utiliser pour l’acteur PDQ Consumer pour indiquer qu’il a fini sa requête. Query Tag (QAK-1) défini par le client peut-être utilisé pour corréler tous les messages de demande et de réponse associé à un même interrogation.

Patient Demographics Query Consumer/Supplier interaction example: Patient Demographics Consumer Patient Demographics Supplier Patient Demographics Query: QBP^Q22 Patient Demographics Response: RSP^K22 DSC-1 valued Patient Demographics Query: echo DSC-1 value Cas 1: le serveur n’a plus de réponse Patient Demographics Response: RSP^K22 No DSC-1 value Cancel Query: QCN^J01 Cas 2: le client ne veut plus de réponse ACK

PDQ et ATNA Patient Demographics Query Query Audit Event Patient Demographics Consumer Patient Demographics Supplier Audit Record Repository Patient Demographics Query Query Audit Event Patient Demographics Response Query Audit Event

PDQ Implementation Considerations… Out-of-band issues PDQ Consumer and Supplier need to agree on Set of demographic items that can be queried Profile defines minimal set; but supplier can support additional demographic fields as search criteria Supplier may return any of the demographic attributes defined in the PID segment Support for wildcard queries and syntax used for wildcard queries E.g. Find all patients whose last name starts with “M” Use of Message Query Name (QPD-1) Some PDQ Suppliers may require specific query name List of patient information sources supported by the supplier Consumer needs to identify one of the supported patient information source when issuing PDQ Query

PDQ HL7v3 Fonctionnellement identique à PDQ et destiné à la recherche d’informations d’identité sur les patients : « traits » à partir d’un identifiant et vice-versa, identités à partir de critères (« Ab* »…) Les échanges se font en services web compatibles WS-I et en HL7 v3 codé en XML Surtout destiné aux interrogations hors établissements (serveurs régionaux)

Patient Administration Management (PAM)

Patient Administration Management Objectifs Coordonner l’échange entre services des informations démographiques, de leur mises à jours et des mouvements Informer des applications clientes dans les services Option pour la mise à jour des mouvements Utiliser les profiles de message

Patient Administration Management Value Proposition Différent niveau d’options : possibilité d’avoir des produits avec plus ou moins de richesse fonctionnelle Permettre la mise à niveau des transactions “démographiques (RAD-1 RAD-12)” de radiologie avec les transactions de IT-I Retour d’erreurs Gestion automatique des erreurs

Patient Administration Management Transaction Diagram Patient Demographics Source Patient Demographics Consumer Patient Identity Feed (ITI-030) Patient Encounter Source Patient Encounter Consumer Patient Encounter Management (ITI-031)

Patient Administration Management Groupement des acteurs Patient Demographics Consumer Patient Encounter Source Patient Encounter Management (ITI-031) Patient Demographics Source Patient Encounter Consumer Patient Identity Feed (ITI-030) Patient Demographics Source Patient Encounter Source Patient Encounter Management (ITI-031) Patient Demographics Consumer Patient Encounter Consumer Patient Identity Feed (ITI-030)

Patient Administration Management Standards Used HL7 Version 2.5 ADT Registration, Update, and Patient Movement Trigger Events Admission/registration Merge, update, link/unlink Movement management

Patient Administration Management Transactions Patient Encounter Management [ITI-31] Definition Patient Encounter Source registers or updates an encounter Forwards encounter information to other systems implementing Patient Encounter Consumer Location Providers Dates, times, etc. Options Inpatient/Outpatient Encounter Management Pending Event Management Advanced Encounter Management Temporary Patient Transfer Tracking Historic Movement Management

Patient Administration Management Encounter Management Options Inpatient/Outpatient Encounter Management HL7 Trigger Events Admit inpatient (A01/A11) Register outpatient (A04/A11) Discharge patient (A03/A13) Update patient information (A08) Pre-admit patient (A05/A38) Change outpatient to inpatient (A06) Change inpatient to outpatient (A07) Transfer patient (A02/A12)

Patient Administration Management Encounter Management Options Pending Event Management Additional HL7 Trigger Events Pending admit (A14/A27) Pending transfer (A15/A26) Pending discharge (A16/A25)

Patient Administration Management Encounter Management Options Advanced Encounter Management Additional HL7 Trigger Events Change attending doctor (A54/A55) Leave of absence (A21/A52) Return from leave of absence (A22/A53) Move account information (A44) Merge patient ID list (A40)

Patient Administration Management Encounter Management Options Temporary Patient Transfers Tracking Additional HL7 Trigger Events Patient departing – tracking (A09/A33) Patient arriving – tracking (A10/A32)

Patient Administration Management Encounter Management Options Historic Movement Management Uses trigger events of any of the above options that have been adopted Adds ZBE segment to contain a unique identifier for the movement Standard segment pending adoption by HL7 Adds Z99 trigger event to allow update of any movement information, based on unique ID in ZBE segment Standard trigger event pending adoption by HL7

Cross-Enterprise Document Sharing

Cross-Enterprise Document Sharing (XDS) Objectifs Base du partage de document dans le cadre d’un EHR. Compatible avec l’enregistrement des documents dans les produits existants. Permettre l’indexation des documents d’un patient Permettre l’interrogation et la récupération des documents d’un patient. Architecture évolutive

Cross-Enterprise Document Sharing (XDS) Objectifs Base de l’infrastructure IT de santé : Partage de document électronique dans un réseau, une région… Moyen efficace d’accéder et de contribuer au partage de documents cliniques entre plusieurs acteurs et établissements de santé. (Le patient définissant les droits d’accès) Indépendant du système d’information de l’utilisateur Accès Simple : le professionnel de santé a la possibilité d’interroger le registre et de récupérer des documents pertinents

Cross-Enterprise Document Sharing (XDS) Objectifs Distribué: Chaque « organisation » publie ses informations cliniques Cross-Enterprise : le Registre fournit un index des documents publiés aux membres autorisés du domaine d’affinité Centré Document : Les données cliniques publiées sont organisées en « documents cliniques ». On se met d’accord sur les formats de document à utiliser Neutre : Le contenu du Document n’est lu que par la source et le client. Attributs de registre standard : Les requêtes sont basées attributs permettant la recherche de documents spécifiques

Parcours de soin d’un patient Longitudinal Record Suite de soin Soins intensifs Unité de soins spécialisés (incl. Diagnostics Services) Médecin traitant Clinique (Ambulatoire) Parcours de soin d’un patient

L’approche Manuelle Le challenge: Trouver et accéder facilement Laboratory Results Specialist Record Hospital Record Clinical Encounter Le challenge: Trouver et accéder facilement aux documents générés par la communauté de soin Clinical IT System

Cross-Enterprise Document Sharing (XDS) Différents points de vue : EHR-CR : Care-delivery Record Patient information Géré par le prestataire du soin EHR-LR : Longitudinal Record Documents partagés par les EHR-CR(s) Suivis par le Registre Domaine d’affinité Clinique: Groupe d’entreprises de santé (EHR-CR) Un ensemble de règles communes Partage un registre

4-Patient data presented to Physician L’approche XDS Laboratory Results Specialist Record Hospital Record 3-Records Returned 4-Patient data presented to Physician 2-Reference to Records for Inquiry Index of patients records (Document-level) 1-Patient Authorized Inquiry Clinical Encounter Clinical IT System Temporary Aggregate Patient History

Publication et Accès aux Documents Documents Registry Document Repository Long Term Care Acute Care (Inpatient) Other Specialized Care or Diagnostics Services Submission of Document References PCPs and Clinics (Ambulatory) Retrieve of selected Documents

IHE XDS: Concepts clés XDS Document XDS Submission Set XDS Folder Un ensemble d’informations cliniques constituant un élément du dossier patient à partager. Cet ensemble peut déjà exister dans le système d’information. XDS Submission Set Un ensemble de documents liés à un patient qu’un (ou plusieurs) clinicien a décidé de partager. XDS Folder Le moyen de grouper des documents Documents liés à une pathologie, Épisodes de soin, Informations critiques sur le patient (urgences, allergies…)

Patient Identity Source PIX Cross Referencing Patient Identity Source Patient Identity Feed Dm=XAD, Pid=Px Patient Identity X-Ref Mgr Dm=XAD Pid=Px Patient Identification Domain C Patient Identification Domain XAD Dm=XAD Pid=Px Patient Identification Domain D2 XDS Document Registry Document Entry Dm=XAD Pid=Px XDS Document Consumer XDS Document Source XDS Doc Query Docs Patient ID Consumer Patient ID Consumer XDS Doc Provide&Register Doc Set Dm=D2 Pid=Pd Dm=C Pid=Pc XDS Document Repository

Exemple de « Submission Request » Document Registry Submission Request Folder A Submission Set 1 Document Entry Document Document Repositories

XDS Document C’est la plus petite entité d’information déposée dans un Document Repository et indexée dans un Document Registry Contient des observations Doit pouvoir être lu par un humain ou une application Doit être associé à des meta-données: définies par le Document Source, gérées par le Document Registry et utilisées par le Document Consumer pour l’interrogation Transmises au Document Repository dans un flux d’octet associé à un MIME type. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR- CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

XDS : méta données documents Patient : identifiant « partagé », identité (identifiant et nom…) « vue de la source » Origine : (auteur, institution, vérificateur) Identification : (ID index, URL entrepôt, identifiant unique, dates création et début et fin acte médical, titre, taille, hash, status, document auquel il est associé) Classification : (classe, type, format, type MIME, type et spécialité institution et auteur, codes médicaux, niveau de confidentialité) Requis, Si connu, Généré par le serveur, Recommandé

XDS Submission Set Créé par un seul document source. Émis en une seule transaction : Provide & Register Document Set ou Register Document Set transaction. Lié à un ou plusieurs épisodes de soin d’un seul patient, identifié de façon unique. Enregistre de nouveaux documents. Peut faire références à d’autres documents. Associé a un code de contenu (e.g. sens clinique) par le Document Source. Accessible via la transaction Query Registry. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR- CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

XDS Folder Un moyen de grouper un ou plusieurs documents (peu importe la raison) Groupe des documents liés à un seul patient. Peut inclure des documents de différents Document Source Peut contenir de nouveau documents ou des documents déjà référencés Sera contenu de manière permanente par le Document Registry Sera accessible via la transaction Query Registry. Associé à un code par le Document Source. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR- CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

Cross-Enterprise Document Sharing (XDS) Transaction Diagram Patient Identity Source Document Registry Repository Consumer Retrieve Document Provide & Register Document Set Register Query Documents Feed

Cross-Enterprise Document Sharing (XDS) Actors Document Source Source of documents and metadata about documents Document Repository Stores documents, requests indexing in Document Registry, supports retrieval Document Registry Indexes documents, supports search Patient Identity Source Feeds identity of known patients to Document Registry Document Consumer Initiates search and retrieval for consumer of documents

Modèle d’Intégration 1: EHR-CR avec Repository à la Source

Modèle d’Intégration 2: EHR-LR avec un Repository tiers

Modèle d’Intégration 3: EHR-CR alimente un « hub » EHR-CR/EHR-LR

L’accès par le patient doit être possible L’accès du patient à ses propres données: Query and Retrieve un ensemble de documents en utilisant par exemple un portail qui offre la possibilité d’afficher le contenu des documents. C’est un cas particulier du cas d’utilisation EHR-CR, dans lequel le patient est intéressé à son dossier. Le patient peut également alimenter le dossier avec des documents

Cross-Enterprise Document Sharing (XDS) Standards Utilisés Electronic Business Standards ebXML, SOAP … Internet Standards HTML, HTTP, ISO, PDF, JPEG … Healthcare Content Standards HL7 CDA, CEN EHRcom HL7, ASTM CCR DICOM …

Healthcare Content Standards HL7 Version 2.3.1 Messages for Patient Identity Management HL7 Version 2.5 Datatypes for XDS Registry Attribute values HL7 CDA Release 1 XDS Document concept definition XDS Document Content Source of XDS Document Entry Attributes DICOM, ASTM CCR, HL7 CDA Release 2, CEN EHRcom Sources of XDS Document Entry Attributes

Internet Standards HTTP SMTP IETF MIME PDF, JPEG, HTML UTF-8 Protocol for Retrieve Document Online SOAP bindings SMTP Offline ebMS bindings IETF Language Identifiers MIME Document Type codes PDF, JPEG, HTML XDS Document Content UTF-8 Encoding of Registry Attributes

Electronic Business Standards OASIS/ebXML Registry Information Model v2.0 (basis of XDS Registry Information Model) Registry Services Specifications v2.0 (Registry Services) Messaging Services Specifications v2.0 (Offline protocols) ISO/IEC 9075 Database Language SQL (Registry Query) SOAP with Attachments (communication with XDS Registries and Repositories) SHA-1 [FIPS 180-1] (Document Hashes)

Cross-Enterprise Document Sharing (XDS) Les Options Proposées Pour l’acteur Document Source: Basic operations Submit single document Replace existing document Options : Off-line mode Multi-document submission Document life-cycle management Submit addendum or transformation of document Folder management Create folder, add to folder

Cross-Enterprise Document Sharing (XDS) Profils liès Patient Identity Patient Identity Feed Notification from ADT system to Document Registry of patient admission/registration La soumission de document nécessite un ID de patient valide. Patient Demographics Query (PDQ) Identify patient based on query of demographic information Needed by Document Source: assign correct patient ID Needed by Document Consumer: query against correct patient ID

Document Availability Management Submitted Registration in progress Approved Available for Patient Care Availability Status Visible to a Document Source Availability Status Visible to a Document Consumer Deprecated Obsolete Deleted Availability Status Change under the control of the original document source and patient (if allowed in Affinity Domain)

Document Life Cycle Management Addendum to a registered document Time Document Addendum A two-way relationship between Original and Addendum Addendum Replacing a registered document by a new document Time Document 1 (Approved) A two-way relationship between Original and Replacement Document. Replacement Document 1 (Deprecated) Replacement Document Registering an alternate form of a registered document Transform A two-way relationship between Original and Transform (alternative format, same scope). Document 1 (Approved) Document 2 (transform)

XDS Submission Request Created by a single Document Source through a single Provide & Register Document Set transaction. Includes a Submission Set and zero or more: new documents references to existing documents folders associations of documents with folders. Registered Atomically in a single transaction. Upon successful submission all of the new objects it creates are available for sharing, otherwise none are. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR- CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

XDS Affinity Domain Implements a single Document Registry Identifies: Document Sources Document Consumers Document Repositories Assigns Patient Identity Domain Selects Vocabularies Establishes Document Sharing Polices Establishes Security and Privacy Policies Is the Source of ATNA node certificates The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR- CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

Patient Identification Management One Patient Identity Domain Managed by Patient Identity Source. Accessed by Document Registry. Multiple methods to map into the Domain Using PIX Using PDQ Other Mechanisms

XDS Query Model

Recherche de Documents Patient Id Les 4 axes pour la recherche de Document : Quel patient ? Quel Type de Document ? 3 sous dimensions reliées : Facility Type Document Class Event Type Quel Groupe de Documents Quel date et heure Folder Facility Type Document Class Practice Setting Submission Set Time of Services XDS core Meta-Data derived from HL7 CDA and CEN EHRcom

Security for XDS There is a formal security & privacy profile for XDS Leverages IHE Audit Trail & Node Authentication ATNA creates a secured domain: User Accountability (Audit trail) Node-to-Node Access Control Node-level user authentication User access control provided by node BUT Registry/repository based User-Level Access Control and policy agreements is beyond XDS. User-level Access Control may be provided through the EUA Integration Profile but more effectively through a future PKI based profile. Patient Identity Source Secured Node Patient Identity Feed Secured Node Query Documents Document Registry Document Consumer Secured Node Register Document Set Provide&Register Document Set Retrieve Document Secured Node Document Source Document Repository Secured Node Secured Node

Security for XDS ATNA creates a secured domain: User Accountability (Audit trail) Node-to-Node Access Control Node-level user authentication User access control provided by node BUT Registry/repository based User-Level Access Control and policy agreements is beyond XDS. User-level Access Control may be provided through the EUA Integration Profile but more effectively through a future PKI based profile. Secured Node Patient Identity Source Document Registry Repository Consumer Retrieve Document Provide & Register Document Set Register Query Documents Feed

IHE Roadmap - Building upon XDS Document Content Integration Profiles Workflows Messaging Integration Profiles (e.g. ePrescription) Access Control XDS Cross-Enterprise Document Sharing. XDS est la première pierre de l’EHR inter-établissement: Les profils d’intégration décrivant le contenu des documents sont définis à part et sont spécifiques aux domaines d’application: Ces profils décrivent les format de document, le vocabulaire, des templates, etc.). Des profils d’intégration de type Workflow (ePrescribing, eReferral, eBooking, etc.) compléteront le profil XDS.

Stored Query

XDS Registry Stored Query Patient Identity Source Patient Identity Feed Registry Stored Query Document Query Documents Document Registry Consumer Register Document Set Retrieve Provide&Register Document Document Se t Document Document Source Repository

XDS Registry Stored Query N’est plus dépendant du modèle de base de données du registre : les phrases SQL sont remplacées par des appels fonctions Les échanges sont réalisés en web service compatible WS-I Les demandes sont en ebRS v3.0, les réponses restant en ebRS v2.1 La transaction est obligatoire des deux côtés et remplace donc à terme le Query

XDS: Conclusion XDS n’a pas la prétention de répondre à toutes les exigences d’un EHR complet ! Des profils de contenu (XDS-I, DSG, XDS-MS…) et de contrôle d’accès (XUA) sont dans le pipe-line Avec XDS et en collaboration avec d’autres activités de standardisation, IHE contribue au déploiement d’infrastructures de santé régionale et/ou nationale. XDS automatise un process manuel existant, il permet la création d’EHR-LR, facilite l’accès aux données cliniques et par la même contribue à améliorer la qualité de soin globale des patients.

Notification of Document Availability (NAV)

Notification of Document Availability Utilise l’email pour notifier “l’utilisateur” de la disponibilité de document dans un domaine d’affinité XDS.

Notification of Document Availability Scope Register Documents XDS Document Repository XDS Document Registry Query Consumer Provide and Register Documents Source Retrieve Documents Notification of Document Availability It doesn’t get much simpler than this…

Notification of Document Availability : Objectifs Rendre possible l’automatisation de certains cas d’utilisation dans un environnement de partage de documents : Demandes d’avis Recherche d’enregistrements Accès du patients à ses enregistrements Se base sur une infrastructure existante et largement déployée : l’email

Notification of Document Availability Objectifs Fournit un trigger pour démarrer un processus automatique Possibilité simple de faire suivre la notification par “email forwarding” Utiliser l’infrastructure existante Ne transmettre aucune information médicale!

Notification of Document Availability Diagramme de Transaction Send Notification [ITI-25] SMTP Aether Receive Notification [ITI-26] Notification Sender Notification Receiver Send Acknowledgement [ITI-27] Receive Acknowledgement [ITI-28]

Notification of Document Availability Actors Notification Sender Envoie les notification de disponibilité de documents dans un XDS registry, il reçoit les acquittements de ces notifications. Notification Receiver Reçoit les notifications de disponibilité de documents dans un XDS registry, et peut optionnellement envoyer un acquittement.

Notification of Document Availability Transactions Send Notification (ITI-25) Sending a document availability notice. Receive Notification (ITI-26) Retrieve a document availability notice. Send Acknowledgement (ITI-27) Send an acknowledgement of a document availability notice. Receive Acknowledgement (ITI-28) Retrieve an acknowledgement of a document availability notice.

Profile Name Standards Used RFC-822 Standard for the format of ARPA Internet text messages RFC-1521 Multipurpose Internet Mail Extensions RFC-1738 Uniform Resource Locators (URL) RFC-1939 Post Office Protocol - Version 3 RFC-2368 The mailto URL scheme RFC-2633 S/MIME Version 3 Message Specification RFC-2821 Simple Mail Transfer Protocol RFC-3001 A URN Namespace of Object Identifiers RFC 3501 Internet Message Access Prototcol – Version 4

Notification of Document Availability Basic Use Case Provider A publishes records E-mail sent to Provider B Provider B can access Records Provider A Provider B 1. Update & Publish Records 2. * Send Notification 3. Access Records

Notification of Document Availability Intermediated Use Case Provider A publishes records E-mail sent to Intermediary Notification Forwarded to Provider B Provider B can access Records Provider A Intermediary Provider B Publish Records 2. * Send Notification 3. * Forward Notification 4. Access Records

Notification of Document Availability Notification Attachment <XDSNotification xmlns='http://www.ihe.net/2005/NAV' id='urn:uuid:92d03292-84a0-4b86-8139-dd244173ddbb' registry='http://www.ihe.net:8080/XDS' acknowledgement='emailaddress@ihe.net' > <XDSDocumentEntry id='urn:uuid:92d03292-84a0-4b86-8139-dd244173ddbc' /> <XDSDocumentEntry id='urn:uuid:92d03292-84a0-4b86-8139-dd244173ddbd' /> </XDSNotification>

Audit Trail and Node Authentication & Consistent Time

IHE and PHI Protection User Identity → PWP, EUA User Authentication → EUA, XUA Node Authentication → ATNA Security Audit Trails → ATNA Data Integrity Controls → CT, ATNA TLS option Data Confidentiality → ATNA TLS option Access Controls → Future item in IHE roadmap

Audit Trail and Node Authentication (ATNA) Abstract / Scope Définit les fonctionnalités de base qu’un système doit implémenter pour intégrer l’environnement de sécurité d’un établissement Étend et généralise aux autres domaines le profil de radiologie Basic Security Permet l’identification des systèmes (noeuds) Peux être utilisé en parallèle avec les profils d’identification d’utilisateur (EUA et XUA)

ATNA Objectifs Protéger les données du patient et sécuriser le système Répondre aux exigences réglementaires Simplifier la gestion au niveau de l’entreprise Système d’audit unifié et uniforme Approche commune simplifiant l’administration Réduction de coûts de développement et de support Possibilité de réutiliser le code d’audit pour de multiples acteurs Un seul effort de développement pour satisfaire différentes règles et contraintes réglementaires

ATNA Security Requirements Raisons : Utilisation clinique et protection des données Seules les personnes autorisées doivent pouvoir accéder aux données des patients Les personnes non autorisées ne doivent ni pouvoir interférer avec le processus ni pouvoir modifier des données Garantir: Confidentialité Intégrité Disponibilité Authentification

ATNA Mesures de sécurité Authentification: Identification de l’utilisateur et/ou du système. Répond à la question : “Qui est tu ?” ATNA définit comment authentifier les connexions réseau ATNA est compatible avec les profiles d’authentification des utilisateurs Enterprise User Authentication (EUA) Cross Enterprise User Authentication (XUA).. Autorisation et controle d’acces: Définit les droits d’un utilisateur pour réaliser une action donnée: “Maintenant que je sais qui tu es, qu’est ce que tu as le droit de faire ?” ATNA définit comment négocier (autoriser) une connexion réseau. ATNA impose que les systèmes aient des mécanismes de sécurité pour les accès réseaux et locaux

ATNA Security Measures Accountability and Audit trail: Enregistrer l’historique des actions d’un système ou d’un utilisateur sur une période de temps donnée “Qu’as-tu fait ?” ATNA Définit: Le format du message d’audit et le protocole de transport

Grâce à ATNA la gestion de la sécurité entre noeuds est simplifiée. ATNA IHE Goal Grâce à ATNA la gestion de la sécurité entre noeuds est simplifiée. Ne nécessite guère plus que l’installation d’un certificat Sépare les fonctions Authentification Autorisation Traçabilité Audit a posteriori qui permet de sanctionner les abus

ATNA Integrating Trusted Nodes Secured System Secured System Local access control (authentication of user) Strong authentication of remote node (digital certificates) network traffic encryption is not required, it is optional Audit trail with: Real-time access Time synchronization Secure network Central Audit Trail Repository System A System B

A quels réseaux peut on appliquer ATNA ? Réseaux physiquement sécurisés Sécurité physique explicite du réseau, qui prévient l’accès par d’autres nœuds Technologie VPN et VLAN fournissant une isolation du réseau quasi équivalente. Réseaux protégés Réseau physique sécurisé qui interdit la modification ou l’installation d’équipement non autorisés Un réseau partagé avec des nœuds autorisés au sein de l’établissement. Ces nœuds ne doivent pas permettre l’accès non autorisé aux informations des patients Réseaux ouverts Généralement non supportés. Des nœuds avec un niveau de sécurité suffisant et l’utilisation de l’encryptage permettent néanmoins d’atteindre un niveau de sécurité suffisant

ATNA Securité des noeuds ATNA spécifie certaines des fonctionnalités nécessaires (e.g. le contrôle d’accès) ATNA ne spécifie pas les règles ATNA ne spécifie pas la méthodologie (même si d’autres profils peuvent faire l’affaire EUA) Ceci permet aux vendeurs et aux établissements de choisir les technologies et les règles qui sont appropriées

ATNA Node Authentication X.509 certificates for node identity and keys TCP/IP Transport Layer Security Protocol (TLS) for node authentication, and optional encryption Secure handshake protocol of both parties during Association establishment: Identify encryption protocol Exchange session keys Actor must be able to configure certificate list of authorized nodes. ATNA presently specifies mechanisms for HTTP, DICOM, and HL7

Pourquoi authentifier le nœud ? De nombreux systèmes sont en accès partagés e.g. CT. Dans ce cas l’identité de la machine est plus importantes que l’identité de l’opérateur (en terme de sécurité). . Certains systèmes opère de manière autonome, e.g. PACS archive. Connaître le nom de l’administrateur du PACS d’astreinte est peu utile. En général l’accès des machines est contrôlé par l’administrateur du site. IP assigned to MAC address.

ATNA Audit Trail Conçu pour la surveillance Deux format de message d’audit IHE Radiology interim format, (pour compatibilité avec la radiologie) IETF/DICOM/HL7/ASTM format, DICOM Supplement 95 IETF Draft for Common Audit Message ASTM E.214 HL7 Audit Informative documents Les 2 formats sont de type XML, permettant les extensions

ATNA Auditable Events Actor-start-stop Audit-log-used The storage of persistent objects is completed. Instances-stored The deletion of persistent objects. Instances-deleted The query for instances of persistent objects. Images-availability- query Other health service related auditable event. Health-service-event The storage of any persistent object, e.g. DICOM instances, is begun Begin-storing-instances Reading or modification of any stored audit log Audit-log-used The starting or stopping of any application or actor. Actor-start-stop

ATNA Auditable Events Medication Mobile-machine-event Patient-record-event Patient-care-episode Patient-care-assignment Order-record-event Node-authentication-failure Mobile-machine-event Medication Patient care records are created, modified, deleted. Auditable patient care episode event that is not specified elsewhere. Patient care assignments are created, modified, deleted. An order is created, modified, completed. An unauthorized or improperly authenticated node attempts communication Mobile equipment is relocated, leaves the network, rejoins the network Medication is prescribed, delivered, etc.

ATNA Auditable Events PHI-export PHI-import Procedure-record-event A study is viewed, read, or similarly used. Study-used A study is created, modified, or deleted. Study-object-event Security alerts, configuration changes, etc. Security-administration Any auditable query not otherwise specified. Query-information The patient record is created, modified, or deleted. Procedure-record-event Patient information is imported into the enterprise, either on media or electronically PHI-import Patient information is exported outside the enterprise, either on media or electronically PHI-export

ATNA Record Audit Event Reliable Syslog (RFC 3195) est le protocole de transport préféré des messages d’audit, Cependant le BSD Syslog protocol (RFC 3164) est permis pour compatibilité avec le profil Radiology Basic Security. Les événements et le contenu des messages d’Audit trail sont basés sur IETF, DICOM, HL7, and ASTM standards. Les évenements et le format du profile Radiology Basic Security sont autorisés pour compatibilité.

Comment devenir un secure node ? Le système dans son intégralité doit être sécurisé Sécuriser un sous ensemble est insuffisant Le système doit avoir une politique de contrôle des accès utilisateurs : Identification, authentification et autorisation Toute les “entrées/sorties” pouvant contenir des informations protégées doivent être sécurisées. C.a.d tous les protocoles, ce n’est pas réservé aux seuls transactions IHE Toute activité doit générer des traces…et ce n’est pas réservé aux seuls acteurs IHE

Secure Application Acteur introduit en 2006 par CP Réduit les contraintes sur des sécures nodes. Permet la transition d’une application non sécurisée, vers une application sécurisée Contraintes uniquement lié à l’application

Consistent Time (CT) Network Time Protocol ( NTP) version 3 (RFC 1305) for time synchronization Actor must support manual configuration Required accuracy: 1 second Optionally Secure NTP may be used Required for use of ATNA, EUA, XUA

Document Digital Signature (DSG)

Document Digital Signature Value Proposition Complète le profile XDS Document infrastructure Sur les aspect de Responsabilité Intégrité des documents Auteur, Approbation et/ou revue du document, authentification de l’auteur Infrastructure indispensable dans un contexte de e-Prescribing, ou de e-Referral Lori’s slide

Document Digital Signature Abstract/scope Fournit un mécanisme de signature Fournit un mécanisme de vérification/validation Fournit des attributs de signature XDS gère le document et la signature Permet l’accès direct au document (XDS)

Document Digital Signature Abstract/scope Digital Signature Document format Leverages XDS for signature by reference New document type in XDS – Linkage forward and back. Profiles single / multiple signatures Profiles nested signatures Provide signature integrity across intermediary processing

Document Digital Signature Hors du scope Gestion des Certificats et concept de PKI Standards et l’implémentations sont disponibles et seront discutés plus tard On s’occupe de la signature, et pas de l’encryptage Signature Partielle de Document

Document Digital Signatures Objectifs Document Digital Signatures aide à réduire les risques suivants : Modification d’une prescription (signée ou non) pendant sa transmission ou son archivage Introduction d’une prescription fictive

Document Digital Signatures Les scenarii suivants ne sont pas pris en compte : Usurpation d’identité Vol d’une clé privée Corruption du poste de travail d’un médecin pour l’accès à sa clé Corruption du processus de confirmation …

Document Digital Signature Key Technical Properties W3C XML Signature structure credentials, timestamp, and other signature attributes such as signature purpose Reference to document stored in XDS ISO TS17090 compliant digital certificates Assures message integrity Verification of signed document validity Provides for multiple signers

Document Digital Signature Signature Attributes Expand signature to include additional data relevant to the healthcare signature Includes the date and time the signature was calculated and applied The identity of the signer Signature Purpose

Document Digital Signature Signature Attributes The role of a signer (purpose of the signature) includes actors that may carry the responsibilities of: Signer: the actor that creates the electronic signature. When the signer digitally signs over data object(s) using the prescribed format, this represents a commitment on behalf of the signing entity to the data object(s) being signed. Verifier: the entity that verifies the electronic signature. It may be a single entity or multiple entities Trusted Service Providers: one or more entities that help to build trust relationships between the signer and verifier. Trusted Service Providers include PKI Certification Authorities, Registration Authorities, Repository Authorities (e.g. a directory), Time-Stamping Authorities, Signature Policy Issuers and Attribute Authorities. Arbitrator: An entity that arbitrates in disputes between a signer and a verifier.

Document Digital Signature Transaction Diagram

Document Digital Signature Transaction Diagram

Document Digital Signature Cas d’utilisation Atteste que le document est une copie conforme Each subsequent use of the original signed digital document or a digital copy of the document can inspected signatures to assert that the documents are true copies of information attestable to the signer at the time of the signature ceremony Atteste le contenu When a clinician submits a clinical document to the XDS repository, the clinician using a digital certificate digitally signs the document Atteste le “submission set “ Atteste la Traduction / Transformation

Cross-Enterprise Document Sharing (XDS) Use Case (1) The XDS profile describes how different health care parties can share documents A “document source” is responsible to “provide and register” document in a “registry/repository” for a “query” and “retrieve” by a “document consumer” Document Digital Signature enables to manage the “responsibility” issues

Cross-Enterprise Document Sharing (XDS) Use Case (2) The “document source” wants to prove it has well “authored” the document and the associated “submission set metadata” The “registry/repository” it has not corrupted the documents and metadata The “document consumer” wants to check above items and check the “identity” of author(s) and authenticator(s)

Cross-Enterprise Document Sharing (XDS) Use Case (3) The “document source” includes the document(s) signature(s) into the “submission set” The “registry/repository” stores the document signature(s) as a “document” and metadata associated with it/them as a specific “signature object” metadata The “document consumer” can see the “signature metadata” and retrieve each signature for checking it, including the certificate(s)

Document Digital Signature Signature Purpose From ASTM E1762 * “Author” - Author’s signature, “Author.Co” - Coauthor’s signature “Participant” - Co-participant’s signature “Transcriptionist/Recorder” “Verification” - Verification signature “Validation” - Validation signature “Consent” - Consent signature “Witness” - Witness signature “Witness.Event” - Event witness signature “Witness.Identity” - Identity witness signature such as a Notary “Witness.Consent” - Consent witness signature “Interpreter” “Review” - Review signature “Source” - Source signature “Addendum” - Addendum signature Administrative Timestamp Transcr

Document Digital Signature Additions to ASTM1762 The following items will be added to ASTM1762 Modification Authorization Transformation Recipient Modification is being worked on.

Document Digital Signature Standards Used W3C XML Signature ISO 17090, 21091 ASTM E2212, E1985, E1762, E1084 IETF x509 DICOM supplement 41, 86 NCPDP HL7 CDA

Cross Entreprise Media Interchange (XDM) Cross Entreprise Reliable Interchange (XDR)

L’échange de documents Le succès d’XDS a contribué à mobiliser les acteurs utilisateurs et fournisseurs autour de la notion de partage de documents médicaux gérés par les dossiers patients Mais aussi fait prendre conscience de l’intérêt de solutions d’échange de documents, plus faciles à mettre en place à court terme (organisation, sécurité…)

Fonctionnement XDR/XDM Généraliste Communication spécialiste - MG Spécialiste, Radio ou Labo Echanges ville hôpital Demande d’avis Transfert de patient Hôpital / urgence Dossier personnel (PHR) vers urgence ou dossier de professionnel (EMR) Etablissement Soins intensifs vers soins de suite (ECF)

Cross-Enterprise Document Reliable/Media interchange XDR/XDM Communication point à point de documents complémentaire au partage (XDS) 2 types de transports : XDR email & XDM media Comme XDS, indépendant du contenu Réutilisation maximale des objets et méta-données d’XDS Compatible avec les échanges d’images (IHE PDI, DICOM e-mail…) Adapté à tous les profils “contenu” d’XDS

XDR/XDM Echange de documents « centré patient » Transmission de résultats, lettres de sortie ou courriers médicaux (pas le "workflow" lui-même mais les informations médicales associées) Eléments de dossier médical personnel (résumé…), synthèse des éléments médicaux (traitements en cours, allergies, etc), données physiologiques…

Points techniques clefs d’XDR/XDM Réutilisent l’approche XDS pour les documents SubmissionSet, DocumentEntry Méta-données ebXML Registry Service XDR : Echanges directs sécurisés Messagerie sécurisée (ebMS sur SMTP, S/MIME) En option envoi direct HTTP/SOAP (comme XDS) XDM : Profil « media » comme images DICOM Media CD-R (comme IHE PDI) ou clefs USB En option ZIP e-mail (comme DICOM e-mail – sup.113) Possibilité de combinaison avec XDS ou PDI au sein du même système (Document Source…) Evolution possible pour d’autres protocoles – au delà du SOAP actuel - (MTOM…)

Diagramme XDR Document Source Document Recipient Provide and Register Document Set [ITI-15] -> Document Recipient

Portable Media Creator Portable Media Importer Diagramme XDM Portable Media Creator Distribute Document Set on Media [ITI-32] -> Portable Media Importer

XDR combiné avec XDS XDR XDR Document Registry Document Repository Document Consumer Document Recipient Document Source XDR Document Source Document Recipient XDR XDS

Message de base XDR Part 1 (start) Part 2 Part 3 Part n+2 Protocol encapsulation in SMTP/ESMTP SOAP with MIME attachments (multipart/related) text/xml SOAP:Envelope SOAP:Header, with Service=LifeCycleManager and Action=submitObjects SOAP:Body, with Manifest=list of attachments (e.g. ebXML Reg. Msg + Documents) Part 1 (start) text/xml SubmitObjectRequest (ebXML Registry Message) Part 2 Document 1 Part 3 Document n . . . Part n+2

Structure d’un media XDM

XDM combiné avec PDI contenu XDM : En complément, contenu PDI :

Patient Synchronized Application (PSA)

Patient Synchronized Applications Patient Synchronization of Multiple Disparate Applications Single Patient Selection When combined with PIX Profile, allows patient synchronization across patient identifier domains When combined with EUA Profile, provides user Single Sign-on (SSO)

Patient Synchronized Applications User Convenience: Eliminates the repetitive task of selecting the patient in each application Permits the user to select the patient in the application for which they are most familiar and / or appropriate to the clinical workflow Patient Safety: Ensures all data being viewed across applications is for the same patient Leverage Single Development Effort: Allows vendors to leverage single CCOW enablement effort to support multiple actors: Patient Context Participant (PSA) User Context Participant (EUA)

Patient Synchronized Applications Actors Context Manager Actor The IHE Context Manager Actor may encompass more than a CCOW context manager function. It may include a number of other components such as the context management registry and patient mapping agent. Patient Context Participant Actor The Patient Context Participant Actor shall respond to all patient context changes. This actor shall set the patient context provided the application has patient selection capability.

Patient Synchronized Applications: Transactions Diagram Patient Context Participant Join Context Context Manager Change Context Follow Context Leave Context These transactions are required for both Actors for compliance

Patient Synchronized Applications : Key Technical Properties Standards Used: HL7 Context Management “CCOW” Standard, Version 1.4 Support for both Windows and Web Technology Support of “Patient Subject” IHE Constraints: Specifies use of Patient.Id.IdList item Ensures maximum interoperability with PIX Profile Protects against future deprecation of patient identifier items (HL7 2.3.1, 2.4, 2.5, CCOW).

Enterprise User Authentication (EUA)

Enterprise User Authentication Scope Au sein d’un même établissement ayant une politique de sécurité en place et un domaine réseau propre. N’utiliser qu’un seul login par utilisateur pour toutes les applications et appareillage Centraliser la gestion de l’authentification des utilisateurs. Fournir une solution SSO (single sign-on).

Enterprise User Authentication Value Proposition Satisfaire à une contrainte de sécurité élémentaire : L’authentification de l’utilisateur est nécessaire pour la plupart des applications et des opérations d’accès aux données Réduire les coûts : Centraliser la gestion de authentification des utilisateurs Simplifier les installation multi fournisseurs Amélioration de la qualité de vie des utilisateurs Adoption par les utilisateurs en raison de la simplicité Réduction du temps passé à se connecter/déconnecter Meilleure sécurité du système Cohérence et simplicité.

EUA and CT Key Technical Properties Standards Used Kerberos v5 (RFC 1510) Stable since 1993, Widely implemented on current operating system platforms Successfully withstood attacks in its 10-year history Fully interoperable among all platforms HL7 CCOW, user subject Network Time Protocol (RFC 1305) Minimal Application Changes Eliminate application-specific, non-interoperable authentication Replace less secure proprietary security techniques Leverage NTP interfaces built-into operating systems

Enterprise User Authentication Transaction Diagram with CCOW Option

Enterprise User Authentication Authentification Kerberos Initial username, password Request TGT “kinit” Kerberos Server Response (contains TGT) TGT Cache Request Service ticket TGT Response with Service Ticket Communication Initiated application Application server Protocol specific communication, using Service Ticket as authenticator Single System Environment

Personal White Pages (PWP)

Personnel White Pages (PWP) – Abstract/Scope Provide access to basic information about the human workforce members Does not include Patients Defines method for finding the PWP Defines query/access method Defines attributes of interest

Personnel White Pages (PWP) Value Proposition Single Authoritative Knowledge Base Reduce duplicate and unconnected user info database Single place to update Name Changes New Phone Number Additional Addresses Enhance Workflow and Communications Providing information necessary to make connections Phone Number Email Address Postal Address

Personnel White Pages (PWP) Value Proposition Enhance User Interactions Provide user friendly identities and lists List of members Displayable name of a user Initials query Contributes to Identity Management Additional methods of identity cross verification Name, address, phone number, email Cross reference with Enterprise User Authentication identity Future expansion likely will contain certificates

PWP - Transactions DNS Server Find Personnel White Pages Personnel Consumer Query for Healthcare Workforce Member Info Personnel White Pages Directory Provide access to healthcare staff information to systems in a standard manner.

PWP - Key Technical Properties DNS – Service discovery transaction LDAP – Personnel White Pages Query LDAP v3 Use of UTF-8 to support global character sets Method for determining the Base DN for PWP Directory of Attributes inetOrgPerson – RFC 2789 X.500 Person – RFC 2256 Recommended attributes to be filled if available Healthcare specifics Names using HL7 naming complex Support for Language specific names IHE Enterprise User Authentication (EUA) user ID Universal Physician Identification Number (UPIN)

PWP – Typical Uses The user needs to send a report to the email address of a colleague. The application allows the user to search for that user’s information, and selects the target user’s email address. The user reviews an existing report and finds initials. The system queries on the initials found in the report and displays the displayable name. The user is reviewing a structured report with an embedded author’s universal provider ID. This universal provider ID is used in a query to find the author of the report. The user calls the author on the phone to review the report details.

Personnel White Pages (PWP) Shall Include Login Id, johnmk, q1234 moehrkj@krb.local Last Name, Moehrke Display Name, John F. Moehrke Other Unique Identifiers (e.g. professional).

Personnel White Pages (PWP) Shall Include if available: First Name, John Initials, JFM Phone Numbers, (555) 293-1667 Title, Systems Engineer Email Address, John.Moehrke@med.ge.com Postal Address, W126 N7449 Flint Rd Postal Code 53051 Manager, and Charles Parisot Employee Type Intern Etc… Plus, “may include” and “discourages”

Scanned Document (SD)

XDS-SD (Scanned Document) Génération d’un document XML structuré en CDA R2 à partir d’un document PDF, qu’il ait été numérisé ou généré autrement Version « image » et « texte » Le PDF est inclus dans le fichier XML Le profil décrit les méta-données minimales à rentrer, leur origine et leur transposition XDS versus CDA

Retrieve Form For Data Capture (RFD)

RFD : résumé Gestion des remplissages de formulaires liés aux dossiers patient mais destinés aux études cliniques et épidémiologiques Elaboré en lien avec le DISC qui standardise les échanges en recherche clinique pour les labos pharmaceutiques Basé sur XForms, il définit les interactions entre le dossier patient et un gestionnaire de formulaire remplis en web

RFD (Retrieve Form for Data Capture)