1. September, 2005What IHE Delivers 1 ITI – Infrastructure Update (XDM, XDR, XDS-SD, XDS Stored Query) Emmanuel CORDONNIER (ETIAM) IHE-Europe Workshop, Berlin, Feb.2007

2. September, 2005What IHE Delivers 2 Cross-Enterprise Document Media Interchange XDM (and XDR) IHE ITI Update Feb. 2007

3. 3 User Requirements Beyond the inter-applications structured messages and informal textual interchanges between healthcare professionals, there is an increasing need for interchange of medical documents (structured or not) Complementary to EHR managed by healthcare professionals inside care facilities (acute and ambulatory care), there is an emerging need for sharing medical documents among these professionals, and with the patient

4. 4 Patient « envelope » approach Electronic document is the intermediate object enabling to manage the link between non structured information (letters, dictated reports…) and the one managed inside medical databases (EHR) A patient centric « envelope » approach enables to manage the documents interchange as well as their sharing, with an easy and structuring implementation

5. 5 HL7 Attachments (US claims)

6. 6 DICOM E-mail (started in Germany)

7. 7 Merit-9 CD in Japan Hospital Clinic Home care CD DICOM Images Lab/Hospital Doctors distribution IHE-PDI MERIT-9

8. 8 EDISanté « MMF/MXF » in France.rtf.txt.xml Letter or Report with the presentation Textual Note or ASCII encoded message (HL7…) Structured document [with included files] (CDA…) Other files, included into documents (XSLT…) Tile of medical images (DICOM) Vocal comment or physiological signal John Smith 12/30/1957 Envelope header: patient identity, documents description, author, sender, recipient…

9. 9 Document Sharing Before to address the EHR itself, the IHE community has decided to work on the cross-enterprise clinical document sharing This document sharing IHE XDS Integration Profile is referenced in numerous emerging projects around the World, at different levels (healthcare centers and local / specialized / regional / state health networks)

10. 10 Implementing IHE XDS in regional & national projects…Today Canada Infoway IHE Interoperability Showcase ‘06 Denmark (Funen) Italy (Veneto) Spain (Aragon) Austria THINC- New York NCHICA – N. Carolina Italy (Conto Corrente Salute) MA-Share – MA IHIE – IN Mendicino - CA France National PHR

11. 11 Acute Care (Inpatient) PCPs and Clinics (Ambulatory) Long Term Care Other Specialized Care or Diagnostics Services Building and accessing Documents EHR-CR: Care Record systems supporting care delivery Documents Registry Document Repository EHR-LR: Longitudinal Record as used across-encounters Submission of Document References Retrieve of selected Documents

12. 12 XDS – Value Proposition Foundation for Health IT Infrastructures: Shared Electronic Health Record, in a community, region, etc. Effective means to contribute and access clinical documents across health enterprises. Scalable sharing of documents between private physicians, clinics, long term care, pharmacy, acute care with different clinical IT systems. Easy access: Care providers are offered means to query and retrieve clinical documents of interest.

13. 13 XDS - Value Proposition Distributed: Each Care delivery organization “publishes” clinical information for others. Actual documents may remain in the source EHR-CR. Cross-Enterprise: A Registry provides an index for published information to authorized care delivery organizations belonging to the same clinical affinity domain (e.g. an LHII). Document Centric: Published clinical data is organized into “clinical documents”. using agreed standard document types (HL7-CDA, ASTM-CCR, PDF, DICOM, etc.) Document Content Neutral: Document content is processed only by source and consumer IT systems. Standardized Registry Attributes: Queries based on meaningful attributes ensure deterministic document searches.

14. 14 XDS Document XDS Submission Set XDS Folder XDS Key Concepts

15. 15 SubmissionSet Folder XDS : concepts Document Folder Documents server (registry-repository) Submission

16. 16 XDS Document A set of attested clinical information (structured or not) which form an element of a patient record to be shared. It may already exist within the source IT system. XDS Submission Set A set of documents related to a patient that a (team of) clinician(s) in the same source system have decided to make available to potential consumers. XDS Folder A means to group documents for a number of other reasons: Team work across several physicians, Episode of care, Emergency information for a patient, etc. XDS leaves open the use of folders to affinity domain clinicians. XDS Key Concepts

17. 17 XDS: Diagram

18. 18 XDS: Diagram

19. 19 XDS: Diagram

20. 20 XDS: standards used ebXML Registry Services SOAP with attachments and ebXML SOAP Messaging Services Meta-data based on HL7 CDA with HL7 v2.5 content for ids (patient, prof/org) On line (HTTP) or optional off-line (SMTP) submission of document On-line (HTTP) SQL query with recent stored queries on Web Services

21. 21 XDS: meta-data Patient: Affinity domain id, demographics (id, name, birth date…) « as viewed by the source » Origin: author, institution, legal authenticator Identification: ID index, repository URI, unique id, dates of creation and start /end of medical act, title, size, hash, status, parent document Classification: class, type, format, MIME type, type and specialty of institution and author, medical codes, confidentiality level  Required, If known, Generated by repository, Recommended

22. 22 XDS / XDR / XDM Metadata Ex. XDSDocumentE ntry Attribute DefinitionSource/ Query Data Type classCodeThe code specifying the particular kind of document (e.g. Prescription, Discharge Summary, Report). It is suggested that the XDS Affinity Domain draws these values from a coding scheme providing a coarse level of granularity (about 10 to 100 entries). <rim:Classification classificationScheme= "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="theDocument" nodeRepresentation="classCode"> Affinity Domain Specific Value R/RXDS Affinity Domain specific classCode DisplayName The name to be displayed for communicating to a human the meaning of the classCode. See classCode for example. R/PXDS Affinity Domain specific

23. 23 XDM / XDR Uses Cases Specialist, Radio or Lab GP / PCP Doctor ACare Facility Hospital Acute Care / ED Patient Transfer Personal Health Record (PHR) to ED/Primary Care EMR Acute Care Discharge to Extended Care Facility (ECF) Remote advice Consulting to referring physicians Hospital-doctor communication communication

24. 24 XDM / XDR Value proposition Complementary to sharing documents (XDS), point-to-point communication of documents Both transports: secured mail & media (CD…) As XDS, “document content agnostic” Maximal re-use of XDS objects & meta-data Compatible with exchange of images (PDI…) All XDS “content profiles” apply

25. 25 XDM / XDR Scope Interchange of patient centered documents Transmission of results, discharge letters or patient referrals (not the "workflow" itself but all the medical information associated with - e.g. reports, results, images, signals…) Personal Health Record medical information (history, etc), snapshots of clinical information (medication list, immunization records, etc), current observations from home care medical devices (e.g. blood pressure, blood sugar level, etc).

26. 26 XDM / XDR Key Technical Properties Re-uses XDS approach for documents  SubmissionSet, DocumentEntry  ebRS based XML meta-data w. limited extensions Secure e-mail (ebMS over SMTP, S/MIME) Optional on-line protocol (similar to XDS) PDI like media profile with XDS meta-data Potential association of XDS and PDI at the actor level (Document Source…) Further evolution possible for direct interchange over web services (MTOM…)

27. 27 XDM Diagram Portable Media Importer Portable Media Creator Distribute Document Set on Media [ITI-32] 

28. 28 XDM Actors and Options ActorOptionsVol & Section Portable Media CreatorUSB (Note 1)ITI TF-1:15.2.3 CD-R (Note 1)ITI TF-1:15.2.4 ZIP e-mail (Note 1)ITI TF-1:15.2.5 Portable Media ImporterUSB (Note 1)ITI TF-1:15.2.3 CD-R (Note 1)ITI TF-1:15.2.4 ZIP e-mail (Note 1)ITI TF-1:15.2.5 Note 1: At least one of these options is required for each Actor.

29. 29 XDM Integration Profile Options Multiple Documents Submission Option  Offers the ability to include multiple documents in a single Submission Request ZIP email Mode Option  Offers the ability to send the set of documents to one unique recipient, using a ZIP over email. USB Option  Portable Media Creator writes a set of documents on USB media CD-R Option  Portable Media Creator writes a set of documents on CD-R media.

30. 30 XDM media Structure

31. 31 XDM combined with PDI XDM content: XDM content: Additional PDI content: M

32. September, 2005What IHE Delivers 32 Cross-Enterprise Document Reliable Interchange XDR (and XDM) IHE ITI Update Feb. 2007

33. 33 XDR Diagram Provide and Register Document Set [ITI-15]  Document SourceDocument Recipient

34. 34 XDR in conjunction with XDS Document Source Document ConsumerDocument Repository Document Registry Document Recipient XDR Document Recipient Document Source XDR XDS

35. 35 XDR off-line message 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 SubmitObjectsRequest (ebXML Registry Message) Part 2 Document 1 Part 3 Document n....... Part n+2

36. 36 XDR Actors and Options ActorOptionsVol & Section Document SourceMultiple Document Submission ITI TF-1:15.2.1 On-Line ModeITI TF-1:15.2.2 Document RecipientOn-Line ModeITI TF-1:15.2.2 Note 1: At least one of these options is required for each Actor.

37. 37 XDR Integration Profile Options Multiple Documents Submission Option  Offers the ability to include multiple documents in a single Submission Request On-Line Mode Option  Offers the ability to send the set of documents to one unique recipient, using a HTTP web-service based on-line transmission mode.

38. 38 XDM/R Security considerations (1) Use of S/MIME encryption and signature for off-line network transfer (integrity, privacy) Encryption, with TLS authentication of both hosts, for on- line transfers across secure domains Actors need to protect themselves against confidentiality and integrity related risks XDM / XDR grouped with ATNA (access control/audit) Import operations need to be further protected (hash and size to detect corruption with metadata assurance) Media must be securely managed (respect of privacy, proper identification, and corruption checking)

39. 39 XDM/R Security considerations (2) Additionally, parties are recommended to have a mutual agreement:  Management of Patient identification in order to avoid/limit identification errors. The metadata includes a patient id shared by both the Document Source and the Document Recipient as well as id and associated patient info as known by the Document Source.  Measures taken to avoid/limit loss of email by using acknowledgements.  Management of personnel and the organizations identification and access control mechanisms.  Codes set and vocabulary used enabling a consistent management of the metadata on both side.  In addition both organizations shall have mutually acceptable audit trail mechanisms.

40. September, 2005What IHE Delivers 40 Cross Enterprise Sharing of Scanned Documents (XDS-SD) IHE ITI Update Feb. 2007

41. 41 Cross Enterprise Sharing of Scanned Documents (XDS-SD) A variety of legacy paper, film, electronic and scanner outputted formats are used to store and exchange clinical documents and do not have a uniform mechanism to store healthcare metadata associated with the documents, including patient identifiers, demographics, encounter, order or service information. It is necessary to provide a mechanism that allows such source metadata to be stored with the document. This profile defines how to couple such information, represented within a structured HL7 CDA R2 header, with a PDF or plaintext formatted document containing clinical information. The content of this profile is intended for use in XDS, XDR and XDM. Content is created by a Content Creator and is to be consumed by a Content Consumer.

42. 42 XDS-SD Value Proposition Text Chart Notes   Handwritten, typed or word processed clinical documents and/or chart notes, typically multi-page, narrative text, including preprinted forms with handwritten responses, printed documents, and typed and/or word processed documents, and documents saved in various word processing formats. Graphs, Charts and/or Line Drawings   Growth Charts, Fetal Monitoring Graphs... best rendered using PDF versus an image based compression, such as JPEG. When computer generated PDFs include lines, PDF vector encoding should be used. Optical Character Recognition (OCR) Scanned Documents   Clinical documents can contain text and annotations that cannot be fully processed by optical character recognition (OCR), which may only partially represent the document content. Electronic Documents   Existing clinical documents that are electronically transmitted or software created (e.g. PDF, or plaintext) can be considered as actually scanned, previously scanned or virtually scanned before they are shared.

43. 43 XDS-SD Standards Used Document Content Standards and Specifications   PDF RFC 3778, The application/pdf Media Type   PDF/A ISO 19005-1. Document management - Electronic term preservation - Part 1: Use of PDF (PDF/A) Wrapper Content Standards and Specifications   HL7 CDA Release 2.0 (denoted HL7 CDA R2), or just   IETF (Internet Engineering Task Force) RFC 3066

44. 44 XDS-SD Meta-data creation Source Type Description SASource document Attribute – value is copied directly from source document. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible. SATSource document Attribute with Transformation – value is copied from source document and transformed. The Source/Value column identifies where in the source document this attribute comes from. Specify the location in XPath when possible. Extended Discussion column must be ‘yes’ and the transform must be defined in the extended discussion FMFixed (constant) - for all source documents. Source/Value column contains the value to be used in all documents. FADFixed by Affinity Domain – value configured into Affinity Domain, all documents will use this value. (Note: AD must be configurable along with the Document Source) CADCoded in Affinity Domain – a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list. CADTCoded in Affinity Domain with Transform - a list of acceptable codes are to be configured into Affinity Domain. The value for this attribute shall be taken from this list. n/aNot Applicable – may be used with an optionally R2 or O attribute to indicate it is not to be used. DSDocument Source – value comes from the Document Source actor. Use Source/Value column or Extended Discussion to give details. OOther – Extended Discussion must be ‘yes’ and details given in an Extended Discussion.

45. 45 XDS-SD Meta-data Examples XDSDoumentEntry Attribute Usage in XDS Section number Source Type Source/ Value authorInstitutionR2‎7.1.5.2.1SATClinicalDocument / author / assignedAuthor / representedOrganization / name, id This attribute is the corresponding institution to the authorPerson below. authorPersonR2‎7.1.5.2.1SATClinicalDocument / author / assignedAuthor / id, ClinicalDocument / author / assignedAuthor / assignedPerson / name, id authorRoleR2DSadd value, if known authorSpecialityR2DSadd value, if known classCodeR‎7.1.5.2.2SATClinicalDocument / code classCodeDisplayNameR‎7.1.5.2.2SATClinicalDocument / code @displayName

46. 46 XDS-SD HL7-2.5 to HL7 CDA XDS MetadataHL7 CDA Header HL7 v2.5 Data Type Subcomponen t index Subcomponent nameHL7 CDA R2 Data element HL7 CDA R2 Subelement or attribute XCNII and PN 1Id numberII@extension 2.1FamilyName.surnamePNfamily 3Given NamePNgiven 4Second (middle) NamePNgiven 5SuffixPNsuffix 6PrefixPNprefix 9.1 AssigningAuthority.na mespaceII@assigningAuthorityName 9.2AssigningAuthority.uidII@root

47. 47 XDS-SD Header Example <code code=“34133-9” codeSystem=“2.16.840.1.113883.6.1” codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/> Good Health Clinic Care Record Summary

48. 48 XDS-SD Body Example JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB... RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx MgolJUVPRgo=

49. September, 2005What IHE Delivers 49 Registry Stored Query Transaction for XDS Profile IHE ITI Update Feb. 2007

50. 50 XDS Stored Query Overview This supplement adds a single transaction, Stored Query, to the XDS Profile. Stored Query is a large improvement over the existing Query Registry transaction since it removes the use of SQL. It minimizes the risks of undesired (SQL based) queries. This optimized query simplifies implementation both on the XDS Document Registry and XDS Document Consumer. It is functionally identical to the required subset of the existing Query Registry transaction [ITI-16], and it has been decided to make this new Stored Query mandatory and the existing query optional both on the XDS Document Registry and Document Consumer.

51. 51 Introducing some ebRS 3.0 The simplification and optimization benefits realized outweigh the few incompatible changes introduced by this approach:  A few XML schema change introduced by the move from ebXML Registry 2.x to 3.0 (e.g. name space)  Replacement of the SQL Query expression by a compact set of query attributes The Provide and Register Document Set and Register transactions could have been upgraded to version 3.0 at the same time. They were not upgraded for the following reasons:  Provide and Registry Document Set relies on Soap with Attachments. We anticipate upgrading this transaction to use MTOM once WS-I finishes its profiling work. When that work is done, we anticipate upgrading Provide and Register with both changes at one time.  The Register transaction should be upgraded at the same time as Provide and Register.

52. 52 XDS Consumer and Registry ActorsTransactionsOptionalitySection in Vol. 2 Document Consumer Query RegistryOITI TF-2:3.16 Retrieve DocumentRITI TF-2:3.17 Registry Stored QueryR (Note 4) Document Registry Register Document SetR (Note 2)ITI TF-2:3.14 Query RegistryOITI TF-2:3.16 Patient Identity FeedRITI TF-2:3.8 Registry Stored QueryR (Note 4) Note 4: The Document Registry actor part of the Registry Stored Query transaction shall implement all queries defined by the Registry Stored Query transaction. No such minimum requirements are placed on the Document Consumer actor.

53. 53 XDS: Updated Diagram Document Consumer Retrieve Document Query Documents Patient Identity Source Patient Identity Feed Document Source Document Registry Document Repository Provide&Register Document Se t Register Document Set Stored Query Documents

54. 54 ebRS Transaction Parameters The ebXML Registry stored query facility (Invoke Stored Query transaction) accepts the following parameters:  returnType – ‘LeafClass’ or ‘ObjectRef’  Query ID – a UUID from the Stored Query IDs section (3.18.4.1.2.4) below  Query Parameters – as defined in the Query Parameters section (3.18.4.1.2.3.7) below

55. 55 Query List FindDocumentsFindSubmissionSetsFindFoldersGetAllGetDocumentsGetFoldersGetAssociationsGetDocumentsAndAssociationsGetSubmissionSetsGetSubmissionSetAndContentsGetFolderAndContentsGetFoldersForDocumentGetRelatedDocuments

56. 56 FindDocuments Parameters (1) Parameter Name AttributeOptMult $XDSDocumentEntryPatientId XDSDocumentEntry. patientIdR-- $XDSDocumentEntryClassCode XDSDocumentEntry. classCodeOM $XDSDocumentEntryClassCodeScheme XDSDocumentEntry. classCode 1 O2O2 M2M2 $XDSDocumentEntryPracticeSettingCode XDSDocumentEntry. practiceSettingCode OM $XDSDocumentEntryPracticeSettingCodeSchem e XDSDocumentEntry. practiceSettingCode 1 O2O2 M2M2 $XDSDocumentEntryCreationTimeFrom Lower value of XDSDocumentEntry. creationTime O-- $XDSDocumentEntryCreationTimeTo Upper value of XDSDocumentEntry. creationTime O-- $XDSDocumentEntryServiceStartTimeFrom Lower value of XDSDocumentEntry. serviceStartTime O-- $XDSDocumentEntryServiceStartTimeTo Upper value of XDSDocumentEntry. serviceStartTime O--

57. 57 FindDocuments Parameters (2) Parameter Name AttributeOptMult $XDSDocumentEntryServiceStopTimeTo Upper value of XDSDocumentEntry. serviceStopTime O-- $XDSDocumentEntryHealthcareFacilityTypeCode XDSDocumentEntry. healthcareFacilityTypeCode OM $XDSDocumentEntryHealthcareFacilityTypeCodeScheme XDSDocumentEntry. healthcareFacilityTypeCode 1 O2O2 M2M2 $XDSDocumentEntryEventCodeList XDSDocumentEntry. eventCodeList OM $XDSDocumentEntryEventCodeListScheme XDSDocumentEntry. eventCodeList 1 O2O2 M2M2 $XDSDocumentEntryConfidentialityCode XDSDocumentEntry. confidentialityCode O2O2 M2M2 $XDSDocumentEntryFormatCode XDSDocumentEntry. formatCode OM $XDSDocumentEntryStatus XDSDocumentEntry. statusRM

58. 58 Parameters encoding AdhocQueryRequest ebRS operation with id corresponding to « FindDocuments » ebRS “Slot” with name = “$XDSDocumentEntryPatientId” 123 - without quotes for numbers ‘urn:oasis:names:tc:ebxml-regrep:StatusType:Approved’ - in single quotes for strings. ‘Children’’s Hospital’ – a single quote is inserted in a string by specifying two single quotes Within the LIKE predicate  Underscore (‘_’) matches an arbitrary character  Percent (‘%’) matches an arbitrary string Format for multiple values is  (value, value, value, …) OR  (value) if only one value is to be specified.

59. 59 Introducing (real) Web Services uuid:aaaabbbb-cccc-dddd-eeee-ffffffffffff http://fulfillerlocation/PRPA_AR101202 urn:oasis:names:tc:ebxml- regrep:xsd:query:3.0:StoredQuery... <query:AdhocQueryRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"> st3498702^^^&1.3…3.7&ISO

60. 60 XDS Stored Query WSDL Example <xsd:schema elementFormDefault="qualified" targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:tns="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">

61. 61 www.ihe-europe.org