ITI – Infrastructure Update (XDM, XDR, XDS-SD, XDS Stored Query)

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

2. Cross-Enterprise Document Media Interchange XDM(and XDR) IHE ITI Update Feb. 2007

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. 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. HL7 Attachments (US claims)

6. DICOM E-mail (started in Germany)

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

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

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. Implementing IHE XDS in regional & national projects…Today FranceNational PHR Canada Infoway Austria MA-Share – MA IHIE – IN Mendicino - CA Denmark (Funen) Italy (Veneto) Spain (Aragon) IHE Interoperability Showcase ‘06 Italy (Conto CorrenteSalute) THINC- New York NCHICA – N. Carolina

11. Building and accessing Documents DocumentRepository Submission of Document References Retrieve of selected Documents Documents Registry EHR-LR:Longitudinal Recordas usedacross-encounters Long Term Care Acute Care (Inpatient) Other Specialized Careor Diagnostics Services PCPs and Clinics (Ambulatory) EHR-CR: Care Record systemssupporting care delivery

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. 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. XDS Key Concepts • XDS Document • XDS Submission Set • XDS Folder

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

16. XDS Key Concepts 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.

17. XDS: Diagram

18. XDS: Diagram

19. XDS: Diagram

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. XDS: meta-data • Patient:Affinity domainid, demographics (id, name, birth date…) « as viewed by the source » • Origin:author, institution, legal authenticator • Identification:ID index, repositoryURI, 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 ofinstitution and author, medical codes, confidentiality level • Required, If known, Generated by repository, Recommended

22. XDS / XDR / XDM Metadata Ex.

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

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. 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. 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. XDM Diagram Portable Media Creator Distribute Document Set on Media [ITI-32]  Portable Media Importer

28. XDM Actors and Options Note 1: At least one of these options is required for each Actor.

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. XDM media Structure

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

32. Cross-Enterprise Document Reliable Interchange XDR(and XDM) IHE ITI Update Feb. 2007

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

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

35. Protocol encapsulation in SMTP/ESMTP SOAP with MIME attachments (multipart/related) text/xml SOAP:Envelope SOAP:Header, with Service=LifeCycleManager and Action=submitObjects Part 1 (start) SOAP:Body, with Manifest=list of attachments (e.g. ebXML Reg. Msg + Documents) Part2 text/xml SubmitObjectsRequest (ebXML Registry Message) Part3 Document 1 .. . Part n+2 Document n XDR off-line message

36. XDR Actors and Options Note 1: At least one of these options is required for each Actor.

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. 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. 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. Cross Enterprise Sharing of Scanned Documents (XDS-SD) IHE ITI Update Feb. 2007

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. 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. 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. XDS-SD Meta-data creation

45. XDS-SD Meta-data Examples

46. XDS-SD HL7-2.5 to HL7 CDA

47. XDS-SD Header Example <ClinicalDocument xmlns=“urn:hl7-org:v3”> <typeId extension="POCD_HD000040" root="2.16.840.1.113883.1.3"/> <id root=“1.3.6.4.1.4.1.2835.2.7777”/> <code code=“34133-9” codeSystem=“2.16.840.1.113883.6.1” codeSystemName=“LOINC” displayName=“SUMMARIZATION OF EPISODE NOTE”/> <title>GoodHealth Clinic Care Record Summary</title> <effectiveTime value=“20050329224411+0500”/> <confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/> <languageCode code=“en-US”/>

48. XDS-SD Body Example <component> <nonXMLBody> <text mediaType=“application/pdf” representation=“B64”> JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nGWPMWsDMQyFd/8KjfJwqmVbkr0GQqFbg7fQoSRNWuhB ... RjRDQzdBRUI1NEIzNkZCMjgzQzVDMzI0NzlBRDI4M0Y+XQo+PgpzdGFydHhyZWYKMzAx MgolJUVPRgo= </text> </nonXMLBody> </component> </ClinicalDocument>

49. Registry Stored Query Transaction for XDS Profile IHE ITI Update Feb. 2007

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 optionalboth on the XDS Document Registry and Document Consumer.