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 new 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 (for new supplements)
• Processing and balloting of Change Proposals (CPs)
• Publication of updated trial implementation supplements (based on balloted CPs)
• Publication of updated final text Technical Framework Volumes (based on balloted CPs)

Prior to publishing this information on the domain Wiki page, the co-chairs of the domain planning and technical committees shall communicate the draft schedule to the IHE Domain Coordination Committee and IHE Documentation Specialist, who are responsible for coordinating the scheduling of development activities across all domains. The IHE Documentation Specialist is responsible for the publication of documents and will determine the final detailed schedule of publication. Upon completion, the Documentation Specialist will communicate the schedule to 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.

When editing a current published document, please obtain the most recent version from the ftp site at ftp://ftp.ihe.net/DocumentPublication/CurrentPublished/

Templates

Supplement and Technical Framework documents must use the Official Templates. Feedback to improve the templates is welcome.

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.

Publication Process Workflow Diagrams

Publication Process - New Supplements

Click on the link directly below the image below for a flow diagram of Publication Process for new supplements

Media:NewSupplPubProcess.pdf

General Procedures

Documents will be scheduled for a needed for Publication date range by IHE Publication 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 IHE Documentation Specialist. The Documentation Specialist is responsible for publishing the documents on the IHE website and announcing them to the IHE email distribution list.

Documents ready for publication are to be placed in the appropriate CommittedSubmitted subfolder of the DocumentPublication folder on the IHE FTP Server. Details on proper usage of the FTP folders are provided in the ReadMe document contained in the DocumentPublication folder. Please read this document before using the folders.

An inventory of published IHE documents can be found here.

Document File Naming

The are two file naming conventions for IHE Technical Framework volumes and trial implementation supplements:

1. File names for documents published on http://www.ihe.net/Technical_Frameworks/ (as of July 2012) are generic in nature. This naming convention accommodates direct linking to specific locations within the document via named destinations (for Technical Framework Volumes) and links to current published documents can be maintained as future revisions of the documents are published.

The file naming convention for Technical Framework volumes should be as follows:

• IHE_[Domain Abbreviation]_TF_[Vol. # "n"]

For example: IHE_PCC_TF_Vol1

The file naming convention for trial implementation Technical Framework supplements should be as follows:

• IHE_[Domain Abbreviation]_Suppl_[Title Abbreviation]

For example: IHE_PCC_Suppl_RCK

2. File names for documents published on http://ihe.net/Public_Comment/ and http://ihe.net/Technical_Framework_Archives/ are specific to a document's revision number, status (public comment [PC], trial implementation [TI] or final text [FT]) and date of publication.

The file naming convention for Technical Framework Volumes should be as follows:

• IHE_[Domain Abbreviation]_TF_[Rev. # "x.x"]_[Vol. # "n"]_[TF][ISO formatted date]

For example: IHE_ITI_TF_Rev9.0_Vol1_TF_2012-08-31.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]

For example: IHE_RAD_Suppl_BIR_Rev1.2_TI_2012-07-24.pdf

The file naming convention for white papers should be as follows:

• IHE_[Domain Abbreviation]_WP_[Title]_[Rev. # "x.x"]_[ISO formatted date]

For example: IHE_PCD_WP_MEM_Cyber_Security_Rev2.0_2011-05-27.pdf

Named Destinations

Note: As of June 2016, named destinations are created for Technical Framework Volumes only (not for Trial Implementation Supplements)

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 in bold 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}

Where to Find the Named Destinations Text Files

The named destinations text files can be found on the IHE ftp site in the same directory as their companion published PDF files here with the following naming convention:

IHE_RAD_TF_Rev11.0_Vol3_FT_2012-07-24_named-dest.txt

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. You can create links to specific locations within an IHE Technical Framework document by using

sufffix to url: #nameddest= plus the name from the list

as shown in this example:

http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_Vol2a.pdf#nameddest=3_10_4_1_1_Trigger_Events

Named destinations are case-sensitive, upper and lower case must match the actual destination exactly.

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.

Process

Domain Coordination Committee