Integrating the Healthcare Enterprise

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

IHE Interoperability Worshop
IHE drives healthcare standards based-integration Sept 13-15, 2004 IHE Interoperability Worshop

IHE Organizational Structure Multi-Domain & Multi-National
supervises reports IHE (International) Strategic Development Committee Sponsor Co-Chairs Global Interoperability Delegates IHE Europe IHE North America IHE Asia/Oceania Regional & National Deployment National Extensions IHE Domain-related Planning and Technical Committees Global Development: Radiology, IT Infrastructure, Cardiology, Lab, etc. contribute Participants Sept 13-15, 2004 IHE Interoperability Worshop

IHE 2004 achievements and expanding scope
Over 80 vendors involved world-wide, 4 Technical Frameworks 31 Integration Profiles, Testing at yearly Connectathons, Demonstrations at major exhibitions world-wide Provider-Vendor cooperation to accelerate standards adoption Sept 13-15, 2004 IHE Interoperability Worshop

IHE Process Users and vendors work together to identify and design solutions for integration problems Intensive process with annual cycles: Identify key healthcare workflows and integration problems Research & select standards to specify a solution Write, review and publish IHE Technical Framework Perform cross-testing at “Connectathon” Demonstrations at tradeshows (HIMSS/RSNA…) **Consider making the cycle graphic Incremental approach: Can’t solve all at once Connectathon – Practical measure of progress, Validates the integration work accomplished. Refer the Scorecard. Demo – promotes standards based integration to users/purchasers Sept 13-15, 2004 IHE Interoperability Worshop

A Proven Standards Adoption Process
Product IHE Integration Statement IHE Connect-a-thon Results IHE Connect-a-thon Product With IHE IHE Demonstration Easy to Integrate Products IHE Technical Framework Standards IHE Integration Profiles B Profile A User Site RFP IHE Integration Profiles at the heart of IHE : Detailed selection of standards and options each solving a specific integration problem A growing set of effective provider/vendor agreed solutions Vendors can implement with ROI Providers can deploy with stability Sept 13-15, 2004 IHE Interoperability Worshop

More on IHE IT Infrastructure
To learn more about IHE IT Infrastructure Integrating the Healthcare Enterprise: Read the IHE Brochure Sept 13-15, 2004 IHE Interoperability Worshop

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

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

Introduction: EHR Cross-Enterprise Clinical 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 Sept 13-15, 2004 IHE Interoperability Worshop

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. Sept 13-15, 2004 IHE Interoperability Worshop

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 Sept 13-15, 2004 IHE Interoperability Worshop

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 Sept 13-15, 2004 IHE Interoperability Worshop

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

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

Cross-enterprise Document Sharing EHR-LR: Longitudinal Record as used across-encounters EHR-CR Long Term Care EHR-CR EHR-LR Acute Care (Inpatient) EHR-CR Other Specialized Care or Diagnostics Services EHR-CR PCPs and Clinics (Ambulatory) EHR-CR: Care Record systems supporting care delivery Sept 13-15, 2004 IHE Interoperability Worshop

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). Sept 13-15, 2004 IHE Interoperability Worshop

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. Sept 13-15, 2004 IHE Interoperability Worshop

Document Repository and Registry Example of Submission Request
Document Registry Submission Request Folder A Submission Set 1 Document Entry Document Document Repositories Sept 13-15, 2004 IHE Interoperability Worshop

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. Sept 13-15, 2004 IHE Interoperability Worshop

Cardiac Care Scenario Sept 13-15, 2004 IHE Interoperability Worshop

Standards selection for IHE XDS
Best of breed for an interoperable solution Electronic Business Standards ebXML, SOAP, etc. Internet Standards HTML, HTTP, ISO, PDF, JPEG, etc. Healthcare Content Standards HL7 CDA, CEN EHRcom HL7, ASTM CCR DICOM, 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. Sept 13-15, 2004 IHE Interoperability Worshop

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). Sept 13-15, 2004 IHE Interoperability Worshop

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. Documents are 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). Sept 13-15, 2004 IHE Interoperability Worshop

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. Sept 13-15, 2004 IHE Interoperability Worshop

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). Sept 13-15, 2004 IHE Interoperability Worshop

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 : 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. Sept 13-15, 2004 IHE Interoperability Worshop

Integrating the Healthcare Enterprise
XDS Cross-Enterprise Document Sharing Integration Profile A more detailed presentation Sept 13-15, 2004 IHE Interoperability Worshop

IHE XDS Integration Profile: Key Concepts
Actors and Transactions Document Submission Set Folder Submission Request Affinity Domain Patient Identification Document Lifecycle Security and Privacy Sept 13-15, 2004 IHE Interoperability Worshop

XDS Actors and Transactions Sept 13-15, 2004 IHE Interoperability Worshop

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 Sept 13-15, 2004 IHE Interoperability Worshop

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. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR-CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR. Sept 13-15, 2004 IHE Interoperability Worshop

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. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR-CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR. Sept 13-15, 2004 IHE Interoperability Worshop

Example: Document Source prepares a submission request : One Submission Set associated with two Documents and a Folder Folder A Submission Set 1 Objects to be Registered Document Entry Document Objects to be stored in the Repository Sept 13-15, 2004 IHE Interoperability Worshop

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. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR-CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR. Sept 13-15, 2004 IHE Interoperability Worshop

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) The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR-CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR. Sept 13-15, 2004 IHE Interoperability Worshop

Document Repository and Registry – First Submission
Document Registry Submission Request 1 Folder A Submission Set 1 Document Entry Document Document Repository Document Repository Sept 13-15, 2004 IHE Interoperability Worshop

Document Repository and Registry – After Submission Request succeeded
Document Registry Document Document Entry Submission Set 1 Folder A Document Repository Document Repository Sept 13-15, 2004 IHE Interoperability Worshop

Submission Request 2 - Logical Content
Folder A Folder B Submission Set 2 Original By Reference Document Entry Document Entry Document Document Sept 13-15, 2004 IHE Interoperability Worshop

Document Repository and Registry – Submission Request 2
Document Registry Document Registry Submission Request Folder A Folder B Submission Set 1 Submission Set 2 Document Entry Document Entry Document Document Document Repository Document Repository Sept 13-15, 2004 IHE Interoperability Worshop

Document Repository and Registry – Final State
Document Registry Folder A Folder B Submission Set 1 Submission Set 2 Document Entry Document Document Entry Document Entry Document Document Entry Document Document Document Repository Document Repository Sept 13-15, 2004 IHE Interoperability Worshop

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. The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems, ranging from EHR-CR (Care-delivery Record) in a large hospital network to small physician practice management systems. EHR-LR will be cross-enterprise, possibly across large geographical regions, and may include one or more clinical domains. EHR-LR will be typically collected and retained over a large period of time, providing a deep historic record for the patient. EHR-LR is supported by repositories of encounter data that contribute to the patient’s longitudinal healthcare record. EHR-LR data will be found in multiple repositories that will interoperate and provide a seamless historical view of the patient. Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR. Sept 13-15, 2004 IHE Interoperability Worshop

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

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

XDS Query Model (1) ebXML Query: SQL with eb-Ref-Info-Model XML returned Sept 13-15, 2004 IHE Interoperability Worshop

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 Sept 13-15, 2004 IHE Interoperability Worshop

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

Document Repositories 4-Patient data presented to Physician
Clinicians may perform a “secondary selection” from query responses Document Repositories 4-Patient data presented to Physician Index of patients records (Document-level) 1-Expression of a need for additional information Clinical Encounter Clinical IT System Sept 13-15, 2004 IHE Interoperability Worshop

Querying for Documents
Patient Id The four main axis for Document Queries: Which Patient ? What Type of Document ? 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 Submission Set Time of Services XDS core Meta-Data derived from HL7 CDA and CEN EHRcom Sept 13-15, 2004 IHE Interoperability Worshop

XDS Query Keys Doc-level Sept 13-15, 2004 IHE Interoperability Worshop

XDS Query Keys Doc-level (Contd’) Sept 13-15, 2004 IHE Interoperability Worshop

XDS Query Keys Submis- sion Set And Folder Sept 13-15, 2004 IHE Interoperability Worshop

IHE Roadmap - Building upon XDS
Document Content Integration Profiles Workflows Messaging Integration Profiles (e.g. ePrescription) Document Content Integration Profiles Workflows Messaging Integration Profiles (e.g. ePrescription) Document Content Integration Profiles Access Control XDS Cross-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. Sept 13-15, 2004 IHE Interoperability Worshop

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. Sept 13-15, 2004 IHE Interoperability Worshop

Patient Identity Source Provide&Register Document Set
Security for XDS Leverages IHE (ATNA) Audit Trail & Node Authentication A formal Security and Privacy profile is provided for XDS ATNA creates a secured domain: User Accountability (Audit trail) Node-to-Node Access Control Node-level user authentication User access control provided by node BUT Registry/repository based User-Level Access Control and policy agreements is beyond XDS. User-level Access Control may be provided through the EUA Integration Profile but more effectively through a future PKI based profile. Patient Identity Source Secured Node Patient Identity Feed Secured Node Query Documents Document Registry Document Consumer Secured Node Register Document Set Provide&Register Document Set Retrieve Document Secured Node Document Source Document Repository Secured Node Secured Node Sept 13-15, 2004 IHE Interoperability Worshop

Document Availability Management
Submitted Registration in progress Approved Available 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 Original Document Source and Patient (if allowed in Affinity Domain) Sept 13-15, 2004 IHE Interoperability Worshop

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 Time Document 1 (Approved) A two-way relationship between Original and Replacement Document. Replacement Document 1 (Deprecated) Replacement Document Registering an alternate form of a registered document Transform A two-way relationship between Original and Transform (alternative format with same scope). Document 1 (Approved) Document 2 (transform) Sept 13-15, 2004 IHE Interoperability Worshop

Re-Submission of Documents
Submission Set (Reqested) XDS allow re-submissions of same document with same unique ID. Impact on Document Consumer is to accept that there may be more than one registry entry returned by a query with the same unique doc Id, but with different metadata and belonging to different Submission Sets and Folders. Reference to existing Doc is preferred. New Doc C New Doc A Re-submission Detected Submission Set Doc B Doc A When Registry detects re-submission, it uses hash key to verify that document itself is the same. If hash key does not match submission is rejected. Repository may also detect that Document with same unique ID is already in Repository. If hash keys are different, Repository shall reject Submission Request. Repository may keep both old and new Documents. Sept 13-15, 2004 IHE Interoperability Worshop

ebXML Registry and XDS Registry
XDS Adapter Patient Id is known Vocabularies Checking Submission Set to approve if registration OK otherwise, roll-back registration Patient Identifier Source Patient Id Feed Document Registry ebXML Registry XDS Registry Adapter ebXML Registry Compliance: All transaction are valid ebXML registry transactions Sequencing may be simplified ebXML registry query against a valid but specialized Registry information model Query Document Register Document Set Document Repository Document Consumer Document Source Provide & Register Document Set Sept 13-15, 2004 IHE Interoperability Worshop

Conclusion: IHE Cross-Enterprise Document Sharing IHE XDS addresses one of the key integration problems in the realization of the EHR vision. IHE does not claim with XDS to address all aspects of a complete and interoperable EHR System. In collaboration with well established standards bodies (HL7, ASTM, CEN, OASIS, IETF, DICOM, etc.) and other EHR related initiatives world-wide (EuroREC, etc.), IHE expects to contribute at a more cost-effective and rapid deployment of community, regional and national health IT infrastructures. Sept 13-15, 2004 IHE Interoperability Worshop

How real is XDS ? Specification work since Nov 2003 Under Public Comments June-July 2004 Stable specification in IHE TF August 15th, 2004 IHE Connectathon January 2005 (USA) HIMSS announced : The IHE XDS Integration Profile is expected to be one of the major highlights of the 2005 Annual HIMSS Conference & Exhibition in Dallas, Tex., Feb , where it will be used as a foundation for an on-site technical demonstration of interoperability in support of a National Health Information Infrastructure (NHII). 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 Connectathon April 2005 (Europe) Sept 13-15, 2004 IHE Interoperability Worshop

More information…. Web sites: IHE IT Infrastructure Technical Framework for V 1.0 Final Text IHE IT Infrastructure Technical Framework Supplements for – Trial Implementation Issue resolutions at IHE forum, IT Infrastructure sub-forum. Non-Technical Brochures : IHE Brochure, IHE Fact Sheet IHE Connectathon Results IHE Products Integration Statements Sept 13-15, 2004 IHE Interoperability Worshop

Integrating the Healthcare Enterprise

Similar presentations

Presentation on theme: "Integrating the Healthcare Enterprise"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Integrating the Healthcare Enterprise

Similar presentations

Presentation on theme: "Integrating the Healthcare Enterprise"— Presentation transcript:

Similar presentations

About project

Feedback