Difference between revisions of "Official Templates"

From IHE Wiki
Jump to navigation Jump to search
 
(62 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
{{TOCright}}
 +
 
IHE International manages a set of document templates.  These help authors make sure they have addressed the necessary material, and help readers/users by promoting consistency in how the information is organized and expressed.
 
IHE International manages a set of document templates.  These help authors make sure they have addressed the necessary material, and help readers/users by promoting consistency in how the information is organized and expressed.
 
==IHE Technical Framework Templates==
 
==IHE Technical Framework Templates==
 
===IHE Technical Framework Volume Templates===
 
===IHE Technical Framework Volume Templates===
* [ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/Technical_Framework_Volume_Templates/ Volume 1: Profiles - Word]
+
* [https://drive.google.com/drive/u/0/folders/13jyh22oXwgfD-plpZhSVpCatHSoFqqFu Volume 1: Profiles - Word]
* [ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/Technical_Framework_Volume_Templates/ Volume 2: Transactions - Word]
+
* [https://drive.google.com/drive/u/0/folders/13jyh22oXwgfD-plpZhSVpCatHSoFqqFu Volume 2: Transactions - Word]
* [ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/Technical_Framework_Volume_Templates/ Volume 3: Content Definitions - Word]
+
* [https://drive.google.com/drive/u/0/folders/13jyh22oXwgfD-plpZhSVpCatHSoFqqFu Volume 3: Content Definitions - Word]
* [ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/Technical_Framework_Volume_Templates/ Volume 4: National Extensions- Word]
+
* [https://drive.google.com/drive/u/0/folders/13jyh22oXwgfD-plpZhSVpCatHSoFqqFu Volume 4: National Extensions- Word]
  
 
===IHE Technical Framework Supplement Template===
 
===IHE Technical Framework Supplement Template===
* [ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/Technical_Framework_Supplement_Template/ Supplement Template - Word]
+
* [https://drive.google.com/drive/u/0/folders/13nsG6u3V--lQgCXCZlt0M73-oRgSXE9q Supplement Template - Word]
 +
* [https://github.com/IHE/supplement-template Implementation Guide (IG) Publisher IHE-Supplement template]
  
===IHE Whitepaper Template===
+
===IHE White Paper Template===
* [ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/White_Paper_Template/ Whitepaper Template - Word]
+
* [https://drive.google.com/drive/u/0/folders/13jq16RmmJQJPgSYNhOWcaaBa_smgwnjs White Paper Template - Word]
 +
* Alternatively, white papers can be authored in Markdown on GitHub and published in HTML
  
 
==General Introduction and Shared Appendices==
 
==General Introduction and Shared Appendices==
The documents contained at http://ihe.net/Technical_Frameworks/#GenIntro are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate. These documents will be updated on an annual (or as needed) basis.
+
The documents contained at https://profiles.ihe.net/GeneralIntro/ are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate. These documents will be updated on an annual (or as needed) basis.
 
===General Introduction===
 
===General Introduction===
===Appendix A: Actors===
+
The IHE Technical Frameworks General Introduction is located [https://profiles.ihe.net/GeneralIntro/ here].
===Appendix B: Transactions===
 
This section is in DRAFT state. Content presented is for feasibility testing only at this point.
 
 
{| class="wikitable mw-collapsible autocollapse sortable"
 
|-
 
! Transaction Domain !! Trans # !! Transaction Name !! Transaction Description !! Status
 
|-
 
| ARTI || 1 || Basic Static Beam Storage || In the Basic Static Beam Storage transaction, a Static Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static, non-MLC treatment beams. || Trial Implementation
 
|-
 
| ARTI || 2 || Basic Static Beam Retrieval || In the Basic Static Beam Retrieval transaction, a Static Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static, non-MLC treatment beams. || Trial Implementation
 
|-
 
| ARTI || 3 || Basic Static MLC Beam Storage || In the Basic Static MLC Beam Storage transaction, a Static MLC Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static, MLC treatment beams. || Trial Implementation
 
|-
 
| ARTI || 4 || Basic Static MLC Beam Retrieval || In the Basic Static MLC Beam Retrieval transaction, a Static MLC Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static, MLC treatment beams. || Trial Implementation
 
|-
 
| ARTI || 5 || Arc Beam Storage || In the Arc Beam Storage transaction, an Arc Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only non-MLC arc treatment beams. || Trial Implementation
 
|-
 
| ARTI || 6 || Arc Beam Retrieval || In the Arc Beam Retrieval transaction, an Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only non-MLC arc treatment beams. || Trial Implementation
 
|-
 
| ARTI || 7 || MLC Arc Beam Storage || In the MLC Arc Beam Storage transaction, an MLC Arc Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only MLC arc treatment beams. || Trial Implementation
 
|-
 
| ARTI || 8 || MLC Arc Beam Retrieval || In the MLC Arc Beam Retrieval transaction, an MLC Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only MLC arc treatment beams. || Trial Implementation
 
|-
 
| ARTI || 9 || Conformal Arc Beam Storage || In the Conformal Arc Beam Storage transaction, a Conformal Arc Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only conformal arc treatment beams. || Trial Implementation
 
|-
 
| ARTI || 10 || Conformal Arc Beam Retrieval || In the Conformal Arc Beam Retrieval transaction, an Conformal Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only conformal arc treatment beams. || Trial Implementation
 
|-
 
| ARTI || 11 || Hard Wedge Beam Storage || In the Hard Wedge Beam Storage transaction, a Hard Wedge Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static treatment beams using physical wedges. || Trial Implementation
 
|-
 
| ARTI || 12 || Hard Wedge Beam Retrieval || In the Hard Wedge Beam Retrieval transaction, a Hard Wedge Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static treatment beams using physical wedges. || Trial Implementation
 
|-
 
| ARTI || 13 || Virtual Wedge Beam Storage || In the Virtual Wedge Beam Storage transaction, a Virtual Wedge Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static treatment beams using virtual wedges. || Trial Implementation
 
|-
 
| ARTI || 14 || Virtual Wedge Beam Retrieval || In the Virtual Wedge Beam Retrieval transaction, a Virtual Wedge Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static treatment beams using virtual wedges. || Trial Implementation
 
|-
 
| ARTI || 15 || Motorized Wedge Beam Storage || In the Motorized Wedge Beam Storage transaction, a Motorized Wedge Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static treatment beams using motorized wedges. || Trial Implementation
 
|-
 
| ARTI || 16 || Motorized Wedge Beam Retrieval || In the Motorized Wedge Beam Retrieval transaction, a Motorized Wedge Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static treatment beams using motorized wedges. || Trial Implementation
 
|-
 
| ARTI || 17 || Static Electron Beam Storage || In the Static Electron Beam Storage transaction, a Static Electron Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static electron treatment beams. || Trial Implementation
 
|-
 
| ARTI || 18 || Static Electron Beam Retrieval || In the Static Electron Beam Retrieval transaction, a Static Electron Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static electron treatment beams. || Trial Implementation
 
|-
 
| ARTI || 19 || Step & Shoot Beam Storage || In the Step & Shoot Beam Storage transaction, a Step & Shoot Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only step & shoot IMRT treatment beams. || Trial Implementation
 
|-
 
| ARTI || 20 || Step & Shoot Beam Retrieval || In the Step & Shoot Beam Retrieval transaction, a Step & Shoot Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only step & shoot IMRT treatment beams. || Trial Implementation
 
|-
 
| ARTI || 21 || Sliding Window Beam Storage || In the Sliding Window Beam Storage transaction, a Sliding Window Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only sliding window IMRT treatment beams. || Trial Implementation
 
|-
 
| ARTI || 22 || Sliding Window Beam Retrieval || In the Sliding Window Beam Retrieval transaction, a Sliding Window Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only sliding window IMRT treatment beams. || Trial Implementation
 
|-
 
| ARTI || 23 || IMAT/VMAT Beam Storage || In the IMAT/VMAT Beam Storage transaction, a IMAT/VMAT Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only IMAT/VMAT IMRT treatment beams. || Trial Implementation
 
|-
 
| ARTI || 24 || IMAT/VMAT Beam Retrieval || In the IMAT/VMAT Beam Retrieval transaction, a IMAT/VMAT Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only IMAT/VMAT IMRT treatment beams. || Trial Implementation
 
|-
 
| ARTI || 25 || Stereotactic Beam Storage || In the Stereotactic Beam Storage transaction, a Stereotactic Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static stereotactic treatment beams. || Trial Implementation
 
|-
 
| ARTI || 26 || Stereotactic Beam Retrieval || In the Stereotactic Beam Retrieval transaction, a Stereotactic Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static stereotactic treatment beams. || Trial Implementation
 
|-
 
| ARTI || 27 || Stereotactic Arc Beam Storage || In the Stereotactic Arc Beam Storage transaction, a Stereotactic Arc Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only stereotactic arc treatment beams. || Trial Implementation
 
|-
 
| ARTI || 28 || Stereotactic Arc Beam Retrieval || In the Stereotactic Arc Beam Retrieval transaction, a Stereotactic Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only stereotactic arc treatment beams. || Trial Implementation
 
|-
 
| CARD || 1 || Modality Procedure Step In Progress  || An Acquisition Modality notifies the Performed Procedure Step Manager of the start of a new Procedure Step and the PPS Manager informs the Department System Scheduler/Order Filler and Image Manager. [CARD- 1, derived from RAD-6] || Final Text
 
|-
 
| CARD || 2 || Modality Images/Evidence Stored  || An Acquisition Modality sends acquired or generated images, waveforms, or other evidence documents to the Image Archive. [CARD-2, derived from RAD-8 and RAD-43] || Final Text
 
|-
 
| CARD || 3 || Storage Commitment  || A requestor (Acquisition Modality) requests that the Image Manager confirm ownership for the specified DICOM objects (images, waveforms, evidence documents, or any combination thereof) that the requestor stored in the Image Archive, thus allowing the sender to delete those objects now owned by the Image Manager. [CARD-3, derived from RAD-10] || Final Text
 
|-
 
| CARD || 4 || Retrieve Images/Evidence  || An Image Display requests and retrieves a particular image or set of images or other evidence from the Image Archive. [CARD-4, derived from RAD-16 and RAD-44] || Final Text
 
|-
 
| CARD || 5 || Retrieve ECG List  || A Display queries an Information Source for a list of entries representing ECG documents by patient and time period. [CARD-5, derived from ITI-11] || Final Text
 
|-
 
| CARD || 6 || Retrieve ECG Document for Display  || A Display queries an Information Source for a specific ECG document by document id. [CARD-6, derived from ITI-12] || Final Text
 
|-
 
| CARD || 7 || Encapsulated Report Submission  || A Report Creator sends a preliminary, final, or corrected clinical report to the Report Manager, or a Report Manager sends a preliminary, final, or corrected clinical report to the Enterprise Report Repository. || Final Text
 
|-
 
| CARD || 8 || Report Reference Submission  || A Report Manager sends a reference to a report to the Enterprise Report Repository for storage. || Final Text
 
|-
 
| CARD || 9 || Encapsulated Report Storage  || A Report Manager sends a preliminary, final, or corrected clinical report to the Report Repository. || Final Text
 
|-
 
| CARD || 10 || Encapsulated Report Query  || A Report Reader requests a list of clinical reports known by the Report Repository matching a set of selection criteria. || Final Text
 
|-
 
| CARD || 11 || Encapsulated Report Retrieve  || A Report Reader requests and retrieves a clinical report from the Report Repository. || Final Text
 
|-
 
| CARD || 12 || Query Enhanced Modality Worklist || Query Enhanced Modality Worklist is an “enhanced” version of the “Query Modality Worklist” transaction supporting the additional matching keys for Admission ID and Scheduled Procedure Step Location. || Trial Implementation
 
|-
 
| CARD || 13 || Query Cardiology Images/ Evidence || Query Cardiology Images/Evidence – An enhanced version of the “Query Images” and “Query Evidence Documents” queries that requires the “Performed Protocol Code Sequence” to be returned so resting ECGs can be distinguished from other ECG tests, like stress, and Holter. || Trial Implementation
 
|-
 
| CARD || 14 || Notify Study Access || In the Notify Study Access Transaction, the Image Manager/Image Archive provides a study identifier to the Report Manager. The Report Manager can incorporate that ID into a hyperlink to an initial web page that allows navigation and display of the images in the exam. || Trial Implementation
 
|-
 
| CARD || 15 || Invoke Image Display Service || In the Invoke Image Display Service, the Image Manager/Image Archive provides a web interface to access stored DICOM images and evidence. || Trial Implementation
 
|-
 
| CARD || 16 || Outpatient Patient Update || In the Outpatient Update Transaction, the EHR-S provides updated patient demographics to the DSS/OF. The DSS/OF can apply those demographics to Requested Procedures based on orders previously received from the EHR-S, and forwards the update to the Image Manager. This transaction is identical to Patient Update [RAD-12] (see RAD-TF 2: 4.12), with the ADT actor replaced by the EHR-S, and limited to a subset of the trigger events specified in RAD-12. || Trial Implementation
 
|-
 
| ENDO || 1 || Order Endoscopy || The transaction that places the Endoscopy order. ||
 
|-
 
| ENDO || 2 || Deprecated || Deprecated || Deprecated
 
|-
 
| ENDO || 3 || Notify Observation Report || The transaction that provides endoscopy observation report. ||
 
|-
 
| ENDO || 4 || Notify Endoscopy Execution Information || The transaction that provides endoscopy execution information. ||
 
|-
 
| ENDO || 5 || Fill Endoscopy Order || The transaction that fills the endoscopy order. ||
 
|-
 
| ENDO || 6 || Notify Endoscopy Status || The transaction that provides the endoscopy status. ||
 
|-
 
| ENDO || 7 || Query Modality Worklist || The transaction that queries and retrieves the modality worklist. ||
 
|-
 
| ENDO || 8 || Modality Procedure Step In Progress || The transaction that informs the start of the endoscopy procedure. ||
 
|-
 
| ENDO || 9 || Modality Procedure Step Completed || The transaction that informs the end of the endoscopy procedure. ||
 
|-
 
| ENDO || 10 || Modality Images/Videos Stored || The transaction that stores the images/videos acquired during the endoscopy Procedure. ||
 
|-
 
| EYECARE || 1 || Query Modality Worklist || Based on a query entered at the Acquisition Modality, a modality worklist is generated listing all the items that satisfy the query. This list of Scheduled Procedure Steps with selected demographic information is returned to the Acquisition Modality [EYECARE-1, derived from RAD-5]. || Final Text
 
|-
 
| EYECARE || 2 || Modality Images/Evidence Stored || An Acquisition Modality sends acquired or generated images, waveforms, or other evidence documents to the Image Archive. [EYECARE- 2, derived from RAD-8] || Final Text
 
|-
 
| EYECARE || 3 || Retrieve Images and Measurements || An Image Display requests and retrieves a particular image or set of images from the Image Archive. [EYECARE-3, derived from RAD-16] || Final Text
 
|-
 
| EYECARE || 4 || Query Evidence Documents || A user of Evidence Documents (i.e. Image Display, Evidence Creators, etc.) queries the Image Archive for a list of entries representing Evidence Documents. [EYECARE-4, derived from RAD-44] || Final Text
 
|-
 
| EYECARE || 5 || Query Images, Measurements and Encapsulated Documents || An Image Display queries the Image Archive for a list of entries representing images by patient, study, series, or instance. [EYECARE-5, derived from RAD-14] || Final Text
 
|-
 
| EYECARE || 6 || Modality Procedure Step Completed/Discontinued || An Acquisition Modality notifies the Performed Procedure Step Manager of the completion of a Procedure Step and the PPS Manager informs the Department System Scheduler/Order Filler and Image Manager. [EYECARE-6, derived from RAD-7] || Final Text
 
|-
 
| EYECARE || 7 || Displayable Report Storage || Transaction EYECARE-7 is used by the Report Creator and Report Repository Actors. In the Report Storage transaction, the Report Creator transmits a DICOM Encapsulated Document object to the Report Repository.  || Final Text
 
|-
 
| EYECARE || 8 || Query Displayable Report || Transaction [EYECARE-8] is used by the Report Reader and Report Repository Actors. In the Query Displayable Reports Transaction, the Report Reader queries the Report Repository for draft or final DICOM Encapsulated document. || Final Text
 
|-
 
| EYECARE || 9 || Retrieve Displayable Reports || Transaction [EYECARE-9] is used by the Report Reader and Report Repository Actors. In the Retrieve Displayable Reports Transaction, the requested DICOM Encapsulated documents are transferred from the Report Repository to the Report Reader for viewing. || Final Text
 
|-
 
| EYECARE || 10 || Instructions for Performing a Procedure- Placer Order Management || This transaction is based upon Placer Order Management [RAD-2] (see RAD TF: 2 4.2), with the extension to transmit health care provider instructions to the technician prior to performing a procedure || Final Text
 
|-
 
| EYECARE || 11 || Instructions for Performing a Procedure- Filler Order Management || This transaction is based upon Filler Order Management [RAD-3] (see RAD TF-2 4.3), with the extension to transmit health care provider instructions to the technician prior to performing a procedure. || Final Text
 
|-
 
| EYECARE || 12 || Appoinment Request || The Appointment Requester requests a patient appointment with varying specificity of detail as to date range and purpose of the visit. The Appointment Scheduler receives and acknowledges the request, then either fills the request, returning the appointment, or denies the request. || Trial Implementation
 
|-
 
| EYECARE || 13 || Appointment Notification || The Appointment Scheduler sends information to the Appointment Requester for any change to the schedule, including appointments added, updated or cancelled. || Trial Implementation
 
|-
 
| EYECARE || 14 || Schedule Query || The Appointment Requester queries the Appointment Scheduler for a schedule based on specified parameters. The Appointment Scheduler returns the result of the query and the Appointment Requester displays the returned schedule. || Trial Implementation
 
|-
 
| EYECARE || 15 || Eye Care Patient Registration || The Patient Registration Source Actor registers and/or updates patient information and forwards this data to other information systems [EYECARE-15]. || Trial Implementation
 
|-
 
| EYECARE || 16 || Appointment Scheduling Management || The Appointment Scheduler Actor generates new patient appointments and manages the appointment updates, status changes, etc. This information is forwarded to other information systems [EYECARE-16]. || Trial Implementation
 
|-
 
| EYECARE || 17 || Eye Care Charge Posted || The Eye Care Charge Posted Transaction specifies a message from the Department System Scheduler/Order Filler to the Charge Processor. This HL7 Detailed Financial Transaction message contains procedure data typically needed to generate a claim. || Trial Implementation
 
|-
 
| EYECARE || 18 || Modality Images/Evidence Key Objects Stored || Requires acquisitions systems to select and send key image/measurement objects to a storage/display system (i.e., not an image archive). Also enables Image Manager/Image Archive actors to send selected key images/measurements. || Trial Implementation
 
|-
 
| EYECARE || 19 || Patient Demographics Update || Enables systems to update patient demographic information within an ambulatory (i.e., outpatient, such as a small eye care clinic) or an in-patient setting. || Trial Implementation
 
|-
 
| EYECARE || 20 || Merge Patient || Enables systems to merge Patient IDs for a patient that was incorrectly filed under two different identifiers. || Trial Implementation
 
|-
 
| EYECARE || 21 || Procedure Scheduled || A HL7 OMG V2.5.1 message from the DSS/Order Filler to notify the Image Manager/Image Archive that a procedure has been scheduled. || Trial Implementation
 
|-
 
| EYECARE || 22 || Procedure Status Update || A HL7 OMG V2.5.1 message from the Image Manager/Image Archive to convey an order status update (such as completed and images available). It updates the order created from the Procedure Scheduled [EYECARE-21] transaction. || Trial Implementation
 
|-
 
| EYECARE || 23 || Transfer Refractive Measurement (No Pat ID) || The transfer of eye care refractive measurement information based upon one or more JOIA specification data classifications. The data stream does NOT include a valid Patient ID, therefore, the Refractive Measurement Consumer is required to establish the context of the Patient before receiving the data stream from the Refractive Measurement Source. It uses the context to provide the correct patient information when importing the measurement(s) into its database. || Trial Implementation
 
|-
 
| EYECARE || 24 || Transfer Refractive Measurement (Valid Pat ID) || The transfer of eye care refractive measurement information based upon one or more JOIA specification data classifications. The data stream is required to include a valid Patient ID, therefore, the Refractive Measurement Consumer uses the Patient ID to identify the patient and to provide the correct patient information when importing the measurement(s) into its database. || Trial Implementation
 
|-
 
| EYECARE || 25 || Query Patient List || This transaction provides the ability to obtain a list of patients (with associated patient demographics) that have arrived at the organization (e.g., checked into an eye care clinic). It is intended for acquisition devices (such as eye care refractive instruments, etc.) that are used for patient examinations, but are not based upon orders. || Trial Implementation
 
|-
 
| ITI || 1 || Maintain Time || NTP transactions used to maintain time synchronization. || Final Text
 
|-
 
| ITI || 2 || Get User Authentication || The Client Authentication Agent requests user authentication from the Kerberos Authentication Server. When the user is authenticated, the Kerberos Authentication Server returns a Ticket Granting Ticket (TGT) to optimize future activity. || Final Text
 
|-
 
| ITI || 3 || Get Service Ticket || Obtain a ticket using Kerberos protocol for use with a service. Service identity option is specific for each protocol. For example HOST for HTTP. || Final Text
 
|-
 
| ITI || 4 || Kerberized Communication || The Kerberized Communication transaction is an aspect of the connection between a local client and a remote server. || Final Text
 
|-
 
| ITI || 5 || Join Context || Allows a Context Participant Actor to locate and establish communication with the Context Manager Actor. || Final Text
 
|-
 
| ITI || 6 || Change Context || Includes all messages required to initiate and finalize a context change transaction: -Initiation of a context change request from the instigating participant actor. -Delivery of survey results to instigating actor and display of associated replies. -Communication of context change decision to the Context Manager Actor || Final Text
 
|-
 
| ITI || 7 || Leave Context || Allows Context Participant Actor to notify the Context manager Actor that it is breaking off communication. || Final Text
 
|-
 
| ITI || 8 || Patient Identity Feed || Allows a Patient Identity Source Actor to notify a Patient Identity Cross-Referencing Actor of all events related to patient identification (creation, update, merge, etc.). || Final Text
 
|-
 
| ITI || 9 || PIX Query || This transaction allows a Patient Identity Consumer to find out the identification of a patient in different Patient Identification Domains by using the services of a Patient Identity Cross-reference Manager Actor. || Final Text
 
|-
 
| ITI || 10 || Pix Update Notification || Allows a Patient Identity Consumer to be notified by the Patient Identity Cross-reference Manager Actor of changes to the identification of a patient in Patient Identification Domains the Consumer is interested in. || Final Text
 
|-
 
| ITI || 11 || Retrieve Specific Information for Display || A request issued by a display system for specific information related to a patient returned in a ready for presentation information format || Final Text
 
|-
 
| ITI || 12 || Retrieve Document for Display || A display system requests an instance of a uniquely identified persistent document under custodianship by an information source and returns its content ready for presentation. || Final Text
 
|-
 
| ITI || 13 || Follow Context || Accounts for all messages required to propagate a context change to a responding participant actor: -Survey of all other Context Participant Actors by the Context Manager Actor and display by the instigating Participant Actor of any associated replies. -Notification of context change result from the Context manager Actor to the Context Participant Actors. -Retrieval of the context data by the Context Participant Actors || Final Text
 
|-
 
| ITI || 14 || Register Document Set || A Document Repository Actor initiates the Register Document Set transaction. This transaction allows a Document Repository Actor to register one or more documents with a Document Registry, by supplying metadata about each document to be registered. This document metadata will be used to create an XDS Document Entry in the registry. The Document Registry Actor ensures that document metadata is valid before allowing documents to be registered. If one or more documents fail the metadata validation, the Register Document Set transaction fails as a whole.
 
To support composite documents, an XDS Document may be a multipart document. The Document Repository must handle multi-part data sets as an opaque entity . The Document Repository does not need to analyze or process its multi-part structure nor the content of any parts in the context of the XDS Integration Profile. || Deprecated
 
|-
 
| ITI || 15 || Provide and Register Document Set || A Document Source Actor initiates the Provide and Register Document Set Transaction. For each document in the submitted set, the Document Source Actor provides both the documents as an opaque octet stream and the corresponding metadata to the Document Repository. The Document Repository is responsible to persistently store these documents, and to register them in the Document Registry using the Register Documents transaction by forwarding the document metadata received from the Document Source Actor. || Deprecated
 
|-
 
| ITI || 16 || Query Registry || The Query Registry transaction is issued by the Document Consumer Actor on behalf of a care provider (EHR-CR) to a Document Registry. The Document Registry Actor searches the registry to locate documents that meet the provider s specified query criteria. It will return a list of document entries that contain metadata found to meet the specified criteria including the locations and identifier of each corresponding document in one or more Document Repositories. || Deprecated
 
|-
 
| ITI || 17 || Retrieve Document || A Document Consumer Actor initiates the Retrieve Document transaction. The Document Repository will return the document that was specified by the Document Consumer.  
 
  
To support composite documents, an XDS Document may be a multipart document. In this case, the Document Consumer must take appropriate actions to make the multipart content accessible to the user. || Deprecated
+
===Appendix A: IHE Actors===
|-
+
IHE Actor information is maintained in Gazelle Master Model. See the [https://profiles.ihe.net/GeneralIntro/ch-A.html IHE General Introduction Appendix A] and the [https://wiki.ihe.net/index.php/Gazelle_Browsing Gazelle Browsing] wiki page for additional information.
| ITI || 18 || Stored Query || The Query Registry transaction is issued by the Document Consumer Actor on behalf of a care provider (EHR-CR) to a Document Registry. The Document Registry Actor searches the registry to locate documents that meet the provider s specified query criteria. It will return a list of document entries that contain metadata found to meet the specified criteria including the locations and identifier of each corresponding document in one or more Document Repositories. The stored query uses parameters and not direct SQL || Final Text
 
|-
 
| ITI || 19 || Authenticate Node || This transaction is embedded within all network communications activity. All DICOM, HL7, and HTML connections shall comply with the IHE specification for bi-directional authentication and authorization of communications of Protected Healthcare Information (PHI). IHE does not specify how other protocols that transfer PHI shall perform bi-directional authentication and authorization, but requires that other protocols perform such authentication and authorization. || Final Text
 
|-
 
| ITI || 20 || Record Audit Event || The delivery of an audit event description from any secure node to the Audit Repository. || Final Text
 
|-
 
| ITI || 21 || Patient Demographic Query || Look up and return patient demographic information in a single patient demographics source, based upon matches with full or partial demographic information entered by the user. || Final Text
 
|-
 
| ITI || 22 || Patient Demographic Visit Query || Look up and return patient demographic and visit information in a single patient demographics source, based upon matches with full or partial demographic/visit information entered by the user. || Final Text
 
|-
 
| ITI || 23 || Find Personnel White Pages || This transaction will find the LDAP Directory by querying the DNS. || Final Text
 
|-
 
| ITI || 24 || Query Personnel White Pages || This transaction provides for read-only access to the Personnel White Pages directory. || Final Text
 
|-
 
| ITI || 25 || Send Notification || This transaction provides for sending of document availability notices in an XDS Affinity Domain. || Deprecated
 
|-
 
| ITI || 26 || Receive Notifications || This transaction provides for receipt of document availability notices in an XDS Affinity Domain. || Deprecated
 
|-
 
| ITI || 27 || Send Acknowledgement || This transaction provides for sending of acknowledgements to document availability notices in an XDS Affinity Domain. || Deprecated
 
|-
 
| ITI || 28 || Receive Acknowledgement || This transaction provides for receipt of acknowledgements of document availability notices in an XDS Affinity Domain. || Deprecated
 
|-
 
| ITI || 29 || Assert X-User Identity || This transaction will generate a Cross-Enterprise Authentication Assertion and pass it to a relying service. || Final Text
 
|-
 
| ITI || 30 || Patient Identity Management || The Patient Demographics Supplier registers or updates a patient and forwards the demographic information (i.e. all information directly related to the patient, such as ID, address, next of kin, to other systems implementing Patient Demographics Consumer. || Final Text
 
|-
 
| ITI || 31 || Patient Encounter Management || The Patient Encounter Source registers or updates an encounter (inpatient, outpatient, pre-admit...) and forwards the information to other systems implementing Patient Encounter Consumer. This information will include the patients location and care providers for a particular (usually current) encounter || Final Text
 
|-
 
| ITI || 32 || Distribute Document Set on Media || The Portable Media Creator sends information to media reading actors by means of Interchange Media where it stores the information. || Final Text
 
|-
 
| ITI || 33 || Send Document Set (Unused) ||  || Unused
 
|-
 
| ITI || 34 || Retrieve Form ||  || Final Text
 
|-
 
| ITI || 35 || Submit Form ||  || Final Text
 
|-
 
| ITI || 36 || Archive Form ||  || Final Text
 
|-
 
| ITI || 37 || Retrieve Clarifications ||  || Final Text
 
|-
 
| ITI || 38 || Cross Gateway Query ||  || Final Text
 
|-
 
| ITI || 39 || Cross Gateway Retrieve ||  || Final Text
 
|-
 
| ITI || 40 || Provide X-User Assertion ||  || Final Text
 
|-
 
| ITI || 41 || Provide and Register Document Set-b ||  || Final Text
 
|-
 
| ITI || 42 || Register Document Set-b ||  || Final Text
 
|-
 
| ITI || 43 || Retrieve Document Set ||  || Final Text
 
|-
 
| ITI || 44 || Patient Identity Feed HL7 V3 ||  || Final Text
 
|-
 
| ITI || 45 || PIXV3 Query ||  || Final Text
 
|-
 
| ITI || 46 || PIXV3 Update Notification ||  || Final Text
 
|-
 
| ITI || 47 || Patient Demographics Query HL7 V3 ||  || Final Text
 
|-
 
| ITI || 48 || Retrieve Value Set || This transaction is used by the Value Set Consumer to retrieve a Resolved Value Set from the Value Set Repository. The Value Set Consumer has previously obtained the Resolved Value Set OID by means outside of the scope of this transaction. Appendix B of the IHE ITI Technical Framework Volume 2 has further information about obtaining and managing OIDs which are used as the Value Set Unique ID. || Final Text
 
|-
 
| ITI || 49 || Convey Printed Referral Request ||  || Deprecated
 
|-
 
| ITI || 50 || Request Referral ||  || Deprecated
 
|-
 
| ITI || 51 || Multi-Patient Query ||  || Final Text
 
|-
 
| ITI || 52 || Document Metadata Subscribe ||  || Trial Implementation
 
|-
 
| ITI || 53 || Document Metadata Notify ||  || Trial Implementation
 
|-
 
| ITI || 54 || Document Metadata Publish ||  || Trial Implementation
 
|-
 
| ITI || 55 || Cross Gateway Patient Discovery || The Cross Gateway Patient Discovery transaction supports the ability for Initiating Gateways and Responding Gateways to discover mutually known patients. This transaction assumes an environment where patient data is well described and high quality demographic data is available. || Final Text
 
|-
 
| ITI || 56 || Patient Location Query || The Patient Location Query supports the ability for an Initiating Gateway to query the Responding Gateway for a list of communities which may have relevant health data about particular patients. This transaction can be used synchronously and asynchronously. || Trial Implementation
 
|-
 
| ITI || 57 || Update Document Set || The Update Document Set transaction passes a collection of metadata updates from the Document Administrator actor to the Document Registry or Document Recipient actor. || Trial Implementation
 
|-
 
| ITI || 58 || Provider Information Query || This transaction supports the ability to lookup information about healthcare providers from a healthcare provider directory on the following: • Individual Providers – A person who provides healthcare services, such as a physician, nurse, or pharmacist. • Organizational Providers – Organizations that provide or support healthcare services, such as hospitals, Healthcare Information Exchanges (HIEs), Managed Care, Integrated Delivery Networks (IDNs), and Associations. • Relationship between providers. || Trial Implementation
 
|-
 
| ITI || 59 || Provider Information Feed || The Provider Information Feed specifies one or more of the following actions: • An “Add” to add new provider entries • A “Delete” to delete any existing provider entries • An “Update” to modify or update any existing provider entries || Trial Implementation
 
|-
 
| ITI || 60 || Retrieve Multiple Value Sets || The Value Set Consumer retrieves multiple value sets from the Value Set Repository. These retrieved value sets have metadata that matches retrieval selection criteria. The retrieved sets provide the full metadata describing the value set, and an expanded value set representation for that value set. || Final Text
 
|-
 
| ITI || 61 || Register On-Demand Document Entry || The Register On-Demand Document Entry transaction is used by the On-Demand Document Source to register one or more On-Demand Document Entries in the Document Registry. || Final Text
 
|-
 
| ITI || 62 || Remove Metadata || The Remove Metadata transaction is used by the Document Administrator to request removal of one or more metadata objects from a Document Registry. || Trial Implementation
 
|-
 
| ITI || 63 || Cross Gateway Fetch || This transaction is used to fetch a document or a set of documents that match a given set of metadata attribute values. || Trial Implementation
 
|-
 
| ITI || 64 || Notify XAP-PID Link Change || This transaction informs the recipient that there has been a change to the link between a “local patient ID” and its corresponding XAD-PID. It should not to be confused with the similar link/unlink events documented in transaction ITI-30 (Patient Identity Management) which is used by patient demographic suppliers to notify other interested systems about changes to its own local patient identity records. The transaction can be used in any setting where it is appropriate to have XAD-PID link changes processed as a single event, rather than require individual metadata updates to each object. || Trial Implementation
 
|-
 
| ITI || 65 || Provide Document Bundle || This transaction is used to publish a new document entry and the document. || Trial Implementation
 
|-
 
| ITI || 66 || Find Document Manifests || The Find Document Manifests transaction is used to find Document Manifests that satisfy a number of parameters, and is equivalent to ITI-18 (Registry Stored Query), FindSubmissionSets query from the XDS stored query catalog from [ITI-18] . The result of the query is a bundle of Document Manifest Resources which reference one or more Document Reference Resources containing document metadata. || Trial Implementation
 
|-
 
| ITI || 67 || Find Document References || The Find Document References transaction is used to find Document References that satisfy parameters, and is equivalent to Registry Stored Query [ITI-18]), FindDocuments and FindDocumentsByReferenceId query from [ITI-18] || Trial Implementation
 
|-
 
| ITI || 68 || Retrieve Document || The Retrieve Document transaction is used by the Document Consumer to retrieve a document from the Document Responder. || Trial Implementation
 
|-
 
| ITI || 69 || Create Destroy Pull Point || This transaction is used to create a pull point resource. This resource is used for the creation of subscriptions and for the pulling of the notifications stored. This transaction is also used to destroy the pull point resource when it is no longer needed. || Trial Implementation
 
|-
 
| ITI || 70 || Pull Notification || This transaction is used to retrieve pending notifications. || Trial Implementation
 
|-
 
| ITI || 71 || Get Authorization Token || A transaction that is used to request and obtain an authorization token for use in authorized transactions. || Trial Implementation
 
|-
 
| ITI || 72 || Incorporate Authorization Token || Add an authorization token to a transaction. || Trial Implementation
 
|-
 
| ITI || 73 || Find Matching Services || The Find Matching Services transaction is used to express queries against the CSD schema. This schema is found in ITI TF-2x: Appendix W. The query against the CSD schema may be expressed as an invocation of a stored query or (optionally) as a well-formed ad hoc XQuery. The query is submitted by the Service Finder to the Care Services InfoManager by constructing an XML document expressing the query and executing an HTTP POST transaction. The Care Services InfoManager executes the query and returns the results in a response document. || Trial Implementation
 
|-
 
| ITI || 74 || Query for Updated Services || The Query for Updated Services transaction is used to obtain the CDS directory records that have been updated since the refresh timestamp provided in the query. || Trial Implementation
 
|-
 
| ITI || 75 || Care Services Free Busy Query || The Query for FreeBusy [ITI-75] transaction is used by a Service Finder that supports the FreeBusy option to express a well-formed FreeBusy REPORT query to a CalDAV conformant Service Availability actor adherent to the IETF RFC 4791 specification. || Trial Implementation
 
|-
 
| ITI || 76 || Patient Location Tracking Feed || Used to update patient location. || Trial Implementation
 
|-
 
| ITI || 77 || Patient Location Tracking Query || Used to query for the current patient location || Trial Implementation
 
|-
 
| ITI || 78 || Mobile Patient Demographics Query || Performs a query against a patient demographics supplier using HTTP, REST, and JSON/XML message encoding. || Trial Implementation
 
|-
 
| ITI || 79 || Authorization Decisions Query || Transaction used by the service provider (Authorization Decisions Verifier) to request valid authorization decisions granted for the Requester Entity to disclose specific documents. || Trial Implementation
 
|-
 
| ITI || 80 || Cross-Gateway Document Provide || This Transaction allows an Initiating Gateway in a Community to provide a set of Documents to the Responding Gateway of a remote Community || Trial Implementation
 
|-
 
| ITI || 81 || Retrieve ATNA Audit Event || Retrieve Audit Messages. Search ATNA audit messages based upon queries using ATNA audit message content. || Trial Implementation
 
|-
 
| ITI || 82 || Retrieve Syslog Event || Retrieve Syslog Messages. Search syslog messages based upon using the syslog metadata. || Trial Implementation
 
|-
 
| ITI || 83 || Mobile Patient Identifier Cross-Reference Query || Performs a query against a patient identifier cross-reference manager using HTTP, REST, and JSON/XML message encoding. || Trial Implementation
 
|-
 
| ITI || 84 || Mobile Report Alert || This transaction is used by the Alert Reporter to report alerts to the Alert Aggregator. The Alert Reporter sends alerts to the Alert Aggregator actor in an unsolicited manner. || Trial Implementation
 
|-
 
| ITI || 84x || Mobile Report Alrt || This transaction is used by the Alert Reporter to report alerts to the Alert Aggregator. The Alert Reporter sends alerts to the Alert Aggregator in an unsolicited manner. || Trial Implementation
 
|-
 
| ITI || 85 || Query for Alert Status || This transaction is used by the Alert Reporter to query an Alert Aggregator for alert status information as communicated to an Alert Aggregator for a particular alert. || Trial Implementation
 
|-
 
| ITI || 86 || Remove Documents || The Remove Documents transaction is used by the Document Administrator to request the removal of documents from a Document Repository. || Trial Implementation
 
|-
 
| ITI || 87 || Submit File || This transaction allows a File Source to publish a file and related metadata, or to update an existing file. || Trial Implementation
 
|-
 
| ITI || 88 || Search File || This transaction allows a File Consumer to query for a file metadata that meets certain criteria || Trial Implementation
 
|-
 
| ITI || 89 || Update DocumentReference || This transaction allows a File Source to update file metadata. || Trial Implementation
 
|-
 
| ITI || 90 || Find Matching Care Services || The Find Matching Care Services transaction is used to query for practitioners, locations, organizations, and healthcare services resources as well as links between these resources. The Find Matching Care Services transaction is initiated by the Care Services Selective Consumer against the Care Services Selective Supplier. || Trial Implementation
 
|-
 
| ITI || 91 || Request Care Services Updates || The Request Care Services Updates is used to obtain practitioners, locations, organizations, and healthcare services resources that have been inserted or updated since the specified timestamp. The Request Care Services Updates is initiated by the Care Services Update Consumer against the Care Services Update Supplier. || Trial Implementation
 
|-
 
| LAB || 1 || Placer Order Management || This transaction contains all the messages required between the Order Placer and the Order Filler for the management of the life cycle of the order. Its main goal is to keep a consistent vision of the order, (content and status), between the two actors. || Final Text
 
|-
 
| LAB || 2 || Filler Order Management || This transaction contains all the messages required between the Order Filler and the Order Placer for the notification of a new filler order, as well as the creation of the placer order that reflects it. Its main goal is to ensure that each filler order will be represented by a placer order, and will have both a filler order number and a placer order number. || Final Text
 
|-
 
| LAB || 3 || Order Results Management || This transaction carries changes of the observation results and order status from Order Filler to Order Result Tracker i.e. corrections, cancellations. || Final Text
 
|-
 
| LAB || 4 || Work Order Management || This transaction contain all the messages required between Order Filler and Automation Manager for the execution of a work order containing a subset of tests of the filler order. The main goal of this transaction is to distribute the work to the Automation Manager, and to keep this actor informed of all patient and order updates. This transaction will be based on a push mechanism, the query mechanism never being used in this transaction. || Final Text
 
|-
 
| LAB || 5 || Test Results Management || This transaction carries the technically validated test results from the Automation Manager to the Order Filler. || Final Text
 
|-
 
| LAB || 21 || Specimen Work Order Step Download || This transaction contains the messages used to download a Work Order Step (WOS) from the Automation Manager to the Analyzer or Pre/Post-processor, according to a "push method". It includes "cnew WOS", "update WOS", "cancel WOS" and the related applicative acknowledgements. This transaction is used with Analyzers and Pre/Post-processor which work in download mode. || Final Text
 
|-
 
| LAB || 22 || Specimen Work Order Step Query || This transaction contains the message used by the Analyzer or Pre/Post-processor to query the Automation Manager with one or more specimen (or location) identifiers, and the reply message from the Automation Manager delivering one or more WOS dedicated to each of these specimen. This transaction implements the "pull method" for requesting WOS. || Final Text
 
|-
 
| LAB || 23 || Specimen Work Order Step Status Change || This transaction contains the messages used by the Analyzer to report the status of an AWOS (such as "specimen arrived", "first run failed", "second run started", "AWOS complete" ...) and to send the tests results when the AWOS is complete. It also includes the related applicative acknowledgements from the Automation Manager. || Deprecated
 
|-
 
| LAB || 26 || Specimen Work Order Step Status Change || This transaction contains the messages used by the Pre or Post-Processor to report all the status changes of the SWOS, and the related applicative acknowledgements. Status changes include: "specimen arrived", "SWOS complete", "SWOS failed"... || Final Text
 
|-
 
| LAB || 27 || Query for AWOS || This transaction contains the message used by the Analyzer to query the Analyzer Manager for one specimen (or location). The Analyzer Manager will follow the exchange with a LAB-28 that delivers one or more AWOS dedicated to the specimen or indicates there is no work to perform. This transaction implements the “pull method” for requesting AWOS, which is the default behavior. || Trial Implementation
 
|-
 
| LAB || 28 || AWOS Broadcast || This transaction contains the messages used to broadcast an Analytical Work Order Step (AWOS) from the Analyzer Manager to the Analyzer, according to a “push method”. It includes “new AWOS”, “cancel AWOS” and the related applicative acknowledgements. || Trial Implementation
 
|-
 
| LAB || 29 || AWOS Status Change || This transaction contains the messages used by the Analyzer to send the tests results when the AWOS is complete. It also includes the related applicative acknowledgements from the Analyzer Manager. || Trial Implementation
 
|-
 
| LAB || 30 || Initiate POCT on a Patient Specimen || A POCRG sends to the POCDM a message containing: its own ID, the care unit ID, the ordering provider ID, the operator ID, the patient/visit ID (or QC ID) and other information related to the test to start. The POCDM identifies the operator, and checks the patient identification. It then sends the answer back to the POCRG. The answer may be positive and carry the patient&aposs identity, or negative and carry the reject reason. || Final Text
 
|-
 
| LAB || 31 || Produced Observation Set || The POCRG sends an observation set to the POCDM. The POCDM checks the content of this observation set, stores it and acknowledges it to the POCRG. || Final Text
 
|-
 
| LAB || 32 || Accepted Observation Set || The POCRG sends an observation set to the POCDM. The POCDM checks the content of this observation set, stores it and acknowledges it to the POCRG. || Final Text
 
|-
 
| LAB || 35 || Sub-Order Management || This transaction provides the message flow placing Suborders from Requester to Subcontractor and the message flow acknowledging specimen arrival from Subcontractor to Requester. || Trial Implementation
 
|-
 
| LAB || 36 || Sub-Order Result Delivery || This transaction provides the results message flow from Subcontractor to Requester. || Trial Implementation
 
|-
 
| LAB || 51 || Laboratory Code Set Management || Code set distribution (battery, test, observation). || Final Text
 
|-
 
| LAB || 61 || Label Delivery Request || This transaction is used by the Label Information Provider to send label delivery instructions to the Label Broker. || Final Text
 
|-
 
| LAB || 62 || Query for Label Delivery Instruction || This transaction is used by the Label Broker to query the specimen container labeling instructions from the Label Information Provider. || Final Text
 
|-
 
| LAB || 63 || Labels and Containers Delivered || This transaction is used by the Label Broker to notify the effective labeled containers production to the Label Information Provider. || Public Comment
 
|-
 
| MMRO || II-1 || Spatial Registration Storage || In the Spatial Registration Storage transaction, the Registrator stores one or more Spatial Registration instances to the Archive. Spatial registration objects define how the pixel coordinates of one image data set are transformed to another coordinate system (for example to a coordinate system defined by another image data set thus allowing each dataset to be spatially aligned). A list of the images used in each Frame of Reference to determine the spatial registration shall be stored in the Spatial Registration instance. || Trial Implementation
 
|-
 
| MMRO || II-2 || Spatial Registration Retrieval || A Registered Display, Registered Dose Display or Registered Contourer receives from an Archive one or more Spatial Registration objects carrying the transformation information to be applied to two image data sets intended for further processing or registered display. Each application receiving a Spatial Registration instance shall compare the image set to be used / displayed to the list of images for each Frame of Reference and warn the user if additional images are to be displayed for which the spatial registration may not be defined. || Trial Implementation
 
|-
 
| MMRO || III-1 || Spatial Registration-III Storage || In the Spatial Registration-III Storage transaction, the Registrator sends one or more Spatial Registration instances to the Archive. Spatial registration objects define how the pixel coordinates of one image data set are transformed to another coordinate system (for example to a coordinate system defined by another image data set thus allowing each dataset to be spatially aligned). ||
 
|-
 
| MMRO || III-2 || Spatial Registration-III Retrieval || A Registered Contourer, Registered Display or Registered Dose Display receives from an Archive one or more Spatial Registration objects carrying the transformation information to be applied to two image data sets intended for further processing or fused display. A Registrator may (optional transaction) receive from an Archive one or more Spatial Registration objects. ||
 
|-
 
| MMRO || 3 || Registered Structure Set Storage || In the Registered Structure Set Storage Transaction, the Registered Contourer stores a Structure Set on an Archive to make it available. ||
 
|-
 
| MMRO || 4 || Registered Structure Set Retrieval || In the Registered Structure Set Retrieval Transaction, the Archive stores a Structure Set on a Registered Contourer, Registered Display or Registered Dose Display ||
 
|-
 
| MMRO || 5 || Registered Dose Retrieval || In the Registered Dose Retrieval Transaction, the requested RT Dose is transferred from the Archive to the Registered Dose Display ||
 
|-
 
| PAT || 1 ||  Placer Order Management || This transaction contains all the messages required between the Order Placer and the Order Filler for the management of the life cycle of the order. Its main goal is to keep a consistent vision of the order, (content and status), between the two actors. || Final Text
 
|-
 
| PAT || 2 || Filler Order Management || This transaction contains all the messages required between the Order Filler and the Order Placer for the notification of a new filler order, as well as the creation of the placer order that reflects it. Its main goal is to ensure that each filler order will be represented by a placer order, and will have both a filler order number and a placer order number. || Final Text
 
|-
 
| PAT || 3 || Order Results Management || This transaction carries the results of an Order, as well as status changes, modifications, cancellations of these results, from the Order Filler to the Order Result Tracker. || Final Text
 
|-
 
| PAT || 4 || Procedure Scheduled and Update || The Department System Scheduler/Order Filler sends the Image Manager and Report Manager scheduled procedure information or procedure update. || Final Text
 
|-
 
| PAT || 5 || Query Modality Worklist || Based on a query entered at the Acquisition Modality, a modality worklist is generated listing all the items that satisfy the query. This list of Scheduled Procedure Steps with selected demographic information and information about specimen is returned to the Acquisition Modality. || Final Text
 
|-
 
| PAT || 6 || Modality Procedure Status Notification || It is essentially based on similar transactions RAD-6 and RAD-7 designed for Radiology. The main difference is that the image acquisition is less complex in anatomic pathology than the one in the radiology scenario. || Trial Implementation
 
|-
 
| PAT || 10 || Public Health Reporting || Public Health Reporting || Public Comment
 
|-
 
| PCC || 1 || Share Content ||  || Final Text
 
|-
 
| PCC || 2 || Query Existing Data || Request information about recent patient information, used to obtain vital signs measurements, problems and allergies, diagnostic results, medications, immunizations, or procedures or visits relevant for a patient. The query may request information about some or all of the above topics, or may request information on a specific topic, or one entered for a specific encounter or date range. || Trial Implementation
 
|-
 
| PCC || 7 || Guideline Notification || Transaction PCC-7 is used by the Guideline Manager and Care Manager Actors. || Final Text
 
|-
 
| PCC || 8 || Request Guideline Data || Transaction PCC-8 is used by the Care Manager and/or Clinical Data Source Actors to request Guideline Data from a Guideline Manager Actor. Transaction PCC-8 is similar in structure to Transaction PCC-1. The difference between PCC-8 and PCC-1 is that where PCC-1 requests clinical information matching the query parameters for a specific patient, the PCC-8 transaction requests a specific care record activating a clinical guideline identified in the query parameters. || Final Text
 
|-
 
| PCC || 9 || Care Management Data Query || Transaction PCC-9 is used by the Care Manager and Clinical Data Repository Actors. Transaction PCC-9 is a variation of the pattern used in transaction PCC-1 of the PCC Technical Framework || Final Text
 
|-
 
| PCC || 10 || V3 Care Management Update || Transaction PCC-10 is used by the Care Manager and Clinical Data Repository Actors. || Trial Implementation
 
|-
 
| PCC || 11 || V2 Care Management Update || Transaction PCC-11 is used by the Care Manager and Clinical Data Repository Actors. || Trial Implementation
 
|-
 
| PCC || 12 || Request for Clinical Guidance || Request for Clinical Guidance || Trial Implementation
 
|-
 
| PCC || 13 || Query Clinical Knowledge || Query Clinical Knowledge || Trial Implementation
 
|-
 
| PCC || 14 || Retrieve Clinical Knowledge || Retrieve Clinical Knowledge || Trial Implementation
 
|-
 
| PCC || 15 || Communicate PCHA Data Transaction (RPM) || These transactions contain the discrete data from the remote Personal Health Device, such as device identification data, data related to the settings and calibration of the device, and the sensor data itself over at least one of several transport options. The transaction supports five transport options. To qualify as PCHA data certain time stamping requirements must be met; e.g., all stored data must be time stamped and any device containing timestamps in the measurements must expose its sense of current time and its time synchronization (if any). || Trial Implementation
 
|-
 
| PCC || 16 || Share List || This transaction uses the FHIR® List resource query capability to query for and retrieve clinical content lists in FHIR® List resource format. When this is used with the RECON Profile then there are additional constraints on the List resource. First seen in RECON Supplement published for TI, August 2015 || Trial Implementation
 
|-
 
| PCC || 17 || Translate Code (CMAP) || This transaction provides a term to be mapped to a specific terminology equivalent and receives a list of terms which may be used to represent the concept in the requested terminology. || Trial Implementation
 
|-
 
| PCC || 18 || Retrieve Code Mappings (CMAP) || This transaction supports retrieval of all mappings from a source terminology to a destination terminology. || Trial Implementation
 
|-
 
| PCC || 19 || Evaluate Order || Evaluates an order against guidelines and/or policies to determine its appropriateness in a given context. || Trial Implementation
 
|-
 
| PCC || 20 || Invoke Questionnaire || Displays the CDS questionnaire using HTML web pages and returns the result invoker || Trial Implementation
 
|-
 
| PCC || 21 || Communicate PCD Data-hData (RPM) || This transaction contains the PCD-01 message generated from sensor data using RESTFul hData transports. || Trial Implementation
 
|-
 
| PCC || 22 || Communicate PCD Data-SOAP (RPM) || This transaction contains the PCD-01 message generated from sensor data using Web Services. || Trial Implementation
 
|-
 
| PCC || 23 || Admission Notification || The Admission notification transaction notifies actors about admission of a patient to a bed || Trial Implementation
 
|-
 
| PCC || 24 || Admission Order || The Admission Order transaction notifies actors about the intention to admit a patient to a bed. || Trial Implementation
 
|-
 
| PCC || 25 || Patient Movement || The Patient Movement transaction communicates information about movement of a patient from one location to another. || Trial Implementation
 
|-
 
| PCC || 26 || Submit and assign HT Management || The Submit and assign HT Management transaction starts a Heart Team process. It submits a new Workflow Document in order to provide the HT Request document to the HT Manager and/or to assign HT management to the HT Manager. || Trial Implementation
 
|-
 
| PCC || 27 || Accept/Reject HT Activity || This transaction allows a HT Manager or HT participant to accept or reject the assignment respectively to manage the Heart Team or to be involved in the Heart Team. || Trial Implementation
 
|-
 
| PCC || 28 || Assign HT Participation || The Assign HT Participation transaction updates the Workflow Document in order to assign HT participation to each HT Participant. The identification of which group of HT Participants to be involved in Heart Team is out of scope for this specification and should be locally defined by domain policies || Trial Implementation
 
|-
 
| PCC || 29 || Add Request of more clinical information || The Add Request of more clinical information transaction updates and submits an updated Workflow Document, in order to allow each HT Participant to request that HT Requester provides more clinical information. || Trial Implementation
 
|-
 
| PCC || 30 || Add more clinical information || The Add more clinical information transaction updates and submits an updated Workflow Document which provides clinical information requested by one or more PCC-29 transactions. || Trial Implementation
 
|-
 
| PCC || 31 || Complete individual preparation || The Complete individual preparation transaction updates and submits an updated Workflow Document, in order to inform Heart Team that HT Participant has concluded the preliminary phase (Involvement task and Preparation task). In this transaction the HT Participant may provide Individual evaluation report to support the Heart Team. || Trial Implementation
 
|-
 
| PCC || 32 || Plan HT Discussion || The Plan HT Discussion transaction updates Workflow Document in order to schedule the team’s communication among members of Heart Team. || Trial Implementation
 
|-
 
| PCC || 33 || Complete HT || The Complete Heart Team transaction updates and submits an updated Workflow Document, in order for the HT Manager to provide the Final Report in response to the HT Request || Trial Implementation
 
|-
 
| PCC || 34 || Finalization || The Finalization transaction updates and submits an updated Workflow Document needed to finalize the HT Request. The Final Report provides information that was requested to support clinical care. || Trial Implementation
 
|-
 
| PCC || 35 || Cancel HT || This transaction cancels an ongoing Heart Team process. || Trial Implementation
 
|-
 
| PCC || 36 || Cancel HT assignment || This transaction revokes the assignment of a HT Lead task if the sender is the HT Requester or HT Involvement tasks if the sender is HT Manager. || Trial Implementation
 
|-
 
| PCC || 37 || Update Care Plan || Update an existing or create a new Care Plan || Trial Implementation
 
|-
 
| PCC || 38 || Retrieve Care Plan || Retrieve a Care Plan || Trial Implementation
 
|-
 
| PCC || 39 || Subscribe to Care Plan Updates || Subscribe to receive updated Care Plans for specific patients || Trial Implementation
 
|-
 
| PCC || 40 || Provide Care Plan || Provide updated Care Plans to subscribers || Trial Implementation
 
|-
 
| PCC || 41 || Search for Care Plan || Used to find a care plan || Trial Implementation
 
|-
 
| PCC || 42 || Communicate FHIR Data-hData (RPM) ||  ||
 
|-
 
| PCC || 43 || Share FHIR Resources (RPM) ||  ||
 
|-
 
| PCC || 44 || Mobile Query Existing Data || The Mobile Query Existing Data transaction is used to query for clinical fine grained data elements that satisfy a set of parameters by using the FHIR framework. The result of the query is a FHIR Bundle containing FHIR clinical data Resources that match the query parameters. The QEDm Profile assumes that categories and codes referenced by these FHIR Resources need to be defined at the time of deployment. The specification of these FHIR Resources make recommendations on categories and codes that should be considered. || Trial Implementation
 
|-
 
| PCC || 45 || Update Care Team || This transaction is used to update or to create a CareTeam resource. A CareTeam resource is submitted to a Care Team Service where the update or creation is handled. || Trial Implementation
 
|-
 
| PCC || 46 || Search for Care Team || This transaction is used to find a CareTeam resource. The Care Team Contributor searches for a CareTeam resource of interest. A CareTeam resource located by search may then be retrieved for viewing or updating. || Trial Implementation
 
|-
 
| PCC || 47 || Retrieve Care Team || This transaction is used to retrieve a specific CareTeam resource using a known FHIR CareTeam resource id. || Trial Implementation
 
|-
 
| PCC || 48 || Subscribe to Care Team Updates || This transaction is used to subscribe to updates made to a CareTeam resource. As noted in PCC Section X.1.1.2, the Care Team Service SHALL support RESTful delete of the subscription, as well as the following messages for creating and updating a Subscription. See: http://hl7.org/fhir/subscription.html || Trial Implementation
 
|-
 
| PCC || 49 || Provide Care Team || This transaction is used to provide an updated CareTeam resource to a Care Team Contributor that has subscribed to updates. || Trial Implementation
 
|-
 
| PCC || 50 || Register Medical Device || This transaction is intended to record information about a device identity (e.g., UDI) and associate it with a patient from data acquired directly at the point-of-care and report it to the enterprise system. This transaction relies on patient and device identity information scanned/entered at the point-of-care by the front-line clinicians. || Trial Implementation
 
|-
 
| PCC || 51 || Search Medical Device || This transaction is intended to provide a synchronous query mechanism. || Trial Implementation
 
|-
 
| PCC || 52 || Start Point-of-Care Device Procedure || This transaction is intended to record information about the start of a new device-related procedure. This transaction relies on patient and device identity information scanned/entered at the point-of-care by the front-line clinicians. It also allows clinicians to record information about the type of procedure in which the device was use or implanted. || Trial Implementation
 
|-
 
| PCC || 53 || Complete Point-of-Care Device Procedure || This transaction is intended to record information about the completion of a new device-related procedure. This transaction relies on patient and device identity information scanned/entered at the point-of-care by the front-line clinicians. It also allows clinicians to record information about the type of procedure in which the device was used or implanted. || Trial Implementation
 
|-
 
| PCC || 54 || Search Point-of-Care Device Procedure || This transaction is used to query information about procedures performed at the point-of-care and reported from the point-of-care. || Trial Implementation
 
|-
 
| PCC || 55 || Referral Request || This transaction is used to initiate the referral workflow by providing the referral workflow information and the relevant clinical information known to the Referral Initiator. || Trial Implementation
 
|-
 
| PCC || 56 || Referral Decline || This transaction is used to convey the inability of the Referral Recipient to provide the requested service after the Referral Recipient had already accepted the request. || Trial Implementation
 
|-
 
| PCC || 57 || Referral Outcome || This transaction is used to convey the outcome of the referral, and that completes the referral process. This transaction contains both the indication that the referral is complete, and the final clinical information provided by the Referral Recipient. || Trial Implementation
 
|-
 
| PCC || 58 || Referral Cancellation || This transaction is used to request a cancelation of the referral. It is directed from the Referral Initiator to the Referral Recipient. || Trial Implementation
 
|-
 
| PCC || 59 || Interim Consultation Note || This transaction is used to convey intermittent or preliminary findings as a result of the consultation requested by the Referral Request. The referral is still considered in process, until the Referral Outcome [PCC-57] is successfully sent. || Trial Implementation
 
|-
 
| PCC || 60 || Appointment Notification || This transaction is used to inform the Referral Initiator about a scheduled appointment with the Referral Recipient as part of the fulfillment of the Referral Request. The referral is still considered in progress, until the Referral Outcome transaction [PCC-57] is successfully sent. || Trial Implementation
 
|-
 
| PCC || 61 || No-show Notification || This transaction is used to inform the Referral Initiator that the patient did not show up for an appointment with the Referral Recipient as part of the fulfillment of the Referral Request || Trial Implementation
 
|-
 
| PCC || 62 || Query for Transport Data || Queries for transport data and patient information elements using a query/response. || Trial Implementation
 
|-
 
| PCD || 1 || Communicate PCD Data || Transmit PCD data to enterprise clients from a Device Observation Reporter or Observation Filter and Receive PCD data by a Device Observation Consumer. || Final Text
 
|-
 
| PCD || 2 || Subscribe to PCD Data || Defines predicate for communication of PCD data from Device Observation Filter (DOF) to a Device Observation Consumer (DOC). || Trial Implementation
 
|-
 
| PCD || 3 || Communicate Infusion Order || This transaction contains the information from the Infusion Order Placer, such as caregiver, patient, and pump identification, medication, volume, and rate, for the infusion being programmed. || Final Text
 
|-
 
| PCD || 4 || Report Alarm || This transaction is used by the Alert Reporter to report both unsolicited and subscribed alerts to the Alert Manager || Trial Implementation
 
|-
 
| PCD || 5 || Report Alarm Status || This transaction is used by Alert Management to report one or more dissemination status updates to the Alert Reporter. || Trial Implementation
 
|-
 
| PCD || 6 || Disseminate Alarm || This transaction is used by Alarm Management to disseminate the alarm to the Alarm Communicator. || Trial Implementation
 
|-
 
| PCD || 7 || Report Dissemination Alarm Status || This transaction is used by Alarm Communication to report one or more dissemination status updates to Alarm Management. || Trial Implementation
 
|-
 
| PCD || 8 || (Reserved) ||  || Trial Implementation
 
|-
 
| PCD || 9 || Communicate IDC Observation || Communicate IDC Observation || Trial Implementation
 
|-
 
| PCD || 10 || Communicate Infusion Event Data || Communicates significant clinical and technical events from a Patient Care Device such as infusion pump to an information system which may present it to a clinical user, acts on it in some way or records it. || Trial Implementation
 
|-
 
| PCD || 11 || Reserved || Communicates Alarms, Alarm Status to Alarm Archiver || Trial Implementation
 
|-
 
| PCD || 12 || Retrospective Data Query || The PCD-12 transaction is used to communicate Retrospective Data Query parameters from a Retrospective Data Consumer (RDC) to a Retrospective Data Responder (RDR). A PCD-12 message is initiated by the RDQ Consumer through a message interface to repositories containing retrospective device data. || Trial Implementation
 
|-
 
| PCD || 13 || Retrospective Query Response || The Retrospective Data Response will represent the best efforts of the responder to fulfill the query || Trial Implementation
 
|-
 
| PCD || 14 || (Reserved) ||  ||
 
|-
 
| PCD || 15 || Device Management Information Observation (DMIO) || Contains observations of device identification (unique identification, versions for software, firmware, hardware) and status (power, power source, battery, self-test, etc.). This transaction might not commonly contain patient associated information and would likely be destined for a CMMS and not for an EMR for EHR storage. || Trial Implementation
 
|-
 
| PCD || 16 || Report Location Observation (RLO) || If the location observation information is sourced from an external to device tag and reporting system, then the device to which it is attached has the potential of being unaware of its presence and would likely not contain device associated patient information. Then, the observation will be sourced by the LS and not the medical device. This transactions contains an observation of the location of a device or person or information about the Location Services tag, such as environmental (temperature, humidity, gases, etc.) or operator interactions (buttons, pulls, accelerometers, etc.). || Trial Implementation
 
|-
 
| PCD || 17 || Assert Device-Patient Association ||  ||
 
|-
 
| PCD || 18 || Assert Device-Patient Disassociation ||  ||
 
|-
 
| PCD || 19 || Query Device-Patient Associations ||  ||
 
|-
 
| PCD || 20 || Register Device ||  ||
 
|-
 
| PHARM || 1 || Query Pharmacy Documents || This transaction defines how a querying actor has to query the Community Pharmacy Manager for prescriptions (PRE) and their related documents. Related documents are Pharmaceutical Advice (PADV) and Dispense (DIS) documents. || Trial Implementation
 
|-
 
| PHARM || 2 || Query Administration Requests || Request for individual administration actions to be performed ||
 
|-
 
| PHARM || 3 || Report Administration Results || Report on the outcome of each single administration event ||
 
|-
 
| PHARM || 4 || Request decoded barcode content || The Barcode reader / consumer has scanned the barcode and sends the encoded barcode sequence to the Barcode Processor requesting the decoded barcode information. The barcode processor sends the decoded barcode information as a response to the Barcode reader / consumer as structured information (e.g., GTIN=8712345670012, batch number = 12345, expiry date = 2020-11-12.) ||
 
|-
 
| PHARM || H1 || Prescription Order || Transaction PHARM-H1 is used by the Prescription Placer and Pharmaceutical Adviser Actors. || Trial Implementation
 
|-
 
| PHARM || H2 || Validated Order || Transaction PHARM-H2 is used by the Pharmaceutical Adviser and Prescription Placer and Medication Dispenser Actors. || Trial Implementation
 
|-
 
| PHARM || H3 || Medication Preparation Report || Transaction PHARM-H3 is used by the Medication Dispenser and Medication Administration Informer and Prescription Placer and Pharmaceutical Adviser Actors. || Trial Implementation
 
|-
 
| PHARM || H4 || Administration Report || Transaction PHARM-H4 is used by the Medication Administration Informer, Prescription Placer, Medication Dispenser and Pharmaceutical Adviser Actors. || Trial Implementation
 
|-
 
| PHARM || H5 || Advance Prescription Notification || Transaction PHARM-H5 is used for the Prescription Placer to notify the Medication Dispenser and Administration Informer or a prescription order, to allow for preparation in advance. || Trial Implementation
 
|-
 
| PHARM || H6 || Validated Order Confirmation || Transaction PHARM-H6 is used for the Pharmaceutical Adviser to notify the Medication Administration Informer that the prescription order is validated, to allow for administration preparation. || Trial Implementation
 
|-
 
| QRPH || 1 || Reserved ||  || Reserved
 
|-
 
| QRPH || 2 || Reserved ||  || Reserved
 
|-
 
| QRPH || 3 || Reserved ||  || Reserved
 
|-
 
| QRPH || 4 || Reserved ||  || Reserved
 
|-
 
| QRPH || 5 || Reserved ||  || Reserved
 
|-
 
| QRPH || 6 || Reserved ||  || Reserved
 
|-
 
| QRPH || 7 || Reserved ||  || Reserved
 
|-
 
| QRPH || 8 || Reserved ||  || Reserved
 
|-
 
| QRPH || 9 || Reserved ||  || Reserved
 
|-
 
| QRPH || 10 || RetrieveProtocolDef - Retired ||  || Retired
 
|-
 
| QRPH || 11 || EnterPatientRequest - Retired ||  || Retired
 
|-
 
| QRPH || 12 || PatientScreeningVisitsScheduled - Retired ||  || Retired
 
|-
 
| QRPH || 13 || RecordPatientScreeningVisit - Retired ||  || Retired
 
|-
 
| QRPH || 14 || EnrollPatientRequest - Retired ||  || Retired
 
|-
 
| QRPH || 15 || PatientStudyVisitsScheduled - Retired ||  || Retired
 
|-
 
| QRPH || 16 || RecordPatientStudyVisit - Retired ||  || Retired
 
|-
 
| QRPH || 17 || AmendProtocolDef - Retired ||  || Retired
 
|-
 
| QRPH || 18 || AlertProtocolState - Retired ||  || Retired
 
|-
 
| QRPH || 19 || Archive Data ||  ||
 
|-
 
| QRPH || 20 || Retrieve Process Definitions || RetrieveProcessDefinitions enables access to one or more process definitions specified by an identifier or other query criteria. This transaction is implemented by the ProcessDefinitionManager and used by both the: ProcessActivityExecutor – to examine processes it may be interested in becoming an active participant and,ProcessStateManager – to deploy processes it wishes to manage || Trial Implementation
 
|-
 
| QRPH || 21 || Subscribe || Subscribe allows either a ProcessStateManager or ProcessActivityExecutor to optionally establish a subscription to new or amended process definitions of matching interest, as they become available from a ProcessDefinitionManager. || Trial Implementation
 
|-
 
| QRPH || 22 || Publish Process Definitions || This transaction involves a Process Definition Manager publishing process definitions to a Process Activity Executor or Process State Manager. || Trial Implementation
 
|-
 
| QRPH || 23 || Initiate Activity || InitiateActivity allows the ProcessActivityExecutor to be in control of the lifecycle of activities it performs, e.g., an EHR may want to use it’s own task processor and interfaces to create and manage the activities it needs to perform as part of a process managed by the ProcessStateManager. || Trial Implementation
 
|-
 
| QRPH || 24 || Receive Process State Alert || ReceiveProcessStateAlert provides either the ProcessStateManager or ProcessActivityExecutor the ability to notify each other of unscheduled events that effect the state of the process, e.g., an EHR patient withdrawing from a clinical trial or, a study being placed on hold. ||
 
|-
 
| QRPH || 25 || Initiate Process || InitiateProcess enables a ProcessActivityExecutor to initiate a new process to be managed by a ProcessStateManager, e.g., an EHR entering a new patient candidate in a clinical trial being managed by a research sponsor. || Trial Implementation
 
|-
 
| QRPH || 26 || Retrieve Activities || RetrieveActivities enables a ProcessActivityExecutor to retrieve the current set of activities it needs to execute as part of a process managed by a ProcessStateManager. || Trial Implementation
 
|-
 
| QRPH || 27 || Update Activity || Update Activity allows a ProcessActivityExecutor to provide an update on activity’s state or data to a ProcessStateManager for a process it is a participant in. || Trial Implementation
 
|-
 
| QRPH || 28 || Send Process State Alert || SendProcessStateAlert provides either the ProcessStateManager or ProcessActivityExecutor the ability to notify each other of events that effect the state of the process, e.g., an EHR patient withdrawing from a clinical trial or, a study being placed on hold. || Trial Implementation
 
|-
 
| QRPH || 29 || Request Medical Knowledge || The Retrieve Medical Knowledge Transaction specifies the query and reciept of medial knowledge from an authoritative source (e.g. Publc Health Authority). This medical knowledge is not patient specific, though the tetrieval query for the knowledge may contain patient-specific content. || Trial Implementation
 
|-
 
| QRPH || 30 || Send Distribution Message || The Send Distribution Message Transaction supports the distribution of content from an authoritative source (e.g. Public Health Aurhority. This may be leveraged for emergency distribution messages and for informative health status for a monitored population (e.g. hearing screening conformance status.) || Trial Implementation
 
|-
 
| QRPH || 31 || SendExportDocument || Sends a document that needs to be redacted. The document sent includes an identifier for the Extraction Specification to be applied. || Deprecated w/RSP
 
|-
 
| QRPH || 32 || ReturnRedactedDocument || This transaction returns a redacted document. It also includes the ID of the original document and the ID of the extraction specification used to create the redacted document. || Deprecated w/RSP
 
|-
 
| QRPH || 33 || RetrieveExtractionSpecification || This transaction is a query and response. The ID of an Extraction Specification is sent to the Extraction Specification Manager and the Extraction Specification Manager returns the corresponding Extraction Specification document. || Deprecated w/RSP
 
|-
 
| QRPH || 34 || NANIFeed || This transaction communicates event information, including corroborating demographic data, after a newborn is admitted or discharged. ||
 
|-
 
| QRPH || 35 || NANIPublish || This transaction constrains and extends the Patient Identity Feed [ITI-8] transaction from IHE IT Infrastructure Technical Framework and is used by Admission Information Source actor to send content to Newborn Admission Notification Manager. ||
 
|-
 
| QRPH || 36 || ArchiveSourceDocuments || This transaction involves a Form Filler archiving content to a Form Archiver, before issuing a Retrieve Form request to a Form Manager. The content of this transaction is similar to that of Retrieve Form, ITI-34. || Trial Implementation
 
|-
 
| QRPH || 37 || BFDRFeed || This transaction is used to communicate clinician-sourced birth and fetal death information from the Information Source to the Information Recipient. This transaction may alternatively be initiated by a Form Receiver Message Exporter and communicated to the Information Recipient. This transaction uses the Health Level Seven International (HL7) Version 2.5.1 Implementation Guide (IG): Reporting Birth and Fetal Death information From the EHR to Vital Records Draft Standard for Trial Use (DSTU).or This transaction transmits the HL7 V2.6 formatted message containing the Birth and Fetal Death Reporting information  || Trial Implementation
 
|-
 
| QRPH || 38 || VRDRFeed || This transaction is used to communicate clinician-sourced death information from the Information Source to the Information Recipient. This transaction may alternatively be initiated by a Form Receiver Message Exporter and communicated to the Information Recipient. This transaction uses the Health Level Seven International (HL7) Version 2.5.1 Implementation Guide (IG): Vital Records Death Reporting Draft Standard for Trial Use (DSTU) US Realm. || Trial Implementation
 
|-
 
| QRPH || 39 || HWFeed || This transaction is used to communicate healthy weight surveillance information from the Healthy Weight Information Source to the Healthy Weight Information Recipient. This transaction may alternatively be initiated by a Form Receiver Message Exporter and communicated to the Healthy Weight Information Recipient. This transaction uses the HL7 Version 2.5.1 Implementation Guide: Height and Weight Report, Release 1 (US Realm) to communicate this content. The transaction payload is limited to those attributes defined by this implementation guide and does not include the plan and risk assessment content. || Trial Implementation
 
|-
 
| QRPH || 40 || Retrieve Research Study List || This transaction is used by the Research Information Consumer to fetch a patient context specific list of applicable research studies from the Research Information Source. The patient context is determined by processes outside the scope of this transaction. || Deprecated w/RM Profile
 
|-
 
| QRPH || 41 || Research Information Subscribe || Transaction QRPH-41 is used by the Research Information Consumer and the Research Information Source actors. The transaction uses the Publish/Subscribe Infrastructure as described in IHE ITI TF-3: 4.4. The Research Information Source represents a combined Publisher/Notification Broker and the Research Information Consumer represents a Combined Subscriber/Notification recipient, as described in IHE ITI TF-3: 4.4.1.4. || Deprecated w/RM Profile
 
|-
 
| QRPH || 42 || Research Information Notify || Transaction QRPH-42 is used by the Research Information Consumer and the Research Information Source actors. The transaction uses the Publish/Subscribe Infrastructure as described in IHE ITI TF-3: 4.4. The Research Information Source represents a combined Publisher/Notification Broker and the Research Information Consumer represents a Combined Subscriber/Notification recipient, as described in IHE ITI TF-3: 4.4.1.4. || Deprecated w/RM Profile
 
|-
 
| QRPH || 43 || Retrieve Data Element List || This transaction is used by the Metadata Consumer to retrieve a list of Data Elements from the Metadata Source matching the given selection criteria. || Trial Implementation
 
|-
 
| QRPH || 44 || Retrieve Metadata || This transaction is used by the Metadata Consumer to retrieve the metadata of a selected Data Element from the Metadata Registry. The Metadata Consumer has previously obtained the ID of the Data Element he is looking. He may have used the RetrieveDataElementList [QRPH-43] transaction to obtain the ID of the Data Element he is looking for. || Trial Implementation
 
|-
 
| QRPH || 45 || Communicate Hearing Screening Data || This transaction is used to communicate hearing screening result information. || Trial Implementation
 
|-
 
| QRPH || 46 || BFDRQuery ||  ||
 
|-
 
| QRPH || 47 || VRDRQuery ||  ||
 
|-
 
| QRPH || 48 || Mobile Retrieve Form || This message uses the HTTP GET method on the target endpoint to retrieve and launch a URL form. || Trial Implementation
 
|-
 
| QRPH || 49 || Mobile Retrieve Capability || This transaction is used to request a statement of behaviors from a Data Responder. || Trial Implementation
 
|-
 
| QRPH || 50 || Mobile Authorize Form || This transaction is used to request authorization for the FHIR resource server from a Data Responder. || Trial Implementation
 
|-
 
| QRPH || 51 || Mobile Retrieve Access Token || This message uses the HTTP POST method on the target endpoint to convey desire to retrieve access. || Trial Implementation
 
|-
 
| QRPH || 52 || Mobile Populate Form || This message uses the HTTP POST method on the target endpoint to convey specific desired resources. || Trial Implementation
 
|-
 
| QRPH || 53 || ADX POST Content || The POST Content transaction is used by the Content Creator to perform an HTTP POST request on the Content Consumer. || Trial Implementation
 
|-
 
| QRPH || Y1 || Retrieve Protocol Def-Deprecated || Retrieve Protocol Def || Deprecated
 
|-
 
| QRPH || Y2 || Enter Patient Request || Enter Patient Request || Deprecated
 
|-
 
| QRPH || Y3 || Patient Screening Visits Scheduled || Patient Screening Visits Scheduled || Deprecated
 
|-
 
| QRPH || Y4 || Record Patient Screening Visit || Record Patient Screening Visit || Deprecated
 
|-
 
| QRPH || Y5 || Enroll Patient Request || Enroll Patient Request || Deprecated
 
|-
 
| QRPH || Y6 || Patient Study Visits Scheduled || Patient Study Visits Scheduled || Deprecated
 
|-
 
| QRPH || Y7 || Record Patient Study Visit || Record Patient Study Visit || Deprecated
 
|-
 
| QRPH || Y8 || Amend Protocol Definition || Amend Protocol Definition || Deprecated
 
|-
 
| QRPH || Y9 || Alert Protocol State || Alert Protocol State || Deprecated
 
|-
 
| RAD || 1 || Patient Registration || The ADT system registers and/or admits a patient and forwards the information to other information systems. || Final Text
 
|-
 
| RAD || 2 || Placer Order Management || The Order Placer informs the Order Filler of the initiation or cancellation of an order. The Placer/Filler Order Management transaction will sometimes be referred to as -New when a new order is being initiated, or as -Cancel when an existing order is canceled. || Final Text
 
|-
 
| RAD || 3 || Filler Order Management || The Order Filler informs the Order Placer of the initiation, cancellation, or change in the status of an order. The Placer/Filler Order Management transaction will sometimes be referred to as -New when a new order is being initiated, or as -Cancel when an existing order is canceled. || Final Text
 
|-
 
| RAD || 4 || Procedure Schedule || Schedule information is sent from the Department System Scheduler/Order Filler to the Image Manager. || Final Text
 
|-
 
| RAD || 5 || Query Modality Workflist || Based on a query entered at the Acquisition Modality, a modality worklist is generated listing all the items that satisfy the query. This list of Scheduled Procedure Steps with selected demographic information is returned to the Acquisition Modality. || Final Text
 
|-
 
| RAD || 6 || Modality Performed Procedure Step in Progress || An Acquisition Modality notifies the Performed Procedure Step Manager of the start of a new Procedure Step and the PPS Manager informs the Department System and Image Manager. || Final Text
 
|-
 
| RAD || 7 || Modality Performed Procedure Step Completed/Discontinued || An Acquisition Modality notifies the Performed Procedure Step Manager of the completion of a Procedure Step and the PPS Manager informs the Department System and Image Manager. || Final Text
 
|-
 
| RAD || 8 || Modality Image Stored (or Modality Images Stored?) || An Acquisition Modality sends acquired or generated images to the Image Archive. || Final Text
 
|-
 
| RAD || 9 || Modality Presentation State Stored || An Acquisition Modality sends acquired or generated images to the Image Archive. || Final Text
 
|-
 
| RAD || 10 || Storage Committement || An Acquisition Modality or Image Creator requests that the Image Manager take responsibility for the specified DICOM objects (images, GSPS objects, Key Image Notes, Evidence Documents or any combination thereof) that the requestor stored in the Image Archive. || Final Text
 
|-
 
| RAD || 11 || Image Availability Query (or Images Availability Query?) || The Department System Scheduler/Order Filler asks the Image Manager if a particular image or image series is available. || Final Text
 
|-
 
| RAD || 12 || Patient Update || The ADT Patient Registration System informs the Order Placer and the Department System Scheduler/Order Filler of new information for a particular patient. The Department System Scheduler may then further inform the Image Manager. || Final Text
 
|-
 
| RAD || 13 || Procedure Update || The Department System Scheduler/Order Filler sends the Image Manager updated order or procedure information. || Final Text
 
|-
 
| RAD || 14 || Query Images || An Image Display queries the Image Archive for a list of entries representing images by patient, study, series, or instance. || Final Text
 
|-
 
| RAD || 15 || Query Presentation States || An Image Display queries the Image Archive for a list of entries representing image Grayscale Softcopy Presentation States (GSPS) by patient, study, series, or instance. || Final Text
 
|-
 
| RAD || 16 || Retrieve Images || An Image Display or an Imaging Document Consumer requests and retrieves a particular image or set of images from the Image Archive or an Imaging Document Source, respectively. || Final Text
 
|-
 
| RAD || 17 || Retrieve Presentation States || An Image Display or an Imaging Document Consumer requests and retrieves the Grayscale Softcopy Presentation State (GSPS) information for a particular image or image set || Final Text
 
|-
 
| RAD || 18 || Creator Images Stored || An Image Creator sends new images to the Image Archive. || Final Text
 
|-
 
| RAD || 19 || Creator Presentation State Stored || An Image Creator requests that the Image Archive store the created Grayscale Softcopy Presentation State objects. || Final Text
 
|-
 
| RAD || 20 || Creator Procedure Step in Progress || An Image Creator notifies the Performed Procedure Step Manager of the start of a new Procedure Step and the PPS Manager informs the Department System and Image Manager. || Final Text
 
|-
 
| RAD || 21 || Creator Procedure Step Completed || An Image Creator notifies the Performed Procedure Step Manager of the completion of a Procedure Step and the PPS Manager informs the Department System and Image Manager. || Final Text
 
|-
 
| RAD || 22 || Intentionally Left Blank ||  || Final Text
 
|-
 
| RAD || 23 || Print Request with Presentation LUT || A Print Composer sends a print request to the Print Server specifying Presentation LUT information. || Final Text
 
|-
 
| RAD || 24 || Report Submission || A Report Creator sends a draft or final report to the Report Manager. || Final Text
 
|-
 
| RAD || 25 || Report Issuing || A Report Manager sends a draft or final Report to the Report Repository. || Final Text
 
|-
 
| RAD || 26 || Query Reports || A Report Reader provides a set of criteria to select the list of entries representing reports by patient, study, series, or report known by the Report Repository or External Report Repository Access. || Final Text
 
|-
 
| RAD || 27 || Retrieve Reports || A Report Reader or an Imaging Document Consumer requests and retrieves a diagnostic report from the Report Repository, External Report Repository Access or an Imaging Document Source. || Final Text
 
|-
 
| RAD || 28 || Structured Report Export || A Report Manager composes an HL7 Result transaction by mapping from DICOM SR and transmits it to the Enterprise Report Repository for storage. || Final Text
 
|-
 
| RAD || 29 || Key Image Notes Stored || An Acquisition Modality or an Image Creator sends a Key Image Note to the Image Archive || Final Text
 
|-
 
| RAD || 30 || Query Key Image Notes || An Image Display queries the Image Archive for a list of entries representing Key Image Notes by patient, study, series, or instance. || Final Text
 
|-
 
| RAD || 31 || Retrieve Key Image Notes || An Image Display or an Imaging Document Consumer requests and retrieves a Key Image Note from the Image Archive or an Imaging Document Source, respectively. || Final Text
 
|-
 
| RAD || 32 || Authenticate Note || Any two actors exchange certificates in order to validate the identity of another node. || Deprecated
 
|-
 
| RAD || 33 || Maintain Time || Synchronize the local time with the time maintained by the Time Server. || Deprecated
 
|-
 
| RAD || 34 || Record Audit Event || Create and transmit an Audit Record. || Deprecated
 
|-
 
| RAD || 35 || Charge Posted || The Department System Scheduler/Order Filler sends descriptions of potential procedure and material changes. || Final Text
 
|-
 
| RAD || 36 || Account Management || The ADT Patient Registration Actor informs Charge Processor about creation, modification and ending of patient s account. || Final Text
 
|-
 
| RAD || 37 || Query Postprocessing Worklist || Based on a query from a worklist client (Image Creator), a worklist is generated by the worklist manager (Post-Processing Manager) containing either Post-Processing or Computer Aided Detection (CAD) workitems that satisfy the query. Workitems are returned in the form of a list of General Purpose Scheduled Procedure Steps. || Final Text
 
|-
 
| RAD || 38 || Workitem Claimed || A worklist client (Image Creator) notifies the worklist provider (Post-Processing Manager) that it has claimed the workitem (i.e. started a General Purpose Scheduled Procedure Step). || Final Text
 
|-
 
| RAD || 39 || Workitem Performed Procedure Step in Progress || A worklist client (Image Creator) notifies the worklist provider (Post-Processing Manager) that it has started work (i.e. created a General Purpose Performed Procedure Step). || Final Text
 
|-
 
| RAD || 40 || Workitem Performed Procedure Step Completed || A worklist client (Image Creator) notifies the worklist provider (Post-Processing Manager) of the completion of a General Purpose Performed Procedure Step. || Final Text
 
|-
 
| RAD || 41 || Workitem Completed || A worklist client (Image Creator) notifies the worklist provider (Post-Processing Manager) that it has finished the workitem (i.e. completed a General Purpose Scheduled Procedure Step). || Final Text
 
|-
 
| RAD || 42 || Performed Workstatus Update || The worklist provider informs other interested actors of the on-going status and completion of performed work. || Final Text
 
|-
 
| RAD || 43 || Evidence Documents Stored || An Acquisition Modality or Image Creator sends measured or derived diagnostic evidence in the form of a DICOM Structured Report to the Image Archive. || Final Text
 
|-
 
| RAD || 44 || Query Evidence Documents || An Image Display queries the Image Archive for a list of entries representing Evidence Documents. || Final Text
 
|-
 
| RAD || 45 || Retrieve Evidence Docuements || A user of Evidence Documents (Image Display, Report Creator or Report Reader) or an Imaging Document Consumer requests and retrieves an Evidence Document from the Image Archive or an Imaging Document Source, respectively. || Final Text
 
|-
 
| RAD || 46 || Query Reporting Worklist || Based on a query from a Report Creator worklist client, a worklist is generated by the Report Manager containing reporting task workitems that satisfy the query. Workitems are returned in the form of a list of General Purpose Scheduled Procedure Steps. || Final Text
 
|-
 
| RAD || 47 || Distribute Imaging Information on Media || A source actor (Portable Media Creator) writes image data, other evidence objects and reports onto a piece of interchange media. The media is physically transported to another actor (Portable Media Importer, Image Display, Report Reader, Display or Print Composer) which then imports, displays or prints the evidence objects and reports. The media can also be provided to a patient or a referring physician for web-based viewing. || Final Text
 
|-
 
| RAD || 48 || Appointment Notification || Department System Scheduler/Order Filler sends the Order Placer actor the date and time of the appointment(s) related to one or more Scheduled Procedure Step(s). || Final Text
 
|-
 
| RAD || 49 || Instance Availability Notification || The Image Manager/Image Archive notifies interested workflow actors (such as the Department System Scheduler/Order Filler, Post- Processing Manager and Report Manager) about the availability status of instances at specified storage locations. || Final Text
 
|-
 
| RAD || 50 || Store Instances || An Export Selector sends to an Export Manager instances that are to be de-identified, pseudonymized and exported. || Final Text
 
|-
 
| RAD || 51 || Store Export Selection  || An Export Selector sends to an Export Manager an instance of a Key Object Selection Document that references a list of instances that are to be de-identified, pseudonymized and exported || Final Text
 
|-
 
| RAD || 52 || Store Additional Teaching File Information || An Export Selector sends to an Export Manager instances containing additional information about the instances that are to be exported. || Final Text
 
|-
 
| RAD || 53 || Export Instances || An Export Manager sends to a Received instances that have been exported || Final Text
 
|-
 
| RAD || 54 || Provide and Register Document Set || An Imaging Document Source actor initiates the Provide and Register Imaging Document Set transaction. For each document in the Submission Set, the Imaging Document Source actor provides both the documents as an opaque octet stream and the corresponding meta-data to the Document Repository. The Document Repository is responsible to persistently store these documents, and to register them in the Document Registry using the Register Documents transaction by forwarding the document meta-data received from the Imaging Document Source Actor. [RAD-54, derived from ITI-15]. || Deprecated
 
|-
 
| RAD || 55 || Wado Retrieve || A WADO Retrieve transaction is issued by an Imaging Document Consumer to an Imaging Document Source to retrieve DICOM objects over HTTP/HTTPS protocol [RAD-55]. || Final Text
 
|-
 
| RAD || 56 || Spatial Registrations Stored || An Acquisition Modality or Evidence Creator stores transformation information for registering two image data sets in the same coordinate system for further processing or fused display. || Trial Implementation
 
|-
 
| RAD || 57 || Blending Presentation States Stored || An Acquisition Modality or Evidence Creator stores presentation information on registered image data sets for fused display. || Trial Implementation
 
|-
 
| RAD || 58 || Retrieve Spatial Registrations || An Image Display retrieves from an Image Archive the transformation information to be applied to image data sets for further processing or fused display. || Trial Implementation
 
|-
 
| RAD || 59 || Import Procedure Step in Progress || The Performed Procedure Step Manager receives progress notification of an importation Procedure Step and in turn notifies the Order Filler, Image Manager and the Report Manager || Final Text
 
|-
 
| RAD || 60 || Import Procedure Step Completed/Discontinued || The Performed Procedure Step Manager receives completion notification of an importation Procedure Step and in turn notifies the Order Filler, Image Manager and the Report Manager || Final Text
 
|-
 
| RAD || 61 || Imported Instances Stored (or Imported Objects Stored) || A system importing DICOM Objects or digitized hardcopy sends imported DICOM Composite Objects to the Image Archive || Final Text
 
|-
 
| RAD || 62 || Store Dose Information  || An Acquisition Modality sends Dose objects to an Image Manager/Archive for storage so they can be later used for monitoring or analysis of patient radiation exposure. || Final Text
 
|-
 
| RAD || 63 || Submit Dose Information .  || A Dose Information Reporter sends Dose objects to a Dose Register for subsequent compilation, monitoring and analysis of population radiation exposure and current practices. Dose objects will often be de-identified prior to submission. || Final Text
 
|-
 
| RAD || 64 || Query Dose Information || A Dose Information Reporter or Dose Information Consumer requests and receives from the Image Manager/Archive a list of instance metadata describing Dose objects matching a specified filter. || Final Text
 
|-
 
| RAD || 65 || Retrieve Dose Information  || A Dose Information Reporter or Dose Information Consumer requests and receives from the Image Manager/Archive specified instances of Dose objects. || Final Text
 
|-
 
| RAD || 66 || (Image) Rejection Note Stored || Create and send a manifest referencing images that are rejected for quality or patient safety reasons, rejected for incorrect modality worklist selection, or deleted due to data retention expiration. The manifest can be used to hide or provide rejected images later in routine use, based on specific configuration. || Trial Implementation
 
|-
 
| RAD || 67 || Media Information Stored || Media Information Stored || Trial Implementation
 
|-
 
| RAD || 68 || Provide and Register Imaging Document Set – MTOM/XOP  || Provide & Register Imaging Doc Set-MTOM/XOP || Final Text
 
|-
 
| RAD || 69 || Retrieve Imaging Document Set || Retrieve Imaging Doc Set || Final Text
 
|-
 
| RAD || 70 || Image Manager Instances Stored || An Image Manager/Archive supporting the Multiple Identity Resolution option sends DICOM SOP Instances to another Image Manager/Archive. || Trial Implementation
 
|-
 
| RAD || 71 || Image Manager Storage Commitment || A requestor Image Manager/Archive supporting the Multiple Identity Resolution option requests that the receiving Image Manager/Archive confirm ownership for the specified DICOM objects (images, GSPS objects, Key Image Notes, Evidence Documents or any combination thereof) that the requestor stored in the Image Manager/Archive, thus allowing the requestor Image Manager/Archive to delete those objects now owned by the receiving Image Manager/Archive. || Trial Implementation
 
|-
 
| RAD || 72 || Image Manager Instances Query || An Image Manager/Archive supporting the Multiple Identity Resolution option queries another Image Manager/Archive for a list of entries representing DICOM SOP Instances. || Trial Implementation
 
|-
 
| RAD || 73 || Image Manager Instances Retrieval || An Image Manager/Archive supporting the Multiple Identity Resolution option requests and retrieves a particular SOP Instance or set of SOP Instances from another Image Manager/Archive. || Trial Implementation
 
|-
 
| RAD || 74 || Replacement Instances Stored || A Change Requester send new updated instances with corrected header information to an Image Manager/Image Archive || Final Text
 
|-
 
| RAD || 75 || Cross Gateway Retrieve Imaging Document Set || The scope of the Cross Gateway Retrieve Imaging Document Set transaction is semantically the same as the Retrieve Imaging Document Set transaction [RAD-69]. Differences from the Retrieve Imaging Document Set transactions are: - The Cross Gateway Retrieve Imaging Document Set is between an Initiating Imaging Gateway and a Responding Imaging Gateway - The ‘homeCommunityId’ parameter is required. This means that the homeCommunityId parameter which is conditionally required on the Retrieve Imaging Document Set transaction is required by this transaction - The Responding Imaging Gateway is required to support Asynchronous Web Services Exchange on the Cross Gateway Retrieve Imaging Document Set || Final Text
 
|-
 
| RAD || 76 || Query For Study || The Importer queries the Image Manager/Archive to find out if a study already exists. || Trial Implementation
 
|-
 
| RAD || 77 || Query For Patient ID || The Importer queries the Image Manager/Archive to find the local patient identifier corresponding to the patient demographics in the objects to be imported. || Trial Implementation
 
|-
 
| RAD || 78 || Request Filling of Order || This transaction is used by the Importer to create and fill an order with the DSS/Order Filler. The DSS/Order Filler in turn informs the Order Placer about the order it creates and then returns the placed and filled order information to the Importer. Once the order has been filled, the Importer cannot change or cancel it. Only the DSS/Order Filler can change or cancel the order. || Trial Implementation
 
|-
 
| RAD || 79 || Import Instructions Request || This transaction is used by the Importer to send Import Instructions directly to an Image Manager/Archive in an order message. Once the order message has been sent, the Importer cannot change or cancel it. || Trial Implementation
 
|-
 
| RAD || 80 || Query UPS Worklist  || This transaction is used to create a new workitem. The contents of the workitem describe both the task to be performed and associated information such as references to the input data, the order and accession number with which the task is associated, etc. || Trial Implementation
 
|-
 
| RAD || 81 || Claim UPS Workitem || This transaction is used to find workitems of interest. The contents of workitems describe both the task to be performed and related information such as references to the input data, the order and accession number with which the task is associated. || Trial Implementation
 
|-
 
| RAD || 82 || Complete UPS Workitem || This transaction is used to take “ownership” of a selected workitem by telling the managing system to change the state to IN PROGRESS. This permits other worklist users to detect that this workitem has been claimed and locks out others from claiming or modifying the workitem. || Trial Implementation
 
|-
 
| RAD || 83 || Create UPS Workitem || This transaction is used to retrieve the contents (i.e., values of a requested list of attributes) from a workitem. || Trial Implementation
 
|-
 
| RAD || 84 || Update UPS Workitem || This transaction is used by a workitem performer to request that the workitem manager modify the contents of a workitem it manages. || Trial Implementation
 
|-
 
| RAD || 85 || Manage UPS Subscription || This transaction is used by a work performer to tell the managing system (e.g., a Post Processing Manager) that the contents of the selected workitem (e.g., references to result objects, etc.) have been finalized and the state should be changed to a Final State of either COMPLETED or CANCELED. Once in a Final State, further updates to the workitem are not permitted. || Trial Implementation
 
|-
 
| RAD || 86 || Send UPS Notification || This transaction is used by an interested actor to subscribe (or unsubscribe) to notifications for one or more UPS workitems. || Trial Implementation
 
|-
 
| RAD || 87 || Get UPS Workitem Contents || This transaction is used to notify systems ofthe state or contents of a given UPS workitem. || Trial Implementation
 
|-
 
| RAD || 88 || Request UPS Workitem Cancelation || This transaction is used by an interested actor to request that a workitem be canceled. || Trial Implementation
 
|-
 
| RAD || 89 || Start Application || This transaction is used to launch a Hosted Application. || Trial Implementation
 
|-
 
| RAD || 90 || Stop Application || This transaction is used to shut down a Hosted Application. || Trial Implementation
 
|-
 
| RAD || 91 || Bring Application Front || This transaction is used to ask the Hosted Application to bring its Graphical User Interface (GUI) window to the front (not be obscured by other windows in the workstation’s GUI) and come into focus(take control of the user input devices) and resize the GUI if requested. || Trial Implementation
 
|-
 
| RAD || 92 || Start Task || This transaction is used to instruct a Hosted Application to start working on a task. || Trial Implementation
 
|-
 
| RAD || 93 || Get Task Details || This transaction retrievesthe contents of a Unified Procedure Step (UPS) instance using the Application Hosting interface. || Trial Implementation
 
|-
 
| RAD || 94 || Get Task Data || This transaction is used to retrieve data from the Hosting System. || Trial Implementation
 
|-
 
| RAD || 95 || Notify Task Status  || This transaction is used to inform the Hosting System of notable events during the processing of an assigned task || Trial Implementation
 
|-
 
| RAD || 96 || Notify Task Results || This transaction is used to inform the Hosting System that the Hosted Application has data available for storage, created through the processing of the Application’s assigned task. || Trial Implementation
 
|-
 
| RAD || 97 || Get Task Results || This transaction is used to retrieve data from the Hosted Application || Trial Implementation
 
|-
 
| RAD || 98 || Notify Task Complete || This transaction is used to inform the Hosting System that the Hosted Application has completed processing of its assigned task. || Trial Implementation
 
|-
 
| RAD || 99 || Finalize Task || This transaction is used to request an Application to finalize a task by releasing all remaining resources consumed by the task and going into the IDLE state. || Trial Implementation
 
|-
 
| RAD || 100 || Cancel Task || This transaction is used to cancel task processing in a Hosted Application. || Trial Implementation
 
|-
 
| RAD || 101 || Suspend Application || This transaction is used to suspend a running Application. || Trial Implementation
 
|-
 
| RAD || 102 || Resume Application || This transaction is used to resume task processing in a Hosted Application that had been suspended. || Trial Implementation
 
|-
 
| RAD || 103 || Retrieve Imaging Report Template || A Requester retrieves a template from a Responder. || Trial Implementation
 
|-
 
| RAD || 104 || Store Imaging Report Template || A Sender stores a report template to a Receiver. || Trial Implementation
 
|-
 
| RAD || 105 || Query Imaging Report Templates || A Requester queries for a list of templates from a Responder. || Trial Implementation
 
|-
 
| RAD || 106 || Invoke Image Display || Invokes the display of DICOM image studies. || Trial Implementation
 
|-
 
| RAD || 107 || Wado-RS Retrieve || The WADO-RS Retrieve transaction accesses DICOM SOP Instances via an HTTP interface. || Trial Implementation
 
|-
 
| RAD || 108 || Store Instances over the Web || Store one or more DICOM instances using DICOMweb STOW-RS. || Trial Implementation
 
|-
 
| RAD || 109 || Open Event Channel || Opens an event channel that can be used to send back events such as notifications. || Trial Implementation
 
|-
 
| RAD || 110 || Store Radiopharmaceutical Activity Information (or Store Activity Information-from list on ftp) || Send details of Radiopharmaceutical Administration Events encoded in DICOM SR using DICOM Store. || Trial Implementation
 
|-
 
| RAD || 111 || Create XDW Read || The Create XDW Read transaction starts a Remote Read workflow. A Create XDW Read transaction carries the Remote Reading Workflow Document and the Read Request document and associated metadata. || Trial Implementation
 
|-
 
| RAD || 112 || Cancel XDW Read || This transaction cancels an ongoing Remote Reading Workflow. || Trial Implementation
 
|-
 
| RAD || 113 || Accept/Reject XDW Report || Used to acknowledge production or revision of a Final Report. || Trial Implementation
 
|-
 
| RAD || 114 || Revoke XDW Assignment || This transaction acknowledges the production of a Final Report (or Preliminary Report) or requests the revision of a Final Report. || Trial Implementation
 
|-
 
| RAD || 115 || Assign XDW Read || This transaction records the result of assignment in a Remote Reading Workflow Document. The result can be an assignment to a specific Task Performer or the failure of that assignment. || Trial Implementation
 
|-
 
| RAD || 116 || Accept/Reject or Release XDW Read || This transaction allows a Task Performer to accept or reject the assignment of a Remote Read. This transaction also allows a Task Performer that claimed a Remote Read to release it. || Trial Implementation
 
|-
 
| RAD || 117 || Update XDW Read || This transaction makes update(s) to the Perform Remote Read task without changing the status of the task (e.g., attach a Preliminary Report, attach an Addendum to the Final Report, attach the Final Report if the Task Requester asked only for a Preliminary Report, etc.). The Preliminary Report, the Final Report or the Addendum to the Final Report can be submitted by using this transaction or by using a Provide and Register Document Set-b [ITI-41] transaction. || Trial Implementation
 
|-
 
| RAD || 118 || Subscribe Remote Read Task || This transaction allows the Subscriber actor to subscribe for notification of updates to specific tasks. The Subscriber actor will receive notifications for events of interest in separate transactions. || Trial Implementation
 
|-
 
| RAD || 119 || Claim XDW Read || This transaction allows a Task Performer to claim a Read without a previous assignment. || Trial Implementation
 
|-
 
| RAD || 120 || Complete XDW Read || This transaction marks the Perform Remote Read task as completed with a reference to the Final Report (or the Preliminary Report) produced, and document inputs used. || Trial Implementation
 
|-
 
| RAD || 121 || Store Protocol || Transfers a DICOM Defined Procedure Protocol instance from a Sender to a Receiver. || Trial Implementation
 
|-
 
| RAD || 122 || Query Protocol || Requests and receives metadata about Protocol instances matching a specified filter. || Trial Implementation
 
|-
 
| RAD || 123 || Retrieve Protocol || Retrieves a DICOM Defined Procedure Protocol instance. || Trial Implementation
 
|-
 
| RAD || 124 || Transfer Multiple Events || Delivers a payload of many event reports as a single RESTful HTTP PUT transaction. || Trial Implementation
 
|-
 
| RAD || 125 || Store Protocol Approval || Transfers a DICOM Protocol Approval instance from a Sender to a Receiver. || Trial Implementation
 
|-
 
| RAD || 126 || Query Protocol Approval || Requests and receives metadata about Protocol Approval instances matching a specified filter. || Trial Implementation
 
|-
 
| RAD || 127 || Retrieve Protocol Approval || Retrieves a DICOM Protocol Approval instance. || Trial Implementation
 
|-
 
| RAD || 128 || Send Imaging Result || Transfer imaging results (i.e., radiology reports) using an HL7 v2 ORU message. || Trial Implementation
 
|-
 
| RO || 1 || Single/Contoured Image Series Retrieve || In the Single/Contoured Image Series Retrieve transaction, the Archive sends a series of CT-Images to the Contourer, Geometric Planner, or Dosimetric Planner. || Final Text
 
|-
 
| RO || 2 || Structure Set Storage || In the Structure Set Storage Transaction, the Contourer stores a Structure Set on an Archive to make it available || Final Text
 
|-
 
| RO || 3 || Geometric Plan Storage || In the Geometric Plan Storage transaction, the Geometric Planner sends the newly created Geometric Plan to the Archive. || Final Text
 
|-
 
| RO || 4 || Dosimetric Plan Storage || In this transaction, the Dosimetric Planner sends the plan containing the references to the structure set to the Archive || Final Text
 
|-
 
| RO || 5 || Dose Storage || In the Dose Storage transaction, the Dosimetric planner sends the newly created Dose to the Archive. || Final Text
 
|-
 
| RO || 6 || Multi-Series Image Retrieval || In the Multi-Series Image Retrieve Transaction, the Archive stores CT Images from multiple series (but a single study) on a Contourer to make these Images available for contouring || Final Text
 
|-
 
| RO || 7 || Structure Set Retrieval || In the Structure Set Retrieval Transaction, the Archiver stores a Structure Set on a Contourer, Geometric Planner, Dosimetric Planner, or Dose Displayer. || Final Text
 
|-
 
| RO || 8 || Geometric Plan Retrieval || In the Geometric Plan Retrieve Transaction, the requested Geometric Plan is transferred from the Archive to the Dosimetric Planner. || Final Text
 
|-
 
| RO || 9 || Dosimetric Plan Retrieval || In this transaction, the Dose Displayer retrieves the plan containing the references to the structure set to the Archive || Final Text
 
|-
 
| RO || 10 || Dose Retrieval || In the Dose Retrieve Transaction, the requested Dose is transferred from the Archive to the Dose Displayer || Final Text
 
|-
 
| RO || 11 || Resampled/Combined CT Series Storage || In the Resampled/Combined CT Series Storage Transaction, the Contourer stores CT Images which have been combined or resampled into a single series on the Archive. || Final Text
 
|-
 
| RO || 12 || Spatial Registrations Stored || In the Spatial Registrations Stored transaction, the Registrator sends Spatial Registration instances to the Archive. Spatial registration objects define how the pixel coordinates of one image data set are transformed to another coordinate system (for example to a coordinate system defined by another image data set thus allowing each dataset to be spatially aligned). || Trial Implementation
 
|-
 
| RO || 13 || Utililze Spatial Registrations || A Registration Display receives from an Archive one or more Spatial Registration objects carrying the transformation information to be applied to two image data sets intended for further processing or registered display. || Trial Implementation
 
|-
 
| RO || 14 || Registered Structure Set Storage || In the Registered Structure Set Storage Transaction, the Registered Contourer stores a Structure Set on an Archive to make it available. || Trial Implementation
 
|-
 
| RO || 15 || Registered Structure Set Retrieval || In the Registered Structure Set Retrieval Transaction, the Archive stores a Structure Set on a Registered Contourer or Registered Dose Displayer. || Trial Implementation
 
|-
 
| RO || 16 || Registered Dose Retrieve || In the Registered Dose Retrieve Transaction, the requested Dose is transferred from the Archive to the Registered Dose Display actors. || Trial Implementation
 
|-
 
| RO || 17 || Worklist Query for Positioning and Delivery || In the Worklist Query for Positioning and Delivery transaction, a PDS requests and receives a patient positioning and treatment delivery worklist from a TMS. || Trial Implementation
 
|-
 
| RO || 18 || Retrtieve Workitem Input Objects from Archive || In the Retrieve Workitem Input Objects from Archive transaction, a PPS, PDS, or TDD requests and receives from the Archive any SOP Class Instances required for performing desired procedure steps returned by a previous query. Each SOP instance must have been supplied in the Input Information Sequence of one or more of the returned worklist items. || Trial Implementation
 
|-
 
| RO || 19 || UPS In Progress || In the UPS in Progress transaction, a PPS, PDS, or TDD signals to the TMS that responsibility has been taken for the performing of the selected work item. || Trial Implementation
 
|-
 
| RO || 20 || Retrieve Workitem Input Objects from TMS || In the Retrieve Workitem Input Objects from TMS transaction, a PDS or TDD requests and receives requests and receives SOP Class instances from the TMS, in order to support execution of the requested work item. These requested instances are of a “transient” nature, typically generated ‘on-the-fly’ by the TMS || Trial Implementation
 
|-
 
| RO || 21 || UPS Final Update || In the UPS Final Update transaction, a PPS, PDS, or TDD signals to the TMS changes in the properties of the work item that is currently in progress, prior to the UPS being signaled as completed or canceled. || Trial Implementation
 
|-
 
| RO || 22 || Store Position Acquisition Results to Archive || In the Store Position Acquisition Results to Archive transaction, when a patient position acquisition workitem has been completed by a PPS or PDS, the results of the acquisition are stored to the Archive. These results may subsequently be referenced in the Output Information Sequence of the corresponding Unified Procedure Step. || Trial Implementation
 
|-
 
| RO || 23 || Store Position Registration Results to Archive || In the Store Position Registration Results to Archive transaction, when a patient registration workitem has been completed by a PPS or PDS, the results of the registration operation are stored to the Archive. These results may subsequently be referenced in the Output Information Sequence of the corresponding Unified Procedure Step. || Trial Implementation
 
|-
 
| RO || 24 || Store Delivery Results to Archive || In the Store Position Registration Results to Archive transaction, when a treatment delivery workitem has been completed by a PDS or TDD, the results of the treatment delivery operation are stored to the Archive. These results may subsequently be referenced in the Output Information Sequence of the corresponding Unified Procedure Step || Trial Implementation
 
|-
 
| RO || 25 || UPS Completed/Canceled || In the UPS Completed/Canceled transaction, a PPS, PDS, or TDD signals to the TMS that the selected work item has either been completed or canceled. || Trial Implementation
 
|-
 
| RO || 26 || UPS Progress Update || In the UPS Progress Update transaction, a PDS or TDD signals to the TMS changes in the progress of the work item that is currently in progress. || Trial Implementation
 
|-
 
| RO-TDPC || 1 || Retrieve RT Plan || The retrieval of the RT Plan by a Treatment Delivery Plan Consumer, typically for the purpose of delivering a Radiotherapy treatment to the patient. Could be also used for other purposes, e.g., for quality assurance prior to treatment. ||
 
|-
 
| TPPC || 1 || Basic Static Beam Storage || In the Basic Static Beam Storage transaction, a Static Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static, non-MLC treatment beams. || Trial Implementation
 
|-
 
| TPPC || 2 || Basic Static Beam Retrieval || In the Basic Static Beam Retrieval transaction, a Static Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static, non-MLC treatment beams. || Trial Implementation
 
|-
 
| TPPC || 3 || Basic Static MLC Beam Storage || In the Basic Static MLC Beam Storage transaction, a Static MLC Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static, MLC treatment beams. || Trial Implementation
 
|-
 
| TPPC || 4 || Basic Static MLC Beam Retrieval || In the Basic Static MLC Beam Retrieval transaction, a Static MLC Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static, MLC treatment beams. || Trial Implementation
 
|-
 
| TPPC || 5 || Arc Beam Storage || In the Arc Beam Storage transaction, an Arc Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only non-MLC arc treatment beams. || Trial Implementation
 
|-
 
| TPPC || 6 || Arc Beam Retrieval || In the Arc Beam Retrieval transaction, an Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only non-MLC arc treatment beams. || Trial Implementation
 
|-
 
| TPPC || 7 || MLC Fixed Aperture Arc Beam Storage || In the MLC Fixed Aperture Arc Beam Storage transaction, an MLC Fixed Aperture Arc Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only MLC Fixed Aperture Arc treatment beams. || Trial Implementation
 
|-
 
| TPPC || 8 || MLC Fixed Aperture Arc Beam Retrieval || In the MLC Fixed Aperture Arc Beam Retrieval transaction, an MLC Fixed Aperture Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only MLC Fixed Aperture Arc treatment beams. || Trial Implementation
 
|-
 
| TPPC || 9 || MLC Variable Variable Aperture Arc Beam Storage || In the MLC Variable Aperture Arc Beam Storage transaction, a MLC Variable Aperture Arc 860 Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only MLC Variable Aperture Arc treatment beams. || Trial Implementation
 
|-
 
| TPPC || 10 || MLC Variable Variable Aperture Arc Beam Retrieval || In the MLC Variable Aperture Arc Beam Retrieval transaction, an MLC Variable Aperture Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall 865 contain only MLC Variable Aperture Arc treatment beams. || Trial Implementation
 
|-
 
| TPPC || 11 || Hard Wedge Beam Storage || In the Hard Wedge Beam Storage transaction, a Hard Wedge Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static treatment beams using physical wedges. || Trial Implementation
 
|-
 
| TPPC || 12 || Hard Wedge Beam Retrieval || In the Hard Wedge Beam Retrieval transaction, a Hard Wedge Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static treatment beams using physical wedges. || Trial Implementation
 
|-
 
| TPPC || 13 || Virtual Wedge Beam Storage || In the Virtual Wedge Beam Storage transaction, a Virtual Wedge Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static treatment beams using virtual wedges. || Trial Implementation
 
|-
 
| TPPC || 14 || Virtual Wedge Beam Retrieval || In the Virtual Wedge Beam Retrieval transaction, a Virtual Wedge Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static treatment beams using virtual wedges. || Trial Implementation
 
|-
 
| TPPC || 15 || Motorized Wedge Beam Storage || In the Motorized Wedge Beam Storage transaction, a Motorized Wedge Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static treatment beams using motorized wedges. || Trial Implementation
 
|-
 
| TPPC || 16 || Motorized Wedge Beam Retrieval || In the Motorized Wedge Beam Retrieval transaction, a Motorized Wedge Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static treatment beams using motorized wedges. || Trial Implementation
 
|-
 
| TPPC || 17 || Static Electron Beam Storage || In the Static Electron Beam Storage transaction, a Static Electron Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static electron treatment beams. || Trial Implementation
 
|-
 
| TPPC || 18 || Static Electron Beam Retrieval || In the Static Electron Beam Retrieval transaction, a Static Electron Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static electron treatment beams. || Trial Implementation
 
|-
 
| TPPC || 19 || Step & Shoot Beam Storage || In the Step & Shoot Beam Storage transaction, a Step & Shoot Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only step & shoot IMRT treatment beams. || Trial Implementation
 
|-
 
| TPPC || 20 || Step & Shoot Beam Retrieval || In the Step & Shoot Beam Retrieval transaction, a Step & Shoot Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only step & shoot IMRT treatment beams. || Trial Implementation
 
|-
 
| TPPC || 21 || Sliding Window Beam Storage || In the Sliding Window Beam Storage transaction, a Sliding Window Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only sliding window IMRT treatment beams. || Trial Implementation
 
|-
 
| TPPC || 22 || Sliding Window Beam Retrieval || In the Sliding Window Beam Retrieval transaction, a Sliding Window Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only sliding window IMRT treatment beams. || Trial Implementation
 
|-
 
| TPPC || 23 || IMAT/VMAT Beam Storage || In the IMAT/VMAT Beam Storage transaction, a IMAT/VMAT Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only IMAT/VMAT IMRT treatment beams. || Trial Implementation
 
|-
 
| TPPC || 24 || IMAT/VMAT Beam Retrieval || In the IMAT/VMAT Beam Retrieval transaction, a IMAT/VMAT Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only IMAT/VMAT IMRT treatment beams. || Trial Implementation
 
|-
 
| TPPC || 25 || Photon Applicator Beam Storage || In the Photon Applicator Beam Storage transaction, a Photon Applicator Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only static treatment beams using photon applicators. || Trial Implementation
 
|-
 
| TPPC || 26 || Photon Applicator Beam Retrieval || In the Photon Applicator Beam Retrieval transaction, a Photon Applicator Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only static treatment beams using photon applicator. || Trial Implementation
 
|-
 
| TPPC || 27 || Photon Applicator Arc Beam Storage || In the Stereotactic Arc Beam Storage transaction, a Stereotactic Arc Beam Producer stores a treatment plan to the Archive. The treatment plan shall contain only stereotactic arc treatment beams. || Trial Implementation
 
|-
 
| TPPC || 28 || Photon Applicator Arc Beam Retrieval || In the Stereotactic Arc Beam Retrieval transaction, a Stereotactic Arc Beam Consumer or a TMS receives a treatment plan from the Archive. The treatment plan shall contain only stereotactic arc treatment beams. || Trial Implementation
 
|}
 
  
===Appendix C: Namesapces===
+
===Appendix B: IHE Transactions===
See [http://wiki.ihe.net/index.php/OID_Registration OID Registration]
+
IHE Transaction information is maintained in Gazelle Master Model. See the [https://profiles.ihe.net/GeneralIntro/ch-B.html IHE General Introduction Appendix B] and the [https://wiki.ihe.net/index.php/Gazelle_Browsing Gazelle Browsing] wiki page for additional information.
  
===Appendix D: Glossary===
+
===Appendix C: Namespaces===
'''New''' terms from public comment versions of supplements are not in in the glossary; they will be added when the supplement moves to trial implementation. The goal is to update the glossary annually.
+
See the [http://wiki.ihe.net/index.php/OID_Registration OID Registration wiki page] or Appendix C located [https://profiles.ihe.net/GeneralIntro/ch-C.html here].
 +
 
 +
===Appendix D: IHE Glossary===
 +
{| class="wikitable mw-collapsible mw-collapsed sortable"
 +
IHE Glossary terms are managed via the [http://www.skmtglossary.org/ Standards Knowledge Management Tool (SKMT)]. A report can be downloaded from the tool for a "real-time" list of all IHE Glossary terms. The IHE Glossary is also published as Appendix D to the General Introduction and is available [https://profiles.ihe.net/GeneralIntro/ch-D.html here]. Please note that the published Glossary is current as of the publication date and that the SKMT may include additional terms. See the [[Standards_Knowledge_Management_Tool_(SKMT)]] wiki page for additional information.
 
====Glossary Rules====
 
====Glossary Rules====
 +
Note: '''New''' terms from public comment versions of supplements are not in in the glossary; they will be added to the SKMT when the supplement moves to trial implementation. The published version of Appendix D is updated periodically as needed.
 
# The following are '''not''' to be included in the glossary:
 
# The following are '''not''' to be included in the glossary:
 
## Profile names or acronyms
 
## Profile names or acronyms
 
## Actor names or acronyms
 
## Actor names or acronyms
## Domain names or acronyms (e.g., ITI, PCC, PCD, Radiology, Patient Care Coordination, etc.)
+
## Domain names or acronyms (e.g., ITI, PCC, DEV, Radiology, Patient Care Coordination, etc.)
 
## Transaction names or acronyms
 
## Transaction names or acronyms
 
## Domain Technical Framework names or acronyms (e.g., ITI TF-1)
 
## Domain Technical Framework names or acronyms (e.g., ITI TF-1)
Line 1,129: Line 53:
 
##(TOO LONG) Modality Worklist: A mechanism defined to support the imaging workflow, by which the LIS provides the attributes of the imaging subject to modalities. In radiology, the imaging subject is the patient; in anatomic pathology, the imaging subject is a specimen derived from the patient. The Modality Worklist provides patient, order (study) and specimen identification and description to be included in the acquired images. Therefore the LIS needs to provide the attributes of the Specimen Module for each specimen being imaged. Therefore, the attributes of the Specimen Module have been defined in a ‘Macro’ construct, and added to the Scheduled Procedure Step Module of Modality Worklist. Conceptually, then, the Procedure Step is scheduled for the imaging of one or more specimen containers. While the use of the specimen attributes is optional according to the Standard for any Modality Worklist implementation, the APW profile requires their use for effective interoperability.
 
##(TOO LONG) Modality Worklist: A mechanism defined to support the imaging workflow, by which the LIS provides the attributes of the imaging subject to modalities. In radiology, the imaging subject is the patient; in anatomic pathology, the imaging subject is a specimen derived from the patient. The Modality Worklist provides patient, order (study) and specimen identification and description to be included in the acquired images. Therefore the LIS needs to provide the attributes of the Specimen Module for each specimen being imaged. Therefore, the attributes of the Specimen Module have been defined in a ‘Macro’ construct, and added to the Scheduled Procedure Step Module of Modality Worklist. Conceptually, then, the Procedure Step is scheduled for the imaging of one or more specimen containers. While the use of the specimen attributes is optional according to the Standard for any Modality Worklist implementation, the APW profile requires their use for effective interoperability.
 
##(BETTER) Modality Worklist: DICOM PS3.3; A collection of Scheduled Procedure Steps which describe arbitrarily defined units of service that have been scheduled for an imaging device (such as a CT Scanner or a Pathology Whole-Slide Scanner).  
 
##(BETTER) Modality Worklist: DICOM PS3.3; A collection of Scheduled Procedure Steps which describe arbitrarily defined units of service that have been scheduled for an imaging device (such as a CT Scanner or a Pathology Whole-Slide Scanner).  
#For acronyms, include two entries in the glossary, one for the full term and one for the acronym (pointing to the full term). For example:
+
#For acronyms, include them as part of the definition of the full term. When the term is added to SKMT, the acronym will be added with an association to the full term (and vice versa). The report downloaded from SKMT includes an acronym field for each term.
##Modality Worklist: DICOM PS3.3; A collection of Scheduled Procedure Steps which describe arbitrarily defined units of service that have been scheduled for an imaging device (such as a CT Scanner or a Pathology Whole-Slide Scanner).  
 
##MWL: See Modality Worklist
 
  
'''Note:''' Some domains included acronyms without a brief description. In this case, only the acronym appears in the glossary. Please supply the brief description if missing.
+
===Appendix E: Profiling===
 +
Standards Profiling and Documentation Conventions is published as Appendix E to the General Introduction and is available [https://profiles.ihe.net/GeneralIntro/ch-E.html here].
  
===Appendix E: Profiling===
 
 
===Appendix F: Integration Statements===
 
===Appendix F: Integration Statements===
 +
A brief discussion about IHE Integration Statements is published as Appendix F to the General Introduction and is available [https://profiles.ihe.net/GeneralIntro/ch-F.html here].
 +
 +
The IHE [https://gazelle.ihe.net/content/product-registry IHE Product Registry] enables developers to create, manage and publish Integration Statements for their commercial and open source healthcare IT systems. It allows users to browse for these systems based on their conformance with specific IHE Actors and Profiles.
 +
 +
===Appendix G: IHE Implementation Materials===
 +
See [https://profiles.ihe.net/GeneralIntro/ch-G.html Appendix G] for information on where to locate IHE Implementation Material.
  
==Comments==
+
==Comments on IHE Templates, General Introduction and Shared Appendices==
Comments about the templates can be submitted at: [http://www.ihe.net/Templates_Public_Comments/ http://www.ihe.net/Templates_Public_Comments/].
+
Comments on the templates, General Introduction and Shared Appendices can be submitted at: [http://www.ihe.net/Templates_Public_Comments/ http://www.ihe.net/Templates_Public_Comments/].

Latest revision as of 09:37, 9 August 2023

IHE International manages a set of document templates. These help authors make sure they have addressed the necessary material, and help readers/users by promoting consistency in how the information is organized and expressed.

IHE Technical Framework Templates

IHE Technical Framework Volume Templates

IHE Technical Framework Supplement Template

IHE White Paper Template

General Introduction and Shared Appendices

The documents contained at https://profiles.ihe.net/GeneralIntro/ are components shared by all of the IHE domain technical frameworks. Each technical framework volume contains links to these documents where appropriate. These documents will be updated on an annual (or as needed) basis.

General Introduction

The IHE Technical Frameworks General Introduction is located here.

Appendix A: IHE Actors

IHE Actor information is maintained in Gazelle Master Model. See the IHE General Introduction Appendix A and the Gazelle Browsing wiki page for additional information.

Appendix B: IHE Transactions

IHE Transaction information is maintained in Gazelle Master Model. See the IHE General Introduction Appendix B and the Gazelle Browsing wiki page for additional information.

Appendix C: Namespaces

See the OID Registration wiki page or Appendix C located here.

Appendix D: IHE Glossary

IHE Glossary terms are managed via the Standards Knowledge Management Tool (SKMT). A report can be downloaded from the tool for a "real-time" list of all IHE Glossary terms. The IHE Glossary is also published as Appendix D to the General Introduction and is available here. Please note that the published Glossary is current as of the publication date and that the SKMT may include additional terms. See the Standards_Knowledge_Management_Tool_(SKMT) wiki page for additional information.

Glossary Rules

Note: New terms from public comment versions of supplements are not in in the glossary; they will be added to the SKMT when the supplement moves to trial implementation. The published version of Appendix D is updated periodically as needed.

  1. The following are not to be included in the glossary:
    1. Profile names or acronyms
    2. Actor names or acronyms
    3. Domain names or acronyms (e.g., ITI, PCC, DEV, Radiology, Patient Care Coordination, etc.)
    4. Transaction names or acronyms
    5. Domain Technical Framework names or acronyms (e.g., ITI TF-1)
    6. Words that are used in the standard dictionary sense (e.g., antepartum, antibiotic, anorexia, anesthesia, aperiodic, etc,)
  2. For terms we borrow and use from (HL7, DICOM, etc.), reference the standard. For example:
    1. SCU: DICOM PS 3.5; Service Class User.
    2. Modality Performed Procedure Step: See DICOM PS3.3.
  3. Standards are to be included in the glossary. For example:
    1. HTML: Hyper Text Markup Language
  4. Organizations do belong in the glossary and should include a link to the respective web site. For example:
    1. ACC: American College of Cardiology. See http://www.acc.org/.
  5. Limit the body of the definitions to briefly describing what the thing is, but avoid getting into IHE usage details that really belong in the bodies of the technical frameworks themselves.
    1. (TOO LONG) Modality Worklist: A mechanism defined to support the imaging workflow, by which the LIS provides the attributes of the imaging subject to modalities. In radiology, the imaging subject is the patient; in anatomic pathology, the imaging subject is a specimen derived from the patient. The Modality Worklist provides patient, order (study) and specimen identification and description to be included in the acquired images. Therefore the LIS needs to provide the attributes of the Specimen Module for each specimen being imaged. Therefore, the attributes of the Specimen Module have been defined in a ‘Macro’ construct, and added to the Scheduled Procedure Step Module of Modality Worklist. Conceptually, then, the Procedure Step is scheduled for the imaging of one or more specimen containers. While the use of the specimen attributes is optional according to the Standard for any Modality Worklist implementation, the APW profile requires their use for effective interoperability.
    2. (BETTER) Modality Worklist: DICOM PS3.3; A collection of Scheduled Procedure Steps which describe arbitrarily defined units of service that have been scheduled for an imaging device (such as a CT Scanner or a Pathology Whole-Slide Scanner).
  6. For acronyms, include them as part of the definition of the full term. When the term is added to SKMT, the acronym will be added with an association to the full term (and vice versa). The report downloaded from SKMT includes an acronym field for each term.

Appendix E: Profiling

Standards Profiling and Documentation Conventions is published as Appendix E to the General Introduction and is available here.

Appendix F: Integration Statements

A brief discussion about IHE Integration Statements is published as Appendix F to the General Introduction and is available here.

The IHE IHE Product Registry enables developers to create, manage and publish Integration Statements for their commercial and open source healthcare IT systems. It allows users to browse for these systems based on their conformance with specific IHE Actors and Profiles.

Appendix G: IHE Implementation Materials

See Appendix G for information on where to locate IHE Implementation Material.

Comments on IHE Templates, General Introduction and Shared Appendices

Comments on the templates, General Introduction and Shared Appendices can be submitted at: http://www.ihe.net/Templates_Public_Comments/.