Integrating the Healthcare Enterprise

1. Integrating the Healthcare Enterprise XDS Cross-Enterprise Document Sharing Overview and Concepts • IHE IT Infrastructure Technical & Planning Committee • IHE Interoperability Sept 13-15 Workshop IHE Interoperability Worshop

2. IHE IT Infrastructure 2004-2005 Personnel White Page New Access to workforcecontact information New Retrieve Information for Display Retrieve Information for Display Cross-Enterprise Document Sharing Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Registration, distribution and access across health enterprises of clinical documents forming a patient electronic health record Patient Demographics Query New Audit Trail & Node Authentication New Centralized privacy audit trail and node to node authentication to create a secured domain. Enterprise User Authentication Enterprise User Authentication Consistent Time Provide users a single nameand centralized authentication processacross all systems Coordinate time across networked systems Patient Synchronized Applications Synchronize multiple applications on a desktop to the same patient Patient Identifier Cross-referencing for MPI Patient Identifier Cross-referencing for MPI Map patient identifiers across independent identification domains Map patient identifiers across independent identification domains IHE Interoperability Worshop

3. IHE IT Infrastructure 2005-2005 Personnel White Page New Access to workforcecontact information New Retrieve Information for Display Retrieve Information for Display Cross-Enterprise Document Sharing Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Access a patient’s clinical information and documents in a format ready to be presentedto the requesting user Patient Demographics Query New Audit Trail & Node Authentication Registration, distribution and access across health enterprises of clinical documents forming a distributed patient electronic health record New Centralized privacy audit trail and node to node authentication to create a secured domain. Enterprise User Authentication Enterprise User Authentication Consistent Time Provide users a single nameand centralized authentication processacross all systems Coordinate time across networked systems Patient Synchronized Applications Synchronize multiple applications on a desktop to the same patient Patient Identifier Cross-referencing for MPI Map patient identifiers across independent identification domains IHE Interoperability Worshop

4. Introduction: EHR Cross-EnterpriseClinical Document Sharing First step towards the longitudinal dimension of the EHR: Focus: Clinical Information Exchange between EHRs in care settings to communicate with a distributed longitudinal EHR. Goal: Meet a broad range of EHR-LR (Longitudinal Record) needs with a distributed, cross-enterprise, document centric infrastructure IHE Interoperability Worshop

5. XDS – Value Proposition • Foundation for Health IT Infrastructures: Contributes to the foundation of a shared Electronic Health Record, in a community, region, for a specialized care network, etc. • Effective means to contribute and access across health enterprises of electronic clinical documents with textual and structured content. • Scalable sharing of documents between healthcare enterprises with different clinical IT systems, anywhere from a private physician, to a clinic, to a long term care facility, to a pharmacy, to an acute care in-patient facility. • Easy access: Care providers are offered the means to query and retrieve specific clinical documents of interest from this longitudinal cross-enterprise record. IHE Interoperability Worshop

6. Agenda • Continuity of care:.. requires managing a longitudinal patient record. • Cross-enterprise Document Sharing (XDS), operations. • Contribution of documents, organization tools for the physicians • Using XDS in a cardiac care scenario. • Choosing the standards for XDS • Implementation Models • More technical details IHE Interoperability Worshop

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

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

9. 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 IHE Interoperability Worshop

10. Cross-enterprise Document Sharing EHR-LR: Longitudinal Recordas used across-encounters EHR-CR Long Term Care EHR-CR EHR-LR Acute Care (Inpatient) EHR-CR Other Specialized Careor Diagnostics Services EHR-CR PCPs and Clinics (Ambulatory) EHR-CR: Care Record systemssupporting care delivery IHE Interoperability Worshop

11. EHR Cross-Enterprise Document Sharing • 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 (clinically attested) is organized into “clinical documents”. Allows each clinical affinity domain to manage, through agreed standard document types, the broad space of clinical information and associated coded vocabularies (HL7-CDA, ASTM-CCR, PDF, DICOM, etc.). • Document Content Generic: Entries into the Document Registry contain standardized attributes to ensure deterministic document searches. Document content is processed only by source and consumer IT systems). IHE Interoperability Worshop

12. IHE XDS Integration Profile: 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 exists 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 mean 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. IHE Interoperability Worshop

13. Document Repository and RegistryExample of Submission Request Submission Request Folder A SubmissionSet 1 DocumentEntry DocumentEntry Document Document Document Registry Document Repositories IHE Interoperability Worshop

14. 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 form 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 Transaction 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. IHE Interoperability Worshop

15. Cardiac Care Scenario IHE Interoperability Worshop

16. Standards selection for IHE XDS Best of breed for an interoperable solution Electronic BusinessStandards ebXML, SOAP, etc. Internet Standards HTML, HTTP,ISO, PDF, JPEG, etc. HealthcareContent Standards HL7 CDA, CEN EHRcomHL7, ASTM CCRDICOM, etc. No single standard can address Cross-enterprise Document Sharing: Marriage of healthcare standards facilitates implementation and leverages complementary technologies (e.g. security & privacy).  Solution driven and pragmatic selection is IHE’s strength. IHE Interoperability Worshop

17. Integration Model 1: EHR-CR with Repository at Source • An EHR-CR completes a phase of care for a patient where it: • Has these documents available as Repository Actor. • Registers documents with a Registry actor. • Any other EHR-CR may query the Registry actor, find out about documents related to all phases of care for the patient and chose to retrieve some of these documents from any Document Repository Actor (Used in model 1 & 2). IHE Interoperability Worshop

18. Integration Model 2: EHR-LR with Third Party Repository • An EHR-CR completes a phase of care for a patient where it: • Provides the documents to a Repository Actor of its choice. • Documentsare Registered with a Registry Actor. • Any other EHR-CR may query the Registry Actor, find out about documents related to all phases of care for the patient and chose to retrieve some of these documents from any Repository Actor (Used in model 1 & 2). IHE Interoperability Worshop

19. Integration Model 3: Direct Patient Transfer-Referral • An EHR-CR completes a phase of care for a patient where it: • Provides and Registers a set of documents to a Document Repository in an EHR-CR (newly created documents and priors of interest documents). • The EHR-CR Consumer Actor has the documents and may respond to queries and provide them to other document consumers. IHE Interoperability Worshop

20. Patient Access also possible • A patient accesses own record : • Query and Retrieve a set of documents using for example a portal application that offers the ability to display documents’ content. • This a particular case of an EHR-CR, where the patient is interested by its own care. Patient may also register and provide documents (portal as document source not shown below). IHE Interoperability Worshop

21. XDS – Conclusion • Foundation for EHR & Health IT Infrastructures • Effective contribution and access to shared documents across all types of health enterprises • Scalable, Flexible and Easy access • XDS to be one of the major highlights of 2005 Annual HIMSS Conference & Exhibition. Dallas, Tex., Feb. 13-17: • used as a foundation for an on-site demonstration of interoperability in support of a National Health Information Networs (NHIN). • Attendees at the conference will be able to create and share their own health records across vendor booths as well as in the ambulatory and acute care settings on the conference exhibit floor. IHE Interoperability Worshop

22. Integrating the Healthcare Enterprise XDS Cross-Enterprise Document Sharing Integration Profile A more detailed presentation IHE Interoperability Worshop

23. IHE XDS Integration Profile: Key Concepts • Actors and Transactions • Document • Submission Set • Folder • Submission Request • Affinity Domain • Patient Identification • Document Lifecycle • Security and Privacy IHE Interoperability Worshop

24. XDS Actors and Transactions IHE Interoperability Worshop

25. XDS Actors and Transactions IHE Interoperability Worshop

26. XDS Actors and Transactions IHE Interoperability Worshop

27. XDS IHE Integration Profile: Actors (Application Roles) Document Source(EHR-CR) • Healthcare point of service system where care is provided and associated clinical information is first collected Document Registry(EHR-LR) • Index and metadata database for all published clinical documents that may be queried. Document Repository(EHR-LR) • Maintains and stores published documents that may be retrieved Document Consumer(EHR-CR) • Healthcare point of service application system where care is provided that needs access to documents and information Patient Identity Source(EHR-LR) • Assigns and managed Patient identifiers for the XDS Sharing Domain IHE Interoperability Worshop

28. XDS Document • The smallest unit of information that may be provided to a Document Repository Actor and be registered as an entry in the Document Registry Actor. • An XDS Document contains observations and services for the purpose of exchange with: Persistence, Stewardship, Potential for Authentication, and Wholeness (See HL7 Clinical Document Architecture Release 1). • An XDS Document must be human and/or application readable. It shall comply with a published standard defining its structure, content and encoding. IHE intends to define content-oriented Integration Profiles to be used in conjunction with XDS. • An XDS Document shall be associated with Meta-Data defined by the Document Source. This Meta-Data information is managed by the Document Registry Actor, and is used for query purposes by Document Consumer Actors. • An XDS Document shall be provided to the Document Repository Actor as an octet stream (with MIME type) to be retrieved unchanged. IHE Interoperability Worshop

29. XDS Submission Set • Created by a single Document Source • Issued by a single Provide & Register Document Set or Register Document Set transaction • Related to care event(s) of a single uniquely identified patient. • Makes a record of all new documents, references to previously submitted documents and folders. • The XDS Submission Set is labeled by the Document Source with a “content code” (e.g. clinical meaning). • It should be possible to query the EHR-LR Registry and find all documents registered in the same XDS Submission Set. IHE Interoperability Worshop

30. Example:Document Source prepares a submission request :One Submission Setassociated with two Documents and a Folder Folder A SubmissionSet 1 DocumentEntry DocumentEntry Document Document Objects to be Registered Objects to be stored in the Repository IHE Interoperability Worshop

31. XDS Folder • A means to group one or more document (new or existing) for any reason: emergency information, a visit, an episode of care, or various approaches to define and identify the phase of care or service to which documents pertain (not ruled by XDS). • Folder shall group documents related to a single patient. • A Folder may include contributions from one or more Document Sources. • New documents or reference to existing documents may be added at anytime to a Folder by Document Source Actors. • Will be permanently known by the registry. It should be possible to query the Document Registry and find all documents registered in the same Folder. IHE Interoperability Worshop

32. XDS Submission Request • An XDS Submission Request is created by a single Document Source through a single Provide & Register Document Set transaction Issued. • It includes: • zero or more new documents and zero or more references to existing documents included in the Submission Set • one and only one Submission Set • Inclusions of new or references to existing documents into new and existing Folders. • Upon successful submission all (or none) of the objects it includes are available for sharing. • XDS Folder are labeled by the Document Source(s) with an associated code (e.g. clinical meaning) IHE Interoperability Worshop

33. Document Repository and Registry – First Submission Folder A SubmissionSet 1 DocumentEntry DocumentEntry Document Document Document Registry Submission Request 1 Document Repository Document Repository IHE Interoperability Worshop

34. Document Repository and Registry – After Submission Request succeeded Folder A SubmissionSet 1 DocumentEntry DocumentEntry Document Document Document Registry Document Repository Document Repository IHE Interoperability Worshop

35. Submission Request 2 - Logical Content Submission Request 2 Folder B Folder A SubmissionSet 2 Original ByReference DocumentEntry DocumentEntry Document Document Document DocumentEntry IHE Interoperability Worshop

36. Document Repository and Registry – Submission Request 2 Submission Request Folder B Folder A SubmissionSet 1 SubmissionSet 2 DocumentEntry DocumentEntry DocumentEntry DocumentEntry Document Document Document Document Document Registry Document Registry Document Repository Document Repository IHE Interoperability Worshop

37. Document Repository and Registry – Final State Folder B Folder A SubmissionSet 2 SubmissionSet 1 DocumentEntry DocumentEntry DocumentEntry Document Document Document Document Document Registry DocumentEntry Document Repository Document Repository IHE Interoperability Worshop

38. XDS Affinity Domain • A Clinical Affinity Domain is made of a well defined set of Document Repositories, Document Sources and Consumers that have agreed to share clinical documents registered into a single Document Registry. • Addition of a Document Repository or Document Consumer or Source Actor is an administrative act that requires awareness from the Registry and Repositories. • A Clinical Affinity Domain does not deliver care. Only the EHR-CRs belonging to a Clinical Affinity Domain do. • There is a chain of trust established between the users (healthcare staff) in each EHR-CRs and the Clinical Affinity Domain. • It has a patient identification management policy which requires all Document Sources/Consumers to share the same Patient Identifier Registration Domain • A Clinical Affinity Domain may choose to rule what type of documents and vocabularies are used in the documents content. IHE Interoperability Worshop

39. Patient Identification Mgt - Local X-ref Patient Identity Feed Dm=XAD, Pid=Px DocumentEntry Dm=XAD Pid=Px XDS Document Consumer XDS Document Source Query Docs Dm=XAD Pid=Px Dm=XAD Pid=Px Provide&Register Doc Set XDS Doc XDS Doc Patient Identity Source Patient Identification Domain C Patient Identification Domain D2 Patient Identification Domain XAD XDS Document Registry Dm=D2 Pid=Pd Dm=C Pid=Pc XDS Document Repository IHE Interoperability Worshop

40. Patient Identification Mgt - PIX X-ref Patient Identity Feed Dm=XAD, Pid=Px Patient Identity X-Ref Mgr Patient Identity X-Ref Mgr DocumentEntry Dm=XAD Pid=Px XDS Document Consumer XDS Document Source Query Docs Dm=XAD Pid=Px Patient ID Consumer Dm=XAD Pid=Px Provide&Register Doc Set Patient ID Consumer XDS Doc XDS Doc Patient Identity Source Patient Identification Domain C Patient Identification Domain D2 Patient Identification Domain XAD XDS Document Registry Dm=D2 Pid=Pd Dm=C Pid=Pc XDS Document Repository IHE Interoperability Worshop

41. XDS Query Model (1) ebXML Query: SQL with eb-Ref-Info-Model XML returned IHE Interoperability Worshop

42. XDS Query Principles (2) • Query Keys: Against a generic set of “document attributes” to ensure deterministic searches, e.g.: • Patient Id • Service Start and Stop Time • Document Creation Time • Document Class Code and Display Name • Practice Setting Code and Display Name • Healthcare Facility Type Code and Display Name • Availability Status (Available, Deprecated) • Document Unique Id • Query Keys: Against a generic set of submission set/Folder attributes to ensure deterministic searches, e.g.: • Submission Set Id and Content Code. • Submission date/time • Folder Id and List of Content Codes • Folder last update date/time IHE Interoperability Worshop

43. 4-Patient data presented to Physician 3-Documents Returned Temporary Aggregate Patient History 3-Reference to Docs from Inquiry 2- Inquiry for Docs 1-Expression of a need for additional information Clinical Encounter Clinicians access XDS Services through their clinical IT system DocumentRepositories Index of patients records (Document-level) ClinicalIT System IHE Interoperability Worshop

44. DocumentRepositories 4-Patient data presented to Physician 1-Expression of a need for additional information Clinicians may perform a “secondary selection” from query responses Index of patients records (Document-level) ClinicalIT System Clinical Encounter IHE Interoperability Worshop

45. Querying for Documents Patient Id • The four main axis for Document Queries: • Which Patient ? • What Type of Document ? 3 interrelated sub-dimensions: Facility Type Document Class Event Type • By Groups of Documents • By time of Services • 10 additional attributes to query. Folder Facility Type Document Class Practice Setting SubmissionSet Time of Services XDS core Meta-Data derived from HL7 CDA and CEN EHRcom IHE Interoperability Worshop

46. XDSQueryKeys Doc-level IHE Interoperability Worshop

47. XDSQueryKeys Doc-level (Contd’) IHE Interoperability Worshop

48. XDSQueryKeys Submis-sionSet And Folder IHE Interoperability Worshop

49. IHE Roadmap - Building upon XDS Document Content Integration Profiles Workflows MessagingIntegration Profiles(e.g. ePrescription) Document Content Integration Profiles Workflows MessagingIntegration Profiles(e.g. ePrescription) Document Content Integration Profiles Access Control XDSCross-Enterprise Document Sharing. • XDS is a foundation building block for cross-enterprise EHR: • Document Content Integration Profiles will define for a specific domain of care practice: document format, content vocabularies, templates, etc.). • Workflow messaging Integration Profiles will define messages to support specific workflows (ePrescribing, eReferral, eBooking, etc.). These messages should simply reference XDS managed documents for persistent artifacts. •  Solution driven and stepwise pragmatism is IHE’s strength. IHE Interoperability Worshop

50. XDS - Cross-Enterprise Document Sharing • Basic Transactions provided by ebXML Registry Services, ebXML Registry Information Model, ebXML Messaging Services (OASIS-compatible with HL7 V3 messaging layer). • Document Metadata (CDA Header+EHRcom Composition) managed by ebXML Registry. • Document Lifecycle (Medical Records/CDA based) for (addendum, replacement, deprecate, etc.) as mapped to ebXML Registry Information Model. • Shall be used in conjunction with any standard content, e.g. ASTM Continuity of Care Record), EHRcom Compositions, HL7 Clinical Document Architecture and others such as DICOM, PDF, etc. IHE Interoperability Worshop