Toward a Big Data Healthcare Analytics System: a Mathematical Modeling Perspective

Toward a Big Data Healthcare Analytics System: a Mathematical Modeling Perspective Hamzeh Khazaei IBM Research and Development Center Toronto,Canada Email: hamzehk@ca.ibm.com Carolyn McGregor, Mikael Eklund, Khalil El-Khatib, Anirudh Thommandram University of Ontario Institute of Technology Oshawa, Canada Emails: firstname.lastname@uoit.ca Abstract High speed physiological data produced by medical devices at intensive care units (ICUs) has all the characteristics of Big Data. The proper use and management of such data can promote the health and reduces mortality and disability rates of critical condition patients. The effective use of Big Data within ICUs has great potential to create new cloud-based health analytics solutions for disease prevention or earlier condition onset detection. The Artemis project aims to achieve the above goals in the area of neonatal intensive care units (NICU). In this paper, we proposed an analytical model for an extended version of Artemis system which is being deployed at SickKids hospital in Toronto. Using the proposed analytical model, we predict the amount of storage, memory and computation power required for Artemis. In addition, important performance metrics such as mean number of patients in the NICU, blocking probability and mean patient residence time for different configurations are obtained. Capacity planning and trade-off analysis would be more accurate and systematic by applying the proposed analytical model in this paper. Numerical results are obtained using real inputs acquired from a pilot deployment of the system at SickKids hospital. Keywords-realtime analytics; big data; analytical modeling; capacity planning; health informatics;. I. INTRODUCTION Premature birth, also known as Preterm birth, defined as birth before 37 weeks gestational age, has been identified as one of the most important perinatal health problems in industrialized nations. Neonatal Intensive Care Units (NICUs) internationally provide critical care for premature and ill term infants. Premature infants in NICUs can be as young as 23 weeks gestation [1]. The data generated by medical devices in neonatal intensive care is a Big Data problem. Vital organ monitoring together with ventilation support and nutrition or drug titration through smart infusion pumps all generate large volumes of data at high frequency. Electrocardiograms graphs can be generated based on 1000 readings a second. Heart rate, respiration rate and blood oxygen are displayed each second resulting in 86,400 each reading per day. A premature newborn infant s heart beats more than 7000 times an hour which is approximately 170,000 times a day. Yet, traditional charting protocols whether documented on paper or within an electronic health record enables the persistent storage of one value per hour of an indicative heart rate for that hour. A newborn infant s neurological function could also be monitored resulting in multiple waveforms each generating tens of millions of data points per patient per day. Drug and nutrition infusion data from smart infusion pumps can be more than 60 different fields provided every 10 seconds. Given that these infants can have more than 10 infusions concurrently, infusion can generate more than 1GB of drug infusion data from a single patient per day. High speed physiological data is an untouched resource in healthcare. Opportunities abound for significant medical discovery and quality improvement in healthcare that lead to improvements in productivity together with reduced mortality and disability rates through policy driven systemic adoption of Big Data approaches for neonatal intensive care. The effective use of Big Data within Neonatal Intensive Care has great potential to support a new wave of clinical discovery to enable the creation of new online health analytics approaches for disease prevention or earlier condition onset detection [2]. Recent research is building a strong case for the benefits of realtime data analysis, with clinical events such as late onset neonatal sepsis (LONS) [3], [4] exhibiting early warning signs in physiological data before the clinical impact is sufficient to exhibit current clinical detection indicators. However, that research takes a condition specific, patient specific or physiological data stream type specific approach. The translation of that knowledge is another black box clinical decision support system (CDSS) medical device at the bedside. Patients can develop multiple conditions concurrently or over time and each condition can have a set of behaviors with a pattern of occurrence [5]. Through our research we have proposed the Artemis platform which is a Big Data approach for online health analytics of high speed physiological data enriched with other clinical data as required. Artemis enables concurrent multi-patient, multi-stream and multi-diagnosis through temporal analysis to support realtime clinical decision support and clinical research [5], [6]. We have further proposed Artemis Cloud as an approach to provide Artemis as a

service through the cloud [6]. We have designed an expanded Artemis Cloud platform to service multiple healthcare facilities, however, we require an analytical model to enable capacity planning for the usage of such a platform. Analytical models within the context of Cloud based Big Data solutions is currently under researched area, especially within the context of its use in healthcare. In this paper we present a method to create an analytical model to enable more accurate estimation of storage and memory for the realtime online health analytics components and retrospective analytics components of our expanded Artemis Cloud. The model utilizes realistic patient population distribution based on gestation age characteristics and condition onset probabilities within those contexts. Both of these variables dictate the predicted length of stay for that infant. In this work we present the model within the context of an individual hospital and in future work we will present the multi-hospital model. II. RELATED WORK Three dominant themes exist when considering the related work for this research, namely: realtime patient monitoring, cloud computing in healthcare and performance analysis of cloud based solutions. The following three subsections address each of these areas. A. Realtime patient monitoring Historically, physiological stream monitoring of ICU patients has been provided by black box regulatory body approved medical devices located at the patients bedside. While there has been a growing body of biomedical engineering and clinical research over the past 20-30 years proposing newer approaches for advanced physiological stream monitoring they still predominantly have either a physiological stream, clinical condition or patient centric approach [7]. Zhang et al. [8] have discussed the implementation of a Health Data Stream Analytics System called the Anaesthetics Data Analyzer (ADA). The ADA has been developed to provide anesthetists with the ability to monitor and query trends in physiological signals data, a kind of stream data from the health care domain. A second body of research reports on the retrospective analysis of previously persistently stored physiological data through the determination and assessment of temporal abstraction based qualitative behaviors from the analysis of quantitative physiological data. However, again research is either physiological stream, clinical condition or patient centric. A structured approach for the translation of the knowledge gained from this research which is predominantly statistical and sometimes more recently data mining in nature has been lacking [7], [9]. B. Cloud computing in Healthcare Cloud computing enables the use of computing resources outside of the healthcare facility. A range of degrees of cloud computing are available [10] and are classified into four main areas, namely: Infrastructure-as-a-Service where a physical environment is outsourced and made available for use; Platform-as-a-Service where an information technology platform is provided upon which developers can create and deploy software applications; Software-as-a-Service enabling end users to utilize outsourced software to support the various operations of their businesses where their corporate data may or may not be persistently stored in a cloud based data store; and Data-as-a-Service where corporate data can be housed within a cloud computing environment. One approach to the Software-as-a-Service utilizes the Service Oriented Architecture (SOA) approach to software design where software services are made available to the cloud through a series of web services. Examples of early work showing the potential for the use of cloud computing in healthcare are emerging [11]; however these research efforts do not provide functional support to critical care. McGregor [12] proposes a functional set of web services to support critical care as part of her solution manager services as applied to healthcare; however aspects such as rule definition are not clearly defined within that functional set. The application of cloud computing for the provision of a service of critical care supporting both realtime patient monitoring and retrospective clinical research remains an open research problem. C. Performance analysis of cloud based systems Cloud computing has attracted considerable research attention, but only a small portion of the work done so far has addressed performance issues, and rigorous analytical approach has been adopted by only a handful among these. Many research works carried out a measurement-based performance evaluation of the Amazon EC2 [13], [14], IBM Blue Cloud [15] or other cloud providers in the context of scientific computing [16], [17]. Hamzeh et al. [18], [19] proposed various analytical models for performance evaluation of cloud computing centers; however, the authors investigated performance metrics related to generic cloud centers as opposed to a cloud-based solution for a specific domain. In [20], the authors proposed an analytical model for a proposed infrastructure which is supporting an in-house deployment of Artemis. To the best of our knowledge, this work is the first attempt to analyze and model an enterprise cloud-based Big Data compatible system in healthcare informatics. III. TEMIS CLOUD FRAMEWORK The Artemis Cloud is designed in such a way that supports data acquisition and storage of physiological data and clinical information for the purpose of realtime analytics,

ECG HR SpO2 BP Medical Monitor Data Terminal unit Hospital Network ECG HR SpO2 BP Medical Monitor Data Terminal Unit Hospital Gateway Hospitals Interface Data Integration Cloud Environment Realtime Analysis Stream Computing Platform Retrospective Analysis Deployment Server User Interface & Visualization Knowledge Extraction Hospitals Clinical Information System (CIS) Figure 1. The high level architecture of Artemis Cloud. retrospective analysis and visualization. Artemis Cloud is capable of gathering physiological data from a vast variety of medical devices and monitors in a secure way and performing the online analytics within the cloud. Anonymization and potential transformation are performed on the data before transmitting from the hospitals. Artemis Cloud also has an interface for communicating with hospital clinical information management system in order to obtain complementary information about patients. Artemis Cloud utilizes a Hospital Interface which performs the extraction, transformation and load of data (i.e., ETL capabilities) in one hand, and on the other hand facilitates the management of hospitals connectivity. This interface improves the extendability and modularity of the cloud based Artemis. The core of Artemis Cloud is a stream computing middleware component, IBM InfoSphere Streams (Streams, hereafter), which provides scalable processing of multiple streams of high-volume, high-rate data. Streams provides Artemis Cloud with a very extendable realtime execution environment. An application in Streams, consists of a set of operator nodes interconnected in a graph. Each operator node inputs one or more streams and produces one or more output streams. In addition to realtime analytics capabilities, Artemis Cloud is able to provide at-rest analytics (i.e., retrospective analysis) for stored data. Incorporating IBM InfoSphere BigInsights (IBM version of Hadoop ecosystem), offers great power of analysis as well as persistence storage. Researchers can apply data mining techniques, machine learning algorithms and statistical modeling, against vast amount of stored information and find new rules which may help earlier detection of diseases. Such new rules or modified parameters can be deployed to the real time analysis platform seamlessly. The deployment server is responsible for applying new rules and parameters to the realtime environment. Artemis Cloud also utilizes a relational database in data integration component which is interfaced with Streams to store the fresh data arriving from hospitals. Research user interface and visualization component visualizes the realtime and historical data. Fig. 1 shows the architecture of the Artemis Cloud. IV. TEMIS CLOUD DLOYMENT Fig. 2 shows the patient journey in NICU at SickKids hospital. As can be seen, SickKids has 36 NICU beds including different types of patients. Depending on the type of patients, different number of algorithms for various time periods will be triggered. After discharging of a patient, a new patient will be submitted to NICU in 4-6 hours. Fifty percent of patients are term babies who are referred to SickKids for surgical purposes. Approximately, surgical babies stay at hospital for 5 days and 8 medical algorithms will be applied for after-surgery monitoring. The rest of patients, i.e. preterm babies, are classified into three categories; babies who are born in 32 35, 27 32 and 23 27 weeks of their gestation age. The first group (i.e., %30) will be monitored by at most 8 medical algorithms for mean period of 8 days. The second group (%15) of preterm babies will be monitored by 10 or less algorithms for average time of one month. The third class are divided into two sub-classes depending on their

medical conditions: %80 of this class (i.e., %4 of the whole population) needs to be monitored by 20 or more algorithms for 4 months and %20 (i.e., %1 of the whole population) of them needs to be monitored by 20 or more algorithms for approximately 6 months. As Fig. 2 suggests, SickKids NICU can be modeled as a single heterogeneous finite queue with multiple service facilities. Each type of patients has distinct characteristics in terms of service duration and number of algorithms. Algorithms are also different in term of required computational resources. The SickKids NICU receives more admission requests that it has space for and prioritizes neonate surgical patients. Other patients are typically redirected to either Sunnybrook Hospitals or Mt Sinia Hospitals NICU when SickKids is operating at or near capacity. The total number of bed spaces available for admission is thus 118, with 40 and 42 spaces available at these other two hospitals respectively. In order to characterize medical algorithms, we setup a pilot project at University of Ontario Institute of Technology (UOIT) by feeding real data input, obtained from previous experiments. Provided that, we are able to model the infrastructure at SickKids and predict the amount of computational capacity that is needed to support a reliable realtime monitoring following by storing all relevant data for further analysis. %50 %30 %15 %4 Surgery for Term Babies 32-35 weeks 27-32 weeks 23-27 weeks in 36 beds at Sickkids A 8 or more algorithms for 5 days Preterm Babies A 8 or less algorithms for 8 days A 10 or less algorithms for 1 month A out V. ANALYTICAL MODELING OF THE TEMIS CLOUD 20 or more algorithms for 4 months We model Artemis Cloud platform as a M/G/m/m queuing system which (M stands for Markovian) indicates that the interarrival time of patients arrival is exponentially distributed, while patients resident time (G stands for general) at NICU are independently and identically distributed random variables that follow a general distribution with mean value of µ. The system under consideration contains m servers (i.e., bed spaces) that renders service in order of patients arrivals (FIFO). The capacity of system is m which means there is no extra room for queuing patients. As the population size of newborns is relatively high while the probability that a given newborn baby to be preterm is relatively small, the arrival process can be modeled as a Markovian process [21]. Since there is no indication either in academia or industry to assume any well-known probability distribution for duration of patients residence in NICU, we consider a generally distributed random variable for the patient resident time in NICU. One possible scenario is to consider the hospitalization of each type of patient at SickKids NICU as an exponentially distributed random variable with distinct mean value. Therefore, the overall visit time for all patients can be considered as a four-stage hyper-exponentially (HE) distributed random variable. We assume this scenario for numerical validation. As a result, the mean value of hospi- %1 Figure 2. NICU. 23-27 weeks talization is [21]: E[x] = A 20 or more algorithms for 6 months Types of patients and their medical service path at SickKids xf(x)dx = n p i xλ i e λix dx = i=1 0 n i=1 p i λ i (1) in which p i and 1/λ i are the probability of being patient type i and corresponding mean value of residence time in NICU, respectively. Thus, the queuing system that we need to solve and obtain the performance metrics is of type M/HE/m/m. Characterizing multiple queuing systems with non-exponential distributed service time is not exactly tractable [22]; however, since M/HE/m/m queuing system has no extra capacity than service facilities, it works exactly the same as M/M/m/m queuing systems [23]. Fortunately, the steady-state probabilities for such a queuing

systems are known and can be obtained in closed form: p k = ρ k k! m ρ n n=0 n! in which ρ = λ/µ and m is the number of bed spaces. In this model, blocking refers to when an admission request to SickKids results in the patient being redirected to one of the two other hospitals with a Level III NICUs as described above, or potentially to a fourth hospital if this network is at capacity. Blocking probability can be obtained as: P b = ρ m m! m n=0 The probability generating function (PGF) will be: m P (z) = p k z k (4) k=0 The effective patients arrival rate (i.e., the rate of patients who can get through NICU) is ρ n n! λ e = λ(1 P b ) Now, we can obtain the desired performance metrics. The mean number of patients in NICU is the first derivative of P (z) when z = 1. (2) (3) p = P (z) z=1 (5) By Little s law [24], the mean patient residence time is t = p λ e (6) VI. DATA STORAGE MODELING Based on our pilot setup at SickKids hospital, we characterize the type and amount of raw physiological data that Artemis Cloud collects from NICU beds. Table I shows the amount of data collected from each NICU bed during 24 hours in Megabytes. Based on the information presented in Table I, we model the minimum required storage for a Hadoop based system (i.e., BigInsights) for SickKids hospital for different configurations. The results will be presented in section VIII. VII. HDWE REQUIREMENT To determine the hardware requirements for Artemis Cloud, we first provide detailed information about the hardware requirements of BigInsights Enterprise Edition 2.1, organized by type of hardware or deployment units in Table II [25]. Table III shows the minimum hardware requirements for Streams 3.2 [26]. The above mentioned requirements are the base hardware specifications and need to be extended depending on the load and volume of data. Therefore, in section VIII we identify the amount of memory and data storage for Streams and BigInsights clusters respectively. Table I TYPE AND AMOUNT OF PHYSIOLOGICAL DATA ACQUIRED BY TEMIS CLOUD AT SICKKIDS: FOR ONE PATIENT DURING 24 HOURS. Type Description Amount (MB) HR Heart Rate 5 SpO 2 Blood Oxygen Saturation 5 SBP Systolic Blood Pressure 5 DBP Diastolic Blood Pressure 5 MBP Mean Blood Pressure 5 ADBP Arterial DPB 5 AMBP Arterial MBP 5 ASBP Arterial SBP 5 Respiratory Rate 5 IRW Impedance Respiratory Waveform 50 CO 2 CO 2 Waveform 50 PLETH Plethysmography Waveform 50 ECG Electrocardiography 500 TOTAL Size of Raw Data 700 Table II BASE HDWE REQUIREMENTS FOR BIGINSIGHTS EE 2.1. Hardware Storage Memory Processor Requirement Min 80 GB of disk storage total Min 32 GB on the management node Min 20 GB on other nodes Min of 8 GB x86 64-bit systems: Red Hat Enterprise Linux 5.6+ Red Hat Enterprise Linux 6.1+ SUSE Linux Enterprise Server 11 SP2+ Power7 64-bit systems: Red Hat Enterprise Linux 6.2+ Table III BASE HDWE REQUIREMENTS FOR STREAMS 3.2. Component Requirement Comments System Intel x86 64 Streams supports Red Hat Enterprise Linux (RHEL) and the Community Enterprise Operating System (CentOS) on x86 64 systems. IBM POWER7 IBM POWER7 systems support the RHEL operating system. Memory Min of 2 GB The amount of memory required by Streams is dependent on the applications that are developed and deployed on the Streams hosts. The Commodity Purchasing sample application, and many of the other available samples provided with Streams, can be compiled and executed with 2 GB of memory. Disk Space Min of 5.5 GB Minimum of 5.5 GB of disk storage. This includes disk space required for installation and development resources. VIII. NUMERICAL RESULTS The analytical model presented above has been implemented in Maple 17 [27] in order to obtain the numerical

results. First we charactrize the perfromance metrics for the current configuration of Artemis Cloud at SickKids which was described in section IV. Table IV shows the obtained performance metrics and important exogenous parameters. The average length of stay for patients is 16 days and each Table IV CONFIGURATION PAMETERS AND PERFORMANCE METRICS FOR CUENT CAPACITY OF SICKKIDS NICU. Parameter Value (unit) No. of beds in NICU 36 Mean patient arrival rate (patient/day) 4.5 Mean length of stay for patients (days) 16 Mean no of algorithms for one patient 9 No. of all running algorithms on Streams 311 NICU s Service rate (patient/day) 0.062 Blocking probability 0.455 Mean No. of patients in NICU 34.9 Mean value of memory per algorithm 110 (MB) Req. memory on Streams cluster 32 (GB) Req. storage for a patient s data (per day) 700 (MB) Req. storage on BigInsights cluster (per year) 8.6 (TB) patient requires 9 algorithms in average on Streams. Mean number of monitored patients (i.e., occupancy rate) is 34.9 so that 311 algorithms will be running on Streams instance. Each algorithm is approximately consuming 110 Megabytes of memory which indicates the requirement of at least 32 Gigabytes of memory for the stream computing cluster. Note that this amount of memory is just for application hosts and the management hosts require at least 2 more Gigabytes of memory. As can be seen, the amount of minimum storage for Hadoop cluster in order to only support the accommodation of raw physiological data for one year is 8.6 Terabytes. Depending on data schema design on BigInsights cluster, additional storage might be required for the metadata. Moreover, the storage required for non-physiological data such as patient information, lab results and other related medical data should be added on top of this calculations. Fig. 3 shows the amount of storage for BigInsights cluster, for 10, 36, 50, 100, 150 and 200 beds in the NICU. Note that this amount is only for raw physiological data acquired from NICU. As can be seen, the amount of storage increases linearly with respect to NICU capacity up to 50 beds. However, afterward, since the traffic intensity, which is the ratio of arrival rate to service rate, gets decreased, the amount of required storage does not increase sharply. Also, as can be noticed for more than 100 beds the amount of required storage remains unchanged which indicates the departure rate of patients is more than patients arrival rate. In other words, for one year, 16 TB of storage is sufficient for the SickKids NICU regardless of NICU s capacity (i.e., the number of bed spaces). Note that after discharging of a patient, his/her data will be moved to another storage. We are also interested in studying the number of patients Required storage for BigInsights cluster for different configu- Figure 3. rations. Current Capacity: 36 beds that get blocked, i.e. redirected to another NICU, due to the capacity limitations of the NICU of interest. To this end, we characterize the blocking probability for the NICU with the capacity of 10 to 200 beds. As can be seen (Fig. 4), for the current capacity of SickKids NICU (i.e., 36 beds) %46 of patients get blocked. However, by increasing the capacity to 150 beds, the blocking will be less than a percent. Figure 4. Current Capacity: 36 beds Blocking probability for different configurations.

We also investigated the amount of memory for the stream computing cluster for different configurations. Fig. 5 shows the trend of required memory with respect to number of beds. Up to 100 beds there is a linear dependency between the required memory and capacity; however, as can be seen, results show that 65 GB of memory will suffice for the Streams cluster regardless of NICU capacity. We shall repeat the fact that this amount of memory is just for application hosts and depending on the deployment of management servers, extra memory might be needed. Current Capacity: 36 beds also, we plan to consider other types of data such as metadata, lab and medical data, ventilation support, and nutrition or drug titration data into our capacity modeling. Another direction of research would be extending the performance model for a mulit-hospitals scenario which embraces multiple care units that plan to adopt the extended version of Artemis Cloud. ACKNOWLEDGMENT The authors would like to thank Dr. Edward Pugh and Dr. Andrew James from SickKids hospital for their valuable inputs on this research. We also wish to thank Blair Adamache from IBM Canada Research and Development Center for the valuable comments and sharing his knowledge on related IBM components. This research is supported by Southern Ontario Smart Computing Innovation Platform (SOSCIP) consortium, the Canada Research Chairs program and The Canadian Foundation for Innovation. REFERENCES [1] M. S. Kramer, R. W. Platt, H. Yang, K. S. Joseph, S. W. Wen, L. Morin, and R. H. Usher, Secular trends in preterm birth: A hospital-based cohort study, JAMA, vol. 280, no. 21, pp. 1849 54, December 1998. [2] C. McGregor, Big data in neonatal intensive care, Computer, vol. 46, no. 6, pp. 54 59, June 2013. [3] A. A. Flower, J. R. Moorman, D. E. Lake, and J. B. Delos, Periodic heart rate decelerations in premature infants, Experimental Biology and Medicine, vol. 235, no. 4, pp. 531 538, 2010. Required memory for Streams cluster for different configura- Figure 5. tions. IX. CONCLUSION We have described and modeled the Artemis Cloud deployment at SickKids hospital. In light of the proposed architecture and patient journey, corresponding analytical model has been designed and developed. Using the performance model, important performance metrics such as mean number of patients in NICU, mean patient residence time, mean number of required medical algorithms and blocking probability were characterized and discussed. Based on our pilot project at SickKids, we identified the amount of required storage, memory and computation power for analytics and real time components respectively. We obtained interested performance indicators and design parameters for different configurations. Provided that, capacity planning and what-if analysis can be attainable for Big Data growth introduced by extension of the NICU at SickKids hospital. As future work, we plan to estimate the required storage, memory and computation for all components including database, hospital interface and visualization components; [4] M. P. Griffin, D. E. Lake, T. M. O Shea, and J. R. Moorman, Heart rate characteristics and clinical signs in neonatal sepsis, Pediatric research, vol. 61, no. 2, pp. 222 227, 2007. [5] M. Blount, M. R. Ebling, J. M. Eklund, A. G. James, C. McGregor, N. Percival, K. P. Smith, and D. Sow, Realtime analysis for intensive care: development and deployment of the artemis analytic system, Engineering in Medicine and Biology Magazine, IEEE, vol. 29, no. 2, pp. 110 118, 2010. [6] C. McGregor, A cloud computing framework for real-time rural and remote service of critical care, in Computer- Based Medical Systems (CBMS), 2011 24th International Symposium on. IEEE, 2011, pp. 1 6. [7] M. Stacey and C. McGregor, Temporal abstraction in intelligent clinical data analysis: A survey, Artificial Intelligence in Medicine, vol. 39, no. 1, pp. 1 24, 2007. [8] Q. Zhang, C. Pang, S. Mcbride, D. Hansen, C. Cheung, and M. Steyn, Towards health data stream analytics, in IEEE/ICME International Conference on Complex Medical Engineering (CME), 2010, pp. 282 287. [9] C. Catley, H. Stratti, and C. McGregor, Multi-dimensional temporal abstraction and data mining of medical time series data: Trends and challenges, in Engineering in Medicine and Biology Society, 2008. EMBS 2008. 30th Annual International Conference of the IEEE, 2008, pp. 4322 4325.

[10] L. M. Vaquero, L. Rodero-Merino, J. Caceres, and M. Lindner, A break in the clouds: towards a cloud definition, ACM SIGCOMM Computer Communication Review, vol. 39, no. 1, pp. 50 55, 2008. [11] D. B. Hoang and L. Chen, Mobile cloud for assistive healthcare (mocash), in IEEE Asia-Pacific Services Computing Conference (APSCC), 2010, pp. 325 332. [12] C. McGregor, e-baby web services to support local and remote neonatal intensive care, HIC 2005 and HINZ 2005: Proceedings, p. 344, 2005. [25] IBM, System requirements for InfoSphere BigInsights: Version 2.1, Website, Last accessed January 2014, http://www- 01.ibm.com/support/docview.wss?uid=swg27027565. [26], System requirements for IBM InfoSphere Streams: Version 3.2, Website, Last accessed January 2014, http://www- 01.ibm.com/support/docview.wss?uid=swg27036140. [27] Maplesoft, Inc., Maple 17, Website, Last accessed March 2014, http://www.maplesoft.com. [13] An amazon.com company, Amazon Elastic Compute Cloud, Amazon EC2, Website, Last accessed January 2014, http://aws.amazon.com/ec2. [14] A. Iosup, N. Yigitbasi, and D. Epema, On the performance variability of production cloud services, in 11th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, May 2011, pp. 104 113. [15] IBM, IBM Cloud Computing, Website, Last accessed January 2014, http://www.ibm.com/ibm/cloud/. [16] A. Iosup, S. Ostermann, N. Yigitbasi, R. Prodan, T. Fahringer, and D. Epema, Performance analysis of cloud computing services for many-tasks scientific computing, IEEE Transactions on Parallel and Distributed Systems, vol. 22, no. 6, pp. 931 945, June 2011. [17] L. Wang, J. Zhan, W. Shi, Y. Liang, and L. Yuan, In cloud, do MTC or HTC service providers benefit from the economies of scale? Proceedings of the 2nd Workshop on ManyTask Computing on Grids and Supercomputers MTAGS 09, vol. 2, pp. 1 10, December 2010. [18] H. Khazaei, J. Mišić, and V. B. Mišić, A fine-grained performance model of cloud computing centers, IEEE Transactions on Parallel and Distributed Systems, vol. 24, no. 11, pp. 2138 2147, November 2013. [19] H. Khazaei, J. Mišić, V. B. Mišić, and S. Rashwand, Analysis of a pool management scheme for cloud computing centers, IEEE Transactions on Parallel and Distributed Systems, vol. 24, no. 5, pp. 849 861, 2013. [20] G. Hayes, H. Khazaei, K. El-Khatib, C. McGregor, and M. Eklund, Design and analytical model of a platform-as-aservice cloud for healthcare, Journal of Internet Technology (JIT), 2014. [21] G. Grimmett and D. Stirzaker, Probability and Random Processes, 3rd ed. Oxford University Press, Jul 2010. [22] H. Khazaei, J. Mišić, and V. B. Mišić, Performance analysis of cloud computing centers using M/G/m/m + r queueing systems, IEEE Transactions on Parallel and Distributed Systems, vol. 23, no. 5, p. 1, 2012. [23] L. Kleinrock, Queueing Systems, Volume 1, Theory. Wiley- Interscience, 1975. [24] H. Takagi, Queueing Analysis. North-Holland, 1991, vol. 1: Vacation and Priority Systems.