1. September, 2005What IHE Delivers 1 ITI - Overview of Cross Enterprise Document Sharing (XDS) and Related Profiles (XDR, XDM) Emmanuel CORDONNIER (ETIAM) IHE-Europe Booth, World of Health IT, 2006

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

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

4. 4 HL7 Attachements (US claims)

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

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

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

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

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

10. 10 Acute Care (Inpatient) GPs and Clinics (Ambulatory) Long Term Care Other Specialized Care (incl. Diagnostics Services) Continuity of Care : Patient Longitudinal Record Typically, a patient goes through a sequence of encounters in different Care Settings

11. 11 community Clinical Encounter Clinical IT System RecordsSent Laboratory Results Specialist Record Hospital Record Finding the records of a patient-Manual & tedious The challenge: Finding and accessing easily documents from other care providers In the community.

12. 12 community Clinical Encounter Clinical IT System Index of patients records (Document-level) 1-Patient Authorized Inquiry Temporary Aggregate Patient History 4-Patient data presented to Physician Sharing System 3-RecordsReturned Reference to records Laboratory Results Specialist Record Hospital Record 2-Reference to Records for Inquiry Sharing records that have been published

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

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

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

16. 16 XDS Document XDS Submission Set XDS Folder Key Concepts IHE XDS Integration Profile: Key Concepts

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

18. 18 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. Key Concepts IHE XDS Integration Profile: Key Concepts

19. 19 EHR Cross-Enterprise Document Sharing What does IHE deliver ? A set of practical scenarios: Submission of documents, submission set, folder, affinity domains, etc are derived from use case scenarios. Example: cardiac care network. A definition of the Actors involved: XDS relies on 5 Actors implemented by the IT systems involved. A complete specification of the Transactions involved : XDS include 5 Transactions specifying exchange of one or more standards-based messages. XDS leverages the most appropriate standard(s) (e.g. HL7, ebXML, W3C, etc.) and resolves any options to ensure interoperability. A number of implementation scenarios are discussed.

20. 20 Cardiac Care Scenario (1)

21. 21 Cardiac Care Scenario (2)

22. 22 XDS : diagram

23. 23 XDS : diagram

24. 24 XDS : diagram

25. 25 XDS: standards used ebXML Registry Services SOAP with attachments et ebXML SOAP Messaging Services Méta-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

26. 26 XDS: meta-data Patient: Affinity domain id, demographics (id, name, birthdate…) « as viewed by the source » Origin: (author, institution, validator) Identification: (ID index, repository URI, unique id, dates of creation et start /end of medical act, title, size, hash, status, parent document) Classification: (classe, type, format, MIME type, type and specialty of institution and author, medical codes, confidentiality level) Required, if known, generated by repository, Recommended Required, if known, generated by repository, Recommended

27. 27 XDR / XDM 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

28. 28 XDR / XDM 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

29. 29 XDR / XDM 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).

30. 30 XDR / XDM Key Technical Properties Re-uses XDS approach for documents SubmissionSet, DocumentEntry SubmissionSet, DocumentEntry ebRS based XML meta-data w. limited extensions 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…)

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

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

33. 33 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 SubmitObjectRequest (ebXML Registry Message) Part 2 Document 1 Part 3 Document n....... Part n+2

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

35. 35 XDR Integration Profile Options Multiple Documents Submission Option Offers the ability to include multiple documents in a single Submission Request 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. Offers the ability to send the set of documents to one unique recipient, using a HTTP web-service based on-line transmission mode.

36. 36 Diagramme XDM Portable Media Importer Portable Media Creator Distribute Document Set on Media [ITI-32]

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

38. 38 XDM Integration Profile Options Multiple Documents Submission Option Offers the ability to include multiple documents in a single Submission Request 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. 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 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. Portable Media Creator writes a set of documents on CD-R media.

39. 39 XDM media Structure

40. 40 XDM combined with PDI XDM content: XDM content: Additional PDI content:

41. 41 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 XDR / XDM 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)

42. 42 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. 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. Measures taken to avoid/limit loss of email by using acknowledgements. Management of personnel and the organizations identification and access control mechanisms. 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. 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. In addition both organizations shall have mutually acceptable audit trail mechanisms.

43. 43 www.ihe-europe.org