ITI Implementation Guide
Who Maintains this Guide - This guide is maintained by domain experts within the IT Infrastructure Technical Committee.
Relationship to IT Infrastructure Technical Framework - This guide documents Informative-level knowledge regarding ITI Profiles. It is frequently the case that international standards are a little hard to read and interpret. The same can be said for IHE Profiles. This guide is intended to hold secondary documentation to assist the developer. Frequently this means more detailed examples of key concepts. Other times is can be used to explain or point to definitions of key concepts. Many topics in this guide will be tutorial in nature organizing background material.
The Technical Framework always takes precedent over this guide. If conflicts are found between this guide and the Technical Framework please document the descrepency on the IT Infrastructe Technical Committee mailing list or any of the more specific mailing lists. XDS Implementers mailing list is an example of a more specific mailing list.
Purpose - This guide offers background and implementation guidance to implementers of the IT Infrastructure Technical Framework. It will, over time, replace other web sites and wikis designated as support sites.
The IT Infrastructure Technical Framework and its Supplements can be found here.
This committee also maintains an FTP site holding implementation materials such as Schemas and WSDLs. It can be found at here.
See Also
Profiles
General XDS - Common issues and elements to all variants of Cross Enterprise Document Sharing - includes material relevant to XDS.a, XDS.b, XDM, XDR, XCA
XDS.b - Revised Cross Enterprise Document Sharing profile based on ebXML Registry version 3.0 and updated web service
XDS.a - (Retired) Original Cross Enterprise Document Sharing profile based on ebXML Registry version 2.1
ATNA - ATNA FAQ
Metadata Update - This supplement is being developed to replace the Metadata Versioning White Paper
Metadata Versioning White Paper - Examples supporting the Metadata Versioning White Paper
Stored Query - Registry Stored Query Transaction for XDS Profile
XCA - Cross Community Access profile which focuses on document sharing between XDS environments or between XDS and non-XDS environments
XDM - Cross Enterprise Document Media Interchange - for the exchange of XDS documents and metadata between systems via media (CD etc.) or email attachment
XDR - Cross Enterprise Document Reliable Interchange
BPPC - Basic Patient Privacy Concents profile provides a mechanism to record the patient privacy consent(s), a method to mark documents published to XDS with the patient privacy consent that was used to authorize the publication, and a method for XDS Consumers to use to enforce the privacy consent appropriate to the use.
PIX - Patient Identifier Cross-referencing
PDQ - Patient Demographics Query
RFD - Retrieve Form for Data Capture
XUA - Cross-Enterprise User Assertion
Merge - Cross-Enterprise Document Sharing (XDS) Patient Identity Merge
DSG - Document Digital Signature
NAV - Notification of Document Availability
MU - Metadata Update
Instructions on updating the Implementers Guide
The following rules should be applied to the maintanance to this Implementer Guide.
As time passes, different parts of this guide are more/less current than others. This morning I had to add an entry to the ATNA page. I noticed a very nice note at the top
NOTE: This FAQ was last updated for the 2005-2006 Connectathon.
Since I just update the page by adding a new section, this comment is no longer valid.
As a result, I suggest we handle update comments as follows. First, a wiki page is organized by its headers. Usually the top level sections are labeled with two equals signs:
== My top level section ==
and more detail structure is created by using
=== More Detail ===
and even more detail
==== Additional Detail ====
headers.
The Implementers Guide is essentially a collection of rather independent articles organized on pages of similar content. I would like to define an independent article as a section labeled with a two equals (== My Article ==) header. Given this structure, the following rules are proposed.
1) Every independent article (defined by == My Topic ==) have a time stamp just under the header. My example from the ATNA page is:
== Too many certificates problem with Windows clients == Jan 7, 2009 We have had problems ...
2) Later when an article is updated (fixed, new information) we add a "Last Updated" message. Example is
== Too many certificates problem with Windows clients == Jan 7, 2009 Last Updated: Jan 11, 2009 We have had problems ...
3) Secondary entries (titles with more than 2 = signs -
=== Three ===
and
==== Four ====
are examples) do not carry time stamps. This
is content within an article.
This way a reader can determine the up-to-date-ness of an article.