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. Overview • 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.

3. Agenda • Review of new entry types proposed in Cross-Community Dynamic Data White Paper • XDS/XCA Distinction • Use Cases • Detailed discussion of functional changes by transaction • Register • Query • Retrieve • Open Issues

4. Overview of entry types • Stable Document Entry • current XDS Document Entry element • contains metadata about an existing document available for retrieval • Deferred Creation Document Entry • proposed new for this supplement • Small extension to Stable Document Entry which allows deferral of creation of documents until time of retrieval • Dynamic Service Entry (White Paper name is Dynamic Entry) • Proposed new for this supplement • Allows access to a service which is able to, on demand, dynamically generated a particular type of document (e.g. summary) that contains most up-to-date information

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

6. Deferred Creation

8. Dynamic Service Entry

10. XDS and XCA • Choosing between implementing XDS vs. XCA • Choice of Repository vs. Responding Gateway • Push vs pull • Lazy vs proactive action by document owner

11. Use Cases – Dynamic Service • EMR wants to support summary for every patient it knows: • XDS: Becomes a “Document Service Provider” and pushes one entry for each patient. (note: a lot of overhead in requiring an entry per patient) • XCA: Becomes a Responding Gateway and responds to all queries with a single entry describing the service it will use to generate the specified patient’s summary – keeping a mapping between the patient identifier and the document unique ID Note: Wouldn’t it make more sense to have one service and pass the patient ID in as part of the retrieve? If patient ID is an argument of retrieve could it also have other arguments? Where should we draw the line.

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

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

14. Deferred Creation Transactions • Provide and Register Document Set-b • No update needed, Document Source does not participate in this type of content • Register Document Set-b • Add support for submitting DeferredCreation Document Entries • Address how to update the DeferredCreation Document Entries (i.e. when the actual document is created and the status changes from Deferred to Approved) • 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 Deferred is reflected in the response and which metadata attributes are handled differently for this different type. • Retrieve Document Set: • Update Expected Actions on Repository to require update of Deferred Document Entry to Stable. • Cross Gateway Query: • Adopt all changes from Registry Stored Query • Cross Gateway Retrieve • Adopt all changes from Retrieve Document Set

15. Dynamic Service Transactions • Provide and Register Document Set-b • No update needed, Document Source does not participate in this type of content • Register Document Set-b – add new transaction for registering Dynamic Services? • Define content of entry and how to withdraw and update entry • 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 Dynamic Service is reflected in the response and which metadata attributes are handled differently for this different type. • Retrieve Document Set – add new transaction for retrieving from a Dynamic Service? • Cross Gateway Query • Adopt all changes from Registry Stored Query • Cross Gateway Retrieve • Adopt all changes from Retrieve Document Set – or add the new transaction defined to retrieve dynamic service entries

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

17. Open Issues • Should a Service entry be patient specific? If it is not it becomes very much like an entry describing a QED Repository. • Consider new actors/transactions where it makes sense • Registering a service is a very different type of activity than registering a document set. Consider creating a new transaction that register’s a service. Also coming from a new actor. Advantage of this is a) Register update is addition of an optional transaction b) Makes registration of this unique type of entry independent from registering other kinds of entries which allows for independency of implementation. • Retrieve from a service is also very different type of activity than retrieving a stable or deferred document. Consider a different transaction. • One query should return all kinds of entries, depending on parameters • Is submission set useful when registering a service? Should a service entry be able to be included in a folder? Initial thoughts are that neither of these concepts are useful for a service. • Review list of metadata and determine which are valid for the new types of entries • Retrieve of service entry specifies repository unique id but does the doc that is returned have to have the same repository unique ID? • How to declare the capabilities… new options, required in XCA?

18. Backup

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

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

21. Overview of entry types • Stable Document Entry • current XDS Document Entry element • contains metadata about an existing document available for retrieval • Deferred Creation Document Entry • proposed new for this supplement • 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 (White Paper name is Dynamic 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