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 3 Types de profil pour IT-Infrastructure
Gestion des identifiants PAM, PDQ, PIX, PSA Accès au dossier électronique NAV, RFD, RID, XDM, XDR, XDS (a et b), XDS-SD Sécurité ATNA, DSG, CT, EUA, XUA, PWP, BPPC

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 Demographics Query (PDQ)

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

8 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

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

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

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

12 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

13 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

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

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

16 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

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

18 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

19 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

20 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

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

22 Patient Identifier Cross-Referencing for MPI (PIX)

23 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

24 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

25 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

26 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

27 ITI-8 Patient Identity Feed
L’acteur Patient Identity Source transmets les données démographiques 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

28 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

29 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

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

31 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

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

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

34 PIX Implementation Considerations
Le 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

35 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

36 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

37 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

38 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

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 Standard utilisé
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 3 Types de profil pour IT-Infrastructure
Gestion des identifiants PAM, PDQ, PIX, PSA Accès au dossier électronique NAV, RFD, RID, XDM, XDR, XDS (a et b), XDS-SD Sécurité ATNA, DSG, CT, EUA, XUA, PWP, BPPC

52 Cross-Enterprise Document Sharing

53 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

54 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

55 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

56 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

57 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

58 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

59 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

60 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

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

62 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

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

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

65 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éatio, 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é

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

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

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

69 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

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

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

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

73 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

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

75 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

76 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

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

78 Cross-Enterprise Document Sharing (XDS) Les Options Proposées
Pour l’acteur Document Source: Operations de bases Publication d’un document unique Remplacement d’un document existant Options : Off-line mode Publication de plusieurs document Gestion du cycle de vie du document Publication d’addendum ou transformation du document Gestion des dossiers (Folder) Création des dossier et publication dans le dossier

79 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

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

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

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

83 XDS Affinity Domain Ne comprend qu’un Document Registry Identifies:
Document Sources Document Consumers Document Repositories Définit le domaine d’identification du patient Choisit les Vocabulaires Définit les régles de partage de document Définit les régles de securité et de confidentialité Source des certificats pour les nœuds sécurisés ATNA 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.

84 Patient Identification Management
Un seul domaine d’identification du patient Géré par l’acteur Patient Identity Source. Plusieurs méthodes pour récupérer l’identifiant dans le domaine Utilisation de PIX Utilisation de PDQ Autres mécanismes

85 XDS Query Model

86 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

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

94 XDS.b is an evolution of the current XDS Integration Profile (XDS.a)
Introduction XDS.b is an evolution of the current XDS Integration Profile (XDS.a) Same business scenario as XDS.a Provides new transactions in line with current standards XDS.a and XDS.b can co-exist 94 94

95 What’s new in XDS.b Document metadata format is ebXML Registry Information Model, Version 3.0 Added new repositoryUniqueId attribute New Retrieve Document Set transaction with Web Services binding New transactions with updated Web Services bindings WSDL for Document Repository, Document Registry Allows for either Patient Identity Feed HL7v2 or HL7v3 or both to accommodate different scenarios E.g.: Canada focusing on HL7 v3, U.S. focusing on HL7 v2 No support for “off-line” mode 95

96 What is the Same in XDS.b Addresses same scenario as XDS.a providing new implementation mechanism Maintains the same options as XDS.a Multiple document submission Document Lifecycle management Folder management Composes with other IHE content profiles 96

97 Document Metadata Changes
New repositoryUniqueId allows for proper identification of location where document is stored Document Consumers binds to appropriate repository Document URI becomes optional If present indicates support for Retrieve Document transaction [ITI 17] 97

98 Coexistence and Migration
XDS.b allows the document URI metadata attribute to be present Facilitates the use of XDS.b Document Repository/Registry in legacy XDS.a environments XDS.b identifies rules for implementations claiming conformance against both XDS.a and XDS.b at the same time [ITI TF-1:10.7] in the supplement explains common scenarios 98

99 XDS.b Actors and Transactions
Document Registry Registry Stored Query [ITI-18] Register Document Set-b Patient Identity Feed (HL7v2/HL7v3) Document Repository Provide and Register Document Set-b Retrieve Document Set 99

100 XDS.b Actors and Transactions
Patient Identity Source Patient Identity Feed [ITI-8] Patient Identity Feed HL7v3 Registry Stored Query [ITI-18] Document Registry Document Consumer Register Document Set-b Provide and Register Document Set-b Document Source Document Repository Retrieve Document Set Integrated Document Source/Repository 100

101 Changes in Actor Behavior
Document Repository populates repositoryUniqueId before calling Register Document Set-b Document Registry can support either Patient Identity Feed HL7v2 or HL7v3 or both to accommodate different scenarios and requirement Document Consumer needs to resolve the Document Repository endpoint before invoking the Retrieve Document Set transaction Enables use of proxies for multiple Document Repositories 101

102 XDS.b Transactions All transactions reference ebXML Registry Information Model 3.0 All transactions support SOAP 1.2 Optionally support SOAP 1.1 All transactions support WS-Addressing All transactions have WSDL defined Appendix V: one WSDL per Actor per Integration Profile 102

103 Changes in Transactions
New XML schema types are defined Provide and Register Document Set-b Request Retrieve Document Set Request/Response Document content is within the s:Body in an element of type xs:base64Binary for MTOM support 103

104 Provide and Register Document Set-b Request
Same document metadata as XDS.a Links the document to its metadata Enables support for MTOM 104

105 Retrieve Document Set Request
Support for Cross Community Access (XCA) Retrieve any number of documents Enables Consumer to bind to actual Web Service 105

106 Retrieve Document Set Response
Error messages consistent with ebRS 3.0 Retrieve any number of documents Links to Registry Response 106

107 XDS.b Document Registry Web Services Definitions
Transaction s:Body wsaw:Action (*) Register Document Set-b Request lcm:SubmitObjectRequest urn:ihe:iti:2007: RegisterDocumentSet-b Register Document Set-b Response rs:RegistryResponse urn:ihe:iti:2007: RegisterDocumentSet-bResponse Registry Stored Query Request query:AdhocQueryRequest urn:ihe:iti:2007: RegistryStoredQuery Registry Stored Query Response query:AdhocQueryResponse urn:ihe:iti:2007: RegistryStoredQueryResponse Patient Registry Record Added Request hl7:PRPA_IN201301UV urn:hl7-org:v3: PRPA_IN201301UV Patient Registry Record Revised Request hl7:PRPA_IN201302UV urn:hl7-org:v3: PRPA_IN201302UV Patient Registry Duplicates Resolved Request hl7:PRPA_IN201304UV urn:hl7-org:v3: PRPA_IN201304UV Patient Registry Transactions Response hl7:MCCI_IN000002UV urn:hl7-org:v3: MCCI_IN000002UV 107 (*) Namespaces presented on multiple lines for readability purposes

108 XDS.b Document Repository Web Services Definitions
Transaction s:Body wsaw:Action (*) Provide and Register Document Set-b Request ihe:ProvideAndRegisterDocumentSetRequest urn:ihe:iti:2007: ProvideAndRegisterDocumentSet-b Provide and Register Document Set-b Response rs:RegistryResponse urn:ihe:iti:2007: ProvideAndRegisterDocumentSet-b Response Retrieve Document Set Request ihe:RetrieveDocumentSetRequest urn:ihe:iti:2007: RetrieveDocumentSet Retrieve Document Set Response ihe:RetrieveDocumentSetResponse urn:ihe:iti:2007: RetrieveDocumentSetResponse 108 (*) Namespaces presented on multiple lines for readability purposes

109 Retrieve Document Set Request Sample
<s:Envelope xmlns:s=" xmlns:a=" <s:Header> <a:Action s:mustUnderstand="1"> urn:ihe:iti:2007:RetrieveDocumentSet </a:Action> <a:MessageID> urn:uuid:80b0b9c6-e bae5-7fcf994a9f25 </a:MessageID> <a:ReplyTo> <a:Address> </a:ReplyTo> <a:To s:mustUnderstand="1"> </a:To> </s:Header> <s:Body> <RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"/> </s:Body> </s:Envelope> Support for WS-Addressing Synchronous request 109

110 Retrieve Document Set Response
<s:Envelope xmlns:s=" xmlns:a=" <s:Header> <a:Action s:mustUnderstand="1"> urn:ihe:iti:2007:RetrieveDocumentSetResponse </a:Action> <a:RelatesTo> urn:uuid:80b0b9c6-e bae5-7fcf994a9f25 </a:RelatesTo> </s:Header> <s:Body> <RetrieveDocumentSetResponse xmlns="urn:ihe:iti:xds-b:2007"/> </s:Body> </s:Envelope> Use of appropriate WSA action Indicates reply to previous message 110

111 Tips and Tricks When generating Web Services proxy/stubs, evaluate using a development WSDL Replaces typed definitions with un-typed XML MTOM gives you binary attachments for free Supports composition with WS-Security, WS-Reliable Messaging 111

112 Sample C# Code 112 Use appropriate namespace and WSDL name
Define WS-Addressing Actions for both Request and Response [ServiceContract( Namespace = "urn:ihe:iti:xds-b:2007", Name = "XDSRepository")] public interface IXdsDocumentRepository { [OperationContract( Action = "urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b", ReplyAction = "urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse")] Message ProvideAndRegisterDocumentSet(Message input); Action = "urn:ihe:iti:2007:RetrieveDocumentSet", ReplyAction = "urn:ihe:iti:2007:RetrieveDocumentSetResponse")] Message RetrieveDocumentSet(Message input); } Evaluate use of un-typed development WSDL 112

113 Cross Community Access (XCA) composes with XDS.b
What’s Next for XDS.b Cross Community Access (XCA) composes with XDS.b Cross-Enterprise User Assertion (XUA) composes with XDS.b via WS-Security 1.1 113

114 Notification of Document Availability (NAV)

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

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

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

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

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

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

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

122 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

123 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

124 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

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

126 Audit Trail and Node Authentication & Consistent Time

127 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

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

129 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

130 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

131 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

132 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

133 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

134 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

135 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

136 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

137 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

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

139 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

140 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

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

142 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

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

144 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

145 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

146 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

147 Document Digital Signature (DSG)

148 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

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

150 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

151 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

152 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

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

154 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

155 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

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

157 Document Digital Signature Transaction Diagram

158 Document Digital Signature Transaction Diagram

159 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

160 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

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

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

163 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

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

165 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

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

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

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

169 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

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

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

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

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

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

175 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

176 Structure d’un media XDM

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

178 Patient Synchronized Application (PSA)

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

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

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

182 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

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

184 Enterprise User Authentication (EUA)

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

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

187 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

188 Enterprise User Authentication Transaction Diagram with CCOW Option

189 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

190 Personal White Pages (PWP)

191 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

192 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

193 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

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

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

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

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

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

199 Scanned Document (SD)

200 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

201 Retrieve Form For Data Capture (RFD)

202 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

203 RFD (Retrieve Form for Data Capture)