dynamic document sharing detailed profile proposal for 2010 presented to the it infrastructure...

Dynamic Document SharingDynamic Document Sharing

Detailed Profile Proposal for 2010Detailed Profile Proposal for 2010presented to thepresented to the

IT Infrastructure Technical CommitteeIT Infrastructure Technical Committee

Karen WittingKaren WittingNovember 10, 2009November 10, 2009

IT Infrastructure Planning CommitteeIT 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


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.


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.


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.


Community Architectural ModelsUse Case for XCA

• Community Architectural Models identified: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. Single Organization HIE – one or more tightly integrated databases and single EHR system which accesses data in the database as requested.

C. Distributed Source Databases – dynamic collection of data across distributed, independent databases. Collection of data happens in response to a specific request for content.


Gateway

Single Organization

Document Registry

Repository

GatewayRepository

Stable Document Sharing

Distributed Databases

Gateway

DB

EHR

Conversion from DB results to Document

based

DB DB DB

DB

Web PortalConversion from Web Display to Document

based


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


Current approach to XCA support in Database oriented HIE’s


Deferred Creation


Dynamic Service Entry


Proposed Standards & Systems

• The Cross-Community Dynamic Data White Paper The Cross-Community Dynamic Data White Paper considers the following standards:considers the following standards:– IHE Query for Existing Data (QED): underlying standard is HL7 V3IHE Query for Existing Data (QED): underlying standard is HL7 V3– Expansion of Cross Gateway Query (ITI-38): underlying standard is Expansion of Cross Gateway Query (ITI-38): underlying standard is

ebRSebRS

• The white paper recommends expansion of the XCA Cross The white paper recommends expansion of the XCA Cross Gateway Query (ITI-38) and explains the rationale for this Gateway Query (ITI-38) and explains the rationale for this approach.approach.


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


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


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


Effort Estimate

• Pages: 40-50• Complexity of Issues: Low• Effort Estimate: Small to Medium