The technical requirements are summarized in Table 1.

Basic requirements:

• 1)

  The CIS must be able to interact with other hospital information systems using an HL7 protocol. In this sense it is advisable for the HL7 version to be 2.4 or higher.

Optional requirements:

• 1)

  Compliance with the Integrating the Healthcare Enterprise standards (IHE, http://www.ihe.net/), with conversion to Connectathon, with a positive evaluation. The Connectathon is a periodic meeting held to test and certify the integration characteristics of different products and devices with respect to the standards advocated by the IHE.

• 2)

  It also would be advisable for the CIS to be able to adapt to the Clinical Document Architecture standard (CDA, http://hl7book.net/index.php?title=CDA) in the generation of documents and reports.

• 3)

  Possibility of parameterizing the HL7 messages to adapt them for connection to other systems using different subversions or parameter specifications.

• 4)

  Possibility of automatically generating summaries of configurable data (minimum basic data set (MBDS), indicators, etc.) in XML format that can be sent via web or e-mail to centralized registries for benchmarking, quality control, SEMICYUC statistics, etc.

Basic requirements:

• 1)

  Integration engine (proprietary or configurable), allowing the introduction of new connections with other systems in a flexible manner, using a well defined communication protocol available for those in charge of conducting future integrations. This integration engine must be included in the technical support.

Optional requirements:

• 1)

  Integration engine allowing input and output connections via HL7 and XML in a configurable manner.

Basic requirements:

• 1)

  The architecture, whether client-server or web, must allow utilization of the system from all the work areas, and the analysis of data as required.

• 2)

  Statistical data exploitation must be possible in parallel to normal operation of the application, without data loss of any kind over time. Under no circumstance or condition can the manufacturer cease to afford access to all the stored patient data.

Optional requirements:

It would be advisable for the system to allow its integration within a service-oriented architecture, as either producer or consumer.

It also would be advisable for the system to allow transparent access to other Department or general applications without requiring repeat password entry.

Basic requirements:

• 1)

  The manufacturer must offer clear specification of the independent functional modules conforming the program (both basic and optional), their dependencies and the expected frequency of revision and upgrading.

Basic requirements:

• 1)

  The manufacturer must clearly specify the procedure for notifying the availability of new version, the economical conditions for the upgrading of versions, the procedure to be followed for upgrading, the approximate upgrading time, and its impact upon functioning of the system.

Optional requirements:

• 1)

  It would be advisable for the product to have a major version upgrading frequency of at least once in every two years.

• 2)

  User access to improvement plans and new functional options of the manufacturer shall be made easy.

• 3)

  The upgrading process must be accompanied by new formation if new functional options are introduced, or if there are modifications in the use of the existing functions.

Basic requirements:

• 1)

  The conditions of maintenance must be clearly specified in the contract, and it must be possible to establish paid agreement for a sufficiently rapid response or reaction time to guarantee the continued operability of the system.

• 2)

  The manufacturer must collaborate with the Informatics Department of the center to facilitate maintenance, the execution of easily configurable backup copies at regular intervals (in all cases to be established by each hospital), and integration of the system with other Department or general applications.

• 3)

  The manufacturer will provide permanent advisory service for the clinical administrator or administrators of the CIS.

Basic requirements:

• 1)

  Acquisition of the system entails the obligation of the supplier to provide sufficient training for all users of the system, in order to allow correct handling of all the functions required in their daily working activities.

• 2)

  The training period must be established in the contract.

• 3)

  Training must cover both the functions of the CIS and the configuration and parameterization of the system.

Optional requirements:

Periodic upgrading courses imparted by the manufacturer.

Basic requirements:

• 1)

  A malfunction response protocol must be available, allowing posterior full recovery of the system and of the previous data, as well as posterior inclusion of the data generated during the malfunction period or interval.

• 2)

  It must be possible to correct erroneous data and introduce previous data, keeping a complete registry of the changes in all cases, in abidance with the current legal guidelines in this field (Spanish Data Protection Act).

Optional requirements:

• 1)

  It must be possible to re-send and receive the messages produced during the malfunction period, from and to other systems of the Department and center: monitorization, interfaces with other devices (respirators, pumps), laboratory, hospital information system (HIS), etc.

• 2)

  After web malfunction, the system must allow continued visualization of the information of a given patient through local memory caches or web and server redundancy architecture, as well as local storage of the information generated in the client, in order to allow its transmission once system function has been restored.

Basic requirements:

• 1)

  The system response time must be sufficiently short to not interrupt the normal user working rhythm. This implies immediate system response, or a delay of no more than a few seconds in the case of more complex tasks.

• 2)

  The hospital will guarantee that the available hardware in clients and servers, and the web capacity, are sufficient for ensuring correct system operation to meet the above mentioned specification.

• 3)

  The hospital also will ensure that the bandwidth is sufficient.

• 4)

  The administrative and maintenance activities within the system should not slow it down excessively.

Optional requirements:

It would be advisable to use mirror, cluster or load balanced servers, virtualization or other server enhancement mechanisms and client equipment to guarantee security and efficiency in the functioning of the system.

Basic requirements:

• 1)

  The patient data storage capacity must be sufficient to avoid losses as time elapses following patient discharge. The clinical information stored in the CIS database must be available for at least five years after the last patient visit or admission, as specified by the Data Protection Act.

• 2)

  It must be possible to recover the information on previously discharged patients to incorporate or at least visualize the data during a new admission.

Optional requirements:

Possibility of importing data from other previous applications in the case of a change in product.

The incorporation of a CIS to an ICU is a complex process requiring close collaboration between the technical team of the supplier of the system and the team assigned by the Unit and hospital for managing the system. Different factors intervene in this process, as specified in Table 2.

The time needed to incorporate the CIS depends on its complexity and on the integrations required. It is advisable to follow the recommendations of the supplier in this sense.

• a)

  It is advisable to assign a project director in charge of integration of the CIS within the ICU. The project director will be a technician of the company supplying the CIS, or a qualified person designated by the hospital, and will be accompanied and advised by the necessary technicians to ensure full incorporation of the system in accordance to the purchased products.

• b)

  On the part of the hospital, it is advisable to designate a project team composed of a technical supervisor and a clinical supervisor: the former will be in charge of the technical aspects of the project, while the latter will supervise the clinical configuration of the product. Both supervisors in turn will be assisted by the opportune hospital professionals. It is advisable for the clinical supervisor to have the support of physicians and nurses willing to lead implantation of the CIS in the Unit and to keep it up to date from the clinical perspective. It is strongly recommendable for the professionals participating in implantation of the CIS to have the necessary time to carry out their assigned duties, freeing them fully or in part from those healthcare activities which they may have during the system introduction period.

Starting phase. Before acquiring or installing a CIS, it is essential to analyze its bidirectional operativeness with other hospital systems–fundamentally the HIS, or specific Department applications (pharmacy, laboratory, radiology, etc.), defining the components needed to cover these activities (both hardware and software).

Development phase. The supplier will install the acquired product or products, and will be in charge of integrating them with other applications and connections to the different medical devices as agreed. The development phase comprises modification of the standard configuration and the hospital-specific modifications of tables and files that will guide functioning of the application. The project team of the hospital will construct the application with the counseling and the training afforded by the project team of the supplying company.

Test phase. During this phase, tests will be made of the established integrations, connections with devices, and all the clinical configurations. Those points that fail to operate as expected or for which new changes are suggested must be corrected or incorporated in this phase. Posteriorly, training of all ICU personnel will start, under the supervision of the previously trained clinical team.

Activation phase. After having checked the entire system (components, integration and parallel validation), and having trained its users, the decision relating to activation or non-activation will be taken jointly by the supplier and the hospital. It is advisable for the start of activity with the CIS to be simultaneous to cessation of activity in paper format.

Maintenance phase. Once the CIS is operational, the technical and clinical teams of the hospital will supervise clinical maintenance of the application, modifying the templates and the configuration as required. It is advisable for the DICM to have at least one physician and a nurse to listen to the user suggestions and propose changes in the configuration accordingly.

Clinical information system upgrades. The application upgrades will be programmed in terms of time and resources by the hospital and the supplier in such a way as to ensure minimum interruption of clinical practice. In this phase it becomes more necessary to have a test system in order to evaluate the upgrades before introducing them to clinical activity.

Once the technical and training requirements for installing the CIS have been reviewed, the fundamental or core part of its functioning is addressed. This refers to the functional or operative standards allowing the essential clinical work which the system must be able to cover quickly and reliably. In our opinion, the requirements included under this point are the most important, since they speak of the current basic mission of these applications.

In order to describe the standards in a logical and orderly manner, we have used the criterion of following the basic patient work flow from admission to discharge. Each of these steps comprises a group of specific requirements which are detailed in Tables 3 and 4.

The areas covered are the following:

• 1.

  Patient data.

• 2.

  Creation of the admission report and planning.

• 3.

  Prescription.

• 4.

  Connection to monitorization systems.

• 5.

  Modeling of patient course. Specific techniques and care.

• 6.

  Scales, reports and coding.

Basic requirements:

• 1)

  Patient demographic data (first and last names, birth date, sex, address, telephone number, history number, admission number) acquired via direct importing of the HIS through ADT.

• 2)

  Importing of allergies.

Optional requirements:

• 1)

  Clinical history: importing of the most relevant patient history data to avoid duplications of the information contained in the HIS.

• 2)

  Nursing diagnoses (NANDA) and planning of care through interventions (NIC or Nursing Interventions Classification) and nursing objectives (NOC or Nursing Outcomes Classification).

• 3)

  Integration, or rapid access to laboratory test and radiology results.

• 4)

  Drugs received in the ward prior to admission to the ICU, via XML or HL7, specifying drug substance, dose, timing and start (ideally).

• 5)

  It must be possible to incorporate data corresponding to a previous and recent admission to the ICU, particularly when the patient has not abandoned the hospital.

Basic requirements:

Tool for preparing admission reports. This tool must be able to generate texts in different formats and allow the use of macros, abbreviations or other elements assisting in writing. This function must be simple to use for the clinical administrators. In some cases, it may be replaced or complemented by the reporting tools of the HIS.

Optional requirements:

Daily objectives sheet.

Basic requirements:

• 1)

  Monitors: ideally, it should be possible to capture all the monitoring signals which the device can register through all its channels.

• 2)

  Ventilators: capture of all the information allowed by the communication protocol and data output of each apparatus.

• 3)

  Cardiac output monitors.

• 4)

  Perfusion pumps: drip rate.

Optional requirements:

• 1)

  Perfusion pumps: importing of drug libraries, accumulated volumes and doses.

• 2)

  Connection to extrarenal filtration machines.

• 3)

  Bar code reading systems.

• 4)

  Discrimination, based on pre-established rules, of possible anomalous data attributable to monitoring device error or to actual patient measured values.

• 5)

  Alerts and alarms corresponding to these deviations for checking and correction, as required.

The requirements of these sections are summarized in Table 5.

Basic requirements:

• 1)

  Any CIS installed in a DICM must be equipped with a tool for conducting searches and analyses of the data registered in the system.

• 2)

  If this tool does not come with the CIS package, the supplier may offer the task of data processing through an external application, provided it has been validated for the system and installed by the supplier.

• 3)

  With these tools, the CIS will elaborate reports on the variables conforming the Unit control panel. In addition, searches will be made for investigational studies or activity reports of certain user groups.

Optional requirements:

• 1)

  The CIS will generate statistical reports on relevant indicators and events in the activity of the ICU.

• 2)

  Storage, exploitation and data processing in Data Warehouse type databases, either proprietary or integrated in the HIS, and to which the CIS conveys the information. This database is defined by the following characteristics:

  • a)

    Topic oriented. The information is organized in such a way that the data relating to one same event or object in the real world (e.g., a clinical indicator) are inter-joined.

  • b)

    Variable over time. The time changes in the data are registered with a view to reflect these variations in future reports.

  • c)

    Non-volatility. The data are neither modified nor eliminated; once information has been stored, it becomes read-only information and is retained for future consultations.

  • d)

    Integrated. The database comprises all the data entered in the CIS for each patient, whether imported (demographic, MBDS, monitorization) or manually entered (codes, scales, techniques). The Data Warehouse of the CIS can inter-relate with the database (Data Warehouse or otherwise) of the HIS for specific consultation on cost or other issues.

  The advantages of databases of this kind are better and easier access to the data by the end users, an important help in the taking of decisions, based on consistent and integrated information on pilot indicators, and the identification of occult relations and trends among data with a view to developing clinical or management hypotheses allowing the understanding of past errors and future predictions according to the scenario involved. Their main disadvantage is high cost, though adequate exploitation and design can secure an important investment return.

• 3)

  As support to clinical management, with this or some other type of database, the following capacities must be available:

  • i.

    Extraction of the relevant information, data transformation and filtering.

  • ii.

    Data storage in raw and aggregated form for exploitation.

  • iii.

    Generation of the data model best suited to the desired exploitation, and which should be previously defined and implanted.

  • iv.

    Elaboration and presentation of the information in the form of control panels containing tables, indicators and graphic representations offering key aspects of the system considered globally, with the definition of alerts, and based on a navigable structure.

  • v.

    Generation of the statistics required for activity follow-up.

  • vi.

    Extrapolation of data and identification of incidents.