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

Présentation au sujet: "Les profils d’intégration du domaine IT-Infrastructure"— Transcription de la présentation:

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

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

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é Etablissement Poste de travail Niveau / Fonction

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 Gestion des Identifiants
Patient Identifier Cross-referencing for MPI (PIX) Patient Administration Management (PAM) Patient Demographics Query (PDQ) Patient Synchronized Application (PSA)

6 Patient Identifier Cross-Referencing for MPI (PIX)

7 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

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

10 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

11 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

12 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

13 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

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

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 Patient Identifier Cross-referencing for MPI Process Flow Showing ID Domains & Transactions

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

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|| |M|||Via del Lavoro, 17^^Bologna^BO^40127|||||||||0|||Bologna|||||||||| 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& &ISO^PI~123456^^^A& &ISO^NH^^^^^A||SMITH^JOHN^^^^^D|| |M|||34 rue des test^^ABANCOURT^^59265^100^H|| ^PRN^PH|||S|||||||DIJON

19 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

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

22 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

23 Patient Demographics Query (PDQ)

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 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 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 Patient Demographics Query Diagramme des Transactions
Patient Demographics Supplier  Patient Demographics Query [ITI-21]  Patient Demographics and Visit Query [ITI-22] Patient Demographics Consumer

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

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| ||QBP^Q22| |P|2.5||||||8859/1 QPD|QRY_PDQ_1001^Query By RCP|I|4^RD| MSH|^~\&|ADT_DATAPROCESSING|ADT|XPLORE|EDL| ||RSP^K22|1680|P|2.5 MSA|AA| ||||0^Message accepted QAK|QRY |OK|QRY_PDQ_1001^Query By Name^IHEDEMO|6|6 QPD|QRY_PDQ_1001^Query By PID|||PDQ113XX03^^^HIMS2005& &ISO^PI||MOHR^ALICE|| |F|||820 JORIE BLVD.^^OAK BROOK^IL^60523|||||||||0||||||||||||| PID|||PDQ113XX05^^^HIMSS2005& &ISO^PI||MOONEY^STAN|| |M|||100 TAYLOR^^ST LOUIS^MO^63110|||||||||0||||||||||||| PID|||PDQ113XX04^^^HIMSS2005& &ISO^PI||MOODY^WARREN|| |M|||1000 CLAYTON RD^^CLAYTON^MO^63105|||||||||0||||||||||||| PID|||PDQ113XX01^^^HIMSS2005& &ISO^PI||MOORE^CHIP|| |M|||10 PINETREE^^WEBSTER^MO^63119|||||||||0||||||||||||| DSC|1680-1

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 ITI-22 Patient Demographics and Visit Query
Cette transaction est optionnelle pour les acteurs Patient Demographics Consumer et Patient Demographics Supplier

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

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

35 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

36 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

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

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 Patient Administration Management (PAM)

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

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

44 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

45 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

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

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

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

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

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

51 Cross-Enterprise Document Sharing

52 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

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

55 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

56 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

57 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

58 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

59 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

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

61 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

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

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

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

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

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

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

68 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

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

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

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

72 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

73 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 …

74 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

75 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

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

77 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

78 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

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

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

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

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

83 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

84 XDS Query Model

85 Recherche de Documents
Patient Id Les 4 axes pour la recherche de Document : Quel patient ? Quel Type de Document ? 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

86 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

87 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

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

89 Stored Query

90 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

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 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 Notification of Document Availability (NAV)

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

95 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…

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’

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

98 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]

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

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

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

103 Notification of Document Availability Intermediated Use Case
Provider A publishes records 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

104 Notification of Document Availability Notification Attachment
<XDSNotification xmlns=' id='urn:uuid:92d a0-4b dd244173ddbb' registry=' > <XDSDocumentEntry id='urn:uuid:92d a0-4b dd244173ddbc' /> <XDSDocumentEntry id='urn:uuid:92d a0-4b dd244173ddbd' /> </XDSNotification>

105 Audit Trail and Node Authentication & Consistent Time

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

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

113 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

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

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

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

119 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

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

121 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

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

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

125 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

126 Document Digital Signature (DSG)

127 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

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

129 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

130 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

131 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

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

133 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

134 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

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

136 Document Digital Signature Transaction Diagram

137 Document Digital Signature Transaction Diagram

138 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

139 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

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

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

142 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

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

144 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

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

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

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

148 Cross-Enterprise Document Reliable/Media interchange XDR/XDM
Communication point à point de documents complémentaire au partage (XDS) 2 types de transports : XDR & 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 …) Adapté à tous les profils “contenu” d’XDS

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

150 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 (comme DICOM – 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…)

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

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

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

154 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

155 Structure d’un media XDM

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

157 Patient Synchronized Application (PSA)

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

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

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

161 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

162 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 (HL , 2.4, 2.5, CCOW).

163 Enterprise User Authentication (EUA)

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

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

166 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

167 Enterprise User Authentication Transaction Diagram with CCOW Option

168 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

169 Personal White Pages (PWP)

170 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

171 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 Address Postal Address

172 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, Cross reference with Enterprise User Authentication identity Future expansion likely will contain certificates

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

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

175 PWP – Typical Uses The user needs to send a report to the address of a colleague. The application allows the user to search for that user’s information, and selects the target user’s 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.

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

177 Personnel White Pages (PWP) Shall Include if available:
First Name, John Initials, JFM Phone Numbers, (555) Title, Systems Engineer Address, Postal Address, W126 N7449 Flint Rd Postal Code Manager, and Charles Parisot Employee Type Intern Etc… Plus, “may include” and “discourages”

178 Scanned Document (SD)

179 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

180 Retrieve Form For Data Capture (RFD)

181 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

182 RFD (Retrieve Form for Data Capture)