Technical Framework Publication Process
General
The Technical Committee of each Domain is responsible for preparing documents (Technical Framework Volumes, Supplements, Change Proposals, white papers, etc).
They perform this work following an annual cycle of activities defined in advance by the Planning Committee of the domain and published on the domain’s Wiki page. This cycle shall include a series of specified teleconference, meeting and deadline dates for:
- Selection of committee work items (see Profile Proposal Process)
- Face-to-face meetings for development of Public Comment supplement drafts
- Publication of supplements for public comment
- Deadline for submission of public comments
- Face-to-face meeting for resolution of public comments and development of Trial Implementation supplement drafts
- Processing and balloting of Change Proposals
- Publication of updated Final Text Technical Framework documents
Prior to publishing this schedule, the co-chairs of the domain planning and technical committees shall communicate the draft schedule to the IHE Domain Coordination Committee and Technical Project Management staff, who are responsible for coordinating the scheduling of development activities across domains. Technical Project Management staff are responsible for publication of documents and will determine the detailed schedule of publication, which they will communicate to the co-chairs of all domain planning and technical committees.
Each document must have at least one designated author and two designated reviewers. Authors and reviewers must be active committee members subscribed to committee email distribution lists and must attend in person the committee’s face-to-face meetings to draft public comment versions of documents and resolve public comments. Review and approval by the full technical committee is required before each publication stage.
Public Comment
Supplement documents are published initially in a draft for public comment. The minimum public comment period is 30 days. A general invitation for public comment is issued on the initial date of publication. All comments received are to be reviewed, addressed and dispositioned by the committee. Details on the Public Comment Process are available here.
Trial Implementation
Once all public comments are addressed, supplement documents are published for trial implementation. Trial implementation documents are used for testing at Connectathons and other IHE testing and demonstration activities. Testing events are used to gather feedback and frequently result in changes to a published supplement. A supplement may remain in trial implementation status for a number of cycles and be republished in a number of revisions before being advanced to final text status.
Final Text
When a committee determines that a supplement has passed through a sufficient amount of successful Connectathon testing, all known issues have been addressed and both the supplement and its underlying standards are judged to be sufficiently stable, it should be advanced to Final Text status and incorporated into the domain's Technical Framework document. The process for reviewing a technical framework supplement to consider advancing it to Final Text is available here.
General Procedures
Documents will be scheduled for a needed for Publication date range by IHE Staff. Within that date range, documents are accepted on a First In/delivered First Out (FIFO) basis for editing and publishing by the IHE Publication Staff. If a Domain misses its assigned submission date, the document will go to the end of the publication queue. This could result in inadequate time for a Public Comment Period, missing the F2F comment review meeting, missing the Trial Implementation delivery date, and, subsequently will not be tested for a specific Connectathon.
The Secretariat for each Domain is responsible for delivering all documents to the documentation specialist. The documentation specialist is responsible for publishing them on the IHE website and announcing them to the IHE email distribution list.
Documents for publication are to be placed in the appropriate subfolder of the DocumentPublication folder on the ftp://ftp.ihe.net FTP server. Details on proper usage of those FTP folders are provided in the ReadMe document contained in that folder. Read that document before using the folders.
An inventory of published IHE documents can be found here.
Document File Naming
The file naming convention for IHE Technical Frameworks should be as follows:
- IHE_[Domain Abbreviation]_TF_[Rev. # "x.x"]_[Vol. # "n"]_[ISO formatted date]
- Example: IHE_ITI_TF_Rev7.0_Vol1_2010-08-10.pdf
The file naming convention for supplements should be as follows:
- IHE_[Domain Abbreviation]_Suppl_[Title Abbreviation]_[Rev. # "x.x"]_[Publication Status PC/TI/FT]_[ISO formatted date]
- Example: IHE_RAD_Suppl_BIR_Rev1.1_TI_2010-11-16.pdf
The file naming convention for white papers should be as follows:
- IHE_[Domain Abbreviation]_White-Paper_[Title]_[Rev. # "x.x"]_[ISO formatted date]
- Example: IHE_QRPH_White-Paper_Performance_Measure_Data_Element_Structured_for_EHR_Extraction_Rev1.0_2008-06-10.pdf
Named Destinations
Named destinations are generated from existing bookmarks and bookmarks are converted to use named destinations instead of direct page references. Named destinations enable you to set navigation paths across a collection of PDF documents. Linking to a destination is recommended when linking across documents, because unlike a link to a page, a link to a destination is not affected by the addition or deletion of pages within the target document. Named destinations can be also shared between multiple links or bookmarks within a document. For example, instead of using a direct link to page 10, a bookmark will point to the named destination "Chapter 1" . You will be able to link to this location using a human-readable name instead of a page number.
Once created, all named destinations are exported to a tab-delimited plain ASCII text file. Each named destination is exported on a separate text line and includes the following parameters: destination name, target page number and a complete description of the page view (zoom fit type, page rectangle and a zoom factor).
An example of a named destination file (only the first two parameters are required, as highlighted below):
- 15_2_Portable_Data_for_Imaging_ 10 {XYZ;-32768.000000;-32768.000000;423.000000;-32768.000000;0.000000}
- 15_3_1_Use_Cases 11 {XYZ;-32768.000000;-32768.000000;291.000000;-32768.000000;0.000000}
- 15_3_2_Process_Flow_Description 12 {XYZ;-32768.000000;-32768.000000;454.000000;-32768.000000;0.000000}
Using Named Destinations To Open PDF Documents
As previsouly mentioned, named destinations are very useful when it is necessary to open a PDF document at a specific page view. They can be used in HTML links, URL or in command-line syntax. Add #nameddest=destination directly after the PDF filename, where "destination" is the the named destination, found in the named destination text file, you want to jump to. This example uses "nameddest" parameter in URL
Named destinations are case-sensitive, upper and lower case must match the actual destination exactly. You can create links to specific locations within an IHE Technical Framework document by using
Some URL limitations:
- Only one digit following a decimal point is retained for float values.
- Individual parameters, together with their values (separated by & or #), can be no greater then 32 characters in length.
- You cannot use the reserved characters =, #, and &. There is no way to escape these special characters.
See Also
Writing Technical Frameworks and Supplements for details on structure, style and conventions when editing technical framework documents.