Difference between revisions of "Technical Framework Publication Process"
m (Updated "General Procdures" section to reflect current practice) |
(→Actors, Transactions and Glossary Terms: Gazelle to Gazelle Master Model (GMM)) |
||
(42 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
− | + | =General= | |
− | |||
The '''Technical Committee''' of each Domain is responsible for preparing documents (Technical Framework Volumes, Supplements, Change Proposals, white papers, etc). | 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: | 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) | + | * Selection of committee work items [https://wiki.ihe.net/index.php/Profile_Proposal_Process (see Profile Proposal Process)] |
− | * Face-to-face meetings for development of | + | * Face-to-face meetings for development of public comment supplement drafts |
− | * Publication of supplements for public comment | + | * Publication of new supplements for public comment |
* Deadline for submission of public comments | * Deadline for submission of public comments | ||
− | * Face-to-face meeting for resolution of public comments and development of | + | * 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 | + | * Processing and balloting of Change Proposals (CPs) |
− | * Publication of updated | + | * 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 | + | 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 [https://docs.google.com/spreadsheets/d/1vjX0lYn4xVEVynpoelvLRe_TzXD5KJ2EyDEQ6WIY0w0/edit#gid=1 publication schedule]. 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. | 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 | + | =Templates= |
+ | Supplement and Technical Framework documents must use the [[Official Templates]]. Feedback to improve the templates is welcome and can be provided [http://ihe.net/Templates_Public_Comments/ here.] | ||
+ | |||
+ | When profiling the [[:Category:FHIR]] standard, please also follow the [[Guidance on writing Profiles of FHIR]] | ||
+ | |||
+ | ''' IMPORTANT: When editing a current published document, please obtain the most recent version from the IHE Google Drive at https://drive.google.com/drive/u/0/folders/1qJVFWjhzb_5JgxSDGGE8j-l4FpERyhsG''' | ||
+ | |||
+ | =Actors, Transactions and Glossary Terms= | ||
+ | |||
+ | IHE actors and transactions are maintained via Gazelle Master Model (GMM) and IHE Glossary terms are maintained via the Standards Knowledge Management Tool (SKMT). Visit the following Wiki pages for additional information: | ||
+ | |||
+ | *See [https://wiki.ihe.net/index.php/Approval_Process_for_IHE_Actors,_Transactions_and_Glossary_Terms this wiki page] for instructions on gaining approval for new actors and transactions and glossary terms. | ||
+ | *See [https://wiki.ihe.net/index.php/Gazelle_Browsing this wiki page] for information on browsing GMM for existing actors and transactions. | ||
+ | *See [https://wiki.ihe.net/index.php/Standards_Knowledge_Management_Tool_(SKMT) this wiki page] for information on looking up existing glossary terms. | ||
+ | |||
+ | =Public Comment (PC)= | ||
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|Public Comment Process are available here]]. | 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|Public Comment Process are available here]]. | ||
− | + | =Trial Implementation (TI)= | |
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. | 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. | ||
− | + | At Trial Implementation step there must be a wiki [[Profiles]] page. There is a [[Profile Overview Template]] for this with instructions within. | |
− | 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 [http:// | + | |
+ | =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 [http://ihe.net/Technical_Frameworks/ Technical Framework] document. The process for reviewing a technical framework supplement to consider advancing it to Final Text [[Final Text Process| 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 the publication process for ''new'' supplements. The diagram contains some useful hyperlinks. | |
+ | [[File:IHENewSupplPubProcessThmb.png|none|link=|New supplement publication process]] | ||
− | + | [[Media:NewSupplPubProcess.pdf]] | |
− | |||
− | + | ===Publication Process - Updated Supplements (To be developed)=== | |
− | ==Document File Naming | + | |
+ | =General Procedures= | ||
+ | Documents will be scheduled for a '''needed for Publication''' date range by IHE Documentation Specialist. Within that date range, documents are accepted on a First In/delivered First Out (FIFO) basis for editing and publishing by the Documentation Specialist. 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 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 ''Committed Submitted'' subfolder of the ''Document Publication'' folder on the [https://drive.google.com/drive/folders/19Fmb0A0zq_NiOs1lAYr6lUunR5uGLOrY IHE Google Drive]. Details on proper usage of the Google Drive folders are provided at [[IHE Document Publication Google Drive Folder Structure]]. Please read this information before using the folders. | ||
+ | |||
+ | An inventory of published IHE documents can be found [https://docs.google.com/spreadsheets/d/1R5aw4hgezmyJpt8eRwk35S6ofu93YU9u03h4LdVOKzI/edit?authkey=CID59tIJ&hl=en&hl=en&authkey=CID59tIJ#gid=2 here]. | ||
+ | |||
+ | =Document File Naming= | ||
The are two file naming conventions for IHE Technical Framework volumes and trial implementation supplements: | 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/ | + | 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. |
Line 51: | Line 81: | ||
− | + | 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. | |
− | 2. | ||
The file naming convention for Technical Framework Volumes should be as follows: | The file naming convention for Technical Framework Volumes should be as follows: | ||
− | *IHE_[Domain Abbreviation]_TF_[Rev. # "x.x"]_[Vol. # "n"]_[ISO formatted date] | + | *IHE_[Domain Abbreviation]_TF_[Rev. # "x.x"]_[Vol. # "n"]_[TF][ISO formatted date] |
− | :For example: IHE_ITI_TF_Rev9. | + | :For example: IHE_ITI_TF_Rev9.0_Vol1_TF_2012-08-31.pdf |
The file naming convention for supplements should be as follows: | 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] | *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 | :For example: IHE_RAD_Suppl_BIR_Rev1.2_TI_2012-07-24.pdf | ||
The file naming convention for white papers should be as follows: | The file naming convention for white papers should be as follows: | ||
− | *IHE_[Domain Abbreviation] | + | *IHE_[Domain Abbreviation]_WP_[Title]_[Rev. # "x.x"]_[ISO formatted date] |
− | :For example: | + | :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. | 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. | ||
Line 79: | Line 110: | ||
===Where to Find the Named Destinations Text Files=== | ===Where to Find the Named Destinations Text Files=== | ||
− | The named destinations text files can be found on the IHE | + | The named destinations text files can be found on the IHE Google Drive in the same folder as their companion published PDF files [https://drive.google.com/drive/folders/1M3i4R8iyxqIe_hctkJCPIFtDlVF-kQsB here] with the following naming convention: |
::IHE_RAD_TF_Rev11.0_Vol3_FT_2012-07-24_named-dest.txt | ::IHE_RAD_TF_Rev11.0_Vol3_FT_2012-07-24_named-dest.txt | ||
Line 85: | Line 116: | ||
===Using Named Destinations to Open PDF Documents=== | ===Using Named Destinations to Open PDF Documents=== | ||
− | As | + | As previously 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 | ::sufffix to url: #nameddest= plus the name from the list | ||
Line 102: | Line 133: | ||
*You cannot use the reserved characters =, #, and &. There is no way to escape these special characters. | *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. | [[Writing Technical Frameworks and Supplements]] for details on structure, style and conventions when editing technical framework documents. |
Latest revision as of 08:57, 16 August 2024
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 publication schedule. 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.
Templates
Supplement and Technical Framework documents must use the Official Templates. Feedback to improve the templates is welcome and can be provided here.
When profiling the Category:FHIR standard, please also follow the Guidance on writing Profiles of FHIR
IMPORTANT: When editing a current published document, please obtain the most recent version from the IHE Google Drive at https://drive.google.com/drive/u/0/folders/1qJVFWjhzb_5JgxSDGGE8j-l4FpERyhsG
Actors, Transactions and Glossary Terms
IHE actors and transactions are maintained via Gazelle Master Model (GMM) and IHE Glossary terms are maintained via the Standards Knowledge Management Tool (SKMT). Visit the following Wiki pages for additional information:
- See this wiki page for instructions on gaining approval for new actors and transactions and glossary terms.
- See this wiki page for information on browsing GMM for existing actors and transactions.
- See this wiki page for information on looking up existing glossary terms.
Public Comment (PC)
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 (TI)
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.
At Trial Implementation step there must be a wiki Profiles page. There is a Profile Overview Template for this with instructions within.
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 the publication process for new supplements. The diagram contains some useful hyperlinks.
![New supplement publication process New supplement publication process](/uploads/e/e3/IHENewSupplPubProcessThmb.png)
Publication Process - Updated Supplements (To be developed)
General Procedures
Documents will be scheduled for a needed for Publication date range by IHE Documentation Specialist. Within that date range, documents are accepted on a First In/delivered First Out (FIFO) basis for editing and publishing by the Documentation Specialist. 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 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 Committed Submitted subfolder of the Document Publication folder on the IHE Google Drive. Details on proper usage of the Google Drive folders are provided at IHE Document Publication Google Drive Folder Structure. Please read this information 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 Google Drive in the same folder 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 previously 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:
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.