Dynamic Document Sharing Detailed Profile Proposal for 2010 presented to the IT Infrastructure Technical Committee Karen Witting November 10, 2009

IT Infrastructure Planning Committee The Problem Sharing dynamically compiled health information within and across communities Improves upon XCA and XDS.b to support dynamically compiled content in addition to source attested, static content. Problem Scope discussed in detail in the “Cross- Community Dynamic Data” White Paper. Technical Extension to existing profiles

IT Infrastructure Planning Committee Use Case General Use Case – –In certain cases, there is a need for a document to be created as result of a specific request, e.g. provide patient data snapshot. – –In other cases, health care data is not organized as a collection of documents, and documents are created only for the purposes of sharing of data. It will be beneficial to allow for “announcing” the general availability of such documents, but only create them when they are actually requested. Extension to XDS.b and XCA – –Currently, the XDS.b and XCA profiles describe the sharing of documents after they have been created as a consequence of healthcare activity. This proposal adds the capability of creating documents when necessary to share data.

IT Infrastructure Planning Committee Use Case - XDS An XDS Affinity Domain consists of a large healthcare organization (L) and several small physician offices (PO 1 … PO n ). Organization L has an integrated Document Source/Document Repository. Only a relatively small percentage of patients in the Affinity Domain are seen at both L and any one of the physician offices, so L only registers deferred/dynamic documents in the Affinity Domain registry. When a Retrieve Document Set transaction is received at the integrated Document Source/Document Repository, the document is generated and returned as a result of the request.

IT Infrastructure Planning Committee Use Case - XCA In an XCA environment, a large healthcare organization participates as a community of its own. Many of the patients who are admitted in any one of the organization’s hospitals receive some of their healthcare in other communities, so there is a need to provide relevant information to healthcare providers in other communities. When a request for documents for a particular patient is received, the response is currently supposed to contain a list of matching documents, including the size and hash of each document. In many cases only a small subset of these documents are ever retrieved. In particular, non-recent discharge summaries may rarely be requested. This proposal allows the healthcare organization to indicate the availability of the matching documents for the particular patient, without actually creating the document until it is requested.

IT Infrastructure Planning Committee Community Architectural Models Use Case for XCA Community Architectural Models identified: A. A.Sharing of Stable, Source Attested Documents – XDS and similar models of sharing. Documents created as a by-product of patient care and shared when requested B. B.Single Organization HIE – one or more tightly integrated databases and single EHR system which accesses data in the database as requested. C. C.Distributed Source Databases – dynamic collection of data across distributed, independent databases. Collection of data happens in response to a specific request for content.

IT Infrastructure Planning Committee Gateway Single Organization Document Registry Repository Gateway Repository Stable Document Sharing Distributed Databases Gateway DB EHR Conversion from DB results to Document based DB Web Portal Conversion from Web Display to Document based

IT Infrastructure Planning Committee Overview of new entry types Support for exchange of two new types of entries: Deferred Creation Document Entry – –Allows deferral of creation of documents until time of retrieval – –Small extension to current use of Document Entry and its relationship to a document – –Requires Document Metadata Update for implementation within an XDS Affinity Domain Dynamic Service Entry – –Allows access to a service which is able to, on demand, dynamically generated a summary document that contains most up-to-date information – –Provides a new model for accessing data – dynamic aggregation of healthcare content XDS/XCA assumption is the aggregation and consolidation is done on the receiving side, Document Consumer. The “raw” data is sent from the responder and receiver does any consolidation and aggregation needed. This model supports aggregation at the responding side, Responding Gateway. – –Current approach uses slightly modified retrieve transaction to access content from service. Another alternative is to have the “service” be accessed through QED or another appropriate standard

IT Infrastructure Planning Committee Current approach to XCA support in Database oriented HIE’s

IT Infrastructure Planning Committee Deferred Creation

IT Infrastructure Planning Committee Dynamic Service Entry

IT Infrastructure Planning Committee Proposed Standards & Systems The Cross-Community Dynamic Data White Paper considers the following standards:The Cross-Community Dynamic Data White Paper considers the following standards: –IHE Query for Existing Data (QED): underlying standard is HL7 V3 –Expansion of Cross Gateway Query (ITI-38): underlying standard is ebRS The white paper recommends expansion of the XCA Cross Gateway Query (ITI-38) and explains the rationale for this approach.The white paper recommends expansion of the XCA Cross Gateway Query (ITI-38) and explains the rationale for this approach.

IT Infrastructure Planning Committee XDS.b Transactions Modified Register Document Set-b – –Define how to submit DeferredCreation Document Entries Dynamic Service Entries – –Define how to update DeferredCreation Entries when the document has been created – uses XDS Metadata Update profile to enable this function. Registry Stored Query: – –Define how to select which combination of types of entries to return: Stable Document Entries (current function) DeferredCreation Document Entries Dynamic Service Entries – –Define how each of the new types of entries is reflected in the response and how the receiver can interact with these new entry types. Retrieve Document Set: – –Define the unique characteristics of retrieval of a DeferredCreation Document Entry (i.e. transition to Stable Document Entry) – –Define use of Retrieve Document Set to access a Dynamic Service defined by a Dynamic Service Entry

IT Infrastructure Planning Committee XDS.b Profile Actor Options XDS.b Document Consumer: option(s) to accept in response to Registry Stored Query: – –DeferredCreation Document Entry – –Dynamic Service Entry XDS.b Document Registry: option(s) to accept in a submission and return in a query: – –DeferredCreation Document Entry – –Dynamic Service Entry XDS.b Integrated Document Repository/Document Source: option(s) to be able to submit and support retrieval of: – –DeferredCreation Document Entry – –Dynamic Service Entries

IT Infrastructure Planning Committee XCA Transactions Modified and Actor Options Cross Gateway Query: – –Adopts the request for and response of DeferredCreation Document Entries and Dynamic Service Entries as defined in Registry Stored Query. Cross Gateway Retrieve: – –Adopts the ability to retrieve DeferredCreation Document Entries and Dynamic Service Entries as defined by Retrieve Document Set. XCA Initiating Gateway: option(s) to accept in response to Cross Gateway Query and specify in Registry Stored Query: – –DeferredCreation Document Entry – –Dynamic Service Entry XCA Responding Gateway: option(s) to return in a query: – –DeferredCreation Document Entry – –Dynamic Service Entry

IT Infrastructure Planning Committee Effort Estimate Pages: Complexity of Issues: Low Effort Estimate: Small to Medium