Official Templates

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

• Volume 1: Profiles - Word
• Volume 2: Transactions - Word
• Volume 3: Content Definitions - Word
• Volume 4: National Extensions- Word

IHE Technical Framework Supplement Template

• Supplement Template - Word

IHE Whitepaper Template

• Whitepaper Template - Word

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.

Appendix A: Actors

The IHE Actor information below is replicated from the current published IHE General Introduction Appendix A published here. 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. Change requested by PaLM : 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	Deprecated with QRPH RSP Profile.
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.
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).
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	Deprecated with QRPH RSP Profile.
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	Deprecated with QRPH RM Profile.
Research Information Source	Deprecated with QRPH RM Profile.
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 User	Makes service requests of an X-Service Provider.

Appendix B: Transactions

The IHE Transaction information below is replicated from the current published IHE General Introduction Appendix B published here. To expand the table, click on the blue "Expand" in the last column of the header.

Transaction	Name	Transaction Description
ARTI-01	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.
ARTI-02	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.
ARTI-03	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.
ARTI-04	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.
ARTI-05	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.
ARTI-06	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.
ARTI-07	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.
ARTI-08	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.
ARTI-09	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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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]
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]
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]
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]
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]
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]
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.
CARD-8	Report Reference Submission	A Report Manager sends a reference to a report to the Enterprise Report Repository for storage.
CARD-9	Encapsulated Report Storage	A Report Manager sends a preliminary, final, or corrected clinical report to the Report Repository.
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.
CARD-11	Encapsulated Report Retrieve	A Report Reader requests and retrieves a clinical report from the Report Repository.
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.
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.
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.
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.
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.
ENDO-1	Order Endoscopy	The transaction that places the Endoscopy order.
ENDO-2	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].
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]
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]
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]
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]
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]
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.
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.
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.
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.
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.
EYECARE-12	Appointment 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.
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.
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.
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].
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].
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.
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.
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.
EYECARE-20	Merge Patient	Enables systems to merge Patient IDs for a patient that was incorrectly filed under two different identifiers.
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.
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.
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.
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.
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.
ITI-1	Maintain Time	NTP transactions used to maintain time synchronization.
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.
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.
ITI-4	Kerberized Communication	The Kerberized Communication transaction is an aspect of the connection between a local client and a remote server.
ITI-5	Join Context	Allows a Context Participant Actor to locate and establish communication with the Context Manager Actor.
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
ITI-7	Leave Context	Allows Context Participant Actor to notify the Context manager Actor that it is breaking off communication.
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.).
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
ITI-20	Record Audit Event	The delivery of an audit event description from any secure node to the Audit Repository.
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.
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.
ITI-23	Find Personnel White Pages	This transaction will find the LDAP Directory by querying the DNS.
ITI-24	Query Personnel White Pages	This transaction provides for read-only access to the Personnel White Pages directory.
ITI-25	Send Notification	This transaction provides for sending of document availability notices in an XDS Affinity Domain.
ITI-26	Receive Notifications	This transaction provides for receipt of document availability notices in an XDS Affinity Domain.
ITI-27	Send Acknowledgement	This transaction provides for sending of acknowledgements to document availability notices in an XDS Affinity Domain.
ITI-28	Receive Acknowledgement	This transaction provides for receipt of acknowledgements of document availability notices in an XDS Affinity Domain.
ITI-29	Assert X-User Identity	This transaction will generate a Cross-Enterprise Authentication Assertion and pass it to a relying service.
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.
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.
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.
ITI-33	Send Document Set (Unused)	Unused
ITI-34	Retrieve Form	This transaction involves a Form Filler requesting a form from a Form Manager or Form Processor. The Form Filler has a formID, and possibly additional workflow information, obtained by a means that is outside the scope of this transaction.
ITI-35	Submit Form	This transaction involves a Form Filler submitting a form to a Form Receiver or Form Processor.
ITI-36	Archive Form	This transaction involves a Form Filler submitting form instance data to a Form Archiver.
ITI-37	Retrieve Clarifications	This transaction involves a Form Filler requesting a set of clarifications from a Form Manager or Form Processor. A Form Filler supporting the Retrieve Clarifications Option shall perform this request periodically, based upon a duration defined by or agreed upon with the Form Manager / Form Receiver or Form Processor.
ITI-38	Cross Gateway Query	The scope of the Cross Gateway Query transaction is based on the Registry Stored Query [ITI-18] transaction. The same set of stored queries is required to be supported and the options controlling what kind of data is returned are the same.
ITI-39	Cross Gateway Retrieve	The scope of the Cross Gateway Retrieve transaction is semantically the same as the Retrieve Document Set transaction [ITI-43].
ITI-40	Provide X-User Assertion	Transaction ITI-40 is used by the X-Service User to pass a claimed identity assertion to the XService Provider. The X-Service User and X-Service Provider use the X-Assertion Provider as the third party issuer of the claimed identity assertion.
ITI-41	Provide and Register Document Set-b	Provide and Register Document Set-b is used to transmit a set of documents and associated metadata. The documents and metadata might be stored for later retrieval or processed in some other way depending on the actor and workflow using the transaction.
ITI-42	Register Document Set-b	Register Document Set-b is used to register a set of document-associated metadata. The Register Document Set-b transaction passes a Document Submission Request (see ITI TF-3:4.2.1.5) from a Content Sender to a Content Receiver.
ITI-43	Retrieve Document Set	This transaction is used by the Document Consumer to retrieve a set of documents from the Document Repository, On-Demand Document Source, or Initiating Gateway. The Document Consumer has already obtained the XDSDocumentEntry uniqueId and the Document Repository repositoryUniqueId from the Document Registry/Initiating Gateway by means of the Registry Stored Query transaction.
ITI-44	Patient Identity Feed HL7 V3	Transaction ITI-44 is used by the Patient Identity Source, Patient Identifier Cross-reference Manager and Document Registry Actors. The scope is identical to ITI-8, patient Identity Feed.
ITI-45	PIXV3 Query	Transaction ITI-45 is used by the Patient Identifier Cross-reference Consumer and Patient Identifier Cross-reference Manager Actors. The scope is identical to ITI-9, PIX Query Scope.
ITI-46	PIXV3 Update Notification	Transaction ITI-46 is used by the Patient Identifier Cross-reference Consumer and Patient Identifier Cross-reference Manager Actors. The scope is identical to the scope of transaction ITI-10, PIX Update Notification.
ITI-47	Patient Demographics Query HL7 V3	Transaction ITI-47 is used by the Patient Demographics Consumer and Patient Demographics Supplier Actors. The scope is identical to ITI-21, Patient Demographic Query.
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.
ITI-49	Convey Printed Referral Request	This transaction has been retired in favor of use of the Cross-Enterprise Document Workflow (XDW) Profile.
ITI-50	Request Referral	This transaction has been retired in favor of use of the Cross-Enterprise Document Workflow (XDW) Profile.
ITI-51	Multi-Patient Query	The Multi-Patient Stored Query supports a variety of queries for multiple patients. It is based on the Registry Stored Query [ITI-18] transaction. The main difference is the set of queries, which is specified in this transaction.
ITI-52	Document Metadata Subscribe	This transaction involves a request by the Document Metadata Subscriber to the Document Metadata Notification Broker to start a subscription using a particular set of filters, or to cancel an existing subscription.
ITI-53	Document Metadata Notify	This transaction delivers a notification from the Document Metadata Notification Broker to the Document Metadata Notification Recipient about an event which matches an existing subscription.
ITI-54	Document Metadata Publish	This transaction delivers information from the Document Metadata Publisher to the Document Metadata Notification Broker about an event which may have a subscription. The WS Brokered Notification Publisher Registration requirements are out of scope for this transaction.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
ITI-65	Provide Document Bundle	This transaction is used to publish a new document entry and the document.
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.
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].
ITI-68	Retrieve Document	The Retrieve Document transaction is used by the Document Consumer to retrieve a document from the Document Responder.
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.
ITI-70	Pull Notification	This transaction is used to retrieve pending notifications.
ITI-71	Get Authorization Token	A transaction that is used to request and obtain an authorization token for use in authorized transactions.
ITI-72	Incorporate Authorization Token	Add an authorization token to a transaction.
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.
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.
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.
ITI-76	Patient Location Tracking Feed	Used to update patient location.
ITI-77	Patient Location Tracking Query	Used to query for the current patient location
ITI-78	Mobile Patient Demographics Query	Performs a query against a patient demographics supplier using HTTP, REST, and JSON/XML message encoding.
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.
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.
ITI-81	Retrieve ATNA Audit Event	Retrieve Audit Messages. Search ATNA audit messages based upon queries using ATNA audit message content.
ITI-82	Retrieve Syslog Event	Retrieve Syslog Messages. Search syslog messages based upon using the syslog metadata.
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.
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.
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.
ITI-86	Remove Documents	The Remove Documents transaction is used by the Document Administrator to request the removal of documents from a Document Repository.
ITI-87	Submit File	This transaction allows a File Source to publish a file and related metadata, or to update an existing file.
ITI-88	Search File	This transaction allows a File Consumer to query for a file metadata that meets certain criteria
ITI-89	Update DocumentReference	This transaction allows a File Source to update file metadata.
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.
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.
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.
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.
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.
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.
LAB-5	Test Results Management	This transaction carries the technically validated test results from the Automation Manager to the Order Filler.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
LAB-36	Sub-Order Result Delivery	This transaction provides the results message flow from Subcontractor to Requester.
LAB-51	Laboratory Code Set Management	Code set distribution (battery, test, observation).
LAB-61	Label Delivery Request	This transaction is used by the Label Information Provider to send label delivery instructions to the Label Broker.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
PAT-10	Public Health Reporting	Public Health Reporting
PCC-1	Document Sharing	PCC-1 describes common functional requirements for content exchange.
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.
PCC-7	Guideline Notification	Transaction PCC-7 is used by the Guideline Manager and Care Manager Actors.
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.
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.
PCC-10	V3 Care Management Update	Transaction PCC-10 is used by the Care Manager and Clinical Data Repository Actors.
PCC-11	V2 Care Management Update	Transaction PCC-11 is used by the Care Manager and Clinical Data Repository Actors.
PCC-12	Request for Clinical Guidance	This transaction is used by the Care Manager and Decision Support Service actors found in the RCG profile.
PCC-13	Query Clinical Knowledge	This transaction returns a list of references to clinical knowledge resources relevant to the requested clinical knowledge. This may occur when a user attempts to lookup information relevant to a particular term or collection of terms found on a patient’s chart, such as a problem, medication, allergy, laboratory result, et cetera. To support access to a wide variety of information sources, information is returned as an Atom feed listing links to relevant resources.
PCC-14	Retrieve Clinical Knowledge	This transaction is used by the Clinical Knowledge Requester to retrieve a document from the Clinical Knowledge Resource Repository. The Clinical Knowledge Requester has already obtained the URI information from the Clinical Knowledge Directory by means of the Query Clinical Knowledge transaction.
PCC-15	Communicate PCHA Data Transaction	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).
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
PCC-17	Translate Code	This transaction is used to translate a code from one coding system to another.
PCC-18	Retrieve Code Mappings	This transaction is used to retrieve the table used to perform code mapping.
PCC-19	Evaluate Order	Evaluates an order against guidelines and/or policies to determine its appropriateness in a given context.
PCC-20	Invoke Questionnaire	Displays the CDS questionnaire using HTML web pages and returns the result invoker.
PCC-21	Communicate PCD Data-hData	This transaction contains the PCD-01 message generated from sensor data using RESTful hData transports.
PCC-22	Communicate PCD Data-SOAP	This transaction contains the PCD-01 message generated from sensor data using Web Services.
PCC-23	Admission Notification	The Admission notification transaction notifies actors about admission of a patient to a bed.
PCC-24	Admission Order	The Admission Order transaction notifies actors about the intention to admit a patient to a bed.
PCC-25	Patient Movement	The Patient Movement transaction communicates information about movement of a patient from one location to another.
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.
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.
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.
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.
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.
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.
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.
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
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.
PCC-35	Cancel HT	This transaction cancels an ongoing Heart Team process.
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.
PCC-37	Update Care Plan	Update an existing or create a new Care Plan
PCC-38	Retrieve Care Plan	Retrieve a Care Plan
PCC-39	Subscribe to Care Plan Updates	Subscribe to receive updated Care Plans for specific patients.
PCC-40	Provide Care Plan	Provide updated Care Plans to subscribers.
PCC-41	Search for Care Plan	Used to find a care plan.
PCC-42	Communicate FHIR Data-hData
PCC-43	Share FHIR Resources
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.
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.
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.
PCC-47	Retrieve Care Team	This transaction is used to retrieve a specific CareTeam resource using a known FHIR CareTeam resource id.
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
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.
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.
PCC-51	Search Medical Device	This transaction is intended to provide a synchronous query mechanism.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
PCC-62	Query for Transport Data	Queries for transport data and patient information elements using a query/response.
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.
PCD-2	Subscribe to PCD Data	Defines predicate for communication of PCD data from Device Observation Filter (DOF) to a Device Observation Consumer (DOC).
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.
PCD-4	Report Alarm	This transaction is used by the Alert Reporter to report both unsolicited and subscribed alerts to the Alert Manager
PCD-5	Report Alarm Status	This transaction is used by Alert Management to report one or more dissemination status updates to the Alert Reporter.
PCD-6	Disseminate Alarm	This transaction is used by Alarm Management to disseminate the alarm to the Alarm Communicator.
PCD-7	Report Dissemination Alarm Status	This transaction is used by Alarm Communication to report one or more dissemination status updates to Alarm Management.
PCD-8	(Reserved)
PCD-9	Communicate IDC Observation	Communicate IDC Observation
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.
PCD-11	Reserved	Communicates Alarms, Alarm Status to Alarm Archiver.
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.
PCD-13	Retrospective Query Response	The Retrospective Data Response will represent the best efforts of the responder to fulfill the query.
PCD-14	(Reserved)	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.
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.).
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.
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.
PHARM-H2	Validated Order	Transaction PHARM-H2 is used by the Pharmaceutical Adviser and Prescription Placer and Medication Dispenser Actors.
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.
PHARM-H4	Administration Report	Transaction PHARM-H4 is used by the Medication Administration Informer, Prescription Placer, Medication Dispenser and Pharmaceutical Adviser Actors.
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.
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.
QPPH-1	Reserved	Reserved
QPPH-2	Reserved	Reserved
QPPH-3	Reserved	Reserved
QPPH-4	Reserved	Reserved
QPPH-5	Reserved	Reserved
QPPH-6	Reserved	Reserved
QPPH-7	Reserved	Reserved
QPPH-8	Reserved	Reserved
QPPH-9	Reserved	Reserved
QPPH-10	RetrieveProtocolDef - Retired	Retired
QPPH-11	EnterPatientRequest - Retired	Retired
QPPH-12	PatientScreeningVisitsScheduled - Retired	Retired
QPPH-13	RecordPatientScreeningVisit - Retired	Retired
QPPH-14	EnrollPatientRequest - Retired	Retired
QPPH-15	PatientStudyVisitsScheduled - Retired	Retired
QPPH-16	RecordPatientStudyVisit - Retired	Retired
QPPH-17	AmendProtocolDef - Retired	Retired
QPPH-18	AlertProtocolState - Retired	Retired
QPPH-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.
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.
QRPH-22	Publish Process Definitions	This transaction involves a Process Definition Manager publishing process definitions to a Process Activity Executor or Process State Manager.
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.
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.
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.
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.
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.
QRPH-29	Request Medical Knowledge	The Retrieve Medical Knowledge Transaction specifies the query and receipt of medial knowledge from an authoritative source (e.g. Public Health Authority). This medical knowledge is not patient specific, though the retrieval query for the knowledge may contain patient-specific content.
QRPH-30	Send Distribution Message	The Send Distribution Message Transaction supports the distribution of content from an authoritative source (e.g. Public Health Authority. This may be leveraged for emergency distribution messages and for informative health status for a monitored population (e.g. hearing screening conformance status.)
QRPH-31	SendExportDocument	Sends a document that needs to be redacted. The document sent includes an identifier for the Extraction Specification to be applied.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
QRPH-45	Communicate Hearing Screening Data	This transaction is used to communicate hearing screening result information.
QRPH-46	BFDRQuery
QRPH-47	VRDRQuery	This transaction connects a Data Consumer to a Data Responder to allow query/retrieve of death reporting related health information.
QRPH-48	Mobile Retrieve Form	This message uses the HTTP GET method on the target endpoint to retrieve and launch a URL form.
QRPH-49	Mobile Retrieve Capability	This transaction is used to request a statement of behaviors from a Data Responder.
QRPH-50	Mobile Authorize Form	This transaction is used to request authorization for the FHIR resource server from a Data Responder.
QRPH-51	Mobile Retrieve Access Token	This message uses the HTTP POST method on the target endpoint to convey desire to retrieve access.
QRPH-52	Mobile Populate Form	This message uses the HTTP POST method on the target endpoint to convey specific desired resources.
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.
RAD-1	Patient Registration	The ADT system registers and/or admits a patient and forwards the information to other information systems.
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.
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.
RAD-4	Procedure Schedule	Schedule information is sent from the Department System Scheduler/Order Filler to the Image Manager.
RAD-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 is returned to the Acquisition Modality.
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.
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.
RAD-8	Modality Image Stored	An Acquisition Modality sends acquired or generated images to the Image Archive.
RAD-9	Modality Presentation State Stored	An Acquisition Modality sends acquired or generated images to the Image Archive.
RAD-10	Storage Commitment	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.
RAD-11	Image Availability Query	The Department System Scheduler/Order Filler asks the Image Manager if a particular image or image series is available.
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.
RAD-13	Procedure Update	The Department System Scheduler/Order Filler sends the Image Manager updated order or procedure information.
RAD-14	Query Images	An Image Display queries the Image Archive for a list of entries representing images by patient, study, series, or instance.
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.
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.
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.
RAD-18	Creator Images Stored	An Image Creator sends new images to the Image Archive.
RAD-19	Creator Presentation State Stored	An Image Creator requests that the Image Archive store the created Grayscale Softcopy Presentation State objects.
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.
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.
RAD-22	Intentionally Left Blank	Intentionally Left Blank
RAD-23	Print Request with Presentation LUT	A Print Composer sends a print request to the Print Server specifying Presentation LUT information.
RAD-24	Report Submission	A Report Creator sends a draft or final report to the Report Manager.
RAD-25	Report Issuing	A Report Manager sends a draft or final Report to the Report Repository.
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.
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.
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.
RAD-29	Key Image Notes Stored	An Acquisition Modality or an Image Creator sends a Key Image Note to the Image Archive.
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.
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.
RAD-32	Authenticate Note	Any two actors exchange certificates in order to validate the identity of another node.
RAD-33	Maintain Time	Synchronize the local time with the time maintained by the Time Server.
RAD-34	Record Audit Event	Create and transmit an Audit Record.
RAD-35	Charge Posted	The Department System Scheduler/Order Filler sends descriptions of potential procedure and material changes.
RAD-36	Account Management	The ADT Patient Registration Actor informs Charge Processor about creation, modification and ending of patient s account.
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.
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).
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).
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.
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).
RAD-42	Performed Workstatus Update	The worklist provider informs other interested actors of the on-going status and completion of performed work.
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.
RAD-44	Query Evidence Documents	An Image Display queries the Image Archive for a list of entries representing Evidence Documents.
RAD-45	Retrieve Evidence Documents	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.
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.
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.
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).
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.
RAD-50	Store Instances	An Export Selector sends to an Export Manager instances that are to be de-identified, pseudonymized and exported.
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.
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.
RAD-53	Export Instances	An Export Manager sends to a Received instances that have been exported.
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].
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].
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.
RAD-57	Blending Presentation States Stored	An Acquisition Modality or Evidence Creator stores presentation information on registered image data sets for fused display.
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.
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.
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.
RAD-61	Imported Instances Stored	A system importing DICOM Objects or digitized hardcopy sends imported DICOM Composite Objects to the Image Archive.
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.
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.
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.
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.
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.
RAD-67	Media Information Stored
RAD-68	Provide and Register Imaging Document Set – MTOM/XOP	Provide & Register Imaging Doc Set-MTOM/XOP
RAD-69	Retrieve Imaging Document Set	Retrieve Imaging Doc Set
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.
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.
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.
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.
RAD-74	Replacement Instances Stored	A Change Requester send new updated instances with corrected header information to an Image Manager/Image Archive.
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
RAD-76	Query For Study	The Importer queries the Image Manager/Archive to find out if a study already exists.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
RAD-87	Get UPS Workitem Contents	This transaction is used to notify systems of the state or contents of a given UPS workitem.
RAD-88	Request UPS Workitem Cancelation	This transaction is used by an interested actor to request that a workitem be canceled.
RAD-89	Start Application	This transaction is used to launch a Hosted Application.
RAD-90	Stop Application	This transaction is used to shut down a Hosted Application.
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.
RAD-92	Start Task	This transaction is used to instruct a Hosted Application to start working on a task.
RAD-93	Get Task Details	This transaction retrieves the contents of a Unified Procedure Step (UPS) instance using the Application Hosting interface.
RAD-94	Get Task Data	This transaction is used to retrieve data from the Hosting System.
RAD-95	Notify Task Status	This transaction is used to inform the Hosting System of notable events during the processing of an assigned task
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.
RAD-97	Get Task Results	This transaction is used to retrieve data from the Hosted Application
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.
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.
RAD-100	Cancel Task	This transaction is used to cancel task processing in a Hosted Application.
RAD-101	Suspend Application	This transaction is used to suspend a running Application.
RAD-102	Resume Application	This transaction is used to resume task processing in a Hosted Application that had been suspended.
RAD-103	Retrieve Imaging Report Template	A Requester retrieves a template from a Responder.
RAD-104	Store Imaging Report Template	A Sender stores a report template to a Receiver.
RAD-105	Query Imaging Report Templates	A Requester queries for a list of templates from a Responder.
RAD-106	Invoke Image Display	Invokes the display of DICOM image studies.
RAD-107	Wado-RS Retrieve	The WADO-RS Retrieve transaction accesses DICOM SOP Instances via an HTTP interface.
RAD-108	Store Instances over the Web	Store one or more DICOM instances using DICOMweb STOW-RS.
RAD-109	Open Event Channel	Opens an event channel that can be used to send back events such as notifications.
RAD-110	Store Radiopharmaceutical Activity Information	Send details of Radiopharmaceutical Administration Events encoded in DICOM SR using DICOM Store.
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.
RAD-112	Cancel XDW Read	This transaction cancels an ongoing Remote Reading Workflow.
RAD-113	Accept/Reject XDW Report	Used to acknowledge production or revision of a Final Report.
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.
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.
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.
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.
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.
RAD-119	Claim XDW Read	This transaction allows a Task Performer to claim a Read without a previous assignment.
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.
RAD-121	Store Protocol	Transfers a DICOM Defined Procedure Protocol instance from a Sender to a Receiver.
RAD-122	Query Protocol	Requests and receives metadata about Protocol instances matching a specified filter.
RAD-123	Retrieve Protocol	Retrieves a DICOM Defined Procedure Protocol instance.
RAD-124	Transfer Multiple Events	Delivers a payload of many event reports as a single RESTful HTTP PUT transaction.
RAD-125	Store Protocol Approval	Transfers a DICOM Protocol Approval instance from a Sender to a Receiver.
RAD-126	Query Protocol Approval	Requests and receives metadata about Protocol Approval instances matching a specified filter.
RAD-127	Retrieve Protocol Approval	Retrieves a DICOM Protocol Approval instance.
RAD-128	Send Imaging Result	Transfer imaging results (i.e., radiology reports) using an HL7 v2 ORU message.
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.
RO-2	Structure Set Storage	In the Structure Set Storage Transaction, the Contourer stores a Structure Set on an Archive to make it available
RO-3	Geometric Plan Storage	In the Geometric Plan Storage transaction, the Geometric Planner sends the newly created Geometric Plan to the Archive.
RO-4	Dosimetric Plan Storage	In this transaction, the Dosimetric Planner sends the plan containing the references to the structure set to the Archive
RO-5	Dose Storage	In the Dose Storage transaction, the Dosimetric planner sends the newly created Dose to the Archive.
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
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.
RO-8	Geometric Plan Retrieval	In the Geometric Plan Retrieve Transaction, the requested Geometric Plan is transferred from the Archive to the Dosimetric Planner.
RO-9	Dosimetric Plan Retrieval	In this transaction, the Dose Displayer retrieves the plan containing the references to the structure set to the Archive
RO-10	Dose Retrieval	In the Dose Retrieve Transaction, the requested Dose is transferred from the Archive to the Dose Displayer
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.
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).
RO-13	Utilize 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.
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.
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.
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.
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.
RO-18	Retrieve 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.
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.
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.
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.
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.
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.
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
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.
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.
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-01	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.
TPPC-02	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.
TPPC-03	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.
TPPC-04	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.
TPPC-05	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.
TPPC-06	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.
TPPC-07	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.
TPPC-08	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.
TPPC-09	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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

Appendix C: Namesapces

See OID Registration

Appendix D: Glossary

Term	Definition
ACC NM Image Display	A display format for myocardial studies approved by the American College of Cardiology and the Society of Nuclear Medicine, as detailed in RAD TF-1: E5.3.3 and RAD TF-2: 4.16.4.2.2.
Access Decision Manager	A complex system that is responsible for access/creation/disclosure decisions performed according to Domain Policies, Consent Documents, etc. This actor can implement additional functionalities typical of a PDP (Policy Decision Point), PAP (Policy Administration Point) and a PIP (Policy Information Point).
Accession Number	The unique identifier assigned by the LIS of an Anatomic Pathology laboratory to an imaging Study. As expressed in DICOM Supplement 122: The concept of “accession” in Anatomic Pathology has been determined to be sufficiently equivalent to an “accession” in Radiology so that the existing Accession Number at the Study level may be reused for the same purpose and with essentially the existing definition. For Anatomic Pathology, like in Radiology, the Accession Number may correspond to the Order Filler Number, as specified in HL7 v2.x.
Accession Number	A user-friendly identifier, which identifies an instance of a filler order or imaging service request. It may group one or more requested procedures.
Accountability	The property that ensures that the actions of the entity may be traced uniquely to the entity.
Accountable Care Organization	Health care entity which supports an organization of health care providers that agrees to be accountable for improving the health and experience of care for individuals and improving the health of populations while reducing the rate of growth in health care spending.
ACO	See Accountable Care Organization.
ACR	American College of Radiology. See http://www.acr.org/.
Activity	A specific instance of an activity definition created in, and available from, an activity processor.
Activity	A specific instance of an activity created in, and available from, a task processor.
Activity Definition	A designed task which is deployable to a runtime activity processor, typically as part of a process definition.
Activity Definition	A definition of an individual task activity which is deployable to a runtime task processor. Typically an activity is defined as part of a process but standalone activities may also be defined.
Actor	An entity within a use case diagram that can perform an action within a use case diagram. Possible actions are creation or consumption of a message
Actor	Information systems or components of information systems that produce, manage, or act on health information. Actors exchange information through standards-based transactions.
Actor	An actor in the Unified Modeling Language (UML) "specifies a role played by a user or any other system that interacts with the subject." "An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchanging signals and data), but which is external to the subject."
Acuity Assessment	Also known as triage category, this is the acuity of the patient assigned during the process of ED triage. A number of evidenced based triage scales exist, including Emergency Severity Index (ESI), Canadian Triage and Acuity Scale (CTAS), the Australian Triage Scale (ATS), and the Manchester Triage System. In many emergency departments, patients may simply be classified as emergent, urgent, or non-urgent.
Acute Care	Inpatient care designed to treat or cure a disease or injury that has a rapid onset and follows a short course or requires immediate attention in a hospital.
ADC	Apparent Diffusion Coefficient.
Administration Report	The information about an actual administration event or act. For example, a report that “1 tablet of paracetamol was given to patient X at 13:45”. The administration report is for one single administration act.
Administration Request	An instruction for a single medication administration event. For example, a request to “administer paracetamol to patient X on 1/7, at 13:00”. An administration request does not expect any further action (such as dispensing), only the administration. One event can also include several units at the same time (e.g., give paracetamol to patient X - 2 tablets at 3 pm”, even different medications (e.g., “give drug A and drug B mixed together to patient X – 1 each at 3 pm ”).
Admit, Discharge and Transfer	See HL7 version 2.3.1.
ADT	See Admit, Discharge and Transfer.
Adverse Event	Any unfavorable and unintended diagnosis, symptom, sign (including an abnormal laboratory finding), syndrome or disease which either occurs during the study, having been absent at baseline, or if present at baseline, appears to worsen. (Adapted from the NINDS Glossary of Clinical Research Terms, Last updated November 24, 2008, retrieved from http://www.ninds.nih.gov/research/clinical_research/basics/glossary.htm.)
AE	See Adverse Event.
Aggregate-level Quality Report	A quality report that includes data computed from a set of patients across a set of encounters or another measured item.
AHD	See Application Hosting Device.
Alarm	A clinical alarm is an indication from a system or device, that when activated, indicates a condition requiring urgent clinical assessment and possible intervention.
Alert	A clinical alert is an indication from a system or device that a condition exists requiring clinical assessment and possible attention.
Aliquoter	An automated device which aliquots a parent specimen into one or more child specimen.
Ambulatory Care	All types of health services that do not require an overnight hospital stay.
American Academy of Ophthalmology
American College of Cardiology
American College of Clinical Engineering	American College of Clinical Engineering. See http://www.accenet.org/.
American Joint Commission on Cancer	Author of the TNM staging system (See TNM Stage.)
Analytical Work Order Step	A unit of work allocated from a Work Order, assigned to an analyzer, performed on a biological specimen, and producing observations characterizing this specimen.
Analytical Work Order Step	An analytical service to be performed by an analyzer on a specimen. The AWOS is ordered by means of a code representing this analytical service. The code may represent an elementary test or a panel of several elementary tests. In all cases the analytical service is expected to produce observations on the specimen.
Annotated Case Report Form	A case report form that includes the metadata associated with each data element on the form.
Antigen	A component of a disease-causing agent that stimulates an immune response. More commonly, the disease which a vaccine is supposed to protect against. In the context of immunization, the latter is the meaning of interest.
Aperiodic	PCD data which occurs at irregular intervals such as a Cardiac Output measurement.
Application Hosting Device	In the context of home health care, an intermediary or gateway device which may act as a Device Observation Reporter on behalf of associated home health care devices.
Appropriate Use Criteria	Appropriate Use Criteria (AUC) is an algorithm, typically evidence-based, which specifies the appropriateness of medical procedure(s) or service(s) based on the patient’s presenting clinical indication(s).
Arrest Disorder	"Arrest of dilation: Condition in which there is no progress in cervical dilation for more than 2 hours.
Arrest of descent: Condition in which the fetal head does not descend for more than 1 hour in primiparous woman and more than 0.5 hours in a multiparous woman. "
ASE	American Society of Echocardiography. See http://www.asecho.org/.
Assembler	A system that faithfully combines available information and does not create new information in the process of assembling the available data.
Assessment	Collection of clinical health data.
Association	A relationship between two or more entities. Implies a connection of some type - for example one entity uses the services of another or one entity is connected to another over a network link.
Attestation	A personal assertion of the truth of the statement to which you are attesting.
Audit Message	A syslog message that complies with the DICOM PS3.15 schema.
Audit Record	A syslog message that complies with the DICOM PS3.15 schema.
Authenticator	Role played by a laboratory "Clinical Expert" (see Clinical Expert) when performing "Clinical Validation" (see Clinical Validation) of a set of results issued in a CDA® R2 laboratory report, by which this person authenticates and endorses the laboratory report or a subset of it.
Authoritative	Acknowledged to be reliable.
Authorization Decision	A security token that describes which documents can be accessed by a specific entity.
Auto Program	A pump program in which some or all settings are received from another system such as an eMAR or BCMA system. When an auto-program is received on the pump, the clinician will enter any additional required settings, confirm them, and start the pump
Automatic Indentification and Data Capture	A technological solution like barcodes and RFIDs that allow information to be captured and entered into IT systems.
Autopopulate	This term is used in the Structured Data Capture (SDC) Profile to define content that is pulled into a form by a Form Filler. This contrasts against Prepopulate (RFD) and Querypopulate (mRFD)
Auto-population	When an EHR system automatically fills in form fields with data that are already available within the system’s database.
AWOS	See Analytical Work Order Step.
Basic Text SR Storage SOP Class	See DICOM Supplement 23
Battery	A set of one or more laboratory tests, identified by a single name and code that can be ordered to a laboratory. Synonym: Panel. See HL7 version 2.
Bedside	The point of care, typically in an acute care environment.
Bedside Computer-assisted Medication Administration system.	Bedside Computer-assisted Medication Administration system. Also known as Barcode Medication Administration system.
Binding	Process of associating two related elements of information. In the PCD context this typically means the association of a Patient with a device or set of devices.
Biometric	Measurable, physical characteristic or personal behavioral trait used to recognize the identity, or verify the claimed identity.
BIRADS 0	The American College of Radiology defines an assessment system for Mammography image interpretation and reporting (Breast Imaging Reporting and Data System: BI-RADS). "Assessment 0" means that the Mammographic assessment is incomplete, and that additional images or prior studies are needed to finalize the assessment and report.
Blending Softcopy Presentation State SOP Class	See DICOM 2004 Final Text Supplement 100.
Blood Type	Test to determine blood group, i.e., A, B, AB or O.
BMI	See Body Mass Index.
BMI z-score and percentiles	Among children and adolescents (ages, 2 to 18 years), BMI levels differ between boys and girls, and across ages. Therefore, for a BMI value to be interpretable among children and adolescents, it is necessary to express it as a z-score (standard deviation score) or as a percentile relative to children of the same sex and age in the CDC reference population. (This representative population consists of data collected from 1963 to 1980).
Body Mass Index	Body Mass Index (BMI) is a number calculated from weight and height: weight (kg)/[height (m)]2
Bounded Waveform	A limited duration continuous block of waveform data which is bounded in time, synonymous with waveform snapshot or waveform snippet.
BPOC	Barcode Point of Care System.
BT	Classic Bluetooth (versus BTLE).
BTLE	Bluetooth Low Energy (also called Bluetooth Smart and denoted BLE).
CAD	Computer Aided Detection
Cancer Case	A summary of all submitted information. It contains the final best information regarding a patient and his or her cancer and includes patient demographic, medical, staging, treatment, and service information.
Cancer Control	Actions taken to reduce the frequency and impact of cancer, both financially and medically.
Cancer Reporting	Actions taken to notify a public health agency of a case of cancer.
Cancer Reporting Extract	A CDA document containing required and recommended information about a patient’s cancer diagnosis and treatment, submitted by a physician to a public health cancer registry.
Candidate Standard Validation	Executing the Candidate Standard validation approach. HL7 will have a modified open approach to candidate standard validation. All those participants that made a non-binding commitment in step (5) will be included if they choose to honor the commitment. Others may be added to achieve a balance or for other necessities for validation. The previous notwithstanding, HL7 will limit the number of participants to ensure a manageable process and reasonable time frame.
Cardiac Device Programmer	A device used to noninvasively interrogate, monitor, and alter the operating parameters of an implantable pacemaker, defibrillator, or cardiac resynchronization device.
Care Delivery Organization	A Care Delivery Organization refers to a broad variety of healthcare facilities (private practice, nursing home, ambulatory clinic, acute care in-patient facility, hospitals etc.
Care Plan	A patient has only one care plan. This is the patient-centered holistic view of all the various plans of care reconciled together, and adopted by the patient as what they actually agree they intend to do.
Care Plan (as used in DCP Profile)	Tool used by clinicians to plan and coordinate care for an individual patient. It aids in understanding and coordinating the actions that need to be performed for the target of care. The care plan is known by several similar and often interchangeable names such as the plan of care and treatment plan. See http://wiki.hl7.org/index.php?title=Care_Plan_Project_-_PCWG.
Care Plan Domain Analysis Model	A common reference used to support the development of implementable care plan models. See http://wiki.hl7.org/index.php?title=Care_Plan_Project_-_PCWG.
Care Transitions	When a patient is transferred or discharged to another phase of care. The destination of the care transition can be to the patient's home or the individual's specific living arrangements (half-way house), another nursing unit within a provider's organization, hospice or home health care, a long-term care facility (nursing home), a specialty hospital, a rehabilitation hospital, or a public facility (jail).
Case Report Form	A record of clinical study observations and other information that a study protocol designates must be completed for each subject.
Causes of Death	All those diseases, morbid conditions or injuries which either resulted in or contributed to death and the circumstances of the accident or violence which produced such injuries. (ref ICD-10 vol 2, section 4.1.1).
CCD	See Continuity of Care Document.
CCOW	See Clinical Context Object Working Group.
CD	Compact Disk.
CDA®	See Clinical Document Architecture.
CDASH	A standard from CDISC which defines those data elements common to case report forms.
CDEs	See Common Data Elements.
CDISC	A standards development organization which focuses on clinical research standards.
CDR	Clinical Data Repository.
CDS	See Clinical Decision Support
CEMS	See Clinical Equipment Management System.
Centers for Medicare & Medicaid Service	Centers for Medicare & Medicaid Service (CMS) is a department of the U.S. Health and Human Services (HHS).
Centrifuge	An automated device which divides the blood into a serum ingredient and a blood cell ingredient by centrifugal separation. Acts as a Pre/Post-processor in LDA integration profile.
Certified Nurse Midwife	A nurse with specialized education and training in providing care to childbearing women during all stages of pregnancy including the postpartum period.
Certified Tumor Registrar	A nationally certified data collection and management expert with the training and specialized skills to provide the high quality data required in all avenues of cancer statistics and research.
Certifier	Person authorized by law (e.g., the physician who attended the deceased in his/her last illness; or the medical examiner/coroner for deaths of persons who were not attended during the last illness by a physician or for unnatural deaths due to violence or accident) who reports, on the prescribed form, stating to the best of his/her knowledge and belief, the cause of death and other facts related to the event for submission to the registrar (ref UN, Handbook of Vital Statistics Systems and Methods, Volume 1, Glossary)
Certifies	Process of reporting in the jurisdiction's prescribed format on the prescribed form, to the best of his/her knowledge and belief, the cause of death and other facts related to the event for submission to a registrar.
Chemotherapy regimen	A collection of drugs administered in a highly organized manner for treating cancer. It includes information on doses, scheduling, and duration of administration.
Chromosome abnormalities	Chromosome abnormalities consist of any change occurring in the structure or number of any of the chromosomes of a given species. In humans, a number of physical disabilities and disorders are directly associated with aberrations of both the autosomes and the sex chromosomes, including Down, Turner's, and Kleinfelter's syndromes.
CIS	Clinical Information System.
Class	A logical entity encapsulating data and behavior. A class is a template for an object - the class is the design, the object the runtime instance.
CLIA	See Clinical Laboratory Improvement Amendments.
Clinical Context Object Working Group	ANSI certified technology neutral specification for the Health Level Seven Context Management Architecture (CMA). This architecture enables multiple applications to be automatically coordinated and synchronized in clinically meaningful ways at the point of use. The architecture specified in this document establishes the basis for bringing interoperability among healthcare applications to point-of-use devices, such as a personal computer that serves as a clinical desktop.
Clinical Context Object Working Group	ANSI certified technology neutral specification for the Health Level Seven Context Management Architecture (CMA). This architecture enables multiple applications to be automatically coordinated and synchronized in clinically meaningful ways at the point of use.
Clinical Decision Support	The ability to use data to discover and/or justify the proper activities planned for a patient.
Clinical Decision Support	A clinical decision support (CDS) system is designed to assist physicians and other health care professionals with clinical decision making tasks. A CDS system implements an Appropriate Use Criteria (AUC) algorithm.
Clinical Document Architecture	An HL7 V3 standard for the electronic representation of clinical documents.
Clinical Document Architecture	An HL7 standard for the exchange for clinical documents. It specifies the structure and semantics of clinical documents. More information is available from http://www.hl7.org.
Clinical Document Architecture	The HL7® Version 3 Clinical Document Architecture (CDA®) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange between healthcare providers and patients. It defines a clinical document as having the following six characteristics: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness and 6) Human readability.
Clinical Document Architecture	This term is used to describe conformance of an XML document against a variety of industry standards.
Clinical Equipment Management System	A clinical equipment specific variant of a Computerized Maintenance Management System (CMMS).
Clinical Expert	Also “Medical expert” or “Bio-medical scientist” or “Results principal interpreter”. The person who assumes the overall responsibility for the clinical validation and reporting of an order or an order group. HL7 V2.5 speaks of “Result principal interpreter”. In HL7 CDA R2 this actor is playing the role of “Authenticator” (AUTHEN) of the laboratory report or of a subset of this report.
Clinical Laboratory Improvement Amendments	Quality standards regulating activities related to in vitro testing for laboratories in the US. See http://www.fda.gov/CDRH/clia/ and http://www.cms.hhs.gov/clia/.
Clinical Trial	A research investigation involving human subjects that is designed to answer specific questions about the safety and efficacy of a biomedical intervention
Clinical Validation	Also “Medical validation”. The process by which a clinical expert accepts and interprets the results of an order or an order group. Interpretation of the results considers the results together with the biological history, clinical and therapy information available for the patient. This step may sometimes be performed by an expert system that uses knowledge rules and emulates the reasoning of the bio-medical scientist, under its responsibility. In HL7 CDA R2 this process is recorded as “authentication” of the laboratory report or of a subset of this report.
Closed Loop Referral	A closed loop referral is a referral with a definite end-point, when the referral is considered complete. Closed Loop Referral is a subset of Transition of Care, where the cooperative provision of care is limited to the Referral Request and Referral Outcome between two providers. It includes bi-directional information exchange between the Referral Initiator and the Referral Recipient.
CLSI	The Clinical and Laboratory Standards Institute.
Code Set	A code set is any set of codes used for encoding data elements, such as tables of terms, medical concepts, medical diagnosis codes, or medical procedure codes. An example of international code set is LOINCTM (Logical Observation Identifier Names and Codes).
Cohort Specification	Defines the public health cohort by specifying inclusion and exclusion criteria. Inclusion criteria must be met for cohorts. Exclusion criteria are the characteristics in a cohort specification, any one of which may exclude a potential subject from participation in a cohort.
Combination Vaccine	A vaccine product containing antigens to more than one disease. Combination vaccines are commonly used to reduce the number of “needle sticks” required to give multiple vaccines at the same time. A combination vaccine is effectively the same thing as a Multiple Antigen Vaccine or a Poly-valent Vaccine.
Common Data Elements	Standardized data element descriptions for collection and exchange of data of common interest to a particular community, and thus the community has agreed to share their definition, management and use. CDEs share a common set of attributes which facilitates their reuse in different settings, and are intended to aide in interoperability and data reuse.
Communication	A process for the transfer of information from one entity to another. The process can be verbal or written, but requires a sender, a message, and a recipient.
Community	A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information via an established mechanism. Membership of a facility/enterprise in one community does not preclude it from being a member in another community.
Community	A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information via an established mechanism. Facilities/enterprises may host any type of healthcare application such as EHR, PHR, etc. A community is identifiable by a globally unique id called the homeCommunityId. Membership of a facility/enterprise in one community does not preclude it from being a member in another community. Such communities may be XDS Affinity Domains which define document sharing using the XDS Profile or any other communities, no matter what their internal sharing structure.
Community Medication List	A Community Medication List is a collection of Medication Treatment Plan-, Prescription-, Dispense- and Medication Administration Items (and their related Pharmaceutical Advice Items) representing the Medication information of the patient at a certain point of time and according to business rules specified.
Co-morbidity	The presence of one or more disorders (or diseases) in addition to cancer.
Completed Form	A form where all the fields contain data – through a combination of pre-population, auto-population, and manual edits, and is ready for submission.
Complex Interval Administration	A specific case of continuous administration where the parameters of the administration are changed and those changes are considered relevant. For example, one administration that starts at one rate and then is changed to another rate, or when there is a change in the solvent and is important to capture that change.
Complications	A list of current or past health problems a patient is experiencing or has overcome.
Composer	A system that creates new information about the patient. The new information may be introduced while assembling other available data.
Computerized Maintenance Management System.	This is the system which the hospital makes use of to maintain its inventory of medical devices, their identification, their status, their software, firmware, and hardware versioning information and history. This is a system for which reception of device location observation is well suited as a means of identifying the last known location of equipment in need of servicing, repairs, or version upgrades.
Confidentiality Code	A value from the value-set that indicates the sensitivity and/or confidentiality of an object (e.g., Document). This may be from the HL7 defined vocabulary or extension defined in the Security/Privacy Domain. The Confidentiality Code is used during access control to indicate the type of object as viewed by the security and/or privacy policies.
Conformance Statement	A conformance statement is a claim that the behavior of an application or application module agrees with the constraints stated in one or more profiles. A Conformance Statement is documentation of the degree to which a particular application conforms to the specification. Part of that document will be a profile expressing the requirements relevant to a particular standard. Standard Profiling is based upon the consistent application of constraints to a set of base specifications. This document outlines the processes that govern the definition of profiles and conformance statements.
Congenital Heart Defect	"Congenital heart defect (CHD) is a defect in the structure of the heart and great vessels of a newborn. Obstruction defects. CHD can be classified as:
-Obstruction defects occur when heart valves, arteries, or veins are abnormally narrow or blocked.
-Septal defects, for defects concerning the separation between left heart and right heart.
-Cyanotic defects, including persistent truncus arteriosus, total anomalous pulmonary venous connection, tetralogy of Fallot, transposition of the great vessels, and tricuspid atresia."
Connectathon	IHE testing process - a weeklong interoperability testing event where participating companies test their implementation of IHE capabilities with corresponding systems from industry peers.
Containment Tree	The Domain Information Model for patient care devices defined in ISO/IEEE 11073 includes a hierarchy of objects representing the structure of a device: medical device system (MDS), virtual medical device (VMD), channel, and metric. An object in a device is described in terms of the objects containing it in this hierarchy, that is, its containment tree. See also "Dotted Notation".
Content Binding	A content binding describes how the payload used in an IHE transaction is related to and/or constrained by the data elements contained within the content sent or received in those transactions.
Context Management Registry	An HTTP technology specific service defined by the HL7 Context Management "CCOW" Standard to locate an instance of a context manager servicing a specific desktop.
Context Session	A collection of participant applications that are sharing context on one or more subjects.
Continuity of Care Document	An HL7 Clinical Document Architecture (CDA) implementation alternative to ASTM ADJE2369 for institutions or organizations committed to HL7 standards. This specification was developed as a collaborative effort between ASTM and HL7. See http://www.hl7.org.
Continuity of Care Document	Continuity of Care Document (CCD®) is document specification standard specified by HL7®/ASTM and commonly used for electronic document exchange. CCD® is based on HL7®’s Clinical Document Architecture (CDA®).
Continuous Administration	An administration that takes a measurable amount of time, for example an infusion.
Continuous Waveform	A continuous stream of waveform data terminated only on request, on patient disconnect or due to technical reasons.
Contraindication	Any medical, environmental, genetic, or other condition that makes a treatment inadvisable. Contraindications include increased likelihoods of a serious Adverse Events, reduced effectiveness of treatment, or duplicative therapies.
Conventional 2D Mammography	Refers to mammography images that have been acquired using FFDM.
Conveyor	An automated device which transports specimen to other devices. Acts as a Pre/Post-processor in LDA integration profile.
Coordination of Care Services Functional Model	Supports shared and coordinated care plans as well as support of multidisciplinary care team members to communicate changes resulting from care plan interventions and collaborate in removing barriers to care. See http://wiki.hl7.org/index.php?title=Care_Coordination_Capabilities.
Cytology	Microscopic examination of cells.
D (Rh)	A blood screening test for presence of IgG antibodies to the Rh D antigen on red blood cells.
D (Rh) Sensitized	Rh negative mother is sensitized to the Rh D antigen. A sensitized mother produces IgG anti-D (antibody) that crosses the placenta and coats D-positive fetal red cells which are then destroyed in the fetal spleen.
DAM	See Domain Analysis Model.
DAP	Dose Area Product.
Data Element	A data element is a unit of data for which the definition, identification, representation, and permissible values are specified by a set of attributes and considered in context to be indivisible.
Data Element	A logical definition of data.
Data Field	A physical unit of storage in a record.
Data Item	An individual instance of a data element.
Data Set	A series of images or set of frames.
DBT	Digital Breast Tomosynthesis
DCM	See Detailed Clinical Model.
Decapper	An automated device which takes off the cap of the specimen container. Acts as a Pre/Post-processor in LDA integration profile.
Decision Support Service	Decision Support provided as a computerized web service. It is a basic component of Service Oriented Architecture (SOA) for Healthcare. When it is used to provide Clinical Decision Support, it is often called a CDS Service, or simply CDSS.
Defined Procedure Protocol Instance	A DICOM instance of a Defined Procedure Protocol SOP Class such as the CT Defined Procedure Protocol SOP Class.
Delivery	Expulsion or extraction of the infant, placenta and membranes at birth.
Delivery	The infusion pump mechanism for moving fluid into a patient is engaged.
Detached Signature	"A Digital Signature approach that includes only references to the signed content (aka manifest) within the signature syntax.
The signature is over content external to the Signature element, and can be identified via a URI or transform. Consequently, the signature is ""detached"" from the content it signs. This definition typically applies to separate data objects, but it also includes the instance where the Signature and data object reside within the same XML document but are sibling elements. [W3C XMLDSIG]"
Detailed Clinical Model	"A Detailed Clinical Model (DCM) is an information model of a discrete set of precise clinical knowledge which can be used in a variety of contexts.
Detailed Clinical Models (DCM) are descriptions of items of clinical information that include the clinical knowledge on the concept, the data specification, a model and where possible, technical implementation specifications. A DCM is a conceptual specification of the semantics of discrete structured clinical information. It provides the data elements and attributes, including the possible values and types of the attributes, needed to convey the clinical reality in a fashion that is understandable to both clinical domain experts and modelers. This includes the potential for use in health care information and communication technology, for example in EHR, Telehealth applications, messages, medical devices, computer algorithms, and deductive reasoning, decision support, among others. It provides unambiguous detail which is intended to be cross domain and cross discipline and standardized and reusable over domains, purposes, standards and implementations. DCM work currently includes clinical content analysis, quality assurance, information modeling, and repositories. DCM includes the structural model. Dynamic models are handled elsewhere, but some aspects of dynamics might be in the DCM.
""Detailed Clinical Models are small items of clinical, preventive and care information that are well defined and for which knowledge, data definition, vocabulary binding, and information model for use in information and communication technology are standardized and reusable over domains, purposes, standards and implementations."" [ISO 13972 draft]"
Diagnoses	Analysis of patient assessment data.
DICOM	Digital Imaging and Communications in Medicine. See http://medical.nema.org/.
DICOM Encapsulated PDF	See DICOM PS 3.3.
DICOM Model of the Real World	See DICOM PS 3.3.
Digital Signature	A useful legal equivalent to facsimile signature that may be generated for a variety of entities, including human and machine sources. Based on digital certificates attributable to well-known healthcare oriented certificate authorities; incorporating cryptographically secure techniques for signature generation and validation.
Digital Signature	Formally speaking, a value generated from the application of a private key to a message via a cryptographic algorithm such that it has the properties of integrity, message authentication and/or signer authentication. (However, we sometimes use the term signature generically such that it encompasses Authentication Code values as well, but we are careful to make the distinction when the property of signer authentication is relevant to the exposition.) A signature may be (non-exclusively) described as detached, enveloping, or enveloped. [W3C XMLDSIG]
Directory	A book containing the names and residences of the inhabitants of any place, or of classes of them; an address book; as, a business directory.
Dispense Item	A Dispense Item belongs to one Dispensation and represents one dispensed medication. It contains the dispensed medicinal product including information such as product code, brand name and packaging information.
Dispense/Dispensation	Dispensation is the act of assigning a medication to a patient, normally as indicated in the corresponding prescription. Since prescriptions can span long periods of time, a single prescription may result in medicines dispensed several times.
Dispensing	The act of assigning a medication to a patient, normally as indicated in the corresponding prescription. Since prescriptions can span long periods of time, a single prescription may result in medicines dispensed several times.
Dose Length Product	Dose Length Product.
Device Message Layer	Device Message Layer defined by the standard POCT1-A.
Date of Birth	Date of Birth.
Domain Analysis Model	A Domain Analysis Model (DAM) is an abstract representation of a subject area of interest designed to provide a generic representation of a class of system or capability and to suggest a set of approaches to implementation. In HL7 a DAM is complete enough to enable the development of downstream platform-independent models: HL7 RIM-based information and service models. A DAM may also be used to constrain other standards for use in healthcare (e.g., to constrain access control markup standards). The process used to create a DAM is documented in the HL7 Development Framework (HDF).
Dosage Instructions	Dosage Instructions are a set of data elements which together represent the dosage instructions to a medication such as duration of treatment, medication frequency, dose quantity and route of administration.
Dose Object	A persistent DICOM object (See DICOM PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD) for recording details related to Irradiation Events. DICOM has defined Dose Objects for CT and Projection X-ray procedures.
Dose of Antigen / Vaccine Component	Immunization CDS will analyze an existing immunization history by vaccine component, or doses of antigen, in order to build a proposed immunization care plan (ICP).
Dose of Vaccine / Administered Dose	This is a quantity of medication or vaccine substance that is administered as a single shot. It will contain one or more doses of antigens. Immunization histories are typically recorded in terms of administered doses of vaccine, rather than doses of antigens.
Dose Registry	A system that collects dose information from multiple sites, generally to perform analysis of Population Dose and Dose Indicators.
Dosimetric Plan	An RT Plan object containing sufficient information to dosimetrically define a radiation therapy treatment. The Dosimetric Plan shall contain references to RT Structure Set and RT Dose objects. A Dosimetric Plan shall contain a Fraction Group Sequence (300A,0070) containing a single sequence item. Each beam in the Referenced Beam Sequence (300C,0004) shall have its Beam Meterset (300A,0086) defined.
Dotted Notation	A string in the form k.l.m.n[.o] (where k..o are integer ordinals mapping an object within a device: Medical Device System (MDS),Virtual Medical Device (VMD),Channel, Metric, and optional Facet), used in PCD -- specifically in the OBX-4 Sub-id field, to associate an observation with its unique ‘address’ within the device.
DSS	See Decision Support Service.
DVD	A trademark of the DVD Forum that is not an abbreviation.
ECG	Electrocardiogram
EDC	See Electronic Data Capture.
EDIS	See Emergency Department Information System.
EDRS	See Electronic Death Registration System.
EEG	Electroencephalogram.
EHR	Eye Care Electronic Health Record System or sometimes called Eye Care Electronic Medical Record System.
EHR	See Electronic Health Record.
EHR-CR	An EHR-CR or Care-delivery Record abstracts the patient information managed by the IT system or set of systems of a Care Delivery Organization, which may support a broad variety of healthcare facilities (private practice, nursing home, ambulatory clinic, acute care in-patient facility, etc.
EHR-LR	The documents shared by the EHR-CR and tracked by the Registry form a Longitudinal Record for the patients that received care among the EHR-CRs of the XDS Affinity Domain. This is known as the EHR-LR.
Electronic Data Capture	The process of collecting clinical trial data into a permanent electronic form.
Electronic Death Registration System	A jurisdiction-based system used to create and register the legal death certificate.
Electronic Health Record	An electronic record derived from a computerized system used primarily for delivering patient care in a clinical setting
Electronic Health Record	This term is used to describe a system that maintains a longitudinal view of a patient’s history. It contains comprehensive information on a patient’s health.
Electronic Medical Record	This term is used to describe a system that maintains a narrow view of a patient’s history. It is primarily used by providers to diagnose and treat conditions.
Electronic Medical Record	An Electronic Health Record system used within an enterprise to deliver care (also called EHR-CR by IHE-XDS).
Eligibility Criteria	Defines the study population by specifying inclusion and exclusion criteria. Inclusion criteria must be met for prospective subjects to be eligible for participation in a study. Exclusion criteria are the characteristics in a protocol, any one of which may exclude a potential subject from participation in a study.
eMAR	Electronic Medication Administration Record.
Emergency Department Information System	An extended EHR system used to manage data in support of emergency department patient care and operations. The functions of an EDIS may be provided by a single application or multiple applications.
eMPI	Enterprise Master Patient Index.
EMR	See Electronic Medical Record.
Encounter	An interaction between a patient and care provider(s) for the purpose of providing healthcare-related service(s). Healthcare services include health assessment. For example, outpatient visit to multiple departments, home health support (including physical therapy), inpatient hospital stay, emergency room visit, field visit (e.g., traffic accident), office visit, occupational therapy, telephone call.
Encounter	An encounter happens between a patient and a care provider who can be an individual or an organization.
End of Care	In the context of closed loop referral, the End of Care is determined by the Referral Recipient when no more care is needed to satisfy the reason for the referral; it is when the result of referral is sent to the Referral Initiator
Enhanced Form Repository	A form repository with capability to pre-populate form with the data received from the Form Filler.
Enhanced SR Storage SOP Class	See DICOM PS 3.3.
Enveloping Signature	"A Digital Signature approach that encapsulates the signed content within the signature syntax.
The signature is over content found within an Object element of the signature itself. The Object (or its content) is identified via a Reference (via a URI fragment identifier or transform). [W3C XMLDSIG]"
ePHI	Electronic Patient Healthcare Information.
Episodic	Occurring at unpredictable times. Similar in meaning to aperiodic, except that aperiodic is generally applied to observations and episodic can be applied to any sort of happening or event, including patient physiological and device technical alarms.
ESC	European Society of Cardiology
eSource Document	The electronic record used to keep together a collection of eSource data items for capture, transmission, storage, and/or display; and serving as a source document for a clinical investigation.
Estimated Time of Arrival	The time the patient being referred can be expected to arrive in the emergency department.
EUI-64	An 8-byte hexadecimal Extended Unique Identifier number defined by the IEEE, uniquely identifying a particular instance of a device. It begins with a 3- or 4-byte company id assigned to the manufacturer of a device by the IEEE Registration Authority. The rest of the bits are assigned by the manufacturer in such a way as to insure no two individual devices have the same EUI-64. It is one way used in PCD messaging to uniquely identify a device or system.
Event	In UML modeling, an occurrence at a definite time that is significant in the analysis of the system under study.
Event	An occurrence about which it is desired to communicate information between devices and information systems. Events include operational milestones and key parameter changes. Alarms are considered to be a subset of events.
Event	A real world activity has reached a well-defined state. Events can be organized in a hierarchy and event times can be ambiguous. For example, "Person flew from Boston to Chicago" could be defined as one event. Or, it could also be "Person arrived at parking lot", "person found parking place", "Person arrived at terminal", "person arrived at security line", "person cleared security", ….
Event Report	A report describing an Event.
Evidence Documents	Evidence Documents represent the uninterpreted information that is primarily managed and used inside the imaging department, although distribution outside the imaging department is not precluded. Evidence documents are non-image information and include things such as measurements, CAD results, procedure logs, etc., and are to be encoded as DICOM SR documents.
Evidence Documents	Evidence Documents represent the non-interpreted information that is primarily managed and used inside the imaging department, although distribution outside the imaging department is not precluded. Evidence documents are non-image information and include things such as measurements, CAD results, procedure logs, etc. and are to be encoded as DICOM SR documents or Encapsulated PDF.
Evidence Objects	All objects generated as a result of performing procedure steps on systems in an imaging department. These objects are used by the reading healthcare provider in the process of creating a diagnostic report and are managed inside the imaging Department. Examples of evidence objects include Images, Presentation States, Key Image Notes and Evidence Documents.
Expanded Value Set	A set of concept representations that were in effect at a specific time for a particular version of a Value Set. See Value Set. The Value Set and the Expanded Value Set concepts are similar to the programming concepts of Class and Instance of Class. This may also be called a value set resolution or resolved value set.
Expected Actions	Actions which should occur as the result of a trigger event.
Export Source Document	A CDA document from which data will be drawn to send to an external system for secondary use.
Extends Relationship	A relationship between two use cases in which one use case 'extends' the behavior of another. Typically this represents optional behavior in a use case scenario - for example a user may optionally request a list or report at some point in a performing a business use case.
Extensional Value Set	A set of concepts that is specified in terms of a list of concepts.
External Data Repository	A database, outside of the EHR system, where completed forms data can be stored.
External Quality Control	Tests performed on an identified control specimen whose target values are hidden, in order to control the proficiency of the organization. External QC specimens are provided by an external institution that controls and compares the results obtained by multiple healthcare enterprises. This is also called proficiency testing.
Extracted Data	Those data specified by the extraction specification.
Extraction Specification	An XSLT provided by a system external to the EHR which specifies which data elements of the CDA should be sent to the external system for secondary use.
Extraction Specification	A detailed map of data locations within an EHR, an EHR export document, or similar source used as a guide to extract data for re-use by a research, quality reporting, or public health system.
Extubation	This term is used to describe the removal of a device from a hollow organ.
Fast Health Interoperability Resources	The interoperability standard from HL7 which builds on HL7 version 2, version 3, the RIM and CDA. It can be used in conjunction with existing data exchange standards as well as a standalone standard
FDA	The United States Food and Drug Administration. See http://www.fda.gov/.
FFDM	Full Field Digital Mammography.
FHIR	See Fast Health Interoperable Resources.
FHIR Profile	A statement of use of one or more FHIR Resources. It may include constraints on Resources and Data Types, Terminology Binding Statements and Extension Definitions.
FHIR Provenance Resource	Describes the activity that led to the creation of a set of resources. This information can be used to help determine their reliability or trace where the information in them came from. The focus of the provenance resource is record keeping, audit and traceability, and not explicit statements of clinical significance
FHIR Resource List	Collection of resources in a list which is enumerated while providing features for managing the list.
FHIR Resources	The basic building block in FHIR. Used to define exchangeable content.
Filler	See HL7 version 2.3.1.
Filler Order Number	The unique reference assigned to an Order by the Order Filler Actor, which is expected to fulfill this Order.
FiO2	Fraction of inspired oxygen, a percentage of inhaled gas.
First course of treatment	Includes all methods of treatment recorded in the treatment plan and administered to the patient before disease progression or recurrence.
Fixed Wing	Any transport by airplane.
Fluid Management	The process of recording the patient's input and output of fluid. Fluids can be consumed via, but not limited to: oral, intravenous, or irrigation. Output of fluids include, but are not limited to: any expulsion of bodily liquid (blood, urine, feces, sputum, bile, vomitus, perspiration, pus) via oral or rectal cavities, wounds, drains, tubes, catheters, or other medical devices.
Foreign Key (FK)	A database key that is used as a reference to relate one entity to another entity. It may be a unique value, or used in conjunction with another Foreign Key to create a unique value.
Form	A form with data entry fields that will be filled out by an end user or provider.
Form Repository	An authoritative source for forms.
Frame of Reference (FoR)	Identifies the coordinate system that conveys spatial and or temporal information of composite instances in a series. The identified Coordinate System typically includes an origin, orientation and dimension scaling. Data with the same Frame of Reference are inherently using coordinate systems with the same origin, orientation and dimension scaling.
FSC	File-Set Creator.
FSR	File-Set Reader.
Functional Role	Role an individual is acting under when they are executing a function. See ISO 21298.
GBEA	Guide de Bonne Exécution des Analyses Médicales. Minimal regulatory set of quality standards regulating activities related to in vitro testing for laboratories in France.
General Purpose Infusion Pump	A pump used to infuse fluids intravenously in a wide variety of clinical settings. Differentiated from specialty infusion pumps, which are used for a specific purpose or in a specific setting, such as PCA (patient-controlled analgesia) or syringe pumps.
Geometric Plan	An RT Plan object containing a subset of information defining a radiation therapy treatment. The Geometric Plan shall contain a reference to an RT Structure Set. Further definition of a Geometric Plan can be found by review of the appendices of RO TF-2. A Geometric Plan is conceptually the state of an RT Plan object that might be stored by a CT-Simulation application (i.e., a Geometric Planner).
Gestational Age	Gestational age is the number of weeks elapsed between the first day of the last normal menstrual period and the date of delivery; weeks of amenorrhea.
Global Positioning System	"This is the system of orbiting satellites that are constantly broadcasting
extremely high accuracy time information, combined with ubitiquous receivers and software associated with the receivers that upon correlation of the received data can identify with reasonably high accuracy the location of the receiver in 3D space by latitude, longitude, and altitude."
Globalized Distribution	A dispensing mode in which the pharmacy distributes the medication to the wards and the nurses then dispense the medication to each patient as needed.
Globally Unique Identifier	An identifier that has been generated by an algorithm guaranteeing its global uniqueness. The identifier is used to identify an entity, such as persistent document. See ITI TF-2x: Appendix B discussion of OIDs and UUIDs.
Goals	A defined outcome or condition to be achieved in the process of patient care. Goals include patient defined goals (e.g., prioritization of health concerns, interventions, longevity, function, comfort) and clinician specific goals to achieve desired and agreed upon outcomes.
Grayscale Softcopy Presentation State Storage SOP Class	See DICOM PS 3.4.
Grayscale Standard Display Function	See DICOM PS 3.14.
Grouping	Associating Actors together in one system such that information transferred between the actors is accomplished through direct application program interfaces, being out of scope to the IHE.
GSPS	Grayscale Softcopy Presentation State. See DICOM PS 3.4
GUID	See Globally Unique Identifier
Guidelines	Systematically developed statements to assist practitioner and patient decisions about appropriate health care for specific clinical circumstances. (Field MJ, Lohr KN. Guidelines for Clinical Practice: from development to use. Washington DC: National Academic Press, 1992. Retrieved from http://www.nap.edu/openbook.php?record_id=1863&page=27#p200063cf8960027001)
Hand-offs	A transfer of patient information during transitions of care to ensure safety and provide continuity of care for the patient. This transfer of information is provided internally, within the health care organization, or externally, outside the health care organization.
Hardcopy Import	The process of importing non-digital data into the Enterprise as DICOM Objects. The original data may be Films or Documents that are scanned and stored as DICOM Objects.
Hash	A value uniquely calculated by using a well-known one way algorithm to create a digest of all the data constituting an electronic record.
Health Assessment	The screening/examining of an individual for their overall condition or optimal well-being (mind, body, and spirit).
Health Care Proxy	The legal appointment, power of attorney, of someone else, a proxy, other than yourself, to make healthcare decision for you when you are physically or cogitatively unable to. The person designates a trusted individual to make medical decisions in the event of inability to make such decisions. It is a vehicle for directing his/her own treatment in the event of serious illness and/or loss of mental ability to communicate those wishes; in an Advanced Directive, the person indicates in advance, how treatment decisions are to be made with regard to the use of artificial life support.
Health Concerns	The issues/current status and likely course identified by the patient or team members that require intervention(s) to achieve the patient’s goals of care, any issue of concern to the individual or team member.
Health Data Locator	Health Data Locator is a function provided by a community or external entity that manages the locations of patient health data for a selected set of patients. A Health Data Locator keeps track of communities that know a patient and provides a list of these communities to a requesting community.
Health Device Profile	A transport profile defined for classic Bluetooth (BT)
Healthcare domain/ secondary use domain	The healthcare domain and its central system the EHR exist to provide medical care to patients. Data are created by the healthcare domain which are of value to the secondary use domains such as research, public health, and quality reporting. In general, only tightly specified data are permitted to be exported by the healthcare domain to a secondary use domain.
Healthcare Professional	A specially trained individual who provides healthcare services like a GP, specialist, nurse, midwife, dentist, physiotherapist, pharmacist etc.
Healthcare Provider	Medical information entities such as physicians, medical laboratories, hospitals, dentists, pharmacists, nurses, diagnostic imaging professionals etc. This includes both individuals as well as organizations.
Hearing Test	Any test that measures hearing or quantifies hearing loss; sound is perceived by intensity–loudness and by tone; both are measured in HTs, as is the ability to hear sound through air–air conduction and bone–bone conduction.
Heart Team
Hematocrit (HCT)	The volume percentage of erythrocytes in whole blood.
Hemoglobin (HGB)	Protein in red blood cells that carries oxygen; HGB measured by blood test.
Hemoglobin Disease	"Hemoglobin is produced by genes that control the expression of the hemoglobin protein. Defects in these genes can produce abnormal hemoglobins and anemia, which are conditions termed ""hemoglobinopathies"". Abnormal hemoglobins appear in one of three basic circumstances:
- Structural defects in the hemoglobin molecule.
- Diminished production of one of the two subunits of the hemoglobin molecule.
- Abnormal associations of otherwise normal subunits. "
HIMSS	Healthcare Information and Management Systems Society. See http://www.himss.org.
HIS	Hospital Information System.
Histopathology	Microscopic examination of tissues.
HL7	Health Level Seven International. An international standards development organization in the domain of healthcare information exchange. See http://www.hl7.org/.
HL7	Health Level Seven is a not-for-profit, American National Standards Institute (ANSI)-accredited health care focused International and membership-driven Standard Development Organization (SDO) based in the United States with international affiliates.
HL7 Profile	"An HL7 profile is an unambiguous specification of one or more HL7 standards that have been analyzed for a particular use case. It prescribes a set of precise constraints upon one or more standard HL7 artifacts.
An HL7 profile is conformant, in all aspects, with the HL7 defined specification used in the profile according to the constraints or extension rules. It may specify constraints on the standard HL7 definition. An implementation profile fully describes an interoperability interaction between two or more systems through the combination of the following:
a) one use case analysis,
b) one or more dynamic definitions, and
c) one or more static definitions."
Home Care	Professional care (e.g., skilled nursing, physical therapy, speech-language pathology, occupational therapy, medical social work, home health aide) that an individual of any age with an acute or chronic condition, as well as a disability or a terminal illness, receives in the home. The professional will work with the patient and their families to teach them about their condition as well as how to care for themselves or the patient, so that the patient can be independent. A physician or a clinician with prescriptive authority is required to document or verbally communicate an order for the services to be provided.
homeCommunityId	A globally unique identifier for a community.
Hospital Cancer Registry	Collects information on all cancer patients who use the services of a hospital. It may be required to report cancer cases to the central registry, to respond to inquiries from the central registry, or to allow central registry access to its records.
HTML	Hyper Text Markup Language.
Human actor	Individual (physician, pharmacist, etc.) that usually makes use of a system actor to perform an activity in the e-pharmacy domain.
ICA	Intolerances, Contra-indications and Allergies. An ICA may be considered as a relationship between a Patient and a Medicine. A detected problem in a Pharmaceutical Advice may refer to an ICA.
ICE	Intracardiac Echocardiography.
ICRU	International Commission on Radiological Units.
IEC	International Electrotechnical Commission.
IEEE	Institute of Electrical and Electronics Engineers. See http://www.ieee.org.
IEEE-11073-20601	Optimized Exchange Protocol. A transport-agnostic packet-based protocol for exchanging health data. Currently used only over local transports (PHCD USB, ZigBee, HDP Bluetooth, NFC)
IETF	Internet Engineering Task Force. See http://www.ietf.org.
IHE	Integrating the Healthcare Enterprise. See http://www.ihe.net.
IHE PCD Data	PCHA sensor data expressed in the form of a PCHA-compliant IHE PCD-01 message.
IHI	See Institute for Healthcare Improvement.
IIS	See Immunization Information System.
Image Fusion	The process of superimposing (overlaying) data sets for display. This is typically done so that corresponding features of the data sets can be seen at once. Fusion typically requires that the datasets be registered. This would normally involve two data sets- one underlying and one superimposed.
Image Registration	Spatially aligning datasets. This is done by mapping the pixel spatial coordinates of the Original Data Sets to the Registered Space and may include translations or rotations between the coordinate systems. The primary purpose is to support display of correlated features in two images. Typically the Registered Space is defined by one of the datasets, and the other is aligned with it.
Image Re-sampling	Synthesizing a new image dataset where the number of pixels, resolution, number of slices, slice locations and slice orientations may differ from the original, but the frame of reference is preserved (i.e., the pixel value at a given spatial location in the new dataset corresponds to the value at the same spatial location in the old dataset).
Imaging Service Request	See DICOM PS 3.3.
Immediate Cause of Death	Final disease or condition resulting in death, that is, one that is most proximate to time of death.
Immunization Information System	A software system designed to collect all information about immunizations given to a certain population. An IIS is typically funded or sponsored by a Public Health Department or Ministry.
Immunization Interval	A measure of the interval between doses of antigens. For maximum effectiveness against the targeted disease, many vaccines must have booster shots given after the initial dose. The recommended interval varies by vaccine. In most cases, administration of a vaccine with less than the minimum immunization interval reduces the effectiveness of the vaccine, and one that is substantially longer than the recommended interval exposes a person to a higher risk of contracting the disease during the period of delay.
Immunization Recommendation	A collection of proposed immunizations and encounters which a provider may use to develop an immunization care plan. Also known as an Immunization or Vaccine Forecast.
Immunization Recommendation	A set of proposed immunizations to be given to a patient, including the dates to give them. The recommendation may be general, or it may be focused on a particular disease (such as an influenza pandemic) or a particular risk situation (such as travel to places with high risk factors for certain diseases).
Immunization Registry	See Immunization Information System.
Immunotherapy	Treatment that stimulates the body's immune system to fight tumors; also called biological response modifier (BRM) therapy.
Implantable Cardiac Monitor	An electronic device implanted beneath the skin used for monitoring/recording the electrical signals of the heart muscle.
Implantable Cardiac Resynchronization Therapy (CRT) Device	An electronic device implanted beneath the skin used to reestablish ventricular synchrony in an effort to improve left ventricular efficiency.
Implantable Defibrillator	An electronic device implanted beneath the skin used to counteract fibrillation of the heart muscle and restore normal heartbeat by applying an electric shock.
Implantable Medical Device	Any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or calibrator, software, material or other similar or related article:1) intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the specific purpose(s) of: diagnosis, prevention, monitoring, treatment or alleviation of disease; diagnosis, monitoring, treatment, alleviation of or compensation for an injury; investigation, replacement, modification, or support of the anatomy or of a physiological process; supporting or sustaining life - control of conception; disinfections of medical devices; providing information for medical or diagnostic purposes by means of in vitro examination of specimens derived from the human body and: 2) which does not achieve its primary intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its intended function by such means. (Reference: GHT)
Implantable Pacemaker	An electronic device implanted beneath the skin for providing a normal heartbeat by electrical stimulation of the heart muscle, used in certain heart conditions.
Includes Relationship	A relationship between two use cases in which one use case 'includes' the behavior. This is indicated where there a specific business use cases which are used from many other places - for example updating a train record may be part of many larger business processes.
Industry Outreach	Depending on the goals of the project this may be as little as a set of announcements of work going on in HL7 targeted at the impacted stakeholder communities. For some projects it may involve scheduling out-of-cycle meetings, scheduling meetings jointly with other stakeholder organizations or some kind of “Town Hall” meetings similar to those used for the EHR Functional Requirements DSTU.
Ineffective Dose	This is a dose of administered vaccine or vaccine component which may be predictably less effective than desired, due to inadequate immunization interval, expired vaccine, concurrent administration of antibiotics, vaccine recall, improper vaccine storage, or other issues.
inetOrgPerson	The inetOrgPerson [RFC 2798] object class is a general purpose object class that holds attributes about people. The attributes it holds were chosen to accommodate information requirements found in typical Internet and Intranet directory service deployments. The inetOrgPerson object class is designed to be used within directory services based on the LDAP v3 [RFC 2251] and the X.500 family of protocols, and it should be useful in other contexts as well.
Infobutton	A graphical user interface element which allows the user of an application to quickly obtain information about a specialized term or value found on application displays. It is typically represented as a lowercase letter "i" in a blue circle. The term may also be used to refer to the HL7 Context Aware Information Retrieval standard, which is often used to implement the information retrieval side of the interface.
Inpatient	A patient who is admitted to a hospital or clinic for treatment that requires at least one overnight stay.
Institute for Healthcare Improvement	An independent not-for-profit organization to improve health care throughout the world. See http://www.ihi.org.
Instructions	Information or directions to the patient and other providers including how to care for the individual’s condition, what to do at home, when to call for help, any additional appointments, testing, and changes to the medication list or medication instructions, clinical guidelines and a summary of best practice. This is provided as a list of action steps given to a team member or patient to address health concerns.
Integrity	The property of the data has not been altered or destroyed in an unauthorized manner.
Integrity	"The property of the data has not been altered, or destroyed in an unauthorized manner.
""The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner."" [SEC] A simple checksum can provide integrity from incidental changes in the data; message authentication is similar but also protects against an active attack to alter the data whereby a change in the checksum is introduced so as to match the change in the data. [W3C XMLDSIG]"
Intensional Value Set	A set of concepts that is specified in terms of the “intension” of use, for example “all concepts that are children of this node in a tree of concepts”. Intensional value sets often have some kind of algorithmic basis for selection of concepts.
Interaction Diagram	A diagram which depicts data flow and sequencing of events.
Interchange Media	A piece of data-bearing physical media, such as a CD or DVD. The term, which is used in the DICOM standard, is synonymous with "portable media" or "transfer media".
Internal Quality Control	Tests performed on an analyzer using an identified control specimen with usually known target values, in order to check the accuracy of the device.
Interoperable	The ability of health information systems to work together within and across organizational boundaries in order to advance the effective delivery of healthcare for individuals and communities.
Interval from onset to death	Minutes, hours, days, weeks, months, or years between the onset of each condition and the date of death (ref ICD-10 vol 2, section 4.1.3).
Interventions	Actions taken to maximize the prospects of achieving the patient’s or providers’ goals of care, including the removal of barriers to success. Instructions are a subset of instructions.
Invalid Dose	See Ineffective Dose.
IOD	Information Object Definitions. See DICOM PS 3.3
Irradiation Event	An irradiation event is one continuous occurrence of irradiation being applied to a patient. A pulsed fluoro X-Ray acquisition, or a multi-slice helical CT scan are examples of single events; while a CT scanogram and the helical scan, or two different presses of the fluoro pedal, or simultaneous irradiation from two X-ray tubes are examples of separate events. See RAD TF-3: 4.62.4.1.1 in Store Dose Information for a more detailed description.
ISO Reference Terminology Model	To establish a nursing reference terminology model consistent with the goals and objectives of other specific health terminology models in order to provide a more unified reference health model. This International Standard includes the development of reference terminology models for nursing diagnoses and nursing actions and relevant terminology and definitions for its implementation.
ISO/IEC 11179 metadata registry	A metadata registry is defined as “an information system for registering metadata” by ISO/IEC 11179. In particular, ISO/IEC 11179 defines a metadata registry is a database that manages the semantics of Data Elements.
ISO/IEEE 11073-10101 Nomenclature	Within this standard nomenclature codes are defined, these give the possibility to clearly identify objects and attributes in relation to the so-called OID-Code). The nomenclature is divided in partitions, to demarcate codes with regards to content and functional.
IT	Information Technology.
IVD	In vitro diagnostic. This abbreviation is related to the processing of tests on in vitro specimens. A laboratory device (see term LD) is usually an IVD device and performs work order steps (see term WOS).
IVOCT	Intravascular Optical Coherence Tomography
IVUS	Intravascular Ultrasound.
JavaScript Object Notation	A textual representation of a serialized object from the JavaScript language.
JPEG	Joint Photographic Experts Group.
JSON	See JavaScript Object Notation
KDC	Key Distribution Center (the Kerberos server that issues Ticket Granting Tickets and service tickets. See RFC1510).
Keep Vein Open	A fluid delivery mode that may occur once the programmed volume has been infused.
Labeler	An automated device which affixes the bar code label to the specimen container.
Laboratory Performer	A laboratory who performed (all or some of) the tests documented in a laboratory report or reported in a results message. It is described with the laboratory’s name and address and the laboratory director’s identification
Laboratory Request	Synonym of “Order Group”.
Language Proficiency	Family planning users who do not speak the national dominant language as their primary language and who have a limited ability to read, write, speak or understand the dominant language and therefore require language assistance services (interpretation or translation) in order to optimize their use of health services. Include users who receive services from multilingual staff in the user’s preferred language, are assisted by a competent agency or contracted interpreter, or who opt to use a family member or friend as an interpreter after refusing the provider’s offer of free language assistance services. Do not include users who are visually or hearing impaired or have other disabilities unless they also have a need for language assistance service.
LAS	Laboratory Automation System.
LDAP	Lightweight Directory Access Protocol is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP).
LIS	Laboratory Information System.
Local Authentication	In the ATNA profile the term "local authentication" means that the user identification, authentication, and authorization method is chosen by the local system administration and does not necessarily comply with any IHE profile. It may be a local username password system, a secure token system, or any other system that is considered acceptable by the local security administration.
Location Services	This is a collection of software applications and services which utilize tag tracking information to provide the last known location of the tags as well as any environmental or operator interactions with the tags.
Logical Observation Identifiers Names and Codes	A vocabulary developed by the Regenstrief Institute aimed at standardizing laboratory and clinical codes for use in clinical care, outcomes management, and research. See http:/loinc.org.
LOINC	See Logical Observation Identifiers Names and Codes.
Long Term Signature	A signature that is intended to be valid for months or years later.
Long-term Care	A variety of services that help people, who have a chronic illness or disability, with medical or non-medical care needs and activities of daily living over a specified period of time. Long-term can be provided at home, in the community, or in various types of facilities, including nursing homes and assisted living facilities.
LUT	Look Up Table.
MAC	Media Access Control – A unique identification/serial number associated with every device used in network communications.
Malpresentation	Abnormal position of fetus in birth canal. Natural delivery becomes difficult or impossible.
Manner of Death	Way the conditions reported as causes of death resulted in death, or for injuries, intent.
Master File	A common reference file used by one or more application systems. A code set can be considered a master file.
MCW	Multi-channel Waveform.
MDC	Medical Device Communication. The general name for the suite of standards in ISO/IEEE 11073 defining communications protocols for patient care devices.
MDS	Medical Device System. The object in ISO/IEEE 11073 representing a whole medical device. It contains Virtual Medical Devices representing subsystems.
Medical Device	"Any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or calibrator, software, material or other similar or related article:
1) intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the specific purpose(s) of:
- diagnosis, prevention, monitoring, treatment or alleviation of disease
- diagnosis, monitoring, treatment, alleviation of or compensation for an injury
- investigation, replacement, modification, or support of the anatomy or of a physiological process
- supporting or sustaining life
- control of conception
- disinfections of medical devices
- providing information for medical or diagnostic purposes by means of in vitro examination of specimens derived from the human body
and:
2) which does not achieve its primary intended action in or on the human body by pharmacological, immunological or metabolic means, but which may be assisted in its intended function by such means.
Reference: GHTF/SG1/N29R16:2005 published by the Global Harmonization Task Force, (2005): "
Medication	A medication is part of a prescription item and defines the actual prescribed drug. It contains the brand or generic name of the drug, national and/or regional drug codes, unit strength, active ingredients and packaging information.
Medication Administration	Medication Administration is the act of applying a medication to a patient (e.g., intake of tablet, injecting a syringe, applying an infusion, etc.), whether performed by the patient him- or herself or another person, such as a health care professional.
Medication Administration Item	A Medication Administration Item belongs to a Medication Administration and represents one administered medication. It contains the administered medicinal product including information such as product code, brand name, lot number as well as all other parameters describing the administering process, such as dose, drop-rate, etc.
Medication Brand Name	The brand name is the name given to a medicine by the pharmaceutical company that makes it. This is also called the "proprietary name".
Medication Dispenser	In the domain of community pharmacy a Medication Dispenser is an abstract actor which dispenses prescribed medication to a patient (generally a healthcare professional, usually a pharmacist when the patient enters the pharmacy to get the prescribed medication).
Medication Generic/Scientific Name	The generic or scientific name is the term given to the active ingredient in the medicine that is decided by an expert committee and is understood internationally. This is also called the "non-proprietary name".
Medication Preparation	The act of making medication items available for a specific intended administration action.
Medication Record	A list of all medication-related data for a specific patient, including prescriptions (including (partially) fulfilled ones), dispenses and possibly administrations.
Medication Treatment Plan	The Medication Treatment Plan (MTP) of a patient is the collection of all medications the patient was planned to take in the past, presently or in the future. The Medication Treatment Plan is the complete set of all Medication Treatment Plan Items of the patient, i.e., not partitioned or grouped by pathology, planner, organization, etc.
Medication Treatment Plan Item	A Medication Treatment Plan Item is a single medication the patient was planned to take in the past or is planned to take presently or in the future, including its name, dosage, frequency of intake, etc. as well as other information such as patient- and fulfillment instructions and substitution handling. A Medication Treatment Plan Item triggers prescriptions and/or, dispenses in order to fulfill the medication treatment planned by the item.
Message Profile	An HL7 message profile is an unambiguous specification of one or more standard HL7 messages that have been analyzed for a particular use case. Each message profile may have a unique identifier as well as publish/subscribe topics
Metadata	Data that describe other data, particularly XML tags characterizing attributes of values in data fields, such as version, unique identifier, mappings.
MFI	Metamodel Framework for Interoperability (MFI) -- an ISO/IEC 19763 standard.
MFI-13	Metamodel Framework for Interoperability (MFI) – ISO/IEC 19763-13 Metamodel for Forms Registration
Minimal Lower Layer Protocol	Used for transferring HL7 messages over Ethernet. It defines delimiters which identify the beginning and ends of the HL7 messages.
MLLP	See Minimal Lower Layer Protocol.
Mobility/Fall Risk	A screening, or assessment, of a patient's balance, mobility, muscle strength, cognitive status, sensory impairments, physiological parameters and sometimes home environment to identify the patient's risk for falling and implementation, if needed, fall prevention interventions.
Modality	See DICOM PS 3.3.
Modality Performed Procedure Step	See DICOM PS 3.3.
Modality Performed Procedure Step Information Module	See DICOM PS 3.3.
Modality Performed Procedure Step Relationship Module	See DICOM PS 3.3.
Modality Performed Procedure Step SOP Class	See DICOM PS 3.4.
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.
Modality Worklist SOP Class	See DICOM PS 3.4.
Mode of Arrival	The method of transportation used to transport the patient to the emergency department.
Movement	An event describing a change of the situation of the patient in the context of the encounter. This concept encompasses changes such as transfers of patient location, change of patient class, new attending doctor, new consulting doctor, new encounter starting, encounter closing, etc. The concept of Movement is a superset of the concept of "Transfer".
MPI	Master Patient Index. See eMPI.
MPPS	See Modality Performed Procedure Step.
MPR	Multi-Planar Reconstruction. Creating orthogonal images from a data set (e.g., creating coronal and sagittal images from a transverse data set).
MQSA	Mammography Quality Standards Act of 1992.
MRN	Medicare Record Number.
MRN	Medicare Record Number (US) or Medical Record Number.
Multiple Antigen Vaccine	See Combination Vaccine.
MWL	See Modality Worklist.
NAACCR	North American Association of Central Cancer Registries. A collaborative umbrella organization for cancer registries, governmental agencies, professional organizations, and private groups in North America interested in enhancing the quality and use of cancer registry data.
Negative Inspiratory Force	A measure of pulmonary mechanics used to assess readiness to wean.
NEMA	National Electrical Manufacturers Association. See http://nema.org
Network Time Protocol	This is the standard Internet protocol for synchronizing computer clocks. See http://www.ntp.org for extensive background documentation at the introductory and expert level on how to synchronize computers. Also see SNTP.
N-Event Report	See DICOM PS 3.7.
NFC	Near Field Communication wireless protocol (peer endpoints must almost ‘touch’ to communicate)
NICU	Neonatal intensive-care unit. Unit of a hospital specializing in the care of ill or premature newborn infants.
NIST Rosetta Terminology Mapping Management System	Specifies the IEEE 11073 nomenclature and co-constraints (units-of-measure, enumerated values and sites).
NMEA	National Marine Electronics Association
Nominative Distribution	A mode of distributing medication in which the pharmacy dispenses the medication to each patient.
Non-repudiation	This service that provides proof of the integrity and origin of data which can be verified by any party.
Non-repudiation	The assurance that someone cannot deny something, such as the receipt of a message or the authenticity of a statement or contract. Typically, non-repudiation refers to the ability to ensure that a party to a contract or a communication cannot deny the authenticity of their signature on a document or the sending of a message that they originated.
Non-volunteer Resources	Beyond the routine support, HL7 headquarters provides for balloting, etc., additional support may be required to assess potential funding requirements. Hosted projects will be expected to provide associated funding.
Notification Broker	A system or a module in a publish/subscribe framework, the purpose of which is to process subscription/un-subscription requests, to keep track of existing subscriptions, to receive publish information, and based on the set of filters for each subscription, to send a notification about the published information to the appropriate notification recipients.
Notification Recipient	A system or a module in a publish/subscribe framework, the purpose of which is to receive and process notifications from the notification broker.
NPO	Nothing by Mouth.
NTP	See Network Time Protocol.
Object Identifier	An open-ended system with a hierarchical scheme of assigning authorities, with a dotted series of numbers where each number represents an assigning authority in the hierarchy – each assigning authority can assign numbers to another, lower-level authority. An example is 2.16.840.1.113883 (joint-iso-itu-t.country.us.organization.hl7). IHE PCD has assigns OIDs starting from 1.3.6.1.4.1.19376.1.6. The IEEE 11073 nomenclature has the OID 1.2.840.10004.1.1.1.0.0.1. OIDs are the preferred unique identification scheme in the HL7 organization and are widely used in HL7 and other healthcare IT contexts to provide a durable globally unique numeric identification scheme.
Observation	See HL7 version 2.3.1.
Observation	A measurement of a single variable or a single value derived logically and/or algebraically from other measured or derived values. A test result is an observation.
Observation	In HL7 generally, patient-oriented clinical data. In IHE PCD, this category is enlarged to include, in addition to patient physiological data (clinical measurements), patient care device data supporting the communication of patient-oriented clinical data such as patient and device identifying data, device technical status data, alarms and device settings. These are all reported using HL7 communications patterns established for clinical data in HL7 version 2.6 Chapter 7, Observations.
OBXV	OBX Visibility. OBX visibility indicates whether an OBX must or may be sent or otherwise accounted for at a particular level in the OBX-4 “observation hierarchy”. See the Rosetta Containment Hierarchy document for additional information.
OID	See Object Identifier.
ONC	The U.S. Department of Health and Human Services (HHS) Office of the National Coordinator for Health Information Technology.
Order	A battery or test ordered by a ward and/or a physician to a laboratory, to be performed on one or more specimens collected from a patient.
Order	A request to perform examination of a specimen or a set of specimens taken from a patient. The Order is the focal object of the transactions between Order Filler and Order Placer or Order Result Tracker. An Order may be standalone or belong to an Order Group. The anatomic pathology laboratory may reorganize the orders placed by a clinical unit, especially in cases where an order was received attached to a set of specimens, which will have to be analyzed separately by different pathologists. For this reason the Order Filler may replace, merge, or split orders received from the Order Placer. This process is accomplished through messages of transactions PAT-1 and PAT-2 initiated by the Order Filler.
Order	In the context of the EHDI-WD profile, an order is a request for one or more services to be performed. The services are likely a procedure to be performed, but they also could include other actions such as administering an assessment questionnaire, or making a diet change. In this profile, a referral causes an order to be placed and that order, when filled, completes the referral request.
Order encoding	The Prescription Placer may fill in the prescription with a free-text description of the treatment details (as simple as Paracetamol 1000 mg oral, as needed, max 3 times a day). This description has to be translated (encoded) into products, and the quantities may have to be determined for the Pharmaceutical Analysis, Dispensing and Administration to take place. This is modeled as an “encoding” sub-task.
Order Group	Also called the “Laboratory Request”: A set of orders placed together by a ward and/or a physician to one or more laboratories for a patient, to be performed on one or more specimens collected from this patient.
Order Group	A set of orders ordered together to investigate or address a patient condition.
ORI	Observation Reporting Interface defined by the standard POCT1-A from CLSI.
Original Dataset	Either of the data sets that are to be transformed and blended.
Other contributing causes of death	Conditions that unfavorably influence the course of the morbid process and thus contributes to the fatal outcome, but which is not related to the disease or condition directly causing death (ref ICD-10, vol 2, section 4.1.3 and UN, Handbook of Vital Statistics Systems and Methods, Volume 1, Glossary).
Outcome	The status of the patient at one or more points in time in the future, related to the established care plan goals.
Outcome Report	An outcome report may consider multiple testing results and result interpretations into consideration. For example, if a newborn’s hearing is screened and the results for the left ear are interpreted as a “fail”, and the right ear’s result interpretation is a “pass”, then the outcome report may indicate to “Refer” the patient for further testing. If the newborn is retested, and the new result interpretation for the left ear is a “pass”, then the outcome report for the newborn would include two screening procedures and the aggregate hearing screening outcome may be a “Pass”. So the plan of care would follow normal well-baby hearing care guidelines.
Outpatient	A patient not hospitalized >24 hours or housed in an extended care facility, who is being treated in an office, clinic, or other ambulatory care facility (Reference: Perinatal Workflow)
PaCO2	Partial pressure of carbon dioxide in the blood. Critical in regulating breathing levels and maintaining body pH.
PACS	Picture Archive and Communication System.
PACU	Post Anesthesia Care Unit.
Panel	Synonym for "Battery" (see Battery).
PaO2	Partial pressure of oxygen in the blood.
Partially Completed Form	A pre-populated and/or auto-populated form served by the EHR to the provider that contains data for most fields.
Patient	See DICOM PS 3.3.
Patient	See DICOM PS 3.3
Patient	(When used in the context of ATNA) RFC 3881 defines the means of identifying the person who is a patient. The patient information in audit event records corresponds to the information available to identify a patient at the time the audit record was generated, and does not reflect later updates (e.g., patient reconciliation).
Patient Care Plan	The synthesis and reconciliation of the multiple Plans of Care produced by each provider to address specific health concerns of the patient. See below Plan of Care definition.
Patient Identification Module	See DICOM PS 3.3.
Patient Identifier Cross-reference Domain	Consists of a set of Patient Identifier Domains known and managed by a Patient Identifier Cross-reference Manager Actor. The Patient Identifier Cross-reference Manager Actor is responsible for providing lists of "alias" identifiers from different Patient Identifier Domains.
Patient Identifier Domain	A single system or a set of interconnected systems that all share a common identification scheme for patients. Such a scheme includes: (1) a single identifier-issuing authority, (2) an assignment process of an identifier to a patient, (3) a permanent record of issued patient identifiers with associated traits, and (4) a maintenance process over time. The goal of Patient Identification is to reduce errors.
Patient Mapping Agent	The CCOW defined component that provides for the mapping of patient identifiers across disparate patient identity domains.
Patient Privacy Policy	A Patient Privacy Policy explains appropriate use of data/documents in a way that provides choices to the patient. The BPPC Profile places no requirements on the content of these policies nor the method used to develop these policies (See ITI TF-1 Appendix P for some guidance on developing these policies). A Patient Privacy Policy will identify who has access to information, and what information is governed by the policy (e.g., under what conditions will a document be marked as containing that type of information). The Patient Privacy Policy may be a consent policy, dissent policy, authorization policy, etc.
Patient Privacy Policy	"A Patient Privacy Policy explains appropriate use of data/documents in a way that provides choices to the patient. The BPPC Profile places no requirements on the content of these policies nor the method used to develop these policies (See ITI TF-1 Appendix P for some guidance on developing these policies). A Patient Privacy Policy will identify who has access to information, and what information is governed by the policy (e.g., under what conditions will a document be marked as containing that type of information). The Patient Privacy Policy may be a consent policy, dissent policy, authorization policy, etc.
A Patient Privacy Policy will identify who has access to information, and what information is governed by the policy (e.g., under what conditions will a document be marked as containing that type of information).
The policy may also describe the patient's rights to specify their consent preferences, notificaions, complaints, or requests as well as the mechanism that allows them to do so."
Patient Privacy Policy Acknowledgement Document	A document that follows the BPPC Content Profile and captures the act of the patient acknowledging a specific Patient Privacy Policy Domain defined Patient Privacy Policy.
Patient Privacy Policy Identifier	A Patient Privacy Policy Domain assigned identifier (OID) that uniquely identifies the Affinity Domain Patient Privacy Policy. There is one unique identifier (OID) for each Privacy Policy within the Patient Privacy Policy Domain.
Patient Privacy Policy Identifier	"A Patient Privacy Policy Domain assigned identifier (OID) that uniquely identifies the Affinity Domain Patient Privacy Policy. There is one unique identifier (OID) for each Privacy Policy within the Patient Privacy Policy Domain.
A Patient Privacy Policy Domain-assigned globally unique identifier that uniquely identifies the Patient Privacy Policy."
Patient Subject	The PSA defined subject that supports sharing the currently selected patient identifier amongst disparate applications running on the desktop.
PatientID	(When used in the context of ATNA) A free text that holds the system-internal patient identifier being unique within that system domain. The patient identifier domain is that assigned to the system that generated the audit event record. The patient information in audit event records corresponds to the information available to identify a patient at the time the audit record was generated and does not reflect later updates (e.g. patient reconciliation)
Patient-level Quality Report	A quality report that includes data about a single patient.
PBE	Password Based Encryption
PCHA	Personal Connected Health Alliance (Formally Continua).
PCHA Data	Data arriving over the Continua-specified PCHA Transaction from PHD devices. This data is typically provided by sensors and contains sufficient information to generate the non-demographic components of and enterprise time requirements for the IHE PCD-01 or PHMR modules.
PDF	Portable Document Format.
Personal Health Device Class	A transport profile defined for USB.
Personal Health Monitoring Report	A C-CDA document designed primarily to record medical measurements taken on a patient by a sensor device.
Personnel White Pages	Information on human workforce members within the authority of the PWP directory. This information has broad use among many clinical and non-clinical applications across the healthcare enterprise. The information can be used to enhance the clinical workflow (contact information), enhance the user interface (user friendly names and titles), and ensure identity.
Pharmaceutical Advice	The outcome of the pharmaceutical analysis.
Pharmaceutical Advice	"A Pharmaceutical Advice document is the outcome of the validation or review of one Prescription- or Dispense Item. It contains the overall result of the validation or review which affects the further processing as well as additional information such as Intolerances, Contra-indications and Allergies (ICAs) and all other information which was discovered during validation.
A Pharmaceutical Advice document is also used to manage Prescription- or Dispensation Items (e.g., change, cancel, etc.) as well as to document Medication Interaction Checking Issues and their resolutions."
Pharmaceutical Advice Concern Item	A Pharmaceutical Advice Concern Item belongs to one Pharmaceutical Advice Item and represents the information to concerns (e.g., problems, allergies, etc.) which the Prescription- or Dispense Item referenced by the underlying Pharmaceutical Advice Item causes.
Pharmaceutical Advice Item	A Pharmaceutical Advice Item belongs to one Pharmaceutical Advice and represents the validation outcome or management command regarding the referenced Prescription- or Dispense Item (e.g., change, cancel, etc.). It may also carry Medication Interaction Checking Issue information regarding the referenced item.
Pharmaceutical Adviser	A pharmaceutical adviser is an abstract actor which validates prescription items issued on a prescription (generally a healthcare professional, usually a pharmacist when the patient enters the pharmacy to get the prescribed medication).
Pharmaceutical Analysis	The action performed by a pharmacist to approve/modify or reject a prescription before it is given out to the patient.
Pharmacy Medication List	A Pharmacy Medication list is a collection of Medication Treatment Plan-, Prescription- and Dispense Items (and their related Pharmaceutical Advice Items) representing the Medication information of the patient at a certain point of time and according to business rules specified.
Pharmacy Validated Order	This term is used to indicate that a medication order (in the current case, a medication prescription) is considered valid after some pharmaceutical analysis. This may require (or not) some review by one or more healthcare professionals, e.g., pharmacists or physicians.
PHD	Personal Health Device such as a pedometer, glucometer, blood pressure cuff, thermometer, etc.
PHDC	See Personal Health Device Class.
PHI	See Protected Health Information.
PHMR	See Personal Healthcare Monitoring Report.
PHR	Personal Health Record
Physiologic	Mechanical, physical, and biochemical functions of living organisms.
Physiological Alarm	An alarm reflecting the physiological state of the patient (such as a heart rate above or below a caregiver-specified safe range for the patient).
Piggyback	A medication, typically administered intermittently in a small volume of fluid that runs into a maintenance line. While a piggyback is infusing, the maintenance fluid is stopped. When the piggyback has completed, the pump will automatically restart the maintenance fluid. The advantage to piggyback administration is that it does not require the patient to have multiple IV sites
PKI	Public Key Infrastructure.
Placer	See HL7 version 2.3.1.
Placer Group Number	The unique pair of identifiers assigned to an Order Group by the Order Placer Actor on the ward side and by the Order Filler Actor on the lab side. Either of the two identifiers may be present, or both may be present.
Placer Order Number	The unique reference assigned to an Order by the Order Placer Actor.
Plan of Care	A concept some clinicians use to focus on discrete problems, the specific interventions to address the problem, and achieve a certain goal related to the problem.
Plan of Care	A plan of care is “specialty focused”. A patient may have multiple plans of care: one from a cardiologist, another from a hearing specialist, another from a nutritionist, etc. These plans of care are developed from the point of view of the specialty or sub-specialty. They are not necessarily reconciled to take other plans of care into consideration.
PM Store	Persistent Metric (PM) data Storage. An IEEE 11073 20601 means of persistently storing measurement data and exposing it to a peer.
PMA	Patient Mapping Agent component as defined by CCOW.
PMS	Practice Management System.
PnP	Plug and Play.
PO	A Latin term "per os", meaning by mouth.
POCT1-A	Interoperability Standard supporting point of care testing, produced by CLSI
Point of Care	Physical area in close proximity to the patient under clinical care. Usually the vicinity around the patient bedside and may include adjacent areas.
Post-Acute Care	The recuperative or rehabilitative care needed to recover from a serious injury or illness.
PPS	Performed Procedure Step.
Precaution	A statement indicating any medical, environmental, genetic, or other condition that may increase the likelihood of an Adverse Event, or reduce the effectiveness of the medication or immunization. A clinician should review the risks and weigh them against the benefits of the vaccine before deciding whether or not to proceed with the immunization.
Pre-fetch	The activity of fetching images or other information objects from previously completed procedures to near-term storage for review of those data.
Pregnancy Intention	A client’s plan or desire to either become pregnant or have a child in the near future or to prevent a future pregnancy.
Pre-op	A phase of care that occurs immediately prior to admitting the patient into the operating room or procedure room.
Prepopulate	This term is used in the Retrieve Form for Data Capture (RFD) Profile to define content that is submitted by a Form Filler and used to populate a form before an end user needs to fill in data. This contrasts against Autopopulate (SDC) and Querypopulate (mRFD)
Pre-Population	When an Enhanced Form Repository fills in form fields using data sent by the Form Filler along with the retrieve request. This activity is distinguished from Auto-population in that Pre-population is performed by the Form Manager using an Enhanced Form Repository, whereas Auto-population is always performed by Form Filler.
Prescription	A prescription is an order given by a clinician (usually physicians and in some particular cases pharmacists, nurses, etc.), for a medication to be dispensed to the patient according to an established pattern. The prescription includes the name of the drugs, their dosages, instructions to the patient for the intake, etc.
Prescription	A prescription is issued by one ordering healthcare professional for one patient, in the context of zero or one administrative encounter (between the patient and the ordering physician and/or the healthcare institution).
Prescription Item	A prescription item belongs to one prescription and represents one prescribed medication. It may be associated with one or more observations. Prescription Item is the atomic entity for logistics, distribution and billing.
Prescription Item	A Prescription Item belongs to one prescription and represents one prescribed medication. It may be associated with one or more observations. Prescription Item is the atomic entity for logistics, distribution and billing. It contains the prescribed medicine and dosage information as well as other information to the prescribed item such as patient- and fulfillment instructions and substitution handling.
Presentation	Presentation is the part of the fetus lying over the pelvic inlet; the presenting body part of the fetus.
Presriber	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).
Primary Alarm System	The patient care device itself provides visual and aural indications of alarms that can be seen and heard in the immediate patient vicinity, and that are the authoritative primary indicators of alarms resulting from monitoring the patient. It is understood that caregivers shall be in a position to take immediate action based on these primary alarm indications and shall not rely exclusively on secondary alarm systems for alarm notifications.
Principal	An end user, 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
Print Presentation LUT SOP Class	See DICOM PS 3.4.
Privacy Consent Document	The document containing a structured policy used to express patients' privacy preference.
Private Key	A key in an asymmetric cryptographic algorithm; the possession of this key is restricted, usually to one entity.
Pro Re Nata	Medication that should be administered as needed or as the situation arises. It represents an administration of prescribed medication whose timing is left to the patient, nurse or caregiver, as opposed to medication that is to be taken according to a fixed schedule. This does not imply that the patient may take as much of the medicine as desired, but rather that the medicine may be taken in the prescribed dosage if needed.
Procedure	A surgery or an invasive examination of a patient that is required by quality review organizations to be preceded by a pre-procedure assessment of procedure risk and anesthesia risk. This assessment is typically referred to as a "Pre-operative" or "Pre-procedure History and Physical."
Procedure	In the context of a "Pre-procedure History and Physical," the "procedure" is a surgery or an invasive examination of a patient that is required by quality review organizations to be preceded by a pre-procedure assessment of procedure risk and anesthesia risk. This assessment is typically referred to as a "Pre-operative" or "Pre-procedure History and Physical."
Procedure Plan	See DICOM PS 3.3.
Procedure Step	A Procedure Step is the smallest unit of work in the workflow that is scheduled (work to do) and/or performed (work done) by a person or machine (automatons, image acquisition modality, etc.) on an object (specimen, tissue sample, tissue section, etc.).
Procedure Type	See DICOM PS 3.3.
Process	A specific instance of a process definition running in a process engine.
Process	A specific instance of a process definition running in a process consumer.
Process Definition	A designed flow of activities involving one or more role-based activity performers, implemented in XML and deployable to a runtime process consumer.
Process Definition	A design definition of a process flow of activities involving one or more role-based activity performers. A process definition is implemented in XML and deployable to a runtime process engine.
Process Flow Diagram	A graphical illustration of the flow of processes and interactions among the actors involved in a particular example.
Program	Settings used to control the operation of the pump. A program typically initiated by the clinician and entered manually on the device. Once the settings are confirmed, the clinician can then start the infusion.
Projection Dataset	A collection of images which do not have a completely defined location in space and whose pixels may not represent an exact location in the patient body. Although each image can have a normal vector describing the orientation of the image plane, they are not strictly planar since the “depth” of each pixel is undetermined. The image represents the (parallel or non-parallel) projection of volume data onto the image plane. Typical examples of projection data include Maximum Intensity Projection (MIP) images, projection images from an NM Gamma camera, most x-rays, mammograms, angio or fluoro series.
Pronouncer	When physician responsible for completing the medical certification of cause of death is not available at the time of death and the jurisdiction has a law providing for a pronouncer, person who determines that the decedent is legally dead but who was not in charge of the patient’s care for the illness or condition that resulted in death.(ref Medical Examiners’ and Coroners’ Handbook on Death Registration and Fetal Death Reporting).
Pronouncing	Process of determining and reporting, in the prescribed format, that the decedent is legally dead.
Protected Health Information	Protected Health Information, as defined in the United States Code of Federal Regulations (Part 45 CFR 160.103) and, as referenced in Section 13400 of Subtitle D (’Privacy’) of the HITECH Act.
Protected Health Information	Information that could be used to identify a patient linked with health data.
Protocol Code	See DICOM PS 3.3.
Protocol Specifications	Protocol specifications encompass the following work products developed and supported by HL7: all versions of the HL7 messaging standard; the Clinical Document Architecture (CDA); Arden Syntax; CCOW specifications; Service Oriented Architecture (SOA) standards; any other normative standards subsequently released by HL7; various functional models, implementation guides, and Implementation Technology Specifications (ITS); the Reference Information Model (RIM); and those informative documents initiated and balloted by the various Work Groups.
Provider	An individual or any category of health care providers who deliver medical or health services and any other person or organization that supplies, bills, or is paid for health care. Including but not limited to: a doctor of medicine, osteopathy, optometry, dental science, podiatry, chiropractic, pharmacist, certified midwife, a registered nurse, a nursing home, a birthing center, or a hospital.
PSD	Peak Skin Dose.
Public Health Cancer Registry	A registry for a defined geographic location that collects cancer information from more than one facility and consolidates multiple reports into one record.
Public Key	A key in an asymmetric algorithm that is publicly available.
Publisher	A system or a module in a publish/subscribe framework, the purpose of which is to publish information to the notification broker about events for which there may be existing subscriptions.
Pull Point Resource	A resource managed by the Pull Point that allows the storing of notification targeted to a specific recipient.
QA	Quality Assurance.
QC	Quality Control.
Quality Criteria	A project commitment to a measure of the quality for each step of the project cycle. It is expected that most projects will use or possibly adapt boiler-plate quality criteria developed as part of HL7’s methodology.
Quality Review	An evaluation of whether the work products of a step meet the pre-established quality criteria. At most steps the project team will self-assess against these criteria and take a vote (not a ballot) to move ahead to the next step.
Querypopulate	This term is used in this profile to define content that is populated into a form via use of RESTful queries to systems that may contain that discrete information. This contrasts against Autopopulate (SDC) and Prepopulate (RFD).
Radio Frequency Identification	A technology that uses radio waves to transfer data from an electronic tag, called RFID tag or label, attached to an object, through a reader for the purpose of identifying and tracking the object.
Radio Frequency Identification	This is the technology whereby tags will transmit their unique identification either periodically (active) or when energized by an energy field (passive). This identification transmission can be correlated by multiple receives to identify the location of the tag.
Radiopharmaceutical Radiation Dose SR Object (RRDSR)	A DICOM Structured Report object conforming to the Radiopharmaceutical Radiation Dose SR IOD.
Real Time Location Services	This is an aspect of Location Services whereby the last known location of devices or people can be communicated to other systems.
Recapper	An automated device which puts back the cap on a specimen container. Acts as a Pre/Post-processor in LDA integration profile.
Reconciliation	The process of merging and adjudicating conflicts between electronically accessed clinical information from multiple sources. It occurs during transfers or transitions of care from one healthcare practice setting or level of care to another, and can occur at other times as needed.
Redacted Document	A document that contains extracted data from the export source document which will be sent to the external system for secondary use.
Referral	In the context of the EHDI-WD profile, a referral is a request for a treatment action to be taken. The treatment could involve performing a procedure or following some other set of instructions. A referral initiates one or more orders to be placed.
Referral Outcome	"In the context of closed loop referral, the Referral Outcome extends the Result of Referral to include situations where the requisite care was not rendered or was ended before completion. Possible Referral Outcomes include:
-The Referral Initiator cancels the referral request (a) before care began or (b) while care was being rendered, but before the care is completed.
-The Referral Recipient declines the referral request (a) before beginning to render care or (b) before care has been completed.
-The Referral Recipient completes the care and submits the Result of Referral."
Referral Request	Referral Request is defined as a request from one provider (Referral Initiator) to another provider (Referral Recipient). The request includes a description of the services the Referral Initiator wants for a patient (i.e., the reason for referral and the specific questions asked).
Registered Space	The space to which the datasets are being registered. Typically this will be the space of one of the Original Data Sets. The Registered Space is identified by the Frame of Reference UID of the Spatial Registration object.
Related Health Information	In the context of closed loop referral, related health information is the patient information that is relevant to the referral request, interim findings, or the referral outcome.
Requested Procedure	See DICOM PS 3.3
Requested Procedure ID	See DICOM PS 3.3.
Requested Procedure Module	See DICOM PS 3.3.
Requester Entity	The entity identified within the identity assertion. This entity asks for resources (documents). This entity performs query to the registry and try to retrieve documents from repositories. Authorization Decisions are created and associated with the Requester Entity.
Research Eligibility Criteria	Defines the study population by specifying inclusion and exclusion criteria. Inclusion criteria must be met for prospective subjects to be eligible for participation in a study. Exclusion criteria are the characteristics in a protocol, any one of which may exclude a potential subject from participation in a study.
Research Management System	This term is used to describe a system that manages research information related to clinical trials or studies.
REST	Representational State Transfer. An integration paradigm whereby data is exchanged with remote hosts by operating on HTTP resources using HTTP verbs such as GET, PUT, POST, etc.
Result Interpretation	A categorization of a result to map actual measures or test observations to a set of possible meanings associated with the test, for example, in a hearing screening test, a measure of lower than 20 dBHL could be interpreted as a “Pass” while a measure of higher than 20 dBHL could be interpreted as a “Fail”. Results are what they are, but interpretations could vary by device, or by jurisdiction, for example, in some cases, the cut off between normal and abnormal could be30 dBHL.
Result of Referral	In the context of closed loop referral, the Result of Referral encompasses the Referral Recipient's findings, conclusions, interpretations, and/or impressions of the service performed for the patient. The results are sent from the Referral Recipient to the Referral Initiator at the End of Care.
Resulting Dataset	The data set created by applying a Registration Transformation to an Original Dataset.
Results	Information measured or produced by a test. This is observable data.
Results Information Object Definition	See DICOM PS 3.3.
RFC	Request for comment. See http://www.rfc-editor.org/.
RFID	See Radio Frequency Identification.
RGB	Stands for "Red Green Blue." It refers to the three hues of light (red, green, and blue) that can mix together to form any color. When the highest intensity (255) of each color is mixed together, white light is created. When each hue is set to zero intensity, the result is black. Software specifies the specific R, G and B levels to generate specific colors per displayed pixel.
RID	Retrieve Information for Display
RIS	Radiology Information System.
Role	The actions of an actor in a use case.
Rosetta Terminology Mapping	"The Rosetta Terminology Mapping (RTM) ) IHE PCD Profile is focused on identifying a core set of semantics that are shared between multiple devices within the same modality (e.g., physiological monitors, ventilators, infusion pumps, etc.) and then mapping them to a standard terminology. The RTM mapping effort will initially include numeric parameters and their associated units of measurement and enumerated values.
http://wiki.ihe.net/index.php?title=PCD_Profile_Rosetta_Terminology_Mapping
References:
ISO/IEEE 11073-10101 Health informatics — Point-of-care medical device communication — Part 10101: Nomenclature, First edition, 2004-12-15. ISO and IEEE, 2004. The ‘Unified Code for Units of Measure’ (UCUM).
"
Rotor Wing	Any transport by helicopter.
RPR	Rapid Plasma Reagin.
RR	Respiration rate in breaths per minute.
RRDSR	See Radiopharmaceutical Radiation Dose SR object.
RSNA	Radiological Society of North America. See http://www.rsna.org/.
RTM	See Rosetta Terminology Mapping.
Run	A “run” is a set of documents to be processed. There can be a run of summary of care documents or a run of patient-level quality report documents. When validating a document produced from a run of documents, the content in that resulting document must demonstrate proper processing of the content in all documents with the run of incoming.
S&I	Standards and Interoperability Framework is an open forum sponsored by ONC’s Office of Standards & Interoperability (OSI) to advance harmonization and implementation of specifications that support national healthcare priorities. SDC is an S&I Framework initiative.
Safety Infusion System (Smart Pump System)	"Infusion devices designed to reduce the error rates associated with infusions through the use of one or more of the following “smart” features:
-Ability to check programmed doses against pre-configured limits in an onboard drug library.
-Ability to read infusion parameters from RFID tags or bar codes.
-Ability to send and receive infusion parameters via a wired or wireless network.
-Ability to communicate through a server or gateway."
SAML	Security Assertion Markup Language is an Extensible Markup Language standard that allows a user to log on once for affiliated but separate Web sites.
SaO2	The saturation level of oxygen in hemoglobin, as measured by samples obtained from arterial puncture.
Scheduled Procedure Step	See DICOM PS 3.3.
Scheduled Procedure Step Module	See DICOM PS 3.3
SCO	Source Cardinality. Indicates the cardinality for a particular observation, for example: 0..1, 0..*, 1..1, 1..*, etc.)
Scope	A brief description of the transaction.
Scope	A brief description of the extent of identified profiles' transaction capacity.
SCP	Service Class Provider. See DICOM PS 3.3
SCU	Service Class User. See DICOM PS 3.3
SDC Form Definition	A standardized set of attributes describing the semantics and syntax of a form design so that it may be rendered consistently in any suitable information system and can be validated using SDC Schema. Based on ISO/IEC 19763-13 with SDC extensions. This is not a fillable form.
SDC HTML Package	A collection of files that contains an HTML form instance derived from an SDC Form Definition, along with (optional) mapping information, (optional) administrative information, and (optional) supplemental data. The package is represented in SDC Content modules and may also be persisted as a collection of files. The HTML form instance is a fillable form.
SDC Schema	A W3C schema for an ISO/IEC 19763-13 compliant form, with SDC extensions.
SDC XML Package	A collection of XML data, meeting the SDC Schema, that includes the particular SDC Form Definition represented as a set of standardized XML elements, along with mapping information, administrative information including submission and compliance instructions, and (optional) supplemental data. The package is represented in SDC Content modules and may also be persisted as a collection of files.
Secondary Alarm System	A system intended to give "best effort" notification of alarms at additional locations, to additional persons, or for additional purposes such as archiving, but not intended to take the place of a primary alarm system as the authoritative primary indicator of alarms resulting from monitoring the patient.
Secure Domain	A network, hardware systems, secure nodes, and physical environment for which a single set of security policies is defined and enforced for access to its addressable objects.
Secure Node	A network-addressable system that conforms to a secure domain's access policies and management. A secure node often supports IHE actors.
Sequence	Term refers to two or more conditions entered on successive lines of Part I of the cause-of-death statement, each condition being an acceptable cause of the one entered on the line above it (ref ICD-10, vol 2, section 4.1.5).
Sequence Diagram	UML Sequence diagrams are a dynamic modeling technique, as are collaboration diagrams and activity diagrams.
Series	A subset of an imaging Study (see this entry) acquired from a single specimen by a single acquisition modality. Whenever an image is acquired from a new specimen or involves a new acquisition modality a new Series is created. A new series is also created when an image is acquired for an existing study after the original order has been fulfilled.
Service Interface	System interfaces are also known as "application roles" or "service interfaces".
Settings	Device operational options that may be reported through the device’s communications interface and in some cases may be changed through the communications interface.
Signature Ceremony	An instance of an entity creating a digital signature document.
Signature Purpose	An indication of the reason an entity signs a document. This may be explicitly included as part of the signed information and can be used when determining accountability for various actions concerning the document. Examples include: author, transcriptionist/recorder, and witness.
Signature Purpose	An indication of the reason that an entity signed a document. This may be explicitly included as part of the signature information and can be used when determining accountability for various actions concerning the document. Examples include attesting to: authorship, correct transcription, and witness of specific event. Also known as a “Commitment Type Indication”
Signature Time	The date and time of a signature ceremony.
Signature Time	The date and time that a signature was created.
Simple Network Time Protocol	This is a reduced accuracy version of NTP. The protocol fields are the same, but the data values and algorithms used are greatly reduced accuracy so that it can be implemented on limited capacity systems.
Single Interval Administration	A specific case of continuous administration where the parameters of the administration remain constant (or are changes are not considered relevant) during the entire interval. For example, one administration at a fixed rate for a given amount of time.
Single Point In Time Administration	An administration that happens in one single point in time, i.e., instantaneously, or that does not take a measurable amount of time. For example, giving or taking a tablet.
Slab	A thick slice tomosynthesis reconstruction (e.g., greater than 1mm).
SME	Subject Matter Expert or Domain Expert. A person with domain knowledge that represent the users of IT systems and their business needs.
SMTP Aether	The interconnected e-mail infrastructure of the Internet. The entry point into the SMTP Aether is an SMTP Server.
SNOMED-CT®	A comprehensive clinical terminology, originally created by the College of American Pathologists (CAP) and, as of April 2007, owned, maintained, and distributed by the International Health Terminology Standards Development Organization (IHTSDO), a non-for-profit association in Denmark. The CAP continues to support SNOMED CT operations under contract to the IHTSDO and provides SNOMED-related products and services as a licensee of the terminology. More information available from http://www.ihtsdo.org/ or the United States National Library of Medicine at http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html.
SOAP	Simple Object Access Protocol: An XML-based messaging protocol.
Sorter	An automated device which sorts the specimen according to their process type. Acts as a Pre/Post-processor in LDA integration profile.
Spatial Registration SOP Class	See DICOM PS 3.3, section A.39.
Specimen Work Order Step	A single non-analytical operation to be performed on a specimen by an automated peri-analytical device.
SpO2	The saturation level of oxygen in hemoglobin; can be determined by noninvasive method of pulse oximetry.
SPS	See Scheduled Procedure Step.
SR	Structured Report.
Stage	The extent of involvement of organs and tissues by tumor (e.g., how far the cancer has spread in the body.
Stakeholder	A person or a company that requests a new standard, a technical correction to an existing standard, or an enhancement.
Standardized Functional Status Assessments	A series of specific, objective, and standardized tests, which include interview questions and/or a physical examination, of an individual, to determine their level or their strengths or weaknesses related, but not limited to fine and gross motor skills, visual perception, sensory processing, social skills, or comfort level. The assessment is used to confirm the individual's current level of functional ability for activities of daily living.
Standards of Practice	"The American Nurses Association defines Standards of Practice as follows (from American Nurses Association (2004). Standards of Clinical Nursing Practice. Washington, DC: ANA):
Standard 1: Assessment: The registered nurse collects comprehensive data pertinent to the patient’s health or the situation.
Standard 2: Diagnosis: The registered nurse analyzes the assessment data to determine the diagnoses or issues.
Standard 3: Outcomes Identification: The registered nurse identifies expected outcomes for a plan individualized to the patient and situation.
Standard 4: Planning: The registered nurse develops a plan then prescribes strategies and alternatives to attain expected outcomes.
Standard 5: Implementation: The Registered nurse implements the identified plan. from
Standard 6: Evaluation: The registered nurse evaluates the progress toward attainment of outcomes. "
Storage Commitment SOP Class	See DICOM PS 3.4.
Stored Print SOP Class	See DICOM PS 3.4
Structured Policy	A machine-processable set of access rules that enables the receiving system to enforce the patients' privacy preferences without requiring human interpretation.
Structured Reporting Information Object Definitions	See DICOM PS 3.3.
Structured Reporting SOP Classes	See DICOM PS 3.4.
Structured Reporting Templates	See DICOM PS 3.16.
Study	A study, in this context, is a test ordered by a clinician to gain information which helps to diagnose a patient’s condition. A screening is a type of test which may include a very simple result interpretation, like pass or fail, normal or abnormal. In the context of this profile, the three concepts: study, test and screening can be classified a synonymous.
Study Coordinator	Person who handles most of the administrative responsibilities of a clinical trial on behalf of a site investigator, acts as liaison between investigative site and sponsor, and reviews all data and records before a monitor’s visit.
Study Protocol	A document that describes the objective(s), design, methodology, statistical considerations, and organization of a trial.
Subject	An individual who participates in a clinical trial, either as recipient of the investigational product(s) or as a control.
Submission Set	A set of XDS documents registered together to a Document Repository concerning information related to one care event of a single patient, provided by an EHR system.
Sub-order	A part of an Order or of an Order Group, which the current laboratory subcontracts to another laboratory.
Subscribe	Make a request that only messages satisfying specific predicates be sent to the subscriber.
Subscriber	A system or a module in a publish/subscribe framework, the purpose of which is to send subscribe and unsubscribe requests to the notification broker on the behalf of a notification recipient. The subscribe request contains a set of filters to determine the information for which the subscription applies.
SUID	The Study Instance UID from a DICOM SOP instance, or collection of SOP instances.
SWOS	Specimen Work Order Step: A WOS performed by Pre/Post-processor in LDA integration profile.
Syslog Message	Any message that complies with RFC-5424, regardless of the format of the message body. An ATNA audit log message is a specific kind of syslog message that has a specific format for the message body.
Syslog Metadata	Attributes that classifies the audit message defining: severity of the event, facility and application that sent the message. These are defined in RFC-5424.
System Actor	Information system that supports a particular function in the pharmacy domain.
Systemic Therapy	Treatment that affects the entire body, rather than a localized area. Types of systemic therapy include chemotherapy, hormone therapy, and biological therapy. Systemic therapy enters the bloodstream to destroy or control cancer throughout the body.
Team Member	Parties who manage and/or provide care or service as specified and agreed to in the care plan, including clinicians, other paid and informal caregivers, and the patient.
Technical Alarm	An alarm reflecting the state of the patient care device themselves that may require action from caregivers (such as ECG leads off the patient).
Technical Validation	The process by which a laboratory technician accepts a single observation or a set of observations that have been produced either with a manual technique or an automated one, generally under his control. Technical validation ensures that observations have been obtained in conformance with defined laboratory procedures and have satisfied quality control and other technical validation criteria.
TEE	Transesophageal Echocardiography.
Test	An operation performed in laboratory or on the point of care, manually or on an analyzer or with the help of a device, instrument or system, to produce one or more observations (aka results). The observations can be obtained by measurement of a quantity on an in-vitro specimen, finding on this specimen, calculation from other observations and data, or any other means
TF	Technical Framework
TGT	Ticket Granting Ticket. The initial credentials that verify that the user has been authenticated. It is used to avoid repeated user authentication events and as a token to request access to services.
The Joint Commission	An independent, not-for-profit organization, which accredits and certifies health care organizations and programs in the United States. See https://www.jointcommission.org/.
The Joint Commission	Formerly "The Joint Commission on Accreditation of Healthcare Organizations" (JCAHO).
Tiers of Effective Contraception	Three tiers of effectiveness for available contraceptive methods have been established based upon efficacy of use and typical failure rates, per USAID and WHO recommendations. The tier 1 methods (such as the intrauterine device, implants, and sterilization) are rated the most highly effective because they are long-acting and independent from coitus, user motivation, or adherence and therefore have failure of rates of <1%. The lower tier methods are more highly dependent upon correct and consistent usage at every coital episode and thus susceptible to user failure with rates greater than 9%. Data elements that present contraceptive options should be ordered by these tiers.
Tissue microarray	Tissue microarrays (TMA) consist of paraffin blocks in which up to 1000 separate tissue cores coming from different donor blocks, different parts and different patients, are assembled in array fashion to allow simultaneous processing and histological analysis.
TMA	See Tissue Micro Array.
TNM Stage	Tumor/Nodes/Metastasis – A system to classify the extent of disease based mostly on anatomic information on the extent of the primary tumor, regional lymph nodes and distant metastasis.
Transclusion	An inclusion within a template design makes use of another template by “virtually” copying the included template definitions, also known as transclusion. In essence this means that template definitions are included by reference and shown as-is on demand, i.e., at time of displaying the template or using it for the creation of validation scripts. Inclusion is automatic and transparent to the user.
Transfer of Care	Any transfer of care involving the exchange of patient care information between or across systems.
Transistion of Care	Transition of Care is defined as the cooperative provision of care by multiple providers, where each provider has part of the responsibility for the patient's wellness.
Transitions	Often referred to as a "hand-offs". Transfer of patient and their care to another similarly licensed care provider. This occurs during a change in acuity, care site, or a different provider.
Transport Medicine	Any field of medicine dealing specifically with an out of care setting environment or restructured to apply to an out of care setting environment.
Transport Mode	The method the patient employs, or is provided to get to the emergency department.
Treatment or Medication Regime	A treatment or medication regime is a series of medications intended to heal the patient or to improve the health status or to diagnose a disease.
Treatment Plan	A concept developed by a provider in collaboration with the individual to address an individual’s health concern under the purview of a single provider.
Trigger Event	An event such as the reception of a message or completion of a process, which causes another action to occur.
TTE	Transthoracic Echocardiography.
Tubal Sterilization	"To make sterile by ligation of the fallopian tubes.
Irving Tubal Ligation - A surgical method of fallopian tube occlusion that excises a small portion of Fallopian tubes and then embeds the end of the cut fallopian tube below the serosa, or peritoneal, surface of the uterus.
Modified Pomeroy Tubal Sterilization - A surgical method of fallopian tube occlusion that excises a small loop of Fallopian tube that has been tied firmly.
Parkland Tubal ligation - A surgical method of fallopian tube occlusion that excises a small portion of Fallopian tubes after ligation proximally and distally.
Uchida Tubal Ligation - A surgical method of fallopian tube occlusion that excises a small portion of Fallopian tubes then embeds the end of the cut fallopian tube below the mesosalpinx resulting in female sterilization "
UCUM	The Unified Code for Units of Measure is a code system intended to include all units of measures being contemporarily used in international science. See www.unitsofmeasure.org/.
UID	See Unique Identifier (see also Globally Unique Identifier).
UML	See Unified Modeling Language.
Unbinding	Disassociation of a patient from a device.
Underlying Cause of Death	The disease or injury which initiated the train of morbid events leading directly to death, or the circumstances of the accident or violence which produced the fatal injury (ref ICD-10, vol 2, section 4.1.2).
Unfixed Dataset	A set of images which are planar, with a defined “depth”, but due to the nature of the modality the relative positions of each frame in the set is undetermined and so they do not technically define a volume. The most typical example of an unfixed dataset is a set of conventional ultrasound images.
Unified Modeling Language	A standardized general-purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group. UML includes a set of graphic notation techniques to create visual models of software-intensive systems.
Unique Identifier	See DICOM PS 3.5.
Universal ID	Unique identifier over time within the UID type. Each UID must belong to one of specifically enumerated species. Universal ID must follow syntactic rules of its scheme.
Universal Service ID	See HL7 version 2.3.1.
Unsolicited	Within the context of HL7 when the transfer of information in initiated by the application system that deals with the triggering event, the transaction is termed an unsolicited update.
Unverified	Results that are flagged to be reviewed by a user prior to being incorporated into the information system.
USB	Universal Serial Bus.
Use Case	A graphical depiction of the actors and operation of a system.
Use Case	A Use Case represents a discrete unit of interaction between a user (human or machine) and the system. A Use Case is a single unit of meaningful work; for example creating a train, modifying a train and creating orders are all Use Cases. Each Use Case has a description which describes the functionality that will be built in the proposed system. A Use Case may 'include' another Use Case's functionality or 'extend' another Use Case with its own behavior. Use Cases are typically related to 'actors'. An actor is a human or machine entity that interacts with the system to perform meaningful work.
User Assertion	A set of claims about an authenticated principal (user, application, system...) that is issued by an identity provider.
User Subject	The PSA defined subject that supports sharing the user identity of the currently logged in to the applications on the desktop.
Username	A sequence of characters, different from a password, that is used as identification and is required when logging on to a multi-user computer system, LAN, bulletin board system, or online service. Also called user ID, or uid.
UTC	Universal Coordinated Time. This is the replacement for GMT. It defines a reference time base that is internationally recognized and supported.
UUID	Universally Unique Identifier
Vaccine	This is a substance designed to be administered to a person in order provide protection against future disease. See also Combination Vaccine.
Validated	PCD data which has been marked as correct by caregiver.
Validator	Synonym of “Clinical Expert” (see Clinical Expert).
Value Set	"A uniquely identifiable set of valid concept representations where any concept representation can be tested to determine whether or not it is a member of the value set. A value set may be a simple flat list of concept codes drawn from a single code system, or it might be an unbounded hierarchical set of possibly post-coordinated expressions drawn from multiple code systems. Also known as a list of valid concept codes.
A valid concept is a concept that would be logically representative of the Value Set that it belongs to, for example for the Value Set “Colours of the rainbow”, “yellow” would be a valid concept. "
VDRL	Venereal Disease Research Laboratories. A blood test.
Verified	Results that are stored in the information system because they were marked as Verified (by device configuration) and did not require user review, or because they were selected at the point of care and reviewed by a user prior to being incorporated into the information system.
Verifier	This term is used in HL7 CDA R2 standard. A laboratory staff who performed “Technical Validation” (see Technical Validation).
Volumetric Dataset	A collection of planar (cross-sectional) images which spans a volume and each image has a defined location in space. Typical examples include a set of CT transversal slices, MR slice stacks, reconstructed tomographic NM or PET volumes or volumes re-constructed from projection X-ray images.
W3C	World Wide Web Consortium. See http://www/w3.org
W3C	A trademark of the World Wide Web Consortium that is not an abbreviation.
WADO-RS	Web Access to DICOM Objects by RESTful Services.
Waveform Snapshot	A limited duration continuous block of waveform data; typically less than one minute in duration.
Web-Viewable	Browsable using a web browser (e.g., XHTML files and JPEG images).
Weight-for-Length z-score and percentiles	For children less than 2 years (24 months) of age, weight-for-length, rather than BMI, is the preferred indicator. The reference population is the WHO Multicentre Growth Reference Study.
Wet Signature	Ink on paper signature.
WNL	Within Normal Limits.
Work Order	A test or battery to be performed on one or more biological specimens in the work area of a clinical laboratory.
Work Order Step	A battery or test requested by the Order Filler Actor to the Automation Manager Actor.
WOS	See Work Order Step.
WSI	Whole Slide Image.
XA	X-ray Angiography.
XAD-PID	XDS Affinity Domain Patient Identifier.
XAD-PID - XDS Affinity Domain Patient Identifier	XDS assumes that the XDS Affinity Domain will establish common means to create a unique patient identifier for persons involved in the domain and allow Document Sources to find the appropriate patient identifier prior to publishing documents to the XDS infrastructure. This identifier is called the XDS Affinity Domain Patient Identifier.
X-Assertion Provider	This is an SAML Identity Provider (IDP) or WS-Trust Security Token Service (STS), and is not further specified by IHE.
XDS Affinity Domain	A group of healthcare enterprises that have agreed to work together using a common set of policies and which share a common infrastructure of repositories and a registry.
XDS Affinity Domain Policy	XDS Affinity Domain Policy that clearly defines the appropriate uses of the XDS Affinity Domain. Within this policy is a defined set of acceptable use Privacy Consent Policies that are published and understood.
XDS Document	An XDS Document is the smallest unit of information that may be provided to a Document Repository and registered in a Document Registry. An XDS Document may contain simple text, formatted text (e.g., HL7 CDA Release 1), images (e.g., DICOM) or structured and vocabulary coded clinical information (e.g., CDA Release 2, CCR), or may be made up of a mixture of the above types of content.
XDS Folder	An XDS Folder allows document sources to group the documents they submit with other related documents. What constitutes a Folder and the vocabulary associated with the specific Folders used by an EHR-CR is decided by an agreement between the care delivery organization members of an XDS Affinity Domain.
XDS Imaging Document	An XDS Imaging Document is the smallest unit of imaging related information that may be provided to a Document Repository and registered in a Document Registry. An XDS Imaging Document may contain a manifest of images (e.g., DICOM Key Object Selection document) or a radiology report provided either as a PDF document or as structured and vocabulary coded clinical information (e.g., CDA Release 2).
XHTML	eXtensible Hypertext Markup Language.
XSD	W3C Schema, when referencing xs:integer and other datatypes.
ZigBee	Zigbee is an IEEE 802.15.4-based specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios, such as for home automation, medical device data collection, and other low-power low-bandwidth needs, designed for small scale projects which need wireless connection. Hence, Zigbee is a low-power, low data rate, and close proximity (i.e., personal area) wireless ad hoc network.

Glossary Rules

Note: 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.

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.

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