Technical challenges related to implementation of a formula one real time data acquisition and analysis system in a paediatric intensive care unit

Vital physiological parameters are recorded from each patient in critical care with the help of sensors attached to the patient and viewed on Philips bedside monitors MP30 [6], a computational device which collects information from different biosensors as electrical currents and converts them into clinically relevant data such as waveform data (for example ECG, PPG) and vital signs (for example heart rate, respiration rate, oxygen saturation). The data from the bedside monitors is transferred to a Philips IntelliVue Information Centre (IIC) iX, central station where the data from all the beds can be viewed simultaneously.

The limitations of the current system include

This study was part of Young Lives project conducted in Birmingham Children’s Hospital National Health Service Foundation Trust (BCH NHSFT) PIC between May 2011 and April 2014. As there are limited real time platforms for capturing continuous physiologic data in critical care, we took the unique and novel approach of partnering with McLaren Electronic Systems, Woking, UK [7] to translate their expertise used to continually monitor and analyse the data from F1 racing cars in real time into a similar system adapted to the needs of the intensive care environment.

Ethical approval was awarded for ‘opt out’ consent by the Local Research Ethics Committee (LREC, West Midlands—South Birmingham Research Ethics Committee) [8], LREC reference number 11/H1202/13. Parents/carers of the patients were informed about the study by research nurses and requested for consent. As the data was recorded in real time from the time of admission to PICU, the data of patients who opted out was deleted from the database and was not utilised in the study.

The project involved the installation of real-time data recording software, ATLAS from McLaren Electronics Systems [7] on a virtual data server on the BCH computer network. The parameter data recorded by the bedside monitors, Philips MP30 was transferred to the Server in real time. The data is stored in Microsoft SQL database through the SQL Race. SQL Race is the interface software that transfers data to the database from external systems, includes pointers to the data and transfers data (segments requested by the user) to a Graphical User Interface (GUI) that can be used to view the data. Additional data analytics software implementing automated early warning scores, machine learning and nonlinear signal processing algorithms using MATLAB 8.5 [9] was provided as an interface between the data collection system and the clinician interface to the data system by Aston University.

The database is a collection of physiological data from three different sub systems as explained below and shown in Fig. 1.

Figure 3 shows an example of how the vital signs of a patient, who experienced a cardiac arrest, can be exported into different formats and plotted for post-incidental analysis by clinicians. This cardiac arrest was listed as unpredictable because the bed-side monitors display the latest 20 s of waveform data (ECG, PPG) and the current values of the vital signs. From the figure it can be seen that there are significant deteriorating trends in the vital signs leading up to the cardiac arrest. Real time visualisation of these trends if enabled could provide advance notification of deterioration to the attending clinicians. This could result in time critical intervention and stabilisation of the patient leading to possible better outcomes for the patient.

The work processes in an established PIC are complex and fluid and, the information systems in some cases outdated. Introducing any new technology will entail disrupting routine clinical care and therefore requires extensive planning and a multi-department level integration. One of the main reasons for the failure of expert systems in clinical environments includes poor execution plan of the expert systems [5].

The system implemented in this project consisted of two individual PCs, one representing the Philips central station (with data displayed on a monitor and keyboard to input data) and the other containing the ATLAS software (a CPU with no input/output devices connected).

As this was the first of its kind system to be implemented, dependence on the vendor’s knowledge and experience in the implementation of the system was high however the vendor’s lack of knowledge of the organisational structure of a PICU/hospital proved to be a major challenge. The system was initiated and tested for connectivity for a period of 6 weeks before patients were consented for the use of their data. The data of patients recorded during this period was deleted. Various functionalities of the system including installation of the ATLAS, clinical data authentication, protocol for automated anonymisation of the data files on the server, modifying the export formats of the data files to suit clinical requirements (which were different from those used during F1) were tested during this period. This testing did not however flag up the various issues encountered during the project. This could be because the system was not running continuously but was switched on and off during this period.

Figure 4 shows the roles and responsibilities of the various individuals and teams involved in the study. The devices and information systems in the PICU were managed by different organisations (external) and departments within the hospital. Sensors were bought from different manufacturers. Philips Healthcare provided the bed-side monitors which recorded the patient’s vital signs and physiological data and the central server for collation of data from all bed-side monitors. Medical devices were tested and serviced by the medical physics department of the hospital; bed-side monitors and the central server were installed and serviced by Philips; databases containing patient information were maintained by the hospital Data Informatics department whilst the physical computer systems including computer networks both wired and wireless were maintained by the hospital IT department.

The first step at initiation of the project was interfacing with the Philips central station. This required clarification of the structure and roles of individuals within the medical physics, IT and data informatics departments of the hospital. A key delay was caused when the communication between the two systems, the Philips central station and the ATLAS was to be initiated. The communication port address of the central station was known only to Philips while the IP address of the central station was known only to the server specialists in IT and not the front line support of the IT department. Connectivity was achieved after multiple communications.

Two major causes for the data loss when the system was fully operational are discussed in detail. The SQL Race database application was built using the Microsoft SQL Server File Stream technology. This technology did not support too many files (limit of 300,000) in the file stream folder. The SQL Race application was built to record data from a single car for one hour from more than 100 sensors however this application was used to record data from 28 beds continuously 24 × 7. The size of the data recorded in a 24 h period ranged between 20 and 50 MB, this data was analysed continuously using specialist data analysis software and the results of the analysis were also stored with the data. Database overload occurred every 3–4 weeks leading to server crash. Though a permanent solution could not be implemented during the life of the project, temporary measures such as creating new databases after every crash were implemented.

PICU, BCH assigns a unique numeric ID to every patient admitted for administrative purposes. The numeric ID is of 8 digits length starting with the year followed by a four digit number. For example the first patient admitted to PICU in the year 2017 is labelled as 20170001. This number is different to the patient’s NHS and Hospital number. Patients transferred to the PICU need immediate and urgent care. This resulted in the admission process and the patient being allotted a PICU number being carried out a few hours after the actual admission. In the case of patients who were admitted after 5 pm, there would sometimes be a delay of 24 h from admission for the patient to be allotted a PICU number. As the database was maintained by external industry partners, LREC permission for data recording included the anonymisation of patient data to ensure patient privacy and confidentiality. It was agreed to use the PICU number to tag the patient data as knowledge of the PICU number does not provide additional details such as name, age, address or any other details. The probability of identifying the patient with the help of the PICU number is extremely small as the records that relate the PICU number to the NHS number were not accessible to non-PICU staff. Secondly the industry partners did not have permission to upload or download any file to/from the project server; permission to modify the files on the server was restricted to the IT staff in BCH. The PICU number was entered on the bed-side monitor once allocated and the data session would be recorded with this identifier. The data of a patient from the time of admission to PICU until they were allotted a PICU number was therefore recorded as an unknown data session. It is also common practise to move patients across beds based on emerging clinical needs such as access needed by multiple clinical teams. The sessions had to be renamed using identifiers such as bed numbers and other patient details but in some cases this was not possible as the patient had moved beds before the PICU number was assigned. Also the sheer volume of admissions and discharges did not permit the identification of all the sessions. Only the data sessions of patients who had experienced a cardiac or respiratory arrest were re-identified. Almost 20% of the patient data recorded was therefore recorded as anonymous.

There were other standard maintenance protocols which caused disruption to the data collection phase. The cause of some of the problems could not be understood immediately. They are as shown in Table 1.

With the experience gained during the implementation of our clinical information system, we have learnt that implementing new clinical systems needs a multidisciplinary project team consisting of clinical, IT (server specialists), medical physics, software engineers and data analysts. IT staff, especially those with expertise in computer networks and servers, should be included in the planning, design, selection, assessment and revamping of the computing systems. Different aspects of planning included:

Practical:

Risk assessment:

Within team communication and dissemination:

Data was collected on the number of patients screened and consented. Ethical approval was awarded for ‘opt out’ consent and parents were approached by research or bedside nurses and informed about the study.

Table 2 provides information about the number of patients admitted and recruited to the study. The ‘Opt out’ consent yielded a high number of recruits. The 10% of cases not recruited were from high turnover patients and non-English speaking parents which led to the inability to document that families had been given information about opting out. Only 8 families declined to participate because they did not want to participate in a research activity.

Figure 5 shows the number of admissions and the number of recruits per year of age. It can be seen that the recruitment rate to the study was not dependent on age and is nearly equal across all the different ages. We compared the patterns of recruitment for the different age groups for the cohort of patients admitted to the PICU using the χ² statistic and found that the recruitment rate was not dependent on the age of the patient (p = 0.65).

Figure 6 shows the length of stay (days, black dot) of each patient recruited to the study and the physiological data recorded for that patient in terms of days in grey in decreasing order of length of stay. Due to the large number of recruits to the study, a zoomed in version of the plot for a random group of patients whose length of stay was less than 20 days has been included. It can be seen that some of the patients’ data was lost. While the length of the data recorded is less compared to the length of the stay for most of the patients, some of the patients had more data recorded compared to the length of the stay. This anomaly was due to the incorrect admission and discharge dates and times recorded and as the consent was opt-out, the patients’ data was recorded prior to the consent and hence this error could not identified or corrected.

Table 3 shows the number of recorded and unidentified data records and the number of high rate data records in terms of sessions. Each session represents the data for a patient for approximately 12 continuous hours. The total size of the data recorded over the 3 years of the project duration is ~29 GB. This included only the parametric data sampled at 0.2 Hz from 22 beds for 3 years, parametric data from eight beds for one year and waveform data sampled at 125 Hz from two beds for 2.5 years.