Formation IHE Décembre 2006 Les profils d’intégration du domaine IT-Infrastructure.

Présentation au sujet: "Formation IHE Décembre 2006 Les profils d’intégration du domaine IT-Infrastructure."— Transcription de la présentation:

1 Formation IHE Décembre 2006 Les profils d’intégration du domaine IT-Infrastructure

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

3 3 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éEtablissementPoste de travail Niveau / Fonction

4 4 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

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

6 Formation IHE Décembre 2006 Patient Identifier Cross- Referencing for MPI (PIX)

7 7 Patient Identifier Cross-referencing for MPI Permettre le partage d’identifiant patient Chacun des participants garde 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

8 8 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

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

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

11 11 ITI-8 Patient Identity Feed 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

12 12 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

13 13 ITI-9 PIX Query 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

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

15 15 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

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

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

18 18 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

19 19 PIX Considérations pour l’implémentation … Il est possible de spécifier le domaine de retour souhaité : –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.Le PIX Cross Reference Manager retournera les identifiants pour tous les domaines connus. Attention, il peut être retourné plusieurs identifiants pour un domaine donné.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

20 20 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é XDSExemple: 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

21 21 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.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 auditLes 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 RecordPIX Cross Reference Manager est responsable de la génération du message d’audit Patient Record

22 22 PIX Considérations pour l’implémentation … Out-of-band issues PIX Consumer and PIX Cross Reference Manager need to agree on –PIX Cross Reference Manager responsible for maintaining list of PIX Consumers subscribing to PIX Update Notifications And for each subscriber, list of domains to subscribe toAnd for each subscriber, list of domains to subscribe to How this information is conveyed to and managed by the PIX Cross Reference Manager is not addressed by the PIX profileHow this information is conveyed to and managed by the PIX Cross Reference Manager is not addressed by the PIX profile

23 Formation IHE Décembre 2006 Patient Demographics Query (PDQ)

24 24 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)

25 25 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

26 26 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,…)

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

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

29 29 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||||||88 59/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|||10 00 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

30 30 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

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

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

33 33 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/6Patient information source identifié en MSH-5/6 –Utilisation de PDQ dans le contexte XDS : on spécifie le domaine d’affinité en QPD-8

34 34 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éesL’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 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 suivantesL’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.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.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.

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

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

37 37 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 criteriaProfile 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 segmentSupplier 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”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 nameSome 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 QueryConsumer needs to identify one of the supported patient information source when issuing PDQ Query

38 38 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)

39 Formation IHE Décembre 2006 Patient Administration Management (PAM)

40 40 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

41 41 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

42 42 Patient Administration Management Transaction Diagram

43 43 Patient Administration Management Actor Grouping Requirements

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

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

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

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

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

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

50 50 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 HL7Standard 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 HL7Standard trigger event pending adoption by HL7

51 Formation IHE Décembre 2006 Cross-Enterprise Document Sharing

52 52 Cross-Enterprise Document Sharing (XDS) Objectifs Servir de base au 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

53 53 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

54 54 Cross-Enterprise Document Sharing (XDS) Objectifs Distributé: 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é Document Centric: Les données cliniques publiées sont organisées en « documents cliniques ». On se met d’accord sur les formats de document à utiliser Document Content Neutral: Le contenu du Document n’est lu que par la source et le client. Standardized Registry Attributes: Les requêtes sont basées attributs permettant la recherche de documents spécifiques

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

56 56 Cross-Enterprise Document Sharing (XDS) Différents points de vue : –EHR-CR : Care-delivery Record Patient informationPatient information Managed by a Care Delivery OrganizationManaged by a Care Delivery Organization –EHR-LR : Longitudinal Record Documents partagés par les EHR-CR(s)Documents partagés par les EHR-CR(s) Suivis par le RegistreSuivis par le Registre –Domaine d’affinité Clinique: Groupe d’entreprises de santé (EHR-CR)Groupe d’entreprises de santé (EHR-CR) Un ensemble de règles communesUn ensemble de règles communes Partage un registrePartage un registre

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

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

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

60 60 IHE XDS: Concepts clés XDS Document –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,Documents liés à une pathologie, Épisodes de soin,Épisodes de soin, Informations critiques sur le patient (urgences, allergies…)Informations critiques sur le patient (urgences, allergies…)

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

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

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

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

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

66 66 Cross-Enterprise Document Sharing (XDS) Transaction Diagram

67 67 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

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

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

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

71 71 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

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

73 73 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 –XDS Document Content –Sources of XDS Document Entry Attributes

74 74 Internet Standards HTTP –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

75 75 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)

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

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

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

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

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

81 81 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

82 82 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

83 83 Cross-Enterprise Document Sharing (XDS) Patient ID Management

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

85 85 XDS Query Model

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

87 87 ATNA creates a secured domain: User Accountability (Audit trail) User Accountability (Audit trail) Node-to-Node Access Control Node-to-Node Access Control Node-level user authentication Node-level user authentication User access control provided by node User access control provided by node BUT Registry/repository based User-Level Access Control and policy agreements is beyond XDS. 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 Document Consumer Retrieve Document Query Documents Patient Identity Source Patient Identity Feed Document Source Document Registry Document Repository Provide&Register Document Se t Register Document Set Secured Node Security for XDS There is a formal security & privacy profile for XDS Leverages IHE Audit Trail & Node Authentication

88 88 XDS est la première pierre de l’HER 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.).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.Des profils d’intégration de type Workflow (ePrescribing, eReferral, eBooking, etc.) compléteront le profil XDS. XDS Cross-Enterprise Document Sharing. Document Content Integration Profiles Workflows Messaging Integration Profiles (e.g. ePrescription) Access Control IHE Roadmap - Building upon XDS

89 Formation IHE Décembre 2006 Stored Query

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

91 91 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

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

93 Formation IHE Décembre 2006 Notification of Document Availability (NAV)

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

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

96 96 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

97 97 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!

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

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

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

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

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

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

104 104 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' > </XDSNotification>

105 Formation IHE Décembre 2006 Audit Trail and Node Authentication & Consistent Time

106 106 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

107 107 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)

108 108 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

109 109 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

110 110 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)Enterprise User Authentication (EUA) Cross Enterprise User Authentication (XUA)..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

111 111 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

112 112 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 AuthentificationAuthentification AutorisationAutorisation TraçabilitéTraçabilité –Audit a posteriori qui permet de sanctionner les abus

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

114 114 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œudsSé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.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ésRé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 patientsUn 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é suffisantGé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

115 115 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

116 116 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

117 117 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.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.IP assigned to MAC address.

118 118 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 95DICOM Supplement 95 IETF Draft for Common Audit MessageIETF Draft for Common Audit Message ASTM E.214ASTM E.214 HL7 Audit Informative documentsHL7 Audit Informative documents Les 2 formats sont de type XML, permettant les extensions

119 119 ATNA Auditable Events 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

120 120 ATNA Auditable Events 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.

121 121 ATNA Auditable Events 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

122 122 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é pour compatibilité.

123 123 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

124 124 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

125 Formation IHE Décembre 2006 Document Digital Signature (DSG)

126 126 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

127 127 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)

128 128 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

129 129 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

130 130 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

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

132 132 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

133 133 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

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

135 135 Document Digital Signature Transaction Diagram

136 136 Document Digital Signature Transaction Diagram

137 137 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

138 138 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

139 139 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)

140 140 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)

141 141 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 AdministrativeTimestamp

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

143 143 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

144 Formation IHE Décembre 2006 Cross Entreprise Media Interchange (XDM) Cross Entreprise Reliable Interchange (XDR)

145 145 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é…)

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

147 147 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

148 148XDR/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…

149 149 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…)

150 150 Diagramme XDR Provide and Register Document Set [ITI-15]  Document SourceDocument Recipient

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

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

153 153 Message de base XDR 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

154 154 Structure d’un media XDM

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

156 Patient Synchronized Application (PSA)

157 157 Abstract / Scope 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

158 158 Value Proposition 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)Patient Context Participant (PSA) User Context Participant (EUA)User Context Participant (EUA) Patient Synchronized Applications

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

160 160 Transactions Diagram Patient Synchronized Applications These transactions are required for both Actors for compliance

161 161 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 ProfileEnsures maximum interoperability with PIX Profile Protects against future deprecation of patient identifier items (HL7 2.3.1, 2.4, 2.5, CCOW).Protects against future deprecation of patient identifier items (HL7 2.3.1, 2.4, 2.5, CCOW). Patient Synchronized Applications

162 Formation IHE Décembre 2006 Enterprise User Authentication (EUA)

163 163 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).

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

165 165 EUA and CT Key Technical Properties Standards Used –Kerberos v5 (RFC 1510) Stable since 1993,Stable since 1993, Widely implemented on current operating system platformsWidely implemented on current operating system platforms Successfully withstood attacks in its 10-year historySuccessfully withstood attacks in its 10-year history Fully interoperable among all platformsFully 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

166 166 Enterprise User Authentication Transaction Diagram with CCOW Option

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

168 Formation IHE Décembre 2006 Personal White Pages (PWP)

169 169 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

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

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

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

173 173 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)

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

175 175 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).

176 176 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 Code53051 Manager, and Charles Parisot Employee TypeIntern Etc… Plus, “may include” and “discourages”

177 Formation IHE Décembre 2006 Scanned Document (SD)

178 178 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

179 Formation IHE Décembre 2006 Retrieve Form For Data Capture (RFD)

180 180 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

181 181 RFD (Retrieve Form for Data Capture)

182 Cross-Enterprise User Authentication (XUA)

183 183 Cross-Enterprise User Authentication Abstract/Scope Provide User Identity between Enterprises Provide Authentication strength knowledge Provide for optional contact information Mechanism to disclose User Identity is Profiled by IHE; controlled by Affinity Domain Policy

184 184 Cross-Enterprise User Authentication Value Proposition Extend User Identity to Affinity Domain –Supports any cross-enterprise transaction –Federated or Centralized Provide information necessary so that XDS actors can make Access Control decisions –Does not include Access Control mechanism Provide information necessary so that XDS actors can produce detailed and accurate Security Audit Trail

185 185 Cross-Enterprise User Authentication Transaction Diagram Identity Provider 2 Request Assertion (of who this user is) 1 XDS Retrieve 3 Request User ID 4 User Identity 5 Authentication Assertion Record Auditable Event ATNA Audit Repository XDS Repository

186 186 Cross-Enterprise User Authentication Standards Used Employs SAML 2.0 Profiles Specifies use of SAML Browser SSO Profile and Enhanced Client/Proxy Profile Specifies SAML Profile to use with XDS (ebXML Registry) –Consistent with ebXML 3.0 use of SAML Extends SAML 2.0 Profiles into HL7 –future DICOM

187 187 Cross-Enterprise User Authentication Actors User Authentication Provider – Not specified but required. Could be EUA or other authentication system X-Identity Provider – SAML Identity Provider X-Service User – Any IHE Actor that interacts with the user, has authenticated the user using the “User Authentication Provider” X-Service Provider – Any IHE Actor requiring XUA Dash Line – Existing Transactions Solid Line – XUA User Authentication Provider X-Identity Provider X-Service User X-Service Provider

188 188 Key: Original Transaction XUA Assertion TLS Protections EHR Patient Data XDS Consumer XDS Registry X-Service User user auth provider X-Identity Provider Cross-Enterprise User Authentication Implementation Example User Auth (ATNA Secure Node) Audit Log

189 189 Cross-Enterprise User Authentication SAML Resources OASIS Security Services (SAML) TC –http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=security http://www.oasis- open.org/committees/tc_home.php?wg_abbrev=securityhttp://www.oasis- open.org/committees/tc_home.php?wg_abbrev=security SAML V2.0 slides from Eve Maler (Sun) –http://www.oasis- open.org/committees/download.php/12958/SAMLV 2.0-basics.pdf http://www.oasis- open.org/committees/download.php/12958/SAMLV 2.0-basics.pdfhttp://www.oasis- open.org/committees/download.php/12958/SAMLV 2.0-basics.pdf SAML V2.0 slides from Prateek Mishra –http://lists.oasis-open.org/archives/security- services/200504/ppt00000.ppt http://lists.oasis-open.org/archives/security- services/200504/ppt00000.ppthttp://lists.oasis-open.org/archives/security- services/200504/ppt00000.ppt SAML V2.0 slides from Hal Lockhart –http://lists.oasis-open.org/archives/security- services/200506/msg00031.html http://lists.oasis-open.org/archives/security- services/200506/msg00031.htmlhttp://lists.oasis-open.org/archives/security- services/200506/msg00031.html