Official Templates

From IHE Wiki
Jump to: navigation, search

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 Whitepaper Template

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.

General Introduction

Appendix A: Actors

This section is in DRAFT state. Content presented is for feasibility testing only at this point. To expand the table, click on the blue "Expand" in the last column of the header.

Actor Name Actor Description
Access Control Service Access Control Service
Acquisition Modality Acquires medical images, waveforms or measurements while a patient or specimen is present (e.g., a Computed Tomography scanner, a specimen microscope or a hemodynamic measurement system).
Acquisition Modality Acquires and creates medical images (e.g., a Computed Tomography scanner or Nuclear Medicine camera). A modality may also create Grayscale Softcopy Presentation States for the consistent viewing of images and create Key Image Notes.
Acquisition Modality Importer Integrates a non-DICOM-ready modality into workflows.
Acquisition Modality Importer A system that interfaces to a non-DICOM ready modality in order to integrate that modality into the Eye Care workflow.
Acquisition Modality Importer in U-EYECARE - Model II Acquisition Modality Importer in U-EYECARE - Model II
Acquisition Modality in U-EYECARE Model II Acquisition Modality in U-EYECARE Model II
ADT Patient Registration Responsible for adding and/or updating patient demographic and encounter information. In particular, it registers a new patient with the Order Placer and Department System.
ADT/Patient Registration Adds or updates patient demographic and encounter information, (Admission/Discharge/Transfer) to a Practice Management System (PMS) or a Hospital Information System (HIS), for example.
Alarm Archiver The Alarm Archiver sends alarm subscription requests to the AM actor and receives report alarm responses from the AM actor.
Alert Aggregator This actor receives alerts from the Alert Reporter and collects status events related to the dissemination of the alert.
Alert Communicator The Alert Communicator (AC) receives the alert from the Alert Manager (AM) and sends the alert to the client application in the endpoint device and reports the dissemination status back to the Alert Manager (AM).
Alert Consumer The Alert Consumer (ACON) receives the alert from the Alert Reporter (AR) and uses the alert information strictly as a consumer of the alert being raised. There is no implementation requirement for how the ACON ultimately uses the alert information.
Alert Manager The Alert Manager (AM) receives the alerts from the Alert Reporter (AR), potentially analyzes the alert, and dispatches the alert to the Alert Communicator (AC), and optionally, provides the alert to the Alert Archiver (AA) or Alert Consumer (ACON) upon subscription.
Alert Manager This actor receives alerts from an Alert Reporter, manages them according to business context and disseminates them to an Alert Communicator.
Alert Message Receiver Alert Message Receiver
Alert Message Transmitter Alert Message Transmitter
Alert Reporter This actor originates the alert (an alarm, either physiological or technical, or an advisory). May also query the Alert Aggregator for the status of the alert.
Analyzer Performs testing on biological specimens and reports the resulting observations.
Analyzer An actor which is an automated device which fulfills clinical tests on biologic specimen. An Analyzer performs analyzing for a specimen according to AWOS, and return the result to the AM.
Analyzer Manager "An Automation Manager that manage the analytical part of the laboratory. This actor is involved in the LAW profiles.
Schedules and manages analytical work order steps (AWOS) to be performed on biological specimens by a set of Analyzers."
Appointment Consumer An information system responsible for consuming patient appointment information. It updates its system with the appointment information and statuses.
Appointment Requester A system that sends requests for appointments and/or schedules and displays the results of those requests.
Appointment Scheduler A system that handles requests for appointments and requests for appointment information. The system is responsible for providing schedule information including both appointments requested by the Appointment Requester Actor and those that were not.
Arc Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with non-MLC Fixed Aperture arc treatment beams.
Arc Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with non-MLC Fixed Aperture Arc treatment beams.
Archive Stores the radiotherapy (RT) DICOM SOP Classes in addition to the computed tomography (CT) images and is capable of transmitting them.
Archive (including RT) A system that stores the RT SOP Classes in addition to the CT images and is capable of transmitting them.
Audit Consumer Query for syslog and ATNA audit records using Syslog metadata and ATNA audit record content. Subsequent processing of the query event is not defined.
Audit Record Forwarder This actor filters audit records that have been received and forwards selected audit records to an Audit Record Repository. Added to the ATNA profile in Sept 2015 in CP-ITI-872
Audit Record Repository A system unit that receives and collects audit records from multiple systems.
Audit Repository Stores audit events.
Authorization Client A client that presents authorization tokens as part of transactions.
Authorization Decisions Manager Actor that can perform Access Control decision, evaluating requests for authorization. The result of this evaluation is the creation of an Authorization Decision that certifies the decision made.
Authorization Decisions Verifier This actor queries for Authorizations Decision related to the Requester Entity before disclosing specific documents. An Authorization Decision is stored and managed by the Authorization Decisions Manager actor and certifies that a decision was made by a trustable actor.
Authorization Server A server that provides authorization tokens to requesting clients
Automation Manager Schedules and manages operations on biological specimens on a set of robotic devices in a clinical laboratory.
Automation Manager A system or component that manages the automation in the laboratory or a part of it. Automation involves the integration or interfacing of automated or robotic transport systems, analytical instruments, and pre- or post-analytical process equipment such as automated centrifuges and aliquoters, decappers, recappers, sorters, and specimen storage and retrieval systems. This actor receives work orders from the Order Filler. It manages the processing of the ordered tests on the appropriate devices, and sends technically validated results back to the Order Filler. This actor must be considered even if it manages a small part of the analytical process; e.g. if it manages one single analytical instrument. Multiple Automation Managers can be related to one Order Filler. The Automation Manager can match unexpected results produced by an analyzer with the appropriate incoming Work Order, or create a new Work Order to fit the unsolicited observations and send them to the OF.
Barcode Processor Receives data from the barcode reader / consumer and sends the decoded barcode content.
Barcode Reader / Consumer Device capable of scanning barcodes. It sends the barcode data for decoding by another system, and receives encoded information, like GTIN, expiry date, batch/lot number from the barcode decoder
Basic Static Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static, non-MLC, treatment beams.
Basic Static Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static, non-MLC, treatment beams.
Basic Static MLC Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static, MLC, treatment beams.
Basic Static MLC Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static, MLC, treatment beams.
Bed Manager A hospital or enterprise-wide system used to coordinate the identification and requisitioning of beds for incoming admissions and transfers and manage intra- and inter-hospital transfers. First defined in PCC BED Supplement, 8/2016.
Care Manager The Care Manager Actor is responsible for supporting the management of the care of patients with respect to a specific health condition. It gathers information about the care provided and current health status of the patient. A Care Manager Actor may be designed for management of a single condition, such as management of Diabetes, or may be a general purpose system supporting management of multiple conditions.
Care Plan Contributor This actor reads, creates and updates Care Plans hosted on a Care Plan Service. First defined in PCC DCP Supplement, 8/2016.
Care Plan Service This actor manages Care Plans received from Care Plan Contributors, and provides updated Care Plans to subscribed Care Plan Contributors. First defined in PCC DCP Supplement, 8/2016.
Care Services Directory The Care Services Directory Actor is responsible for returning an XML document in response to a request from a Care Services InfoManager. The response document contains all the content which has been inserted or updated in the Directory since the specified timestamp and is expressed in the format defined by the CSD Profile’s XML schema.
Care Services InfoManager The Care Services InfoManager Actor has two roles. The Care Services InfoManager maintains a local cache of information that represents cross-referenced data from one or more Care Services Directory actors. The Care Services InfoManager periodically refreshes this cache by querying Care Services Directory actors for updated content. The Care Services InfoManager’s other role is to process inbound queries from Service Finder actors. These queries are executed against the cached content and the results are returned as a reply document.
Care Services Selective Consumer The Care Services Selective Consumer queries the Care Services Selective Supplier for information about healthcare practitioners, organizations, locations, and services.
Care Services Selective Supplier The Care Services Selective Supplier processes received queries from Care Services Selective Consumers and returns information about healthcare practitioners, organizations, locations, and services.
Care Services Update Consumer The Care Services Update Consumer can query for updates since a previous refresh, to information about healthcare practitioners, organizations, locations, and services from one or more Care Services Update Suppliers.
Care Services Update Supplier The Care Services Update Supplier can provide updates about healthcare practitioners, organizations, locations, and services information in response to a refresh request from a Care Services Update Consumer. The updates include new or modified information since a previous refresh.
Care Summary Generator The actor participates in the EHDI workflow. It generates and shares the Care Summary for the encounter associated with the patient’s birth. The summary is generated at the point newborn is discharged or transferred. See EHDI-WD TI Supplement 2016, Vol 1, Sec X.1.1.4
Care Team Contributor This actor reads, creates and updates Care Teams hosted by a Care Team Service.
Care Team Service This actor manages Care Teams received from Care Team Contributors, and provide notification of updates and access to updated Care Teams to subscribers.
Change Requester A system that communicates changes to an Image Manager / Archive, indicating that certain imaging instances should be deleted. In addition, it may also send new versions of these imaging instances containing corrected information
Charge Processor Receives posted charges and serves as a component of the financial system (for instance a PMS or billing system).
Client Authentication Agent Provides local management of user authentication.
Clinical Data Consumer A Clinical Data Consumer makes use of clinical patient data.
Clinical Data Source A Clinical Data Sources maintains patient information about vital signs, problem and allergies, results from diagnostic tests (e.g., Lab, Imaging, or other test results), medications, immunizations or historical or planned visits and procedures.
Clinical Knowledge Directory A Clinical Knowledge Directory receives requests for clinical knowledge and returns a list of relevant clinical knowledge resources based on the content of the knowledge request.
Clinical Knowledge Requester A Clinical Knowledge Requester collects appropriate clinical context and uses it to request clinical knowledge, and presents the resulting knowledge to the user.
Clinical Knowledge Resource Repository A Clinical Knowledge Resource Repository stores documents providing clinical knowledge and returns them to Requesters on demand.
Clinical Mapper The Clinical Mapper selects appropriate mappings for terms that it has been requested to map. First seen: PCC Clinical Mapping Supplement, May 2015
Clinical Mapping Requestor The Clinical Mapping Requestor identifies terms that need to be mapped and requests mappings for them. First seen: PCC TF Clinical Mapping Supplement, May 2015
Code Set Consumer Maintains its internal dictionary of laboratory panels, tests and observations relying on an external code set provided by a Code Set Master.
Code Set Consumer A system which receives code sets from Code Set Master(s) and updates its internal tables to reflect the code set as maintained by the Code Set Master. This system may also be an Order Placer, an Order Result Tracker, an Automation Manager, or an Order Filler.
Code Set Master Manages and provides code sets for laboratory panels, tests and observations
Code Set Master A system which owns (is responsible for the maintenance of) one or several code sets. This system may also be an Order Filler or an Enterprise Common Repository. Code sets can be sent on a routine basis (e.g. every week) or every time the code set changes. A code set may contain battery, test and observation codes.
Community Pharmacy Manager The role of this actor consists in providing the business logic for status management and other purposes. As a second role it acts as a “relaying role” where certain standard XDS communication is routed through for providing the possibility of applying project-specific business logic on it. It provides special query-transactions which consuming actors (prescription placer, pharmaceutical adviser or medication dispenser) used for reducing the amount of data flowing to them. They return just “relevant” information for specific purposes (e.g., returning just all “active” prescriptions ready for being validated or dispensed together with all related documents). This actor is usually a system actor without human participation.
Conformal Arc Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with conformal arc treatment beams.
Conformal Arc Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with conformal arc treatment beams.
Consult Manager "The particpant that performs the following actions and related tasks:
-Analyzing any alarm situations and deciding how to manage them – tasks ANALYZE
AND REQUEST VISIT, ANALYZE AND CHANGE PROTOCOL, ANALYZE AND
TAKE CLINICAL ACTION and ANALYZE AND TAKE NO ACTION;
-If a specialist visit is needed, producing an eReferral Document and creating the related
eReferral Workflow Document or a Consult Note – task ANALYZE AND REQUEST
VISIT;
-After receive the Clinical Report of the visit by the specialist as the end of the eReferral
process, checking the visit’s outcomes and confirming the telemonitoring protocol – task
VISIT RESULT;
-If a change of protocol is decided, updating the Telemonitoring Protocol Document – task
ANALYZE AND CHANGE PROTOCOL;
-If clinical actions are decided (e.g., change therapy) – task ANALYZE AND TAKE
CLINICAL ACTION;
-If no action is decided – task ANALYZE AND TAKE NO ACTION.
-Request of closing for the service or acceptance/refusing of closing for the service when
requested by the Care Manager – task “Close Telemonitoring Service”"
Content Agent The Content Agent actor accesses clinical information in structured and non-structured form. It provides a mechanism for a clinician to add new information to the structured and nonstructured information. It authenticates the clinician prior to storage of the additional information data (this step may be combined with other authentication steps used to finalize the record).
Content Consumer The Content Consumer is responsible for viewing, importing, or other processing of content created by a Content Creator.
Content Consumer Views, imports, or processes content created by a Content Creator.
Content Creator The Content Creator is responsible for the creation of content and transmission to a Content Consumer.
Content Creator Creates content for later consumption by a Content Consumer.
Content Data Structure Consumer The Content Data Structure Consumer consumes a message structure definition that may be employed by a Content Creator to develop profile-conformant messages for exchange with a Content Consumer.
Content Data Structure Creator The Content Data Structure Creator creates a message structure definition that may be employed by a Content Creator to develop profile-conformant messages for exchange with a Content Consumer.
Content Updater
Context Manager Brokers context information (such as current patient subject) between context.
Context Manager This actor serves as a broker for the communication between two or more context participant actors (either Patient Context Participant or User Context Participant). It supports the passing of the user and patient subjects
Contourer A system that consumes CT and creates RT Structure Set. If the Contourer consumes multiple series CT or has an internal requirement for resampling, it also will generate a single series CT to which the RT Structure Set maps.
Contourer Consumes CTs and creates RT Structure Sets.
Data Consumer The Data Consumer is responsible for initiating a query to a Data Responder for resource information, and receiving the result of the query. VRDR Supplement (2017) TF 2:3.47.2 The Data Consumer is responsible for creating a FHIR-based request for death reporting related health information and retrieving this information from the Data responder.
Data Element Extractor The Data Element Extractor extracts data elements from documents along with the associated provenance information that traces back to the source document.
Data Element Provenance Consumer The Data Element Provenance Consumer uses the provenance information associated with data elements to access the source information.
Data Responder A Data Responder is a system that may have information that can be used by a Form Manager in preparation of form data. It is available to respond to RESTful queries from trusted Form Manager systems.
Data Responder The Data Responder is responsible for receiving a query and supplying the corresponding resource information
Decision Support Service The Decision Support Service processes the result and returns a response to the Care Manager Actor in that same transaction.
Dental Document Recipient Receives DICOM SOP Instances and image reports and associated documents.
Dental Document Source Sends DICOM SOP Instances and image reports and associated documents.
Department System Scheduler/Order Filler Manages the scheduling and performance of orders for diagnostic services (e.g., cardiology, radiology, cytology & anatomic pathology examinations, in vitro diagnostic testing) in a department or setting offering such services.
Department System Scheduler/Order Filler A department-based information system (for instance, Radiology or Laboratory) that provides functions related to the management of orders received from external systems or through the department system s user interface. Upon a defined workflow action, makes procedures available for charge posting. The action/event that actually causes charges to post is defined by the actor.
Device Gateway The Device Gateway Actor coordinates communication between the recording/viewing equipment and specialized monitoring (e.g., electronic fetal monitoring) or treatment (e.g., Infusion Pump) devices.
Device Management Information Consumer The DMIC is a new and distinct destination actor and is likely to be a Computerized Maintenance Management System (CMMS), or more specifically a Clinical Equipment Management System (CEMS), but may also be an actor in a different profile (DEC DOC, ACM AM, IPEC DOC).
Device Management Information Reporter The Device Management Information Reporter (DMIR) produces observations. The Device Management Information Reporter (DMIR) may also be an observation transaction sending actor in other IHE PCD profiles, such as a DEC DOR, an ACM AR, or an IPEC DOR. If that is the case then the observations defined in this document may be included in existing observation content for those profiles without adoption of this profile, unless the destination to which the observations are being sent is a CMMS and not an EMR/EHR system. If that the case then this profile should be implemented.
Device Observation Consumer The actor responsible for receiving Patient Care Device data from the Device Observation Reporter, the Device Observation Filter, or both.
Device Observation Consumer / Alarm Manager The Device Observation Consumer / Alarm Manager Actor accepts monitoring and alarm data from the Device Gateway and makes it available to healthcare providers.
Device Observation Filter Provides publish/subscribe-based filtering of Patient Care Device data.
Device Observation Filter The Device Observation Filter (DOF) actor is responsible for providing PCD data filtering services based on publish/subscribe predicates negotiated with client applications implementing the Device Observation Consumer.
Device Observation Reporter Receives data from patient care devices and makes it available with consistent syntax and semantics.
Device Observation Reporter The Device Observation Reporter (DOR) actor receives data from PCDs, including those based on proprietary formats, and maps the received data to transactions providing consistent syntax and semantics.
Device Observation Reporter The Device Observation Reporter communicates information from the Hearing Screening Device, and may accept information from the Order Placer to identify the newborn being screened.
Device Observation Source Referenced in PCC Remote Monitoring Supplement. Have not yet found the formal definition.
Dispensed Medication Repository This repository contains the medication actually dispensed to the patient; this information is received from the medication dispenser. The dispensed medication repository provides the medication record of the patient to other actors such as the dispensed medication consumer.
Display Requests and displays preformatted (“presentation-ready”) data.
Display A system that offers requesting of specific information or documents for display the healthcare information returned
Distribution Message Receiver The Distribution Message Receiver is responsible for receiving and processing the communications from the Distribution Message Transmitter.
Distribution Message Transmitter The Distribution Message Transmitter is responsible for transmitting the source data that is communicated to the Distribution Message Receiver.
DNS Server Provides authoritative network location information.
Document Administrator The Document Administrator is an actor capable of updating and/or removing metadata from the Document Registry. This actor may also be capable of removing associated documents from the Document Repository.
Document Administrator The Document Administrator supports metadata update by issuing the Update Document Set [ITI-57] transaction and Delete Document Set [ITI-62] transaction to the Document Registry.
Document Consumer The Document Consumer queries for document metadata meeting certain criteria, and may retrieve selected documents
Document Consumer The Document Consumer queries a Document Registry Actor for documents meeting certain criteria, and retrieves selected documents from one or more Document Repository actors.
Document Metadata Notification Broker The Document Metadata Notification Broker is the receiver of the Document Metadata Subscribe transaction containing a subscription request, or a subscription cancellation. It keeps track of all subscriptions in the Metadata Notification domain, including the time limits of subscriptions. Based on the metadata associated with document registrations, this actor sends notifications to interested subscribers.
Document Metadata Notification Recipient The Document Metadata Notification Recipient actor receives the notification about an event, when the subscription filters specified for this Document Metadata Notification Recipient are satisfied.
Document Metadata Publisher The Document Metadata Publisher actor sends a Document Metadata Publish transaction to the Document Metadata Notification Broker for any event for which a subscription exists.
Document Metadata Subscriber The Document Metadata Subscriber actor initiates and terminates subscriptions on behalf of a Document Metadata Notification Recipient.
Document Recipient The Document Recipient receives documents and metadata sent by another actor
Document Registry Manages and provides query access to meta-data about registered documents such as the document type, subject and where it is stored.
Document Registry The Document Registry Actor maintains metadata about each registered document in a document entry. This includes a link to the Document in the Repository where it is stored. The Document Registry responds to queries from Document Consumer actors about documents meeting specific criteria. It also enforces some healthcare specific technical policies at the time of document registration.
Document Repository Persistently stores documents and makes them available.
Document Repository The Document Repository is responsible for both the persistent storage of these documents as well as for their registration with the appropriate Document Registry. It assigns a URI to documents for subsequent retrieval by a Document Consumer.
Document Responder The receiver of and responder to requests for document entries and documents.
Document Responder The Document Responder sends documents and/or metadata in response to a request from another actor.
Document Source The Document Source is the producer and publisher of documents and metadata.
Dose Displayer A system that consumes a Dosimetric Plan, CT, Structure Set and an RT Dose and displays the dose
Dose Information Consumer Responsible for supplemental handling of irradiation events, generally on an individual basis, e.g. display, analysis, or further processing.
Dose Information Reporter Responsible for the aggregation, analysis, reporting and business logic related to irradiation events, which may include meeting facility obligations to de-identify and submit data to various dose registers.
Dose Register Collates information about irradiation events from a number of facilities, generally to perform analysis.
Dosimetric Planner A system that consumes (single series) CT, an RT Structure Set, a Geometric Plan, and creates a Dosimetric Plan and an RT Dose.
DSS Order Filler Actor in U-EYECARE - Model I DSS Order Filler Actor in U-EYECARE - Model I
DSS Order Filler in U-EYECARE - Model II DSS Order Filler in U-EYECARE - Model II
DSS Order Filler in U-EYECARE - Model III DSS Order Filler in U-EYECARE - Model III
eCR Client eCR client actor is a grouping of the actors IHE Document Consumer, IHE Document Source, and IHE X-Service User.
eCR Provider eCR provider is a grouping of the actors IHE Document Registry, IHE Document Repository, and IHE X-Service Provider. eCR Provider actor shall be deployed as a secure node.
Electronic Health Record System Electronic Health Record System (EHR-S) is an actor supporting the functions of patient administration, scheduling, clinical records management, decision support, and external orders and referrals.
Eligibility Information Receiver The system that initiates an inquiry to the Eligibility Information Source about an individual’s insurance eligibility, coverage and benefits
Eligibility Information Source The system which holds and maintains the information regarding the individual’s insurance eligibility, coverage and benefits, and responds to the queries initiated by the Eligibility Information Receiver
Emergency Department Information System A departmental system that supports management of the course of care in the ED and supports communications with other hospital systems. First defined in PCC BED Supplement, 8/2016.
Enterprise Report Repository Receives Structured Report Export Transactions from the Report Manager and stores the report.
Event Consumer Processes event reports.
Event Reporter Composes and sends event reports to other actors.
Event Repository Receives and manages event reports.
Evidence Creator Creates evidence objects such as derived images, presentation states, Key Image Notes, and/or measurements (Evidence Documents), and transmits them to an Image Archive.
Evidence Creator A system that creates additional evidence objects such as images, presentation states, Key Image Notes, and/or Evidence Documents and transmits them to an Image Archive. It also makes requests for storage commitment to the Image Manager for the data previously transmitted. It may also retrieve worklist entries for post-processing steps from the Post-Processing Manager and provide notification of completion of the step, allowing the enterprise to track the status of post-processing work.
Execution Information Creator The actor that provides endoscopy execution information to the OP.
Export Manager De-identifies, pseudonymizes and exports imaging data.
Export Manager A system that can de-identify and pseudonymize the attributes, and optionally the pixel data, of a selected list of instances, before exporting them.
Export Selector Selects and tags imaging data for export, e.g. to a teaching file or a clinical trial.
Export Selector A system that allows a user to select one or more instances, series or studies for export, for a specific purpose, with a specific disposition, optionally with the inclusion of additional information.
External Report Repository Access Retrieves clinical reports generated outside the imaging department.
External Report Repository Access A system that performs retrieval of clinical reports containing information generated outside the Radiology department and presented as DICOM Structured Reporting Objects.
Extraction Specification Manager The Extraction Specification Manager manages a set of extraction specifications. An extraction specification explicitly indicates which information to extract from a source document. Extraction Specification Managers are queried using an identifier for a particular Extraction Specification and they return the associated specification file.
File Consumer The File Consumer queries a File Manager for file metadata meeting certain criteria, and may retrieve selected files.
File Manager This actor stores files provided by the File Source and maintains related metadata. The File Manager responds to search and retrieve requests initiated by the File Consumer. The File Manager responds to metadata update requests initiated by the File Source.
File Source The File Source publishes and updates files produced by either the File Source or by other systems. It is responsible for sending files and related metadata to a File Manager.
Form Archiver The actor responsible for receiving form instance data for archival purposes.
Form Archiver A system or module in a CRD framework, the purpose of which is to receive the raw CCD and the completed form from the Form Filler.
Form Filler The actor responsible for retrieving a form from a Form Manager, and for submitting form instance data to a Form Receiver.
Form Filler A system or module in a CRD framework, the purpose of which is to retrieve a form from the Form Manager and provide pre-population data.
Form Filler A Form Filler is a system that needs to complete forms that are managed by an external entity.
Form Manager The actor that supplies a form based upon a request that supplies a unique form identification.
Form Manager A system or module in a CRD framework, the purpose of which is to provide a form to the Form Filler, to apply pre-population data.
Form Manager A Form Manager is a system that maintains form definitions and can provide them to systems that need to fill them out.
Form Processor The Form Processor is an integrated Form Manager and From Receiver, supporting all of the transactions and options of those actors. The Form Processor constructs form such that form data is submitted back to itself.
Form Processor CDA Exporter The Form Processor CDA Exporter receives data submitted through the Submit Form [ITI-35] transaction, transforms that data to create a CDA document, and shares that newly created CDA document with a Content Consumer.
Form Processor Message Exporter The Form Receiver Message Exporter receives data submitted through the Submit Form [ITI-35] transaction, transforms that data to an HL7 message, and sends that message to an Information Recipient.
Form Receiver The actor that receives form instance data.
Form Receiver A system or module in a CRD framework, the purpose of which is to receive completed forms from the Form Filler.
Form Receiver CDA Exporter This Form Receiver CDA Exporter receives data submitted through the Submit Form Transaction (ITI-35), transforms that data to create a CDA document, and shares that newly created CDA document with a Content Consumer.
Form Receiver CDA Exporter The Form Receiver CDA Exporter SHALL conform to the requirements specified for the Form Receiver in the ITI RFD Profile. Additionally, this actor SHALL create and export a CDA document that meets the requirements of a specified document template defined by the profile in which the actor appears. Profiles that use this actor SHALL include a mapping from the data elements of the form data to the data elements of the CDA document template used to create the exported CDA.
Form Receiver Message Exporter This Form Receiver Message Exporter receives data submitted through the Submit Form Transaction (ITI-35), transforms that data to an HL7 message and sends that message to an Information Recipient.
General Clinician Manager The participant that performs the following actions and related tasks: -Creates the Workflow Document for the telemonitoring of the patient, - creates the Request Activation Document - task REQUEST ACTIVATION
Generic HITSP Actor
Geometric Planner A system that consumes (single series) CT and RT Structure Set and creates a Geometric Plan
Guideline Manager The guideline manager actor is responsible for managing the guidelines used to create care plans, and for communicating those guidelines to other systems.
Hard Wedge Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static treatment beams using physical wedges.
Hard Wedge Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static treatment beams using physical wedges.
Heart Team Manager The Heart Team Manager (or HT Manager) is responsible for accepting/refusing the management of HT received from the HT Requester by initiating the Accept/Reject HT Management transaction. The HT Manager is responsible for assigning staff to the HT by initiating the “Assign HT Participation” transaction. The process of defining the list of participants is outside the scope of this profile. The HT Manager is also responsible for planning the team’s communication, initiating the “Plan HT Discussion” transaction, and creating the Final Report as part of the “Perform HT evaluation” transaction. First defined in PCC XCHT-WD Supplement, 8/2016.
Heart Team Participant A Heart Team Participant (HT Participant) is responsible for accepting or refusing to participate in the HT initiating the “Accept/Reject HT” transaction and for requesting more information. Heart Team Participant is also responsible of providing individual evaluation reports, which will be needed in preparation for HT discussion. First defined in PCC XCHT-WD Supplement, 8/2016.
Heart Team Requester The Heart Team Requester (HT Requester) is responsible for initiating the workflow of the HT process. The HT Requester is responsible for assigning a HT Manager to this workflow instance by invoking the “Assign HT Management” transaction. The HT Requester is responsible for making available more clinical information (reports, images or eReferral workflow) to all HT members using the “Add results of more clinical information Transaction”. The HT Requester is responsible for completing the workflow by receiving the Final Report, acknowledging the receipt of the report, and making available new clinical results, if requested, with the Finalization transaction. This transaction completes the workflow. First defined in PCC XCHT-WD Supplement, 8/2016.
HITSP Administrative Transport Client A provider sending a request to a health plan has a client role
HITSP Administrative Transport Server A health plan responding to a request from a provider has a server role
HITSP Information Receiver for Health Plan Authorization The system that initiates a request to the Information Source for Health Plan Authorization about an individuals health insurance requirements to obtain an authorization approval for purposes of benefit coverage determination in order to refer a patient for healthcare services
HITSP Information Source for Health Plan Authorization The system which holds and maintains the information regarding the individual’s health insurance requirements related to an authorization for benefit coverage
HITSP Laboratory Result Message Sender The holder of a laboratory result who is communicating a laboratory result message to another actor
HITSP Medication Formulary and Benefits Retriever The entity that is asking about an individual’s formulary and benefits information. It initiates queries to the Medication Formulary and Benefits Source
HITSP Medication Formulary and Benefits Source The entity that maintains individual’s formulary and benefits information. It responds to queries from the Medication Formulary and Benefits Retriever
HITSP Medication Order Filler The Medication Order Filler responds to the requests for medication orders/prescriptions. This includes the ability to respond to: new orders, refill orders, change orders and cancel orders. These responses are sent to the Medication Order Prescriber.
HITSP Medication Order Prescriber The Medication Order Prescriber initiates requests for medication orders/prescriptions. This includes the ability to: create new orders, refill orders, change orders and cancel orders. These requests are sent to the Medication Order Filler.
HITSP Medication Status Dispenser The Medication Status Dispenser provides a dispensing status (RXFILL message) to a Medication Status Receiver about a preciously performed medication order / prescription
HITSP Medication Status Receiver The Medication Status Receiver receives a dispensing status (RXFILL message) from a Medication Status Dispenser about a previously performed medication order / prescription
HITSP Pseudonymization Services Module or service that can be invoked by Patient Identifier Cross-Reference (PIX) Manager (see next section) to return pseudo-identifier upon request
HITSP Service User The entity represents any individual entity (such as an EHR/PHR system) that needs to make a service request of a Service Provider. The Entity may also be known as a principal and/or entity, which represents an application, a machine, or any other type of entity that may act as a requester in a transaction. A principal is typically represented in a transaction with a digital identity and the principal may have multiple valid digital identities to use with different transactions. Any Service User may also be a Service Provider
HL7 Message Router A system that receives HL7 messages, routes them to one or more configured actors, and handles transport level acknowledgements. The HL7 Message Router may also provide modification of the messages in accordance with specific profiles.
Hosted Application an application (program) runs in an environment provided by a host.
Hosting System a system that hosts applications, including providing an execution environment and mediating interactions with resources.
HT Manager "The actor is responsible for
• accepting/refusing the management of HT by HT Requester
• staffing of HT
• performing the HT, planning team’s communication, if requested, and creating Final Report"
HT Participant "The actor is responsible for:
• accepting/refusing to participate to HT
• providing request more clinical information, if needed
• providing individual evaluation reports"
HT Requestor "The actor is responsible for
• initiating the workflow of HT process for clinical support
• assigning the management of HT to a HT Manager,
• providing more clinical information, if requested,
• completing the workflow by receiving the Final Report, and acknowledging the receiving of that report, providing also new clinical results"
Image Archive Provides long term storage of imaging data such as images, measurements, presentation states, and manifests (e.g., a PACS).
Image Capturer A creator of DICOM® composite instances.
Image Display Queries for, retrieves and displays imaging data.
Image Display A part of a system that can access imaging evidence objects (images, Presentation States, Key Image Notes, Evidence Documents) through network query/retrieve or reading interchange media and allow the user to view these objects.
Image Display Invoker Requests display of DICOM image studies.
Image Manager Manages and provides access to stored imaging objects.
Image Manager Stores DICOM objects without guarantee of long-term storage.
Image Manager/Archive A system that provides functions related to safe data storage and image data handling. It supplies image availability information to the Department System Scheduler. It is always grouped with an Image Archive to provide long term storage of images, presentation states, Key Image Notes, and Evidence Documents.
Image Manager-Image Archive in U-EYECARE - Model I Image Manager-Image Archive in U-EYECARE - Model I
Image Manager-Image Archive in U-EYECARE Model III Image Manager-Image Archive in U-EYECARE Model III
Image Storage/Display A system responsible for receiving DICOM SOP Instances, storing those SOP Instances, and the ability to present them for viewing to the user.
Imaging Document Consumer Retrieves imaging data based on references in a retrieved imaging manifest.
Imaging Document Consumer The Imaging Document Source actor is the producer and publisher of imaging documents. It is responsible for providing imaging documents and meta-data to the Document Repository actor, which subsequently registers the imaging documents with the Document Registry actor. It also supports the retrieval services for DICOM SOP Instances referenced in a published imaging manifest document.
Imaging Document Recipient receives DICOM SOP Instances and image reports.
Imaging Document Source Publishes imaging data and makes it available for retrieval.
Imaging Document Source sends DICOM SOP Instances and image reports.
Imaging Order Filler The Imaging Order Filler Actor represents the information system that receives and processes orders for imaging services. The Imaging Order Filler is a minor variation of Order Filler in the Structured Workflow (SWF) profile of the IHE Radiology Technical Framework. It supports the same ordering transactions as found in the SWF profile, but has one required and two optional transactions. From the perspective of the care providers in this profile, an Imaging Order Filler is a single information system that manages orders and results for a given type of study.
IMAT/VMAT Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with VMAT/IMAT IMRT treatment beams.
IMAT/VMAT Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with VMAT/IMAT IMRT treatment beams.
Implantable Device Cardiac Consumer Receives cardiac implantable device data.
Implantable Device Cardiac Reporter Reports (sends) data from Cardiac Implantable Devices.
Importer Imports and reconciles imaging data.
Importer A system that imports evidence documents such as images, presentation states, Key Image Notes or Evidence Documents from hardcopy or digital media.
Information Recipient Receives event notification information from the Information Source, applies matching and filtering rules to determine which content to accept and which content to reject. It receives or rejects event notification information based on the content matching and filtering rules.
Information Recipient A system that receives event notification information from another system. The system determines if it should receive and consume the event information. It uses the event notification information to trigger a workflow.
Information Recipient (HL7) The Information Recipient Actor is responsible for receiving the HL7 V2.6 message from an Information Source or from a Form Receiver Message Exporter.
Information Source Provides presentation-ready information or documents.
Information Source A system that responds to requests for specific information or documents and returns ready for presentation information to be displays on the requesting actor.
Information Source A system that populates and communicates event notification information.
Information Source (HL7) The Information Source Actor is responsible for creating and transmitting an HL7 V2.6 message to an Information Recipient.
Information Src Provides notification of an admission or discharge of a patient or person known to the Information Source. The event message includes information about the patient needed by the Information Resource.
Infusion Order Consumer Programs an infusion pump based on order information.
Infusion Order Consumer The Infusion Order Consumer (IOC) actor receives the order information from the IOP actor and in turn programs the pump. The mechanism by which the IOC programs the pump with the received information is outside the scope of this profile.
Infusion Order Programmer Provides infusion pump order information.
Infusion Order Programmer The Infusion Order Programmer (IOP) actor sends the information comprising an order to the Infusion Order Consumer (IOC). The mechanism by which the IOP obtains the order information is outside the scope of this profile.
Initiating Gateway Supports all outgoing inter-community communications.
Initiating Imaging Gateway The Initiating Imaging Gateway Actor proxies Imaging Document Set Retrieve requests from an Image Document Consumer to a Responding Imaging Gateway with a Cross Gateway Retrieve Imaging Document Set transaction.
Integrated Document Source/Repository The Integrated Document Source/Repository is an XDS combination of Document Source and Document Repository that does not expose the interface between the Source and Repository. That is, this Source only publishes documents to its own Repository. It does register documents with a Document Registry
Integrated ECG Manager A system that manages the acquisition workflow of resting ECGs.
Integrated Electronic Health Record System The Integrated Electronic Health Record System combines the functionality of the EHR-S, DSS/OS, and PPS Manager actors in an integrated implementation. In such an integrated implementation, the transactions between the EHR-S and the DSS/OF are not externalized; i.e., patient and order management are solely the internal responsibility of the Integrated EHR-S implementation.
Integrated Report Manager/Repository A system that manages the status of reporting, and additionally maintains an internal report repository.
Kerberized Server Receives user authentication information for further use by the service that contains this actor.
Kerberos Authentication Server Provides central authentication of enterprise users.
Knowledge Requestor The system that formulates and sends a contextual request for ancillary information about a medical concept. Takes the parameters and sends to the resource available
Knowledge Resource The system that holds the information requested and responds to the request from the Knowledge Requestor
Label Broker Delivers pre-identified labels or labeled containers for the collection of biological specimens requested for the performance of in vitro diagnostic testing orders.
Label Broker The Label Broker receives label information, and delivers these labels in appropriate operations, and may notify the status of this process.
Label Information Provider An actor that provides the actor Label broker with label information
Label Information Provider Manages and provides specimen labeling instructions.
Laboratory Order Filler The Laboratory Order Filler Actor represents the information system that receives and processes orders for laboratory testing. The Laboratory Order Filler actor is a simplification of the Order Filler in the Laboratory Testing Workflow (LTW) profile of the IHE Laboratory Technical Framework. It supports the same ordering transactions as found in the LTW profile, but has one optional transaction. The Laboratory Order Filler implementing the Content Exchange option also supports the direct exchange of laboratory reports via the PCC-0 Exchange Content transaction using the content specified in XD-LAB profile.
Laboratory Result Message Receiver An authorized entity that is receiving a laboratory result message
Location Observation Consumer The profile actor that receives Location Services observations. The LOC may also be an actor in a different profile (DEC DOC, ACM AM, IPEC DOC). It is highly likely that the Location Observation Consumer (LOC) may also be an observation transaction receiving actor in other IHE PCD profiles. If the observation is simply to be recorded it is likely to be a DEC DOC or IPEC DOC actor. If the observation is to be acted upon it is likely to be an ACM AM Actor. If the location observation is to be used for equipment management the LOC actor is likely to be a MEMDMC DMIC actor (a CMMS).
Location Observation Reporter The profile actor that sends Location Services observations of location for devices or people and data from Location Services tags. The LOR is likely to be a Location Services system (LS) also recognized by the underlying technology used for equipment and people tracking, such as Radio Frequency Identification (RFID) or Real Time Location Services (RTLS), but may also be an actor in a different profile (DEC DOR, ACM AR, IPEC DOR), assuming the location tracking and reporting capability is embedded into the medical device or the location observation is merged with the medical device data in a gateway system prior to it being sent to the observation consumer
Master Patient Index (MPI) Maintains unique enterprise-wide identifiers for patients.
Medical Device Reporter Reports on uses of medical devices. First defined in PMDT Profile
Medical Device Requester Requests for uses of medical devices. First defined in PCC:PMDT Supplement
Medical Device Server Reports on uses of medical devices. First defined in PMDT supplement
Medication Administration Consumer Receives the reports of administration of medications
Medication Administration Informer Sends the reports of the administration actions performed.
Medication Administration Performer Receives instructions for administration of medications to patients, to perform the necessary checks and display it to the user (patient or healthcare professional)
Medication Administration Request Placer Submits the instance orders of medication administrations to the medication Administration Performer.
Medication Dispenser This actor is responsible for the process of dispensing medication to the patient, fulfilling the prescription. Therefore it produces the information on the medication dispensed to the patient. In order to achieve this, it receives prescriptions already validated. It also confirms drug availability for administration and it receives the administration plan and administration reports. This actor may be implemented as the point of sale software of a community pharmacy or the hospital pharmacy module of a hospital information system. The human actor behind this system actor is usually a pharmacist or a pharmacist assistant. In addition to the dispense, in this version this actor is considered to take care of all the dependencies to ensure a proper dispensing.
Medication Treatment Planner The main role of this actor consists in adding a new Medication Treatment Plan Item. It sends the cancelation of the planned item or its discontinuation, as well. In order to fulfill this task, the 290 Medication Treatment Planner retrieves the current set of planned medications of the patient.
Metadata Consumer The Metadata Consumer is responsible for the importation of metadata created by the Metadata Source. The Metadata Consumer can optionally query the Metadata Source for a list of Data Elements matching a selection criteria.
Metadata Source The Metadata Source is responsible for creation of the Data Element list matching a selection criteria and the creation of metadata for a selected Data Element per request from the Metadata Consumer. The Metadata Source is associated with a metadata registry.
Metadata-Limited Document Source The Metadata-Limited Document Source sends documents and metadata similar to a Document Source but is limited in the quantity of metadata it is able to provide.
MLC Fixed Aperture Arc Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with MLC Fixed Aperture arc treatment beams.
MLC Fixed Aperture Arc Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with MLC Fixed Aperture arc treatment beams.
MLC Variable Aperture Arc Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with MLC Variable Aperture arc treatment beams.
MLC Variable Aperture Arc Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with MLC Variable Aperture arc treatment beams.
Motorized Wedge Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static treatment beams using motorized wedges.
Motorized Wedge Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static treatment beams using motorized wedges.
National Contact Point Country A This is the country of affiliation of the patient
National Contact Point Country B This is the country of care
Newborn Admission Notification Manager A system or a module in a NANI framework, the purpose of which is to process subscription/un-subscription requests, to keep track of existing subscriptions, to receive information, and based on the set of filters for each subscription to send a notification about the received information to the appropriate Newborn Admission Notification Recipients.
Newborn Admission Notification Subscriber A system or a module in a NANI framework, the purpose of which is to receive and process notifications from the Newborn Admission Notification Manager.
Notification Pull Point The Notification Pull Point is the actor that stores notifications targeted to a specific Document Metadata Notification Recipient that cannot be directly notified. This actor delivers notifications to the Notification Puller when requested.
Notification Puller The Notification Puller is the actor that can create a pull point resource for the storing of notifications. It pulls notifications stored in a Notification Pull point actor when requested.
Notification Receiver This actor receives notifications of availability for documents in an XDS registry, and may optionally send acknowledgments of them.
Notification Sender This actor sends notifications of availability for documents in an XDS registry, and receives acknowledgements of these notifications.
On-Demand Document Source The On-Demand Document Source is the producer and publisher of On-Demand Documents. This actor registers On-Demand Document Entries with the Document Registry and responds to Retrieve Document Set transactions with a document reflecting current information for the entry requested.
Order Evaluation Requester An actor that requests evaluation of a proposed action to determine whether it may or should be initiated. First defined: PCC Guideline Appropriate Ordering (GAO) Supplement, May 2015
Order Filler See Department System Scheduler/Order Filler
Order Filler The actor that receives and processes (fills) orders. It also receives order cancellations.
Order Filler The Order Filler Actor represents an information system that receives and process orders for services.
Order Placer Generates and distributes orders to various departments.
Order Placer The actor that places orders or cancels orders on necessity.
Order Placer A hospital or enterprise-wide system that generates orders for various departments and distributes those orders to the correct department.
Order Result Tracker Stores and manages laboratory or pathology observations and associated results.
Order Result Tracker A hospital or enterprise-wide system that stores observations of various types (test results, images, clinical examinations reports, radiology reports, surgical act reports) obtained for the patients, registers all state changes in the results notified by Order Fillers. This actor doesn't store standalone observations, but ordered observations. The observations are always stored within the context of the order that generated them, with all the information related to that order.
Patient Context Participant Initiates and responds to patient context changes.
Patient Context Participant This actor participates in a shared context environment by both setting the patient context and responding to context changes as communicated by the Context Manager Actor. This actor shall respond to all patient context changes. This actor shall set the patient context, if the application containing this actor has patient selection capability.
Patient Demographics Consumer Uses demographic information.
Patient Demographics Consumer This actor allows a user to associate information with a patient at the point of care.
Patient Demographics Supplier Provides a searchable repository of patient demographic information.
Patient Demographics Supplier A repository of patient information that can be searched on demographic or visit-related fields.
Patient Encounter Consumer Uses patient encounter information.
Patient Encounter Consumer A system that uses patient encounter information provided by the Patient Encounter Source about a patient. It must be grouped with the Patient Demographics Consumer.
Patient Encounter Supplier Manages and provides information about new and existing encounters.
Patient Encounter Supplier A system responsible for adding, updating and maintaining encounter information about a patient. It supplies new and updated information to the Patient Encounter Consumer. It must be grouped with either the Patient Demographics Source or the Patient Demographics Consumer.
Patient Identifier Cross-reference Consumer Obtains and uses the identification of a patient in different Patient Identifier Domains.
Patient Identifier Cross-reference Consumer This actor allows a system in a Patient Identification Domain to find out the identification of a patient in a different Patient Identification Domain by using the services of a Patient Identity Cross-Reference Manager Actor.
Patient Identifier Cross-reference Manager Provides cross-referencing of patient identifiers across Patient Identifier Domains.
Patient Identity Cross-reference Manager Serves a well-defined set of Patient Identification Domains. Based on information provided by in each Patient Identification Domain by a Patient Identification Source Actor, it manages the cross-referencing of patient identifiers across Patient Identification Domains.
Patient Identity Source Provides a unique identifier and identity traits for each patient.
Patient Identity Source Each Patient Identification Domain requires this Actor to assign patient identities and to notify a Patient Identity Cross-reference Manager Actor of all events related to patient identification (creation, update, merge, etc.). For example, the Registration (ADT) Actor defined by the radiology Scheduled Workflow Profile would likely be a Patient Identity Source.
Patient Location Tracking Consumer Searches for current patient locations.
Patient Location Tracking Manager Manages patient locations within an enterprise.
Patient Location Tracking Supplier Provides updated patient locations.
Patient Registration The Patient Registration Actor is responsible for communicating patient demographics and administrative data (e.g., insurance) to other actors in this profile. These other actors may choose to accept this information from the Patient Registration Actor, or may provide another mechanism to support registration. The actors that support the Patient Registration Option will accept this communication from the Patient Registration Actor
Patient Registration Consumer An information system responsible for consuming patient appointment information. It updates its system with the appointment information and statuses.
Patient Registration Source A system responsible for the generation of patient demographic and visit information. It registers new patients and provides updates.
Performed Procedure Step Manager Re-distributes Performed Procedure Step information.
Performed Procedure Step Manager A system that re-distributes the Modality Performed Procedure Step information from the Acquisition Modality or Image Creator to the Department System Scheduler/Order Filler and Image Manager.
Personal Health Record The Personal Health Record actor represents the information system storing a s personal health data. This actor is responsible for supplying personal health data to the Care Manager actors through the PCC-0 Exchange Content transaction using the PHR Extract content specified in the Exchange of Personal Health Record Content profile.
Personnel White Pages Consumer Uses information from the Personnel White Pages Directory.
Personnel White Pages Consumer This actor has a use for information that can be found in the Personnel White Pages Directory.
Personnel White Pages Directory Holds authoritative Personnel White Pages information.
Personnel White Pages Directory This actor has authoritative Personnel White Pages information on the human workforce members of the enterprise.
Pharmaceutical Advice Repository This repository contains the pharmaceutical advice issued by the pharmaceutical adviser (typically a pharmacist). It provides this information to the prescription & pharmaceutical advice consumer.
Pharmaceutical Adviser This actor is responsible for the validation of prescriptions from a pharmacist’s perspective. Therefore, it receives the initial prescription, validates it and sends it back (accepted, cancelled, modified, substitution of pharmaceutical product); therefore it provides the pharmaceutical advice. To perform this task it checks the current treatment. The pharmaceutical advice can be due to clinical, legal, or supply aspects. This actor may be implemented in the hospital pharmacy module of a hospital information system or the point of sale software of the pharmacy. The corresponding human actor is typically a pharmacist (or pharmacist assistant).
Photon Applicator Arc Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with stereotactic arc treatment beams.
Photon Applicator Arc Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with stereotactic arc treatment beams.
Photon Applicator Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static, stereotactic arc treatment beams.
Photon Applicator Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static, stereotactic arc treatment beams.
Plan of Care Manager The actor knows about the jurisdictionally defined public health EHDI guidelines. Upon receiving a birth notification, this actor initiates an EHDI-WD workflow process for the specified patient. It creates the initial Hearing Plan of Care and records the hearing screening activities recommended for the newborn. It updates the Hearing Plan of Care when an Outcome Report becomes available, or a Care Summary becomes available. It closes the workflow once the Hearing Plan of Care has been updated with the Care Summary information generated at the time of discharge. See EHDI-WD Trial Implementation Supplement 2016, Vol 1 Section X.1.1.1
Point Of Care Data Manager This actor used in LPOCT profile is an application managing a set of POCRG and centralizing their results. The POCDM is ready to react to any conversation from a POCRG. The POCDM receives point of care observations from POCRG actors. It controls these observations within their context, stores them and forwards them to the Order Filler.
Point Of Care Data Manager Manages a set of point of care in vitro diagnostic devices and centralizes their results.
Point Of Care Result Generator A system which receives code sets from Code Set Master(s) and updates its internal tables to reflect the code set as maintained by the Code Set Master. This system may 130 also be an Order Placer, an Order Result Tracker, an Automation Manager, or an Order Filler.
Point Of Care Results Generator Produces in vitro diagnostic observations on the point of care.
Portable Media Creator This actor assembles the content of the media and writes it to the physical medium.
Portable Media Importer Reads imaging data on media, and reconciles and stores the instances.
Portable Media Importer This actor reads the DICOM information (DICOM FSR) contained on the media. This system provides the user the ability to select a set of DICOM instances and reconcile key patient and study attributes (when necessary) to facilitate inclusion of the imported data in the local information system(s).
Portable Media Sender The Portable Media Sender actor will never appear in an Integration Statement, since it only exists in the context of the Sending Software Option of the Portable Media Creator
Positioning and Delivery System A system that determines and corrects patient position then delivers therapeutic radiation.
Post-Processing Manager Schedules and manages post-processing worklists.
Post-Processing Manager A system that provides functions related to post-processing worklist management. This involves the ability to schedule post-processing worklist items (scheduled procedure steps), provide worklist items to post-processing worklist clients, and update the status of scheduled and performed procedure steps as received from post-processing worklist clients.
Pre/Post-Processor Processes biological specimens (e.g., sorters, aliquoters, decappers, specimen conveyors, specimen storage systems).
Pre/Post-processor An actor which provides some pre- and post- processes to the specimen. This actor is categorized to two sub categories, one is pre-processor and the other one is post-processor. A Pre/Post-processor processes a specimen according to SWOS, and return the result to the AM.
Prescriber A prescriber is an abstract actor who issues a prescription to a patient (generally a healthcare professional, usually a physician during treatment of a patient).
Prescription Placer The main role of this actor consists in placing the prescription (initial or modified in case of a substitution of invalidation, for example). It sends the cancellation of the prescription or its discontinuation, as well. In order to fulfill this task, the prescription placer retrieves the current treatment of the patient and medication already dispensed recently. The prescription placer receives the pharmaceutical validation and status tracking information such as substitution, availability, administration plan and reports and cancellation. The corresponding human actor is a prescriber.
Prescription Repository This repository contains the medication prescribed to the patient from the prescription placer and may receive updates to the current treatment (cancellations, changes, etc.). It also provides the current treatment to other actors such as the prescription consumer.
Print Composer A system that generates DICOM print requests to the Print Server. Print requests include presentation state information in the form of Presentation Look-Up Tables (Presentation LUTs). It may also read the DICOM information contained on interchange media.
Print Server Renders hardcopy images based on print requests.
Print Server A system that accepts and processes DICOM print requests as a DICOM Print SCP and performs image rendering on hardcopy media. The system must support pixel rendering according to the DICOM Grayscale Standard Display Function.
Process Activity Executor The ProcessActivityExecutor performs activities as prescribed by a running process being managed by a ProcessStateManager. The ProcessActivityExecutor retrieves current activity or task lists, works its list, updating the ProcessStateManager on activity state until completion. This cycle is repeated until all process activities have been worked and the process itself completes.
Process Definition Manager The ProcessDefinitionManager manages access to a repository of process definitions allowing for search and retrieval.
Process State Manager The ProcessStateManager manages the initiation and state of runtime process instances. The ProcessStateManager typically also supports the initiation and lifecycle management of task activities associated with a process while providing the ability for task performers to retrieve and update activities.
Protocol Archive Stores protocols and supports query and retrieval.
Protocol Definition Manager Protocol Definition Manager
Protocol Executor Protocol Executor
Protocol Manager Manages protocols used by Acquisition Modalities.
Protocol State Manager Protocol State Manager
Provider Information Consumer Accesses healthcare provider data from a Provider Information Directory.
Provider Information Directory Supports a directory of healthcare providers. The directory can include: Only Individual Providers, Only Organizational Providers , Organizational Providers and Individual Providers
Provider Information Source Submits healthcare provider data to a Provider Information Directory and receives an acknowledgement that the submission has been received.
Query Requestor DAF Query Requestor - responsible for Sending the query and receiving the response from the Responding application. First defined: DAF Implementation Guide, Sep 2015, PCC US National Extension
Query Responder DAF Query Responder - responsible for Receiving the query request, processing the query request, creating the query response and sending the query response. First defined: DAF Implementation Guide, Sep 2015, PCC US National Extension
Radiopharmaceutical Activity Supplier A laboratory system, dose creation and/or measurement system used to generate or administer a radiopharmaceutical to a patient as part of a Nuclear Medicine procedure.
Receiver A system that can receive exported instances over the network, whose behavior is otherwise unspecified, unless grouped with other actors.
Reconciliation Agent The Reconciliation Agent actor accesses clinical information in structured form. It automatically identifies potentially duplicated, overlapping, conflicting, or superseded information based upon application knowledge and provides that information for presentation to a clinician to complete the reconciliation process. It presents the demographics used identify the patient provided by each separate source of clinical information to the end user. It highlights inconsistencies found during the automated reconciliation process and provides the clinician with mechanisms to adjust or correct the input. It provides a mechanism for a clinician to add new information to the reconciled results. It authenticates the clinician prior to storage of the reconciled data (this step may be combined with other authentication steps used to finalize the record). It stores the data for future use by other actors.
Redactor The Redactor applies an extraction specification to select only specific information from an input document. The Redactor creates a new document containing only the information included in the extraction specification. The Redactor's output, called a redacted document, is returned to the sender of the original document.
Referral Dispatcher
Referral Initiator The provider, organization, or system, which initiates the referral
Referral Performer Participant responsible for execution of the visit. This workflow participant encapsulate many entities within the enterprise that responds to the referral request and produce the clinical report of the visit ending the eReferral process
Referral Recipient The provider, organization, or system, which will perform the services for which the patient is referred.
Referral Requester Health Professional (e.g., GP) that initiates the referral workflow. Produces the eReferral and the related supporting document.
Referral Scheduler Participant responsible for the scheduling of the referral, by providing an appointment for the patient
Refractive Measurement Consumer A system (such as an EHR) that is able to consume refractive measurements and import them into its database.
Refractive Measurement Source A system (such as an autorefractor, auto-keratometer, lensometer, etc.) that is able to generate standard based refractive measurements.
Refractive Measurement Source Importer A system able to import refractive measurements (typically with a proprietary connection) and synchronize them with a valid patient identifier to generate standard refractive measurements.
Registered Contourer A system that consumes multi-modality images, RT Structure Set objects, and Spatial Registration objects and allows the user to contour images in a registered display.
Registered Display A system that consumes multi-modality images, RT Structure Set objects, and Spatial Registration objects and allows the user to display the registered information
Registered Dose Display A system that consumes multi-modality images, RT Structure Set objects, RT Dose objects and Spatial Registration objects and allows the user to display the registered information.
Registrator A system that consumes multi-modality images and generates 1 or more Spatial Registration objects.
Report Assembler This actor consumes standard CDA summary of care documents and creates standard patient level quality reports. Additionally, this actor may consume patient-level quality reports and produce the corresponding aggregate-level quality report for an electronic clinical quality measure.
Report Consumer A system that receives imaging results (i.e., reports)
Report Creator Generates and transmits diagnostic reports.
Report Creator The actor the creates endoscopy observation report and send it to Order Placer.
Report Creator A system that generates and transmits draft (and optionally, final) diagnostic reports. It may also retrieve work list entries for reporting steps from the Report Manager and provide notification of completion of the step, allowing the enterprise to track the status of an awaited report
Report Creator A system that generates and transmits preliminary, final, or amended diagnositic results (i.e., reports).
Report Manager Manages reporting worklists and short-term storage of Report objects during the reporting process then distributes reports to report repositories.
Report Manager A system that provides functions related to report management. This involves the ability to handle content and state changes to reports and to create new DICOM Structured Reporting Objects based on these changes. In addition, the Report Manager generates and transmits verified, unsolicited text results to the Enterprise Report Repository.
Report Manager A system that provides management and short-term storage of reports during the reporting process then distributes them. It may also manage worklists and status of reporting.
Report Reader Accesses reports through network query/retrieve or reading interchange media and allow the user to view reports presented as DICOM Structured Reporting Objects.
Report Reader A part of a system that can access reports through network query/retrieve or reading interchange media and allow the user to view reports presented as DICOM Structured Report Objects.
Report Receiver Receives and stores anatomic pathology reports.
Report Receiver Report Receiver
Report Repository Provides long-term storage and retrieval of diagnostic reports.
Report Repository A system that provides long-term storage of reports and their retrieval as DICOM Structured Reporting Objects.
Report Sender Creates or has access to anatomic pathology reports in final status and sends these reports or parts of these reports.
Report Sender Report Sender
Report Template Creator A system that enables a user to create and edit report templates.
Report Template Manager A system that provides storage and management of report templates.
Requester Forwards a part of a laboratory testing requisition together with the associated biological specimens to a subcontracting performer, and collects the resulting observations.
Requester An application used by a laboratory to fulfill the upcoming test Orders or Order Groups, and deliver the results thereof to the orderers and to the intended recipients. When necessary, this application is able to extract Sub-orders out of these Orders or Order Groups, to message these Sub-orders to the system of a subcontracting laboratory and to receive and integrate the results returned by this system as well as the Sub-order status changes such as “specimen accepted”.
Research Information Consumer The Research Information Consumer is responsible for the retrieval of a list of potential research studies or of eligibility criteria.
Research Information Source TBD
Resource Server A server that provides services that need authorization
Responding Gateway Supports all incoming inter-community communications.
Responding Imaging Gateway The responding Imaging Gateway proxies Cross Gateway Retrieve Imaging Document Set requests from an Initiating Imaging Gateway to an Imaging Document Source with an Image Document Set Retrieve request.
Retrospective Data Consumer The Retrospective Data Consumer (RDC) initiates the query for retrospective data, initiating such query with the PCD-12 transaction.
Retrospective Data Responder The Retrospective Data Responder (RDR) responds to the Retrospective Data Query for retrospective data with an Retrospective Data Query Response containing (at most) the requested data or (at minimum) a NULL indicating no such data exist.
Screening Requestor This actor participates in the EHDI-WD workflow. It also knows about the jurisdictionally defined public health EHDI guidelines. Based on the recommended screening activity listed in the Hearing Plan of Care, or through the use of standing order, this actor requests the newborn hearing screening test. Prior to requesting the screening and based on jurisdictional requirements, consent for the procedure may be obtained. The request is communicated to the Order Placer Actor who is responsible for returning the results generated by the screening. Based on the results, this actor is responsible for requesting any repeat testing which may be indicated, according the jurisdictional screening guidelines. This actor is responsible for assessing the screening outcome based on one or more results or result interpretations, according to jurisdictional guidelines. See EHDI-WD TI Supplement 2016, Vol 1 Sec X.1.1.2
Secure Application Complies with IHE rules for user authentication, secure communications, security audit recording, and security policy enforcement. The specified application is compliant.
Secure Application The difference between the Secure Node and the Secure Application is the extent to which the underlying operating system and other environment are secured. A Secure Node includes all aspects of user authentication, file system protections, and operating environment security. The Secure Application is a product that does not include the operating environment. The Secure Application provides security features only for the application features. See section 9.7 for the relationships among a Secure Node, Secure Application, and other actors.
Secure Node Complies with IHE rules for user authentication, secure communications, security audit recording and security policy enforcement. All software on the system is compliant.
Secure Node A system unit that validates the identity of any user and of any other node, and determines whether or not access to the system for this user and information exchange with the other node is allowed. Maintains the correct time.
Secure Node Client
Secure Node Server
Sensor Data Consumer This actor receives sensor data from Personal Healthcare Devices (PHDs)
Sensor Data Source This actor is the Personal Healthcare Devices (PHD) generating sensor data
Service Availability The Service Availability actor responds to vFREEBUSY requests for busy time for a provider or service at a specified facility. The format of the request and response is defined by the IETF CalDAV specification (RFC 4791).
Service Availability The Service Availability Actor responds to requests for busy time for a provider at a service location, or for the service itself at a specified facility.
Service Finder The Service Finder Actor submits queries to the Care Services InfoManager, who returns the result(s) in a response document. Queries may be expressed by invoking “stored” queries or (optionally) by submitting well-formed ad hoc XQuery queries. Service Finder actors who support the FreeBusy option may submit a FreeBusy query to a Service Availability actor who will reply with a vFREEBUSY response.
Service Finder The Service Finder Actor submits queries to the Care Services InfoManager, which returns the result(s) in a reply document. Queries are expressed as parameterized stored query invocations or (optionally) as an ad hoc XQuery query. The Service Finder may optionally make queries against a Service Availability Actor as CalDAV vFREEBUSY queries.
Service Provider Service Provider
Sliding Window Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with sliding window IMRT treatment beams.
Sliding Window Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with sliding window IMRT treatment beams.
SMD Receiver Secure Message Delivery Receiver
SMD Receiver Intermediary Secure Message Delivery Receiver Intermediary
SMD Sender Secure Message Delivery Sender
SMD Sender Intermediary Secure Message Delivery Sender Intermediary
SMTP Aether This actor is shown for completeness, but is really part of the SMTP Infrastructure of the Internet.
Static Electron Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static electron treatment beams.
Static Electron Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static electron treatment beams.
Step & Shoot Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with step & shoot IMRT treatment beams.
Step & Shoot Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with step & shoot IMRT treatment beams.
Stereotactic Arc Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with stereotactic arc treatment beams.
Stereotactic Arc Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with stereotactic arc treatment beams.
Stereotactic Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static, stereotactic treatment beams.
Stereotactic Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static, stereotactic treatment beams.
Subcontractor Manages the scheduling and performance of in vitro diagnostic tests in a subcontracting laboratory, and reports the resulting observations to the requesting laboratory.
Subcontractor An application used by a laboratory to fulfill the upcoming Sub-orders placed by other laboratories. This application receives Sub-order messages, acknowledges specimen arrival and sends results messages
Task Manager Manages task instances in a worklist and provides associated query access and notifications
Task Manager Dispatches a read request
Task Performer Claims, performs and updates tasks managed by a Task Manager
Task Performer Executes a read
Task Requester Submits new tasks to a Task Manager
Task Requester Submits a read request
TBR Finalizer A Participant who validates the preliminary Tumor Board Review report
TBR Preparator Any Participant that is part of the Tumor Board, and involved in the review process
TBR Report Writer A Participant (usually a Healthcare Professional) who writes down the conclusions of the Tumor Board Review
TBR Requestor Participant (Healthcare Professional, e.g., gastroenterologist) who initiates the XTB-WD workflow. Produces the Request and the related supporting documents
TBR Scheduler Participant responsible for the scheduling of the Tumor Board Review, by providing one of the timeslots for the requested TBR
Time Client Maintains system clock synchronization with UTC based on time synchronization with one or more Time Servers.
Time Client Establishes time synchronization with one or more Time Servers using the NTP protocol and either the NTP or SNTP algorithms. Maintains the local computer system clock synchronization with UTC based on synchronization with the Time Servers.
Time Server Provides NTP time services to Time Clients.
Time Server A system unit that knows, maintains and distributes the correct time in the enterprise.
Tracker System that receives duplicate copies of messages to enable real-time decision-support and analytics. First defined in PCC BED Supplement, 8/2016.
Transport Data Consumer Queries for Transport data.
Transport Data Responder Responds to a query for clinical content, supplying reconciled lists.
Treatment Delivery Device A system that delivers therapeutic radiation to a correctly positioned patient.
Treatment Delivery Plan Consumer A Delivery System consuming the finalized treatment plan to be delivered.
Treatment Delivery Plan Producer The actor exposing the finalized treatment plan to the delivery System for treatment.
Treatment Management System Treatment Management System accepts RT Plan instances (one of 14 beam types).
Treatment Management System An application providing radiation oncology management services and capable of consuming treatment plans with any of the above treatment techniques.
User Context Participant Initiates and responds to user context changes.
User Context Participant Receives notification of user context changes and follows them for the application that contains it.
Value Set Consumer Retrieves Expanded Value Sets based on its OID and possibly its version if the latter is available.
Value Set Repository Provides Expanded Value Sets
Virtual Wedge Beam Consumer A Treatment Planning System (TPS) capable of consuming a radiation therapy treatment plan with static treatment beams using virtual wedges.
Virtual Wedge Beam Producer A Treatment Planning System (TPS) capable of producing a radiation therapy treatment plan with static treatment beams using virtual wedges.
Watcher Subscribes and receives notifications of events associated with a workitem (such as modification, cancelation or completion).
Watcher Monitors the evolution of a workflow
Web Application The Web Application the healthcare professional uses to view a laboratory report Web
Workflow Monitor Participant that tracks progress of the workflow and reacts to certain exception conditions.
Workitem Creator Requests that new workitems be created by systems that will either manage or perform the workitems.
Workitem Manager Provides management, query access and notifications for workitems in a worklist.
Workitem Performer Provides management, query access and notifications for workitems in a worklist.
X-Identity Provider This actor has authoritative identity information on the human user that is operating the X-Service User actor.
X-Service Provider Provides a service that needs an X-User Assertion.
X-Service Provider X-Service Provider
X-Service User Makes service requests of an X-Service Provider.
X-Service User X-Service User

Appendix B: Transactions

This section is in DRAFT state. Content presented is for feasibility testing only at this point. To expand the table, click on the blue "Expand" in the last column of the header.

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

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

See OID Registration

Appendix D: Glossary

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.

Glossary Rules

  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, PCD, 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 two entries in the glossary, one for the full term and one for the acronym (pointing to the full term). For example:
    1. 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).
    2. 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

Appendix F: Integration Statements

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/.