Dynamic/Deferred Document Sharing (D3S)

1. Dynamic/Deferred Document Sharing (D3S) Profile for 2010 presented to the IT Infrastructure Technical Committee Karen Witting February 1, 2010

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

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

4. Use Case - XDS An XDS Affinity Domain consists of a large healthcare organization (L) and several small physician offices (PO1 … POn). 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.

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

6. Community Architectural ModelsUse Case for XCA • Community Architectural Models identified: • 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 • Single Organization HIE – one or more tightly integrated databases and single EHR system which accesses data in the database as requested. • Distributed Source Databases – dynamic collection of data across distributed, independent databases. Collection of data happens in response to a specific request for content.

7. Single Organization EHR Stable Document Sharing Document Registry Gateway Conversion from DB results to Document based DB Repository Gateway Gateway Distributed Databases Repository Conversion from Web Display to Document based Web Portal DB DB DB DB

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

9. Current approach to XCA support in Database oriented HIE’s

10. Deferred Creation

11. Dynamic Service Entry

12. Proposed Standards & Systems • 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.

13. XDS.b Transactions Modified • Provide and Register Document Set-b • No update needed, Document Source does not participate in this type of content • Register Document Set-b • DeferredCreation Document Entries • Define how to submit and update when the actual document has been created – uses XDS Metadata Update profile to enable this function • Dynamic Service Entries • Define how to submit and remove (withdrawal of a service) • 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

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

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

16. D3S Supplement • Supplement to the XDS.b profile adding options, same as async supplement is written • Also, supplement to XCA profile adding options (or required? Required would mean XCA could not go final text this year) • If above is agreed, supplement updates: • Vol. 1 XDS.b and XCA sections • Vol. 2 Each of the transactions would include text describing the optional behavior (XCA transactions would inherit from XDS.b transactions so would probably have little additional text)

17. Next Steps • Vol. 1 updates to XDS.b and XCA sections • Vol. 2 technical details