
SELECT pg_catalog.setval('integration_profile_id_seq', 60, true);


INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (1, 'PWP', 'Personnel White Pages', '<p>The Personnel White Pages Profile provides access to basic human workforce user directory information. This information has broad use among many clinical and non-clinical applications across the healthcare enterprise.</p>', '2007-06-27 18:39:09.017025+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (17, 'DSG', 'Digital Signature', 'DSG is document content profile that describes the digital signature content and how it is managed in XDS, as well as guidance on how other IHE domains (such as Patient Care Coordination) could create document content profiles for such purposes as e-referral and e-prescription.', '2007-06-27 18:39:09.049558+02', NULL, 3);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (24, 'SINR', 'Simple Image and Numeric Report', 'The Simple Image and Numeric Report Integration Profile facilitates the growing use of digital dictation, voice recognition, and specialized reporting packages, by separating the functions of reporting into discrete actors for creation, management, storage and viewing. Separating these functions while defining transactions to exchange the reports between them enables a vendor to include one or more of these functions in an actual system.', '2007-06-27 18:39:09.067337+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (46, 'IDCO', 'Implantable Device Cardiac Observations', 'The IDCO profile specifies a mechanism for the creation, transmission, and processing of discrete data elements and report attachments associated with cardiac device interrogations (observations).', '2007-06-27 18:39:09.087906+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (2, 'SWF', 'Scheduled Workflow', 'The Scheduled Workflow Integration Profile establishes the continuity and integrity of basic radiological data. It specifies a number of transactions that maintain the consistency of patient and ordering information as well as defining the scheduling and imaging acquisition procedure steps. This profile also makes it possible to determine whether images associated with a particular performed procedure step have been stored (archived) and are available to enable subsequent workflow steps, such as reporting.', '2007-06-27 18:39:09.034234+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (3, 'LSWF', 'Laboratory Scheduled Workflow', 'The Laboratory Scheduled Workflow Integration Profile establishes the continuity and integrity of clinical laboratory testing and observation data throughout the healthcare enterprise. It involves a set of transactions, to maintain the consistency of ordering and patient information, to control the conformity of specimens, and to deliver the results at various steps of validation. Some of these transactions are already defined in the IHE Radiology Technical Framework. This profile also enables automation of preanalytical, analytical and post-analytical processes within the laboratory.', '2007-06-27 18:39:09.035445+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (4, 'CATH', 'Cardiac Catheterization Workflow', '<p>Cardiac Catheterization is complex, especially from a workflow perspective. Evidence-gathering activities may begin before an order is placed; in fact, orders are often not created for a cardiac catheterization procedure due to its frequent emergency nature. There may be a variety of imaging, measurement, and reporting systems that need to coordinate to use the same patient identifier, and to assure that the evidence produced is all associated with the same procedure. Further, the procedure itself may include both diagnostic and interventional or therapeutic aspects, and may extend over a long time period (several hours).</p><p> The Cardiac Catheterization Workflow Integration Profile establishes the continuity and integrity of basic patient data in the context of the cardiac catheterization procedure. This profile deals specifically with consistent handling of patient identifiers and demographic data, including that of emergency patient presentation where the actual patient identity may not be established until after the beginning of the procedure, or even a significant time after the completion of the procedure. It also specifies the scheduling and coordination of procedure data across a variety of imaging, measurement, and analysis systems, and its reliable storage in an archive from where it is available to support subsequent workflow steps, such as reporting. It also provides central coordination of the completion status of steps of a potentially multi-phase (diagnostic and interventional) procedure.<p>', '2007-06-27 18:39:09.036416+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (5, 'ECHO', 'Echocardiography Workflow', '<p>The Echocardiography Workflow Integration Profile describes the workflow associated with digital echocardiography, specifically that of transthoracic echo (TTE), transesophageal echo (TEE), and stress echo. As does the Cath Workflow Integration Profile, this profile deals with patient identifiers, orders, scheduling, status reporting, multi-stage exams (especially stress echo), and data storage. It also specifically addresses the issues of acquisition modality devices that are only intermittently connected to the network, such as portable echo machines, and addresses echo-specific data requirements.</p><p> Intravascular ultrasound (IVUS) and intracardiac echocardiography (ICE) are used in cardiac catheterization procedures, and are supported as modalities in the Cath Workflow, and not in the Echo Workflow.</p>', '2007-06-27 18:39:09.037529+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (6, 'PIR', 'Patient Information Reconciliation', 'The Patient Information Reconciliation Integration Profile extends the Scheduled Workflow Integration Profile by offering the means to match images acquired of an unidentified patient (for example, during a trauma case) or misidentified patient with the patient s admission and order history. In the example of the trauma case, this integration profile allows subsequent reconciliation of the patient record with images that are acquired (either without a prior registration or under a generic registration) before the patient s identity could be determined. Thus images can be acquired and interpreted immediately and later, when the patient s official registration and order information is entered into the ADT, Order Placer and Order Filler Systems, this information is matched with the acquired image set, greatly simplifying these exception-handling situations.', '2007-06-27 18:39:09.038517+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (7, 'PGP', 'Presentation of Grouped Procedures', 'The Presentation of Grouped Procedures Integration Profile (PGP) addresses what is sometimes referred to as the linked studies problem: viewing image subsets resulting from a single acquisition with each image subset related to a different requested procedure (e.g. CT chest, abdomen and pelvis). It provides a mechanism for facilitating workflow when viewing images and reporting on individual requested procedures that an operator has grouped (often for the sake of acquisition efficiency and patient comfort). A single acquired image set is produced, but the combined use of the scheduled workflow transactions and the consistent presentation of images allows separate viewing and interpretation of the image subsets related to each of the requested procedures.', '2007-06-27 18:39:09.039587+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (8, 'RWF', 'Reporting Workflow', 'The Reporting Workflow Profile addresses the need to schedule, distribute and track the status of the reporting workflow tasks such as interpretation,  transcription and verification. Worklists for each of these tasks are generated and can be queried; workitems can be selected and the resulting status returned from the system performing the work to the system managing the work.', '2007-06-27 18:39:09.040542+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (9, 'NMI', 'NM Image', 'The NM Image Profile specifies how NM Images are to be stored by Acquisition Modalities and Evidence Creator workstations and how Image Displays should retrieve and make use of them. It defines the basic display capabilities Image Displays are expected to provide, (such as might be sufficient for a referring physician) but does not address advanced review features. It also defines how result screens, both static and dynamic, such as those created by NM Cardiac Processing Packages, should be stored using DICOM objects that can be displayed on general purpose Image Display systems. The NM Image Profile can be enhanced by combining it with other workflow profiles such as Scheduled Workflow, Post-Processing Workflow and Reporting Workflow which address how to schedule, manage and report the status of the steps in which NM Image objects are created.', '2007-06-27 18:39:09.041469+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (10, 'RFD', 'Retrieve Form for Data Capture', 'The Retrieve Form for Data-capture Profile (RFD) provides a method for gathering data within a user''s current application to meet the requirements of an external system. RFD supports the retrieval of forms from a form source, display and completion of a form, and return of instance data from the display application to the source application.', '2007-06-27 18:39:09.04239+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (11, 'CHG', 'Charge Posting', 'The Charge Posting Integration Profile specifies the exchange of information from the Department System Scheduler/Order Filler actor to the Charge Processor actor regarding charges associated with particular procedures, as well as communication between the ADT/Patient Registration and Charge Processor actors about patient demographics, accounts, insurance, and guarantors. The Charge Posted Transaction contains all of the required procedure data to generate a claim. Currently, these interfaces contain fixed field formatted or HL7-style data. The goal of including this transaction in the IHE Technical Framework is to standardize the Charge Posted Transaction to a Charge Processor, thus reducing system interface installation time between clinical systems and Charge Processors. Additionally, the Charge Posted Transaction reduces the need of the billing system to have knowledge of the radiology internals. The result is that the Charge Processor will receive more complete, timely and accurate data.', '2007-06-27 18:39:09.043322+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (12, 'PWF', 'Post-Processing Workflow', 'The Post-Processing Workflow Integration Profile addresses the need to schedule and track the status of the steps of the typical post-processing workflow, such as Computer-Aided Detection or Image Processing. Worklists for each of these tasks are generated and can be queried, work items can be selected and the resulting status returned from the system performing the work to the system managing the work.', '2007-06-27 18:39:09.04472+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (13, 'DWF', 'Departmental Workflow', '<p>The IHE Departmental Workflow  is centrally monitored by the Department System Scheduler/ Order Filler, but its execution may be managed by distributing further control into two levels.</p><p> The first is a set of one or more Worklist managers that are responsible for management of worklist items used to control the activities within a certain phase of a requested procedure. Worklist Managers are also responsible for conveying phase status and information availability to the Workflow Manager and other peer Worklist Managers. The Worklist Manager s method to generate worklist items is not explicitly described by IHE. Currently it is assumed that a Worklist Manager uses internal logic to generate worklist items. Generation of worklist items directly triggered by an actor other than the Worklist Manager is not defined in this concept paper, and would require additional communication between this other actor and the Worklist Manager. </p><p>The second level is a set of workflow participants that are entirely in charge of performing specific procedure steps. This level is defined in detail in the existing individual workflow profile already included in the IHE Radiology Technical Framework and is not described further in this paper.', '2007-06-27 18:39:09.045717+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (14, 'LCSD', 'Laboratory Code Set Distribution', 'A set of common codes is generally used by multiple application systems in a laboratory workflow environment. These common codes need to be synchronized across the various applications at a given site. In many implementations, one application system will be the author (the "owner") of the code set. The responsibility for managing a code set may also be distributed among different systems. This profile provides a way for the owner of a code set (battery, test and observation codes) to send the code set to other applications. This profile involves all dedicated actors currently defined in the Laboratory Scheduled Workflow Integration Profile: Order Placer, Order Filler, Automation  Manager and Order Result Tracker.', '2007-06-27 18:39:09.046633+02', NULL, 5);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (15, 'DRPT', 'Displayable Reports', 'The Displayable Reports Profile describes mechanisms for the transmission of PDFformatted clinical reports between report creators, managers, repositories, and displays. This profile describes the departmental production of reports, which can be further distributed using the Retrieve Information for Display and Cross-Enterprise Document Sharing Profiles (defined in the IHE IT Infrastructure Domain).', '2007-06-27 18:39:09.047558+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (16, 'TCE', 'Teaching file and Clinical trial Export', 'The Teaching File and Clinical Trial Export Profile addresses the need to select DICOM instances, series or studies (which may contain images, key image notes, reports, evidence documents and presentation states) that need to be exported for teaching files or clinical trials. <br> It defines an actor for making the Export Selection, which would typically be grouped with an Image Display or Acquisition Modality, and an actor for processing the selection, which is required to support a configurable means of de-identifying the exported instances. Additional options are provided for de-identification of pixel data, remapping of identifiers to pseudonymous values, export of additional teaching file information, and delaying export for a variety of reasons.', '2007-06-27 18:39:09.048496+02', NULL, 5);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (18, 'LPOCT', 'Laboratory Point Of Care Testing', 'Laboratory Point Of Care Testing (LPOCT) covers the workflow related to clinical laboratory tests performed on the point of care or on patientu2019s bedside, by ward staff.', '2007-06-27 18:39:09.050486+02', NULL, 5);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (19, 'ED-CARD', 'Evidence Document', 'The Evidence Documents Profile defines ways for data recorded in the course of carrying out a procedure step, such as observations, measurements, and results (i.e., evidence documents), to be output by devices, such as acquisition systems and other workstations; to be stored and managed by archival systems; and to be retrieved and presented or used by display and reporting systems. This allows detailed non-image information, such as measurements, CAD results, procedure logs, etc. to be made available as input to the process of generating a clinical Report, either as additional evidence for the reporting physician, or in some cases for selected items in the Evidence Document to be included in the report.', '2007-06-27 18:39:09.051425+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (20, 'LIR', 'Laboratory Information Reconciliation', 'The LIR profile deals with unexpected but typical situations in which the patient is not correctly registered in the hospital information system or is not present at all so that no order can be created to require a lab analysis. This profile solves most of the cases that cannot be managed by the LSWF because they are considered unscheduled workflow.', '2007-06-27 18:39:09.052335+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (21, 'LDA', 'Laboratory Device Automation', 'The LDA Integration Profile supports the workflow for the automated technical section of the clinical laboratory. It provides the transactions between the actors of this section (Automation Managers, Pre/Post-processors, Analyzers) to fulfill the Work Orders sent by the Order Filler, and send back the results produced for these Work Orders. <p>This LDA profile strictly addresses the workflow between Automation Managers and Laboratory Devices (LD) operated by the clinical laboratory staff. Devices operated by the clinical ward staff, are supported by another profile: LPOCT, and are therefore out of scope of LDA. <p>The input to the LDA workflow is a Work Order generated by the Order Filler. The Automation Manager splits this Wok Order into a sequence of one or more Work Order Steps (WOS), sending each one to a particular automated device. <p>Among this sequence, the particular WOS that instructs the Analyzer to fulfill the clinical tests is called the Analytical Work Order Step (AWOS). The transaction carrying this AWOS instructs the analyzer to perform a list of tests on a particular specimen. It does not say how to perform them: The electromechanical handling of an analyzer is out of scope of this profile. <p>The tests are performed on specimen collected from the patients. The specimen may arrive on an automated device before or after the WOS referring to it has been delivered. In both cases, the specimen and the WOS (instruction) must be both present on the device in order for the step to be performed. <p> This LDA profile also addresses the testing of QC specimen on an Analyzer, and the upload of QC results from the Analyzer to the AM. An Analyzer can fulfill both patient specimen AWOS and QC specimen AWOS. The LSWF profile supports the upload of QC results from the AM to the Order Filler. Thus the combination of both profiles enables the centralization of QC results of all the Analyzers of the clinical laboratory, on the Laboratory Information System. <p>In some situations, the recognition of the specimen (by its ID or position) or the WOS content can be entered manually on the LD user interface. <p>For the purpose of messaging, the identification of specimen is essential. <p>The primary specimen ID is provided either by the Order Placer or by the Order Filler. In case a Specimen Work Order Step (SWOS) instructs an aliquoter to prepare aliquot specimen, a new ID coded on a new barcode label will be required for each aliquot produced. These IDs and labels may be provided by the Automation Manager or by the aliquoter or by a third party. The organizational details of the labeling process are out of the scope of this profile, which only recommends that barcode labels be readable (e.g. format and length of the barcode, label format) by all the LD that will perform a WOS on this specimen. <p>The profile includes the LD&apos;s ability to accept or reject a WOS, with the notice of specimen arrival to the Automation Manager. It also includes the ability of an Analyzer to modify the content of an AWOS, for instance adding automatically a new test, depending on the results obtained on the original tests. <p>The ability to automatically create modification of the work order at the AM may be constrained by regulatory requirement. <p>The exchange of code sets and associated rules is supported by another profile: LCSD. <p>Observation results tracking implies the ability of each actor (Analyzer, Automation Manager) to store the raw results, before refining or translating them, automatically or interactively (e.g. during the technical validation). This safe storage is out of the scope of this profile. <p>This LDA profile may enrich its specifications in order to integrate specific types of pre or post processing laboratory devices. The manufacturers of laboratory devices are invited by the IHE Laboratory Committee to bring their contributions to these specifications.', '2007-06-27 18:39:09.064334+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (22, 'NAV', 'Notification of Document Availability', '', '2007-06-27 18:39:09.065457+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (23, 'KIN', 'Key Image Note', 'The Key Image Note Integration Profile specifies transactions that allow a user to mark one or more images in a study as significant by attaching to them a note managed together with the study. This note includes a title stating the purpose of marking the images and a user comment field. Physicians may attach Key Image Notes to images for a variety of purposes: referring physician access, teaching files selection, consultation with other departments, and image quality issues, etc.', '2007-06-27 18:39:09.066403+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (25, 'ED', 'Evidence Documents', 'The Evidence Documents Profile defines interoperable ways for observations, measurements, results and other procedure details recorded in the course of carrying out a procedure step to be output by devices, such as acquisition systems and other workstations; to be stored and managed by archival systems; and to be retrieved and presented by display and reporting systems. This allows detailed non-image information, such as measurements, CAD results, procedure logs, etc. to be made available as input to the process of generating a diagnostic report. The Evidence Documents may be used either as additional evidence for the reporting physician or in some cases for selected items in the Evidence Document to be included in the diagnostic report.', '2007-06-27 18:39:09.068311+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (26, 'RID', 'Retrieve Information for Display', 'Retrieve Information for Display enables simple and rapid access to patient information for better care.  It supports access to existing persistent documents in well-known presentation formats such as CDA, PDF, JPEG, etc.  It also supports access to specific key patient-centric information such as allergies, current medications, summary of reports, etc. for presentation to a clinician.  It complements workflows from within the users on-screen workspace or application. By linking it with two other IHE profiles - Enterprise User Authentication and Patient Identifier Cross-referencing for MPI, this profile s reach can extend across organization boundaries.  This IHE Integration Profile leverages HTTP, Web Services, IT presentation formats and HL7 CDA.', '2007-06-27 18:39:09.06917+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (27, 'ECG', 'Retrieve ECG for Display', '<p>The Retrieve ECG for Display Integration Profile specifies a mechanism for broad access throughout the enterprise to electrocardiogram (ECG) documents for review purposes. The ECG documents include  diagnostic quality  waveforms, measurements and interpretations. This Integration Profile allows the display of this information without requiring specialized cardiology software or workstations, but with general purpose computer applications such as a Web browser.</p><p> This Integration Profile is intended primarily for retrieving resting 12-lead ECGs, but may also retrieve ECG waveforms gathered during stress, Holter, and other diagnostic tests. This Integration Profile only addresses ECGs that are already stored in an information system. It does not address the process of ordering, acquiring, storing, or interpreting the ECGs.<p>', '2007-06-27 18:39:09.070024+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (28, 'PDI', 'Portable Data for Imaging', 'The Portable Data for Imaging Integration Profile specifies actors and transactions that allow users to distribute imaging related information on interchange media. The intent of this profile is to provide reliable interchange of evidence objects and diagnostic reports for import, display or print by a receiving actor. A single physical transport means is specified that supports the multiple usage scenarios described in this profile. The CD format was chosen for supporting the described use cases.', '2007-06-27 18:39:09.070897+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (29, 'XDS', 'Cross-Enterprise Clinical Documents Sharing', 'The Cross-Enterprise Clinical Document Sharing IHE Integration Profile facilitates the registration, distribution and access across health enterprises of patient electronic health records. Cross-Enterprise Document Sharing (XDS) is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise, ranging from a private physician office to a clinic to an acute care in-patient facility.', '2007-06-27 18:39:09.071707+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (30, 'ARI', 'Access to Radiology Information', '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.', '2007-06-27 18:39:09.072622+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (31, 'CPI', 'Consistent Presentation of Images', 'The Consistent Presentation of Images Integration Profile specifies a number of transactions that maintain the consistency of presentation for grayscale images and their presentation state information (including user annotations, shutters, flip/rotate, display area, and zoom). It also defines a standard contrast curve, the Grayscale Standard Display Function, against which different types of display and hardcopy output devices can be calibrated. It thus supports hardcopy, softcopy and mixed environments.', '2007-06-27 18:39:09.073593+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (32, 'XDS-I', 'Cross-enterprise Document Sharing for Imaging', 'The Cross-enterprise Document Sharing for Imaging (XDS-I) Integration Profile specifies actors and transactions that allow users to share imaging information across enterprises. This profile depends on the IHE IT-Infrastructure Cross-Enterprise Document Sharing (XDS) profile. XDS for Imaging (XDS-I) defines the information to be shared such as sets of DICOM instances (including images, evidence documents, and presentation states), diagnostic imaging reports provided in a ready-for-display.', '2007-06-27 18:39:09.074488+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (33, 'XDS-MS', 'Cross-Enterprise Sharing of Medical Summaries', 'a mechanism to automate the sharing process between care providers of Medical Summaries, a class of clinical documents that contain the most relevant portions of information about the patient intended for a specific provider or a broad range of potential providers in different settings. Medical Summaries are commonly created and consumed by electronic medical record systems at points in time of transfers of care such as referrals or discharge.', '2007-06-27 18:39:09.075506+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (34, 'CT', 'Consistent Time', 'Consistent Time Profile defines mechanisms to synchronize the time base between multiple actors and computers.  Various infrastructure, security, and acquisition profiles require use of a consistent time base on multiple computers.  The Consistent Time Profile provides median synchronization error of less than 1 second.  Configuration options can provide better synchronization. The Consistent Time profile specifies the use of the Network Time Protocol (NTP) defined in RFC 1305.', '2007-06-27 18:39:09.076666+02', NULL, 3);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (35, 'ATNA', 'Audit Trail and Node Authentication ', '<p>The ITI Audit Trail and Node Authentication (ATNA) Profile establishes the characteristics of a Basic Secure Node: </p><ol> <li> 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. </li> <li>It defines basic security requirements for the communications of the node using TLS or equivalent functionality. </li> <li>It defines basic auditing requirements for the node </li> </ol> <p>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. </p> <p>This profile is based upon the Basic Security Profile written by the IHE Radiology committee, and has been extended to incorporate options that are needed by other disciplines. It incorporates a transition strategy so that implementations based on the older IHE Technical Framework will operate properly in this new profile.</p>', '2007-06-27 18:39:09.077671+02', NULL, 3);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (36, 'EUA', 'Enterprise User Authentication', 'Enterprise User Authentication (EUA) - Defines a means to establish one name per user that can then be used on all of the devices and software that participate in this integration profile. It greatly facilitates centralized user authentication management and provides users with the convenience and speed of a single sign-on. This profile leverages Kerberos (RFC 1510) and the HL7 CCOW standard (user subject).  User authentication is a necessary step for most application and data access operations and it is a workflow improvement for the users.  Future profiles will deal with other security issues, such as authorization management', '2007-06-27 18:39:09.078818+02', NULL, 3);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (37, 'XUA', 'Cross Enterprise User Authentication', 'provides user identity in transactions that cross enterprise boundaries, specifically the XDS profile that creates an Affinity Domain. When transactions cross enterprise boundaries the mechanisms found in the EUA and PWP profile are insufficient and often nonfunctional. Enterprises may choose to have their own user directory and their own unique method of authenticating. To provide accountability in these cross enterprise transactions there is a need to identify the requesting user in a way that the receiver can make access decisions and proper audit entries.', '2007-06-27 18:39:09.079713+02', NULL, 3);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (38, 'SEC', 'Basic Security', 'The Basic Security Integration Profile establishes basic security measures that can, as part of an institution s overall security policies and procedures in the enterprise, help protect the confidentiality of patient information. It also provides institutions with a mechanism to consolidate audit trail events on user activity across several systems interconnected in a secure manner.', '2007-06-27 18:39:09.08062+02', NULL, 3);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (39, 'PIX', 'Patient Identifier Cross-referencing for MPI', 'The PIX profile supports the Cross-referencing of patient identifiers from multiple Patient Identification Domains. These Cross-referenced patient identifiers can then be used by "identity consumer" systems to correlate information about a single patient from sources that "know" the patient by different identifiers. This allows a Clinician to have more complete view of the patient information.', '2007-06-27 18:39:09.081513+02', NULL, 2);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (40, 'PDQ', 'Patient Demographics Query', 'This profile provides ways for multiple distributed applications to query a central patient information server for a list of patients, based on user-defined search criteria. Patient demographics data can be entered directly into the application from which the user is querying by picking the appropriate record from a list of possible matches (called here a patient pick list).', '2007-06-27 18:39:09.082455+02', NULL, 2);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (41, 'PSA', 'Patient Synchronized Application ', 'Patient Synchronized Applications supports viewing data for a single patient among otherwise independent and unlinked applications on a user s workstation.  Its implementation reduces the repetitive tasks of selecting the same patient in multiple applications.  It also improves patient safety by reducing the chance of medical errors caused by viewing the wrong patient s data.  Its ability to work with the Patient Identifier Cross-referencing for MPI - provides a seamless environment both for the clinician and the IT staff.   This profile leverages the HL7 CCOW standard specifically for patient subject context management.', '2007-06-27 18:39:09.08334+02', NULL, 2);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (42, 'PAM', 'Patient Administration Management', 'The Patient Administration Management Integration Profile establishes the continuity and integrity of patient data, and additional information such as related persons (primary caregiver, guarantor, next of kinu2026). It coordinates the exchange of patient registration and update information among systems that need to be able to provide current information regarding a patientu2019s encounter status and location. This profile supports ambulatory and acute care use cases including patient identity feed, admission and discharge, and transfer and encounter management, as well as explicit and precise error reporting and application acknowledgment.', '2007-06-27 18:39:09.084263+02', NULL, 2);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (43, 'FUS', 'Image Fusion', 'The Image Fusion Integration Profile specifies communications between systems creating and registering image sets and systems displaying fused images. It defines how DICOM objects for spatial registration, blended presentation and the images themselves are created, stored, queried, retrieved, processed and displayed', '2007-06-27 18:39:09.085155+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (44, 'IRWF', 'Import Reconciliation Workflow', 'The Import Reconciliation Workflow Integration Profile (IRWF) specifies how data Importers obtain local demographics, coerce patient and procedure attribute values in the imported data and report press/status of the importation process. The Profile complements the Scheduled Workflow Profile by using the existing workflow mechanisms for notification and storage of imported Evidence Objects.', '2007-06-27 18:39:09.086015+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (45, 'MAMMO', 'Mammography Image', 'The Mammography Image Profile specifies how DICOM Mammography images and evidence objects are created, exchanged and used. It describes how Acquisition Modalities transfer Full Field Digital Mammography (FFDM) Images, how CAD system as as Evidence Creators, and how Image Displays should retrieve and make use of images and CAD results. It defines the basic display capabilities Image Displays are expected to provide, and which attributes should be used to implement those capabilities.', '2007-06-27 18:39:09.086909+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (47, 'STRESS', 'Stress Testing Workflow', 'The Stress Testing Workflow Profile provides the mechanism for ordering and collecting multi-modality data during diagnostic Stress testing procedures.', '2007-06-27 18:39:09.088868+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (48, 'XDM', 'Cross-Enterprise Document Media Interchange', 'Cross-Enterprise Document Media Interchange (XDM) provides document interchange using a common file and directory structure over several standard media. This permits the patient to use physical media to carry medical documents. This also permits the use of person-to-person email to convey medical documents.', '2007-06-27 18:39:09.089747+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (49, 'XDR', 'Cross-Enterprise Document Reliable Interchange', 'Cross-Enterprise Document Reliable Interchange (XDR) provides document interchange using a reliable messaging system. This permits direct document interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure such as XDS.', '2007-06-27 18:39:09.090634+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (50, 'XDS-SD', 'Cross-Enterprise Document Sharing of Scanned Documents', 'XDS-SD defines how to couple legacy information, represented within a structured HL7 CDA R2 header, with a PDF or plaintext formatted document containing clinical information. Furthermore, this profile defines elements of the CDA R2 header necessary to minimally annotate these documents.', '2007-06-27 18:39:09.091486+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (51, 'XD-Star', 'XDM, XDR, XDS', 'XD-Star is a virtual profile that represents one of XDM, XDR, XDS. You cannot register for XD-Star, but will register for one or more of XDM, XDR, XDS', '2007-06-27 18:39:09.092475+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (52, 'BPPC', 'Basic Patient Privacy Consents', 'provides a mechanism by which an affinity domain can create a basic vocabulary of codes that identify affinity domain privacy consent policies with respect to information sharing', '2007-06-27 18:39:09.09353+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (53, 'EDR', 'Emergency Department Referral', 'This profile may be used to cover a wide variety of ED referral situations, for example, primary care provider to ED Referral, Long term care to ED referral, or even ED to ED referral (as in the case of transfer from a level 2 Critical care facility to a level 1 facility).', '2007-06-27 18:39:09.094462+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (54, 'PPHP', 'Preprecedural History and Physical', 'Patient Care Coordination relating to same day procedures or ambulatory procedures that require anesthesia generates an extensive collection of data that must be available prior to the procedure to evaluate and / or ameliorate risk', '2007-06-27 18:39:09.095312+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (55, 'XPHR', 'Exchange of Personal Health Record Content', 'The Exchange of Personal Health Record Content (XPHR) integration profile describes the content and format of summary information extracted from a PHR system used by a patient for import into healthcare provider information systems, and visa versa.  The purpose of this profile is to support interoperability between PHR systems used by patients and the information systems used by healthcare providers.', '2007-06-27 18:39:09.096159+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (56, 'DEC', 'Device Enterprise Communication', 'The Device Enterprise Communication Integration Profile supports communication of vendor independent, multi-modality Patient Care Device data to Enterprise Applications using consistent semantics. It accomplishes this by mapping of PCD data from proprietary syntax and semantics into a single syntactic and semantic representation for communication to the enterprise The PCD data is time stamped with a consistent enterprise time.', '2007-06-27 18:39:09.097007+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (57, 'XD-Lab', 'Sharing Lab Report', 'The Sharing Lab Report content integration profile is focussed on the sharing of sets of laboratory results in the form of a laboratory report structured document.', '2007-06-27 18:39:09.097876+02', NULL, 1);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (58, 'EYECARE', 'Eye Care Workflow', '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.', '2007-06-27 18:39:09.098773+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (59, 'EYE-CHG', 'Eye Care Charge Posting', 'The Charge Posting Integration Profile describes mechanisms to transfer charge information to the clinic or enterprise Charge Processing System.', '2007-06-27 18:39:09.099646+02', NULL, 4);
INSERT INTO integration_profile (id, keyword, name, description, last_changed, last_modifier_id, integration_profile_type_id) VALUES (60, 'ECED', 'Eye Care Evidence Documents', 'The Eye Care Evidence Documents Profile defines information such as observations, measurements, and results (i.e., evidence documents), to be output by devices, such as acquisition systems and other workstations; to be stored and managed by archival systems; and to be retrieved and presented or used by display and reporting systems.', '2007-06-27 18:39:09.100487+02', NULL, 4);


--
-- PostgreSQL database dump complete
--

