Les profils d

1
Les profils dinté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)

1. Patient Demographics Query (PDQ)
2. Patient Identifier Cross-referencing for MPI
   (PIX)
3. Patient Synchronized Application (PSA)
4. Audit Trail and Node Authentication (ATNA)
5. Consistent Time (CT)
6. Digital Signature (DSG)
7. Enterprise User Authentication (EUA)
8. Cross Enterprise User Authentication (XUA)
9. Personnel White Pages (PWP)

3
(No Transcript)
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 didentifiant patient
• Chacun des participants garde le contrôle des
  identifiants dans son domaine didentification
• Permet linterrogation
• 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 lalgorithme de rapprochement
• Compatible avec les standards et les transactions
  déjà utilisées par IHE
• Solution économique de synchronisation de données
• Il nest pas nécessaire de changer les
  identifiants pour que les systèmes puissent
  communiquer

9
Patient Identifier Cross-referencing for
MPITransaction 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 ADTA40
11
ITI-8 Patient Identity Feed

• Patient Identity Feed
• Lacteur 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 daffinité
• Le PIX Cross Reference Manager utilise les
  informations pour rapprocher les identifiants
  multiples entre domaines

12
ITI-9 PIX Query
Patient Identifier Cross-reference Manager
Patient Identifier Cross-reference Consumer
Get Corresponding Identifiers HL7 QBPQ23
Return Corresponding Identifiers HL7 RSPK23
13
ITI-9 PIX Query

• PIX Query
• Le PIX Cross Reference Consumer interroge
  lacteur 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
  dautres domaines

14
ITI-10 PIX Update Notification
Patient Identifier Cross-reference Manager
Patient Identifier Cross-reference Consumer
Update Person Information HL7 ADTA31
15
PIX Update Notification

• PIX Update Notification
• Le PIX Cross Reference Manager informe le PIX
  Cross Reference Consumer des modifications de
  mise en correspondance didentifiant pour un
  patient donné
• Lacteur PIX Cross Reference Manager doit
  implémenter cette transaction
• La transaction est optionnelle pour lacteur PIX
  Cross Reference Consumer

16
Patient Identifier Cross-referencing for
MPIProcess Flow Showing ID Domains Transactions
17
(No Transcript)
18
PIX Implementation Considerations

• Le domaine didentification des patients est
  renseigné dans le composant assigning authority
  du data type CX
• De domaine didentification du Patient est
  spécifié dans le champ Assigning Authority du
  data type HL7 CX
• PID290011DAADPISmithJohn19800101MV
  ia del Lavoro, 17BolognaBO401270Bo
  logna20060425153546
• 290011 is the patient ID
• DAAD is the assigning authority
• PI from is the Type of identifier (table HL7
  0203)
• Utilisation de PIX dans le contexte du profil XDS
• Le champ Assigning authority doit être spécifié
  comme Universal Id et Universal Id Type
• Universal Id doit être un OID (ce qui implique
  Universal Id Type ISO)
• PID460023HIMSS20051.3.6.1.4.1.21367.2005.1.
  1ISOPI123456A1.2.3.4.5.1ISONHASMIT
  HJOHND19700519M34 rue des
  testABANCOURT59265100H0380234576PRNPH
  SDIJON

19
PIX Considérations pour limplémentation

• Il est possible de spécifier le domaine de retour
  souhaité
• Utilisation du QPD-4 pour spécifier de manière
  explicite la liste des domaines pour lesquels un
  identifiant est souhaité.
• Si on ne spécifie aucun domaine dans le QPD-4
• Le PIX Cross Reference Manager retournera les
  identifiants pour tous les domaines connus.
• 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 limplémentation

• De lintérêt de lutilisation du PIX Update
  Notification
• Utile lorsque le client veut constituer un cache
  local des identifiants mis en correspondances
• Exemple lacteur XDS Document Source dans un
  hôpital qui souhaiterait maintenir une liste
  didentifiant des patient au sein de
  linstitution et leur correspondance dans le
  domaine daffinité XDS
• Mécanisme du PIX Update Notification
• Lacteur PIX Consumer indique la liste des
  domaines pour lesquels il est intéressé de
  recevoir les notifications.
• Lacteur PIX Cross Reference Manager notifie
  lacteur 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 limplémentation

• Obligation relatives à ATNA
• Patient Identity Feed est un événement de type
  Patient Record en tant que tel il doit être suivi
  dune transaction daudit ATNA Record Audit
  Event transaction
• Lacteur Patient Id Source est responsable de
  générer le message daudit.
• PIX Query est un événement de type Query event en
  tant que tel il doit être suivi dune 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 dune transaction daudit ATNA Record
  Audit Event transaction
• PIX Cross Reference Manager est responsable de la
  génération du message daudit Patient Record

22
PIX Considérations pour limplémentation

• Out-of-band issues PIX Consumer and PIX Cross
  Reference Manager need to agree on
• PIX Cross Reference Manager responsible for
  maintaining list of PIX Consumers subscribing to
  PIX Update Notifications
• And for each subscriber, list of domains to
  subscribe to
• How this information is conveyed to and managed
  by the PIX Cross Reference Manager is not
  addressed by the PIX profile

23
Patient Demographics Query (PDQ)
24
Patient Demographics QueryObjectif

• 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
  dadmission 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 dinterroger un serveur didentité sur des
  critères de nom, didentifiant, de contacts et/ou
  de visite.
• Permet de sélectionner le bon patient dans une
  liste, même si lidentification complète du
  patient nest pas disponible
• Accès limité à un sous ensemble des données
  concernant lidentité 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 and Visit Query ITI-22
? Patient Demographics Query ITI-21
Patient Demographics Consumer
28
ITI-21 Patient Demographics Query
Patient Demographics Supplier
Patient Demographics Consumer
Patient Demographics Query QBPQ22
Patient Demographics Response RSPK22
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\XPLOREEDLADT_DATAPROCESSINGADT
  200604280927QBPQ2220060428092725P2.58
  859/1QPDQRY_PDQ_1001Query By
  NameIHEDEMOQRY20060428092725_at_PID.5.1MRC
  PI4RDMSH\ADT_DATAPROCESSINGADTXPLORE
  EDL20060428092718RSPK221680P2.5MSAAA2006
  04280927250Message acceptedQAKQRY2006042809
  2725OKQRY_PDQ_1001Query By NameIHEDEMO66QPD
  QRY_PDQ_1001Query By NameIHEDEMOQRY20060428092
  725_at_PID.5.1MPIDPDQ113XX03HIMS20051.3.6.
  1.4.1.21367.2005.1.1ISOPIMOHRALICE19580131
  F820 JORIE BLVD.OAK BROOKIL605230
  20060424122602PIDPDQ113XX05HIMS
  S20051.3.6.1.4.1.21367.2005.1.1ISOPIMOONEYST
  AN19780920M100 TAYLORST
  LOUISMO6311002006042412261
  0PIDPDQ113XX04HIMSS20051.3.6.1.4.1.21367.2
  005.1.1ISOPIMOODYWARREN19780820M1000
  CLAYTON RDCLAYTONMO631050
  20060424122712PIDPDQ113XX01HIMSS20051.3.6
  .1.4.1.21367.2005.1.1ISOPIMOORECHIP19380224
  M10 PINETREEWEBSTERMO631190
  20060424122242DSC1680-1

30
ITI-22 Patient Demographics and Visit Query
Patient Demographics Supplier
Patient Demographics Consumer
Patient Demographics and Visit Query QBPZV1
Patient Demographics and Visit Response RSPZV2
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 lImplé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
  dune source dinformation patient donnée
• Lacteur PDQ Consumer utilise les champs MSH-5/6
  Receiving Application/Facility pour identifier le
  contexte de la requête.

33
Considérations sur lImplé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 nest spécifiée dans QPD-8,
  alors on retourne tous les domaines associés à
  une source didentification de patient
• Patient information source identifié en MSH-5/6
• Utilisation de PDQ dans le contexte XDS on
  spécifie le domaine daffinité en QPD-8

34
Considérations sur lImplémentation de PDQ

• Continuation protocol
• Utilisé pour retourner/recevoir les réponses par
  paquets de n
• Lacteur 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 !!!
• Lacteur PDQ supplier renvoie continuation
  pointer dans le segment DSC (si il reste des
  réponses à retourner)
• Lacteur PDQ consumer retourne la valeur du DSC
  afin dobtenir les réponses suivantes
• Cancel query doit être utiliser pour lacteur PDQ
  Consumer pour indiquer quil 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 QBPQ22
Patient Demographics Response RSPK22 DSC-1
valued
Patient Demographics Query echo DSC-1 value
Cas 1 le serveur na plus de réponse
Patient Demographics Response RSPK22 No DSC-1
value
Cancel Query QCNJ01
Cas 2 le client ne veut plus de réponse
ACK
36
PDQ et ATNA
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 dinformations didentité sur les
  patients  traits  à partir dun 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 ManagementObjectifs

• 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 doptions
• possibilité davoir 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 derreurs
• Gestion automatique des erreurs

42
Patient Administration Management Transaction
Diagram
43
Patient Administration Management Actor Grouping
Requirements
44
(No Transcript)
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

• Servir de base au partage de document dans le
  cadre dun EHR.
• Compatible avec lenregistrement des documents
  dans les produits existants.
• Permettre lindexation des documents dun patient
• Permettre linterrogation et la récupération des
  documents dun patient.
• Architecture évolutive

53
Cross-Enterprise Document Sharing (XDS)Objectifs

• Base de linfrastructure IT de santé Partage de
  document électronique dans un réseau, une région
• Moyen efficace daccéder et de contribuer au
  partage de documents cliniques entre plusieurs
  acteurs et établissements de santé. (Le patient
  définissant les droits daccès)
• Indépendant du système dinformation de
  lutilisateur
• Accès Simple le professionnel de santé a la
  possibilité dinterroger le registre et de
  récupérer des documents pertinents

54
Cross-Enterprise Document Sharing (XDS)Objectifs

• Distributé Chaque organisation publie ses
  informations cliniques
• Cross-Enterprise le Registre fournit un index
  des documents publiés aux membres autorisés du
  domaine daffinité
• Document Centric Les données cliniques publiées
  sont organisées en documents cliniques . On se
  met daccord sur les formats de document à
  utiliser
• Document Content Neutral Le contenu du Document
  nest lu que par la source et le client.
• Standardized Registry Attributes Les requêtes
  sont basées attributs permettant la recherche de
  documents spécifiques

55
Longitudinal Record
Suite de soin
Soins intensifs
Unité de soins spécialisés(incl. Diagnostics
Services)
Médecin traitantClinique (Ambulatoire)
Parcours de soin dun patient
56
Cross-Enterprise Document Sharing (XDS)

• Différents points de vue
• EHR-CR Care-delivery Record
• Patient information
• Managed by a Care Delivery Organization
• EHR-LR Longitudinal Record
• Documents partagés par les EHR-CR(s)
• Suivis par le Registre
• Domaine daffinité Clinique
• Groupe dentreprises de santé (EHR-CR)
• Un ensemble de règles communes
• Partage un registre

57
(No Transcript)
58
(No Transcript)
59
(No Transcript)
60
IHE XDS Concepts clés

• XDS Document
• Un ensemble dinformations cliniques constituant
  un élément du dossier patient à partager. Cet
  ensemble peut déjà exister dans le système
  dinformation.
• XDS Submission Set
• Un ensemble de documents liés à un patient quun
  (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
(No Transcript)
62
XDS Document

• Cest la plus petite entité dinformation 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
  linterrogation
• Transmises au Document Repository dans un flux
  doctet associé à un MIME type.

63
XDS méta données documents

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

64
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 dun seul
  patient, identifié de façon unique.
• Enregistre de nouveaux documents.
• Peut faire références à dautres documents.
• Associé a un code de contenu (e.g. sens clinique)
  par le Document Source.
• Accessible via la transaction Query Registry.

65
XDS Folder

• Un moyen de grouper un ou plusieurs documents
  (peu importe la raison)
• Groupe des documents liés à un seul patient.
• Peut inclure des documents de différents Document
  Source
• Peut contenir de nouveau documents ou des
  documents déjà référencés
• Sera contenu de manière permanente par le
  Document Registry
• Sera accessible via la transaction Query
  Registry.
• Associé à un code par le Document Source.

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

• Document Source
• Source of documents and metadata about documents
• Document Repository
• Stores documents, requests indexing in Document
  Registry, supports retrieval
• Document Registry
• Indexes documents, supports search
• Patient Identity Source
• Feeds identity of known patients to Document
  Registry
• Document Consumer
• Initiates search and retrieval for consumer of
  documents

68
Modèle dIntégration 1 EHR-CR avec Repository à
la Source
69
Modèle dIntégration 2EHR-LR avec un Repository
tiers
70
Modèle dIntégration 3 EHR-CR alimente un hub
EHR-CR/EHR-LR
71
Laccès par le patient doit être possible

• Laccès du patient à ses propres données
• Query and Retrieve un ensemble de documents en
  utilisant par exemple un portail qui offre la
  possibilité dafficher le contenu des documents.
• Cest un cas particulier du cas dutilisation
  EHR-CR, dans lequel le patient est intéressé à
  son dossier. Le patient peut également alimenter
  le dossier avec des documents

72
Cross-Enterprise Document Sharing (XDS)
Standards Utilisés

• Internet Standards
• HTML, HTTP,ISO, PDF, JPEG

• Electronic BusinessStandards
• ebXML, SOAP

• HealthcareContent Standards
• HL7 CDA, CEN EHRcomHL7, ASTM CCRDICOM

73
Healthcare Content Standards

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

74
Internet Standards

• HTTP
• Protocol for Retrieve Document
• Online SOAP bindings
• SMTP
• Offline ebMS bindings
• IETF
• Language Identifiers

• MIME
• Document Type codes
• PDF, JPEG, HTML
• XDS Document Content
• UTF-8
• Encoding of Registry Attributes

75
Electronic Business Standards

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

76
Cross-Enterprise Document Sharing (XDS) Les
Options Proposées

• Pour lacteur 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

77
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

78
Document Availability Management
SubmittedRegistration in progress
ApprovedAvailable 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)
79
Document Life Cycle Management
Addendum to a registered document
Time
A two-way relationship between Original and
Addendum
Document
Addendum
Addendum
Replacing a registered document by a new document
Document 1 (Approved)
Time
A two-way relationship between Original and
Replacement Document.
Replacement
Replacement Document
Document 1 (Deprecated)
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)
80
XDS Submission Request

• Created by a single Document Source through a
  single Provide Register Document Set
  transaction.
• Includes a Submission Set and zero or more
• new documents
• references to existing documents
• folders
• associations of documents with folders.
• Registered Atomically in a single transaction.
• Upon successful submission all of the new objects
  it creates are available for sharing, otherwise
  none are.

81
XDS Affinity Domain

• Implements a single Document Registry
• Identifies
• Document Sources
• Document Consumers
• Document Repositories
• Assigns Patient Identity Domain
• Selects Vocabularies
• Establishes Document Sharing Polices
• Establishes Security and Privacy Policies
• Is the Source of ATNA node certificates

82
Patient Identification Management

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

83
Cross-Enterprise Document Sharing (XDS) Patient
ID Management
84
(No Transcript)
85
XDS Query Model
86
Recherche de Documents
Patient Id

• Les 4 axes pour la recherche de Document
• Quel patient ?
• Quel Type de Document ? 3 sous
  dimensions reliées Facility Type
  Document Class Event Type
• Quel Groupe de Documents
• Quel date et heure

Folder
Document Class
Facility Type
SubmissionSet
Practice Setting
Time of Services
XDS core Meta-Data derived from HL7 CDA and CEN
EHRcom
87
(No Transcript)
88
IHE Roadmap - Building upon XDS
Document Content Integration Profiles
Workflows MessagingIntegration Profiles(e.g.
ePrescription)
Access Control
XDSCross-Enterprise Document Sharing.

• XDS est la première pierre de lHER
  inter-établissement
• Les profils dintégration décrivant le contenu
  des documents sont définis à part et sont
  spécifiques aux domaines dapplication Ces
  profils décrivent les format de document, le
  vocabulaire, des templates, etc.).
• Des profils dintégration de type Workflow
  (ePrescribing, eReferral, eBooking, etc.)
  compléteront le profil XDS.

89
Stored Query
90
(No Transcript)
91
XDS Registry Stored Query

• Nest 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 na pas la prétention de répondre à toutes
  les exigences dun EHR complet !
• Des profils de contenu (XDS-I, DSG, XDS-MS) et
  de contrôle daccès (XUA) sont dans le pipe-line
• Avec XDS et en collaboration avec dautres
  activités de standardisation, IHE contribue au
  déploiement dinfrastructures de santé régionale
  et/ou nationale.
• XDS automatise un process manuel existant, il
  permet la création dEHR-LR, facilite laccè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 lemail pour notifier lutilisateur de
  la disponibilité de document dans un domaine
  daffinité XDS.

95
(No Transcript)
96
Notification of Document Availability Objectifs

• Rendre possible lautomatisation de certains cas
  dutilisation dans un environnement de partage de
  documents
• Demandes davis
• Recherche denregistrements
• Accès du patients à ses enregistrements
• Se base sur une infrastructure existante et
  largement déployée lemail

97
Notification of Document Availability Objectifs

• Fournit un trigger pour démarrer un processus
  automatique
• Possibilité simple de faire suivre la
  notification par email forwarding
• Utiliser linfrastructure existante
• Ne transmettre aucune information médicale!

98
(No Transcript)
99
Notification of Document AvailabilityActors

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

100
Notification of Document AvailabilityTransactions

• 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 NameStandards 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
(No Transcript)
103
(No Transcript)
104
Notification of Document AvailabilityNotification
Attachment

• ltXDSNotification xmlns'http//www.ihe.net/2005/N
  AV'
• id'urnuuid92d03292-84a0-4b86-8139-dd244173ddb
  b' registry'http//www.ihe.net8080/XDS' acknow
  ledgement'emailaddress_at_ihe.net' gt
• ltXDSDocumentEntry id'urnuuid92d03292-84a0-4
  b86-8139-dd244173ddbc' /gt
• ltXDSDocumentEntry id'urnuuid92d03292-84a0-4
  b86-8139-dd244173ddbd' /gt
• lt/XDSNotificationgt

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 quun système
  doit implémenter pour intégrer lenvironnement de
  sécurité dun établissement
• Étend et généralise aux autres domaines le profil
  de radiologie Basic Security
• Permet lidentification des systèmes (noeuds)
• Peux être utilisé en parallèle avec les profils
  didentification dutilisateur (EUA et XUA)

108
ATNAObjectifs

• 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 lentreprise
• Système daudit unifié et uniforme
• Approche commune simplifiant ladministration
• Réduction de coûts de développement et de support
  
• Possibilité de réutiliser le code daudit pour de
  multiples acteurs
• Un seul effort de développement pour satisfaire
  différentes règles et contraintes réglementaires

109
ATNASecurity 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
ATNAMesures de sécurité

• Authentification Identification de lutilisateur
  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
  dauthentification des utilisateurs
• Enterprise User Authentication (EUA)
• Cross Enterprise User Authentication (XUA)..
• Autorisation et controle daccesDéfinit les
  droits dun utilisateur pour réaliser une action
  donnée Maintenant que je sais qui tu es, quest
  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
ATNASecurity Measures

• Accountability and Audit trail
• Enregistrer lhistorique des actions dun système
  ou dun utilisateur sur une période de temps
  donnée
• Quas-tu fait ?
• ATNA Définit Le format du message daudit et le
  protocole de transport

112
ATNAIHE Goal

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

113
(No Transcript)
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 laccès par dautres 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 linstallation 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 laccè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 lutilisation de
  lencryptage permettent néanmoins datteindre un
  niveau de sécurité suffisant

115
ATNASecurité des noeuds

• ATNA spécifie certaines des fonctionnalités
  nécessaires (e.g. le contrôle daccès)
• ATNA ne spécifie pas les règles
• ATNA ne spécifie pas la méthodologie (même si
  dautres profils peuvent faire laffaire EUA)
• Ceci permet aux vendeurs et aux établissements de
  choisir les technologies et les règles qui sont
  appropriées

116
ATNANode 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 lidentité de la machine est plus
  importantes que lidentité de lopérateur (en
  terme de sécurité). .
• Certains systèmes opère de manière autonome,
  e.g. PACS archive.
• Connaître le nom de ladministrateur du PACS
  dastreinte est peu utile.
• En général laccès des machines est contrôlé par
  ladministrateur du site.
• IP assigned to MAC address.

118
ATNAAudit Trail

• Conçu pour la surveillance
• Deux format de message daudit
• 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
(No Transcript)
120
(No Transcript)
121
(No Transcript)
122
ATNARecord Audit Event

• Reliable Syslog (RFC 3195) est le protocole de
  transport préféré des messages daudit,
• 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 dAudit
  trail sont basés sur IETF, DICOM, HL7, and ASTM
  standards.
• Les évenements et le format du profile Radiology
  Basic Security sont autorisé pour compatibilité.

123
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 nest pas réservé
  aux seuls transactions IHE
• Toute activité doit générer des traceset ce
  nest pas réservé aux seuls acteurs IHE

124
Consistent Time (CT)

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

125
Document Digital Signature(DSG)
126
Document Digital SignatureValue 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 lauteur
• Infrastructure indispensable dans un contexte de
• e-Prescribing,
• ou de e-Referral

127
Document Digital SignatureAbstract/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 laccès direct au document (XDS)

128
Document Digital SignatureAbstract/scope

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

129
Document Digital SignatureHors du scope

• Gestion des Certificats et concept de PKI
• Standards et limplémentations sont disponibles
  et seront discutés plus tard
• On soccupe de la signature, et pas de
  lencryptage
• Signature Partielle de Document

130
Document Digital SignaturesObjectifs

• Document Digital Signatures aide à réduire les
  risques suivants
• Modification dune prescription (signée ou non)
  pendant sa transmission ou son archivage
• Introduction dune prescription fictive

131
Document Digital Signatures

• Les scenarii suivant ne sont pas pris en compte
• Usurpation didentité
• Vol dun clé privée
• Corruption du poste de travail dun médecin pour
  laccès à sa clé
• Corruption du processus de confirmation

132
Document Digital SignatureKey Technical
Properties

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

133
Document Digital SignatureSignature Attributes

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

134
Document Digital SignatureSignature Attributes

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

135
Document Digital Signature Transaction Diagram
136
Document Digital Signature Transaction Diagram
137
Document Digital SignatureCas dutilisation

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

138
Cross-Enterprise Document Sharing (XDS) Use Case
(1)

• The XDS profile describes how different health
  care parties can share documents
• A document source is responsible to provide
  and register document in a registry/repository
  for a query and retrieve by a document
  consumer
• Document Digital Signature enables to manage the
  responsibility issues

139
Cross-Enterprise Document Sharing (XDS) Use Case
(2)

• The document source wants to prove it has well
  authored the document and the associated
  submission set metadata
• The registry/repository it has not corrupted
  the documents and metadata
• The document consumer wants to check above
  items and check the identity of author(s) and
  authenticator(s)

140
Cross-Enterprise Document Sharing (XDS) Use Case
(3)

• The document source includes the document(s)
  signature(s) into the submission set
• The registry/repository stores the document
  signature(s) as a document and metadata
  associated with it/them as a specific signature
  object metadata
• The document consumer can see the signature
  metadata and retrieve each signature for
  checking it, including the certificate(s)

141
Document Digital SignatureSignature Purpose

• From ASTM E1762
• Author - Authors signature,
• Author.Co - Coauthors signature
• Participant - Co-participants 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

142
Document Digital SignatureAdditions to ASTM1762

• The following items will be added to ASTM1762
• Modification
• Authorization
• Transformation
• Recipient
• Modification is being worked on.

143
Document Digital SignatureStandards Used

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

144
Cross Entreprise Media Interchange (XDM)Cross
Entreprise Reliable Interchange (XDR)
145
Léchange de documents

• Le succès dXDS 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 lintérêt
  de solutions déchange de documents, plus faciles
  à mettre en place à court terme (organisation,
  sécurité)

146
(No Transcript)
147
Cross-Enterprise Document Reliable/Media
interchange XDR/XDM

• Communication point à point de documents
  complémentaire au partage (XDS)
• 2 types de transports XDR email XDM media
• Comme XDS, indépendant du contenu
• Réutilisation maximale des objets et méta-données
  dXDS
• Compatible avec les échanges dimages (IHE PDI,
  DICOM e-mail)
• Adapté à tous les profils contenu dXDS

148
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

149
Points techniques clefs dXDR/XDM

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

150
Diagramme XDR
Provide and Register Document Set ITI-15 ?
Document Source
Document Recipient
151
Diagramme XDM
Portable Media Importer
Portable Media Creator
Distribute Document Set on Media ITI-32 ?
152
(No Transcript)
153
(No Transcript)
154
Structure dun media XDM
155
XDM combiné avec PDI

• contenu XDM

• En complément, contenu PDI

156
Patient Synchronized Application (PSA)
157
Patient Synchronized Applications

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

158
Patient Synchronized Applications

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

159
Patient Synchronized ApplicationsActors

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

160
Patient Synchronized Applications

• Transactions Diagram