e-Health applications, in our case Clinical Information Systems (CIS) or Patient Data Management Systems (PDMS), are taking medicine by storm, and intensive care is not an exception. Ensuring delivery of safe, cost-effective, high-quality care in the most expensive hospital beds, has been the major underpinning. Countries with higher GDP tend to have most installations, penetration being less in smaller, poorer countries. The impact of CIS use on patients’ outcome (Prgomet et al. 2017), LOS (Levesque et al. 2015) and hospital costs has been examined and somewhat documented in several studies, though a recent meta-analysis (Thompson et al. 2015) disputed the evidence, admittedly not yet enough to support firm, generalisable conclusions. Several factors may contribute to this variability: the complex nature of multiple processes of ICU care a CIS aims to organise, different ICU population and case mix, lack of standardisation of CIS minimum functionality and usability specifications, the inherent difficulty to comparatively assess users’ compliance, etc.
To design, procure, test, parameterise, implement and maintain a Clinical Information System for an intensive care unit is a quite complicated project. It not only requires a sizable budget (probably 25.000 – 60.000 K Euros/bed, depending on the country and specifications), but it involves substantial managerial and leadership skills as well as wide -eventually- “bottom-up” acceptance and users’ active adoption. Most importantly, it constitutes a substantial change in the way the team delivers care, though at the same time the system should be “adapted” and “customised” to fit local health-care professionals’ and patients’ needs. This fine balance to be kept is not trivial and should be reflected in the outline of specifications as well as the parametrisation and implementation plan. CIS/PDMS is not another equipment piece to buy. It is a project with an open-end life cycle that is to be designed, implemented and maintained with constant improvement/parameterisation. We have deliberately left cybersecurity issues and GDPR compliance as well as IPRs out of the scope of this article as we will come back soon with a practical guide on how to deal with these important issues.
Below we describe 7 essential steps towards this direction:
STEP 1: Define the project extension – Local? Cluster ICUs? ICU purposed solution OR part of a Hospital Information System (HIS)?
The decision to procure the installation of a CIS/PDMS in an ICU in a hospital either refers to an isolated installation or might include other/all ICUs of the same hospital, or even ICUs in other hospitals residing in the same area or other areas in the country. The decision is often beyond the reach of clinicians -even of senior clinicians- as it may bear political and economic dimensions that are part of or might affect general governmental/regional health authorities’ policies. In the case of more than one installation within the same tender, measures should be taken, and mechanisms should be set in order to involve all clinical teams in the decision-making process, accommodating their concerns and needs to the extent possible. In either case, structured interaction between ICUs within the same hospital/different hospitals is strongly encouraged and the technological solutions to facilitate such interactions exist in the market and should be incorporated into the product specifications, even if the ICUs involved have different CIS/PDMS vendors. Despite being in the context of this interaction, ICU tele-medicine systems are beyond the scope of this article and shall be offered in one of the next issues of ICU Management & Practice.
In another note, ICU purposed CIS/PDMS are now increasingly being substituted with modules of more generic Hospital Information Systems, claiming better integration, interoperability and cost control. This trend fired serious controversy since it frequently doesn’t engage users from ICUs in a meaningful way and customisation process has been poor that ends to poor usability, an inherent problem of those systems (von Dincklage et al. 2017). On the other hand, we must admit, the arguments for an all-encompassing, integrated HIS are quite solid. An ICU senior practitioner who is asked her/his opinion should be very clear in terms of the required functionality but, in my opinion, should not fanatically insist to either option beforehand as what really matters is what is offered.
STEP 2: Explore initial “perceived” needs to formulate the outline of specifications - think big - include personnel/patients from the beginning and at all stages
When it comes to IT solutions, our generation’s perceived needs are poorly correlated with the capabilities of even commercially available systems. If right from the beginning the clinical team “undermines” its position by expressing minimal functionality requirements then the game will be gradually lost as the vendor will neither have the motivation to offer more functionality in a certain price range, nor will deploy the resources necessary to offer it. It is thus, of paramount importance to include the younger, “native” to the “technology land” generation, to the decision-making process, especially clinical routines re-design and specifications outline. We should rather think big, and we might subsequently downsize the required functionality and modify the specifications accordingly, as a function of cost and (careful, real!) technology restrictions. All companies have pre-set questionnaires to record pre-installation functionality and clinical routines as well as users’ demands and maturity in handling complex IT systems. An ICU team might want to give its own questionnaire based on local needs and philosophy of care. It is also very important to visit an installation site to discuss with fellow clinicians, nurses and AHPs regarding their experience, strengths, and weaknesses of the system installed.
Figure 1 and Figure 2 graphically display the basic functionality of a CIS in terms of data input, data output and the time dimension. Figure 1 - INPUT: Interface with patient’s monitoring systems (multi-parameter monitor, stand-alone monitors), ABG/POC testing devices and main therapeutic & organ support systems (ventilator, haemofiltration, ECMO etc), patient’s EHR, LIS (laboratories) and PACS (imaging, including POC US studies to be downloaded to PACS and accessed thereafter) as well as any OR/AED electronic records is considered as standard and should be included to the outline of specifications. OUTPUT: should include a health professional display with patient data visualised in numerical and graphical means and in an intuitive order to facilitate, spot diagnosis, decision making and follow up. Unit status panel should be provided for ICU management and should serve as a live report on the main statistics and important events/figures pertaining to ICU function, i.e. trends in mortality, morbidity, complications, organ failure, LOS, ventilator days, procedures, tech/other resources use per bed/area/ICU, etc. This could be provided by CIS/PDMS itself or data could be fed/processed in another programme, depending on local needs. The bottom-line is to allow for a meaningful and timely update of ICU management team regarding unfavourable/dangerous trends or isolated incidents. Including patients’ group(s) into the process might prove beneficial as it offers the added value of creating a “community” beyond users and administrators which could protect the process and extend its life-cycle.
STEP 3: Bring in expertise, set up an interdisciplinary team (IDT) (not MDT!) and create a community of “champions” & “super users”
An ICU (or hospital/healthcare authority) based interdisciplinary project governance team having regular (preferably open) meetings with publicly available agenda and minutes with action points and timelines is essential to allow for effective procurement. The presence and/or the structured input of physicians, nurses, physiotherapists/RTs, clinical dieticians, clinical pharmacists, health/clinical psychologists, health managers, etc should be sought. The coordinator/project manager should ensure meaningful interaction between them as the transition to a “multi-disciplinary” team is not favourable as it involves fragmentation of the processes and loss of global view and integrated approach. We would like to emphasise the role of an experienced health psychologist in the process as she/he would be able to identify important barriers to adoption and implementation of the system beforehand. This, in turn, could be translated into an action plan to include Ftf/group discussions, workshops, etc to overcome the barriers identified.
ICU professionals who are particularly skilled and oriented in IT applications could be proposed to participate more actively in the process of writing specifications, tendering, installing and operating the system, but mainly in facilitating implementation longitudinally by helping and encouraging their colleagues as well as safeguarding the system from misuse. Ideally, a CIS should have 2-4 health-professionals from the champions team (highly skilled and dedicated) who shall share a full-time equivalent system administrator role, particularly in the case of larger units with high patient turnover. The champions and super users will become invaluable when it comes to the implementation of early warning systems, a feature which requires mature users’ community to be implemented successfully and sustainably. The idea is to “infiltrate”- ideally - all shifts with one or two health professionals from the aforementioned group in order to cover 24/7.
STEP 4: Secure budget/cash flow and choose tender method
Securing funding necessary to conclude procurement, installation and ongoing, meaningful support is of crucial importance as this kind of project can easily “die” if procurement lasts for a long period of time. We should be reminded that this installation is usually composed by a conglomeration of software whose life cycle becomes progressively smaller. Additionally, the window of opportunity in relation to other installations in the hospital/area is usually narrow. Tendering method is usually determined by hospital/health authorities of the region or the central government. It is, however, of paramount importance for us - the healthcare professionals - to ensure that the tender process: a) incorporates qualitative assessment criteria and not only cost-related criteria; b) involves exhaustive testing of the proposed solution in demo conditions and – ideally - visiting an installation site before contract is signed; c) includes explicit clauses regarding downtime, emergency situations management etc; d) goes into detailed description of data presentation screens, analysis, reports and other services and products provided as devil is in the details; e) price for extra services, parameterisation, etc is provided in a way that costs could be pre-calculated and budgeted without major deviations, ideally from the beginning. Of course, use of the system will largely define the needs, but, a modular installation is always a solution in case the budget is not enough for an all-encompassing solution in the beginning.
Tender methodologies that allow hospital authorities to negotiate with vendors in a preliminary stage and competitively develop specifications are the most attractive when there is budget available for software/services developments beyond the commercially available solution package. It is, however, a time-consuming process, most suitable for larger establishments with many types of ICUs and complex needs.
STEP 5: Design a realistic project management plan (PMP)
Setting up a PMP is not a trivial task, and in the case of big installations, particularly at the hospital or health authority region level, a full-time professional project manager is required from the beginning and through all steps described here. This plan should be negotiated with all stakeholders in order to consider potentially conflicting (but also synergistic) activities pertaining to other ICUs/departments/hospitals as well as to ensure adequate staffing levels to allow for the extended periods of personnel training. Timelines and bilateral interdependencies of every phase of the project should be carefully considered, especially when interdependencies could potentially affect critical hospital processes like bidirectional patients’ flow towards and from operation theatres and A&E. In case a professional project manager is not available to coordinate the project and a health professional is to undertake this responsibility, handy project management manuals (telemedicine-momentum.eu/) and open-source/commercial software might be of help.
STEP 6: Set and follow up performance and outcome indices - usability
Setting performance indices and a system to follow them up, troubleshoot accordingly and inform the project/unit management and the IDT meetings, is of paramount importance as it allows for early interventions that can maximise success. Such indices may entail the functionality and failures of the system in general (hardware and software) as well as specific modules, the intra/inter-hospital interoperability of the system, the personnel behavior, patterns of use of the system (including time required for certain functions), inaccuracies and mistakes, misuse, etc. CIS “usability”(Lee et al. 2018) has been a major topic of dispute between the users’ community and the industry in the last years. Consequently, it sounds prudent to survey and record usability issues in an organised format. When observations lead to a robust and mature case, this should be moderated with the vendor either adapting the software functionality or adapting the non-clinical routine or both. When it comes to problems in serving clinical routines, customisation should be the primary responsibility of the vendor, and this should have been regulated in specs (see STEP 2 above). Clinical performance - outcome (ICU/hospital mortality, morbidity, complications, length-of-stay, ventilator-free days, sedation-free days, etc) is, of course, the holy grail of healthcare technology effectiveness. CIS gives a unique opportunity to follow these indices systematically.
STEP 7: Creating a life cycle for your CIS to serve the ICU “vertical” ecosystem
Following the STEPS described above (1-6) a life cycle (Figure 3) is created for the CIS rendered sustainable if and only if the community that lives in continues to follow a structured and timed sequence of (re)design, procurement, parameterisation, testing, and implementation. Let’s now zoom out to a bigger picture. Each ICU in the digital era grows its own ecosystem of IT applications serving diverse functions (clinical routine, education, and research) and stakeholders (healthcare professionals, patients/families, administrators) as it is schematically shown in Figure 4. CIS will not necessarily and directly serve all those needs; however, it should serve as a data hub that will enable these applications. We identify this ecosystem as “vertical” juxtaposed to the “horizontal” ecosystem that refers to the hospital and regional/national e-Health applications network. It is thus, of fundamental importance to foster interoperability at all levels.