ITI On-Demand Documents

From IHE Wiki
Revision as of 07:52, 31 August 2010 by Witting (talk | contribs) (→‎Trial Implementation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

History

Working directory is ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr8-2010-2011/Technical_Cmte/Profile_Work/D3S/


Trial Implementation


Dynamic Approval draft July 16 -- approved for Trial Implementation with editorial updates

Closed Issues from Public Comment

The Closed Issues section released for Public Comment has been moved here because the concepts presented in the supplemenet have changed names several times and many of the Closed Issues will not make sense without the historical understanding of the concept names. They are saved here for future reference.

  • D3S001: Should a Service entry be patient specific? If it is not it becomes very much like an entry describing a QED Repository. Resolved: yes a service entry should be patient specific.
  • D3S002: Consider new actors/transactions where it makes sense. Resolved: The following choices are used:
    • Registering a service is a very different type of activity than registering a document set. Consider creating a new transaction that registers 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. Would impact a Consumer who will have a new transaction to support. Not sure if this is good or bad, as Consumer will need to know about new content for dynamic.
    • One query should return all kinds of entries, depending on parameters
  • D3S003: 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 is useful for a service. Resolved: Use of a submission set is important because of consistency, so will be included in the Register of service entry. Because use of folders is emerging we should allow service entries to be part of a Folder. Discussion of potential “automatic” association to a Folder by documents created as a result of retrieve from a service. Agreed to scope that out until the requirement is well understood. Discussion did identify that a new association is needed to be used between a stable document entry that was created as a result of a retrieve from a service entry.
  • D3S004: Review list of metadata and determine which are valid for the new types of entries. Review how the new types of entries will affect query requests and responses. Resolved: All metadata was reviewed and most are found to be unchanged in terms of use by the new entry types. The following list of ‘different’ metadata identifies where things should be different.
    • creationTime – standard use for deferred since it is frozen content it is just not in the right format yet, so creation time should reflect the time that the content was frozen. This means that when deferred becomes approved this does not cause an update to creationTime. Not allowed for dynamic i.e. not applicable
    • Hash – not allowed to be specified for either i.e. not applicable
    • legalAuthenticator on a dynamic service entry this field does not make sense but we won’t particularly restrict this. On deferred it is used the standard way.
    • repositoryUniqueId – needs to be clarified how this works for deferred and dynamic since this does not point to the place where the document exists but is needed to retrieve the document and cause its creation. Update the description and add pointer to the section which describes in more detail.
    • Service start – deferred same as base. For dynamic describes when the service was first made available.
    • Service stop time – deferred same as base. For dynamic service it could reflect the time at which there will be no new content available through the service. If it takes this meaning it would become optional, as in the most common situation it will not be known. New Issue D3S007 created to continue the discussion of this.
    • Size - not allowed to be specified for either i.e. not applicable
    • uniqueId – needs update of definition to reflect our new use of this attribute for dynamic service. No difference for deferred.
  • D3S005: Retrieve of service entry specifies repository unique id but does the doc that is returned have to have the same repository unique ID? Resolved: No, need to include “new” repositoryUniqueID in retrieve response to allow for identification of potentially new repository. Always specified even if identical.
  • D3S006: Should we allow Document Service Providers who do not register new entries when a retrieve of a service causes a document to be created? Resolved: Declare an option on the Document Service Provider Actor which states that this actor will save for later retrieval all documents that are created as a result of invocation of the service. Include in the description of the option that it is a policy decision whether documents are registered at time of retrieval. New option goes on both service provider and responding gateway.
  • D3S007: Use of ServiceStopTime for dynamic service: it could reflect the time at which there will be no new content available through the service. If it takes this meaning it would become optional, as in the most common situation it will not be known. Resolved: ServiceStopTime would not have this meaning. The intent of this attribute is the time of the service of healthcare event, not the electronic service supporting content about the event. For dynamic content by definition the healthcare service is continuing so there would not be expected to be a stop time. So defined ServiceStopTime as N/A for dynamic service. Note: After this resolution the decision was reconsidered and it was decided to allow these attributes but expect they will often be unspecified.
  • D3S008: How should the Document Registry know that a document entry is deferred rather than a stable entry? Options considered a) lack of hash/size in the entry b) similar approach to metadata update to use a flag on an association in the submission. c) could use a new object type. Resolved: choose option b) registry will understand the association flag, set status to deferred creation and save the association and the flag.
  • D3S009: Should Registration allow for multiple dynamic service entries in one registration? Suggested answer is yes, allow multiple. Resolved: Yes
  • D3S010: Decide correct terms for new concepts introduced. Resolution:
    • Stable Document Entry
    • Deferred Creation Document Entry becomes Deferred Document Entry,
    • Dynamic Service Entry becomes Dynamic Document Entry
    • Document Service Provider becomes Dynamic Document Source
    • Register Document Service Entry becomes Register Dynamic Document Entry,
    • Retrievable Entry Types becomes Retrievable Document Entry Types
  • D3S011: How would support of a Dynamic Entry be withdrawn? Replacement or Update could be used to update the metadata, but what if support is withdrawn because no new data will be generated or the service is being shutdown. Initial suggestion of using Deprecated does not work since Deprecated entries can still be retrieved. Instead use Deleted status for this. Note that Deleted status means that the metadata is no longer available through any query (might be available through an administrative function but would be an implementation decision). Resolution: After further discussion we agreed that use of Deprecated was consistent with the concept of withdrawn, as it indicates that the content is no longer current. Agreed to use Deprecate as a way of communicating that a Dynamic Document is no longer supported. Discussed whether a Deprecated Dynamic Document should be retrievable. Agreed that it didn’t make sense but didn’t agree on exact language in terms of requirements on the actors. Recommend to use Deprecate and state that a Dynamic Document Entry which is Deprecated will likely to get an error if an attempt is made to retrieve from it. May return non current data or give an error. If the actor has been told that it will not receive any new data for the patient it shall return an error.
  • D3S013: Is it true that actors specifying the “Document Re-retrieval Support” option shall save ALL created documents? Maybe the option should mean that they are just capable of saving and may use a policy to decide whether to save or not. Resolved: Not declaring the option means that you may save based on policy, declaring option means you shall save all.
  • D3S014: If the Integrated Document Source/Repository DOES support the Deferred Support Option and sends a Register transaction to a Document Registry which does not support the Deferred/Dynamic Support Option then what will happen? Possibilities: a) The Document Registry does not recognize the flag on the association indicating Deferred and returns an error, b) the document Registry ignores the flag on the association and the entry is not created. Resolution: Realized that what will happen is that the Document Registry will reject the Deferred Creation Entry because hash and size are missing. The new association flag will be ignored but the entry will not be created because it is against the rules of the current XDS specification. This does require the Integrated Document Source/Repository to detect this error and take appropriate action. See also section 3.42.4.2.3.1.
  • D3S015: Document Re-retrieval Support – rename this option and how should it be formulated? Resolution: Agreed on “Persistence of dynamically generated content” as the name. Considered the following names: Document retrieval Support, Dynamic Document persistence, Retrievable Document, Stable Document Return, Persisted Dynamic Instatiations, Persisted dynamic Content, Dynamic Document Snapshot Persistence, Dynamic Snapshot Persistence, Dynamic Document Source, Stabilization of Dynamic Document Retrieval. Agreed that this option would be declared when the Actor would save all dynamically generated content for retrieval via XDS/XCA transactions.

The Cross-Community Dynamic Data White Paper contains a number of additional issues that will further clarify the context of this work. Please refer to http://www.ihe.net/Technical_Framework/upload/IHE_ITI_WhitePaper_XC_Dynamic_Data_2009-09-28.pdf for that context.

Public Comment

Profile Supplement Drafts


Detailed proposal

Dynamic/Deferred Document Sharing detailed proposal

Notes

Return to ITI Technical Committee

Retrieved from "http://wiki.ihe.net/index.php?title=ITI_On-Demand_Documents&oldid=44349"