The Alarm Communication Management integration profile defines the communication of alarms from alarm source systems to alarm management systems and from alarm management systems to alarm historical systems.
                        

 An ACP is an element of an optional SAML statement described in the NHIN Authorization Framework specification.
                        

The Eye Care Workflow Integration Profile establishes the continuity and integrity of basic patient and procedure data in the context of an eye clinic and/or an integrated hospital workflow scenario. This profile deals specifically with consistent handling of patient identifiers and demographic data. It also specifies the scheduling and coordination of procedure data to a wide variety of diagnostic imaging and testing equipment, and its reliable storage in an image management system from where it is available to support subsequent workflow steps, such as reporting. It also provides the ability for the acquisition devices to identify the actual procedure(s) that were performed. This enables further workflow steps such as automated billing.
                        

Antepartum Education
                        

Antepartum History and Physical
                        

Antepartum Laboratory
                        

Antepartum Summary
                        

This content profile describes an anatomic pathology structured report (APSR) as a CDA r2 document to be published towards a document sharing resource such as a shared electronic health record used by a community of care providers, relying on one of the infrastructure 
document sharing/exchanging profiles defined in IHE ITI TF.
                        

The Pathology Workflow Integration Profile establishes the continuity and integrity of basic pathology data acquired for examinations being ordered for an identified inpatient or outpatient
                        

The Access to Radiology Information Integration Profile specifies a number of query transactions providing access to radiology information, including images and related reports, in a DICOM format as they were acquired or created. Such access is useful both to the radiology department and to other departments such as pathology, surgery and oncology. Non-radiology information (such as lab reports) may also be accessed if made available in DICOM format.
                        

Anatomic Pathology Reporting to Public Health
                        

This integration profile involves the exchange of RT Plan information between treatment planning systems and between treatment planning systems and treatment management systems.  The emphasis for this profile is on reducing ambiguity involved in re-planning and incorporation of the planning information in to the treatment management system in anticipation of transfer to a treatment delivery system.  The transactions revolve around content rather than workflow.
                        

The ITI Audit Trail and Node Authentication (ATNA) Profile establishes the characteristics of a Basic Secure Node: It describes the security environment (user identification, authentication, authorization, access control, etc.) assumed for the node so that security reviewers may decide whether this matches their environments. It defines basic security requirements for the communications of the node using TLS or equivalent functionality. It defines basic auditing requirements for the node. The profile also establishes the characteristics of the communication of audit messages between the Basic Secure Nodes and Audit Repository nodes that collect audit information. 
                        

It defines the required exchange of information describing the initiator of a request between Health Information Organizations (HIOs) participating as nodes on the NHIN. The purpose of this information exchange is to enable a responding NHIO to evaluate the request based on the information contained in the initiating NHIOs assertions and its own local policies and permissions. 
                        

Basic Eye Care Workflow Integration Profile establishes the continuity and integrity of basic patient and procedure data in the context of an eye clinic and/or an integrated hospital workflow scenario. This profile is a subset of the features defined in the Advanced Eye Care Workflow Integration profile. 
                        

The BFDR Profile is based on the ITI RFD profile. The reader is referred to ITI TF 1:X for a description of the ITI RFD profile. This BFDR Profile defines the content that is used to pre-populate the form retrieved from the Form Manager, and the specification of the pre-population rules to be executed by the Form Manager. This profile does not further constrain the Form Receiver or Form Archiver actors. The pre-pop data is defined by the IHE PCC LDS Profile. See QRPH 1: Appendix X for the specification of the desired pre-pop data constraints to PCC LDS that optimize the Birth and Fetal Death Report data pre-population. 
                        

The Birth and Fetal Death Reporting-Enhanced (BFDR-E) Profile provides a means to capture and communicate information needed to report births and fetal deaths for vital registration purposes. BFDR-E builds upon the earlier Birth and Fetal Death Reporting (BFDR) Profile that utilizes actors and transactions defined in the ITI Retrieve Form for Data Capture (RFD) Profile to capture structured data using digital forms. 

BFDR-E defines a specialized Labor and Delivery Summary (LDS-VR) CDA document. The LDS-VR document is used to prepopulate an electronic form (worksheet) that collects the information needed for submission to vital records. BFDR-E supports pre-population of the worksheet form using either the specialized LDS-VR document or a more general Labor and Delivery Summary (LDS) document that does not conform to all the further constraints of an LDS-VR document. Use of the LDS-VR pre-population option optimizes the initial Birth and Fetal Death Report form data population. 

BFDR-E further defines a mechanism to transform form submission data and record it in a CDA document designed to exchange the information in a standard format. BFDR-E defines a Form Receiver CDA Exporter Actor to perform the transform on the form submission data  and share that document with a Content Consumer. BFDR-E defines the IHE BFDR Document Template which adapts the HL7 BFDR CDA document template to support standard interchange of the information gathered from the form.

BFDR-E also defines a mechanism to transform form submission data and transmit it as a standard HL7 v2 message. The IHE BFDR Message adapts the HL7 V2.5.1 BFDR Message for this purpose. BFDR-E defines the BFDRfeed transaction to transmit this message. The BFDRfeed transaction is just like the VRDRfeed [QRPH-38] transaction defined in the QRPH Vital Records Profile, but is carries a different message payload. 

                        

The document sharing infrastructure provided by XD* allow for the publication and use of clinical documents associated with a patient. This profile allows for a Patient Privacy Policy Domain (e.g., an XDS Affinity Domain to have a number of Patient Privacy Policies that can be acknowledged (aka consent). This allows for more flexibility to support some patient concerns, while providing an important and useful dataset to the healthcare provider. Without BPPC, the XDS profile requires that the administrators of an XDS Affinity Domain creates and agrees to a single document publication and use policy (See ITI TF-1: Appendix L). Such a single XDS Affinity Domain Policy is enforced in a distributed way through the inherent access controls of the systems involved in the XDS Affinity Domain.