InSilc Cloud


Figure16_new logo


Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud Computing model offers the promise of massive cost savings combined with increased IT agility. InSilc Cloud platform will include and integrate diverse geometrical models and simulation outputs from the Mechanical Modelling Module, Deployment Module, Fluid Dynamics Module, Myocardial perfusion Module, Drug-delivery Module and Degradation Module.

The geometrical models and the simulation outputs, used in these stages, will be of diverse nature and format. Specifically:

  • patient images: usually DICOM format (from IVUS, CT, OCT, etc.)
  • geometrical model: surface (STL reconstruction from images, NURBS surface from CAD) or volume (CAD)
  • parametric: a geometrical model including variable parameters
  • mesh: collections of simple basic geometric cells

A standardization of the required formats will be defined to be stored in the Data and Models Repository. Towards this, appropriate converters will be created to convert the models on upload or download to/from the stored format(s). The multitude of the InSilc platform outputs provided at the different stages will also be stored in a generic way: results are either global or applied on the geometric model, can be of scalar or vectorial nature, and will be stored with a common set of keys to identify the nature of the quantity. Model converters will also convert the results accordingly. The necessary converters will be created to allow the InSilc modules output to be linked from one stage to another and to create new model data out of previous results. The standardization of the geometrical models and the simulation results will assist in creating generic WebGL renderers able to render in a browser the 3D models and results of all stages.

InSilc Cloud platform will include the following components: (i) Client application Layer available through the web (access layer using a web browser), (ii) Cloud server computational Layer (data processing layer and compute engines including Restful services’ providers), (iii) Data and Models management Layer, (iv) Cloud data and models repository Layer.

The preferred client application is a standard web browser, with or without WebGL functionality. WebGL functionality is required for the WebGL viewer application, but not for upload/download functions. Non-interactive upload/download applications may also be provided. All connections to the cloud server computational framework are secured and encrypted.

The cloud server computational framework is responsible for setting up the connections, perform authentication, uploads and downloads, and provides applications like data checking, data conversion, data mining and data viewing. Data checking mainly involves validating the incoming data to one of the accepted formats. Data conversion performs conversion of data between different formats or deriving new models from combining existing models. The data viewer allows viewing the models and results of simulations in 3D with full interactive functionality (requires a WebGL enabled browser). The webserver will have a frontend to set up connections and perform data transfer, and a backend to do the processing. The frontend is an existing established web server (nginx/apache). The framework will be built and deployed in a way to allow easy scaling (cloud provider, virtual machines, load balancing). The data and models repository will store all the data and models in a secured environment, taking account of data integrity, security, privacy and licensing concerns. It will consist of a database (established component) and a file storage system. It will store geometrical models, simulation results, and programming code (modelers, converters, (WebGL) renderers).


Virtual scenarios


Figure17_new logo


The process of drug-eluting BVS design starts with the product definition, the requirements that the product should meet and proceeds with the pre-clinical testing. Currently, in the pre-clinical process not all the scenarios of clinical failure and undesired effects can be identified. Some of the clinical failures are related to drug-eluting BVS engineering failure modes, due to design and material considerations, while other are related to the other aspects such as the indices pattern flow, the drug delivery and the degradation processes. Not surprisingly, it is almost impossible to account for all the clinical failure scenarios during the design phase, since this would require multiple stent designs, expensive prototypes, and pre-clinical experiments to estimate the actual risk of such stent failure modes. Since the aforementioned process is very expensive and time-consuming, every drug-eluting BVS design company tries to cut corners and makes assumptions that a certain drug-eluting BVS design will not result in a given failure mode. Sometimes, these assumptions can be valid, however the validity or not of these assumptions are usually revealed during the clinical trial or even worse when the drug-eluting BVS is launched in the market and due to occurring side effects is recalled. In addition, during the BVS design-testing cycle, it is necessary to account on the patient and surgical variability.

InSilc platform will provide thousands of different simulation results (WP4, WP5), relative to a number of drug-eluting BVS through the utilisation of “virtual” patients. The “virtual” patients will be used to simulate the drug-eluting BVS performance and the relevant consequences in the arterial environment. Once this simulation is achieved, several “virtual” scenarios can be performed (D8.5), starting from the alteration of the scaffold design parameters to test anatomical compatibility, and continuing to more detailed functional assessments, typically associated with the analysis of the effects of the deployment, the hemodynamic alterations in the macroscopic and microscopic level, the drug release mechanisms and the process of degradation. InSilc will provide valuable clinical information and predict very-long term outcomes for specific cases that are not included in the clinical trials, such as in the case of patients with a combination of specific characteristics. In addition, for those involved in the clinical trials, the observations and the drug-eluting BVS evaluation is for a period of 6-12 months. In case the side effects appear after this time period, it is very unlikely that any clinical trial will be able to observe them. What InSilc platform offers is the ability to intentionally skew the parameters of our “virtual” patients including all possible patient characteristics and explore the effect of certain effects over a much longer period of time. Based on the availability of the “virtual” patients, InSilc will develop and validate with sufficient confidence patient-specific drug-eluting BVS models which will be used for refining the clinical outcome quantification. This will allow the reduction of the number of patients who need to be involved in the drug-eluting BVS clinical trials and refine the existing clinical trials so that the involved patients are not exposed to suffering and discomfort and experience a lower risk of adverse effects.