Share and enjoy: anatomical models database—generating and sharing cardiovascular model data using web services

Abstract

Sharing data between scientists and with clinicians in cardiac research has been facilitated significantly by the use of web technologies. The potential of this technology has meant that information sharing has been routinely promoted through databases that have encouraged stakeholder participation in communities around these services. In this paper we discuss the Anatomical Model Database (AMDB) (Gianni et al. Functional imaging and modeling of the heart. Springer, Heidelberg, 2009; Gianni et al. Phil Trans Ser A Math Phys Eng Sci 368:3039–3056, 2010) which both facilitate a database-centric approach to collaboration, and also extends this framework with new capabilities for creating new mesh data. AMDB currently stores cardiac geometric models described in Gianni et al. (Functional imaging and modelling of the heart. Springer, Heidelberg, 2009), a number of additional cardiac models describing geometry and functional properties, and most recently models generated using a web service. The functional models represent data from simulations in geometric form, such as electrophysiology or mechanics, many of which are present in AMDB as part of a benchmark study. Finally, the heartgen service has been added for producing left or bi-ventricle models derived from binary image data using the methods described in Lamata et al. (Med Image Anal 15:801–813, 2011). The results can optionally be hosted on AMDB alongside other community-provided anatomical models. AMDB is, therefore, a unique database storing geometric data (rather than abstract models or image data) combined with a powerful web service for generating new geometric models.

1 Introduction

Anatomical Model Database (AMDB), formerly euHeartDB, is a web-fronted database of anatomical models and mesh data. Its initial purpose was to facilitate the sharing and reuse of cardiac geometric models within the cardiovascular research community. More recently, the database has been expanded to host models of other anatomies and models representing other forms of data, such as the results from computational simulations represented geometrically.

Additionally recent work has focused on addressing the difficulties of generating heart models from imaging data, which often involves complex tools whose difficulty of use can negatively affect community adoption. AMDB attempts to ameliorate this problem by wrapping its model generation tool as a web service available to clients through its web interface. This simplifies the use of the tool since clients are not required to host and operate the actual software artefact, but need only communicate with the AMDB site through a standardized interface.

The objectives of AMDB described in [6, 7] cover the processes of adding new models, searching for and downloading existing models, and the curation of models where new versions can be uploaded to update old ones. Model information is generally much smaller than the data sources they were derived from, and so in conjunction with standardized file formats this allows for the easy sharing of low-bandwidth data objects.

The initial data types stored on AMDB covered pre-generated cardiac models only, to which was later added functional models relating to simulation benchmarks. Specifically the study on simulation benchmarks in [13] focused on establishing a definitive set of results for a well-described electro-physiological problem. Using the Ten Tusscher 2006 [18] model to simulate the propagation of electrical activation over a standardized volume of myocardial tissue, a significant number of international participants generated results using their simulation software which were then stored in AMDB. Applying the AMDB database in this way allows participants, and other scientists wishing to use this model for simulations in the future, to compare results and establish by consensus what constitutes a “correct” consensus result.

AMDB facilitates the process of sharing this information by not only hosting the models but also providing comparison and graphing functionality built into the web interface. Site users can create activation time graphs from the uploaded data sets to compare results for different timesteps and mesh resolutions, as well as generate tables of comparison data. Critically this allows research groups to quickly compare their new results with these already stored by uploaded model data and invoking these services. This simplifies the task of determining the accuracy of their simulations, as well as ensuring a consistent basis for comparison is present.

This previous work has addressed the questions of how to share data amongst scientists and clinicians [16], and so it is a logical continuation to investigate how to assist in the creation of the data itself. In most cases cardiac and other anatomical models are created through various processes of converting imaging data into meshes, often manually and usually with the use of complex tool chains. How this process can be made simpler and more accessible to scientists is addressed in this paper through the use of web services to act as the interface for a mesh generation tool. By providing the tool as an online service, this eliminates the need to install software locally, provides control over the tool’s use, and in general simplifies the process through which users interact with it.

This new service is the heartgen tool, implemented as a standard form of web service in AMDB. It is accessible through the web interface of AMDB, allowing models to be created from stacks of segmented binary images derived from magnetic resonance imaging (MRI) or other imaging methodologies. The user interface front end for this tool is organized around a workflow process allowing the user to perform the fitting process with a varying set of parameters until a satisfactory fitted model is produced. These generated models can then be stored in the same manner as user-provided data if the user chooses to do so, as well as being emailed to the user.

This combination of database, simple analysis features such as those for the benchmark datasets, and data generation tool is aimed at creating a platform for facilitating computation medical research. Combining tools which do not need to be installed locally with the database to store results remotely greatly simplifies and streamlines the process scientists must go through to create and disseminate data. This paper discusses AMDB and its methodology for sharing and generating data with the first section providing an overview of the system and a technical overview of the heartgen pipeline. Following sections describe the data stored on AMDB: geometric models, benchmark data and other “functional” models, and models generated by heartgen.

2 Methods

The methodology used to address the challenges discussed above centers around the AMDB web application. This site presents the database in a user-friendly manner, allowing users to browse and access stored data, and provides access to the mesh generation tool through its integrated interface.

AMDB is a JSP ¹-based web application using Struts ² for MVC separation between web pages and backend, and Hibernate ³ for communication with a MySQL ⁴ database. An example excerpt from the database schema is given in Fig. 1 demonstrating the structure of the records used to store the primary information about uploaded models (although not the model data itself). Struts and Hibernate are Java technologies allowing web functionality to be implemented as Java classes. JSP is a server-side scripting language incorporating Java code defined in tags embedded in HTML-like documents. MySQL is a popular and general purpose database accessed through the SQL language interface.

Fig. 1

Database schema excerpt. This describes the table structure where each row represents an uploaded geometrical model linked to other tables which provide curated information about its generation. It outlines the fields used to describe models and their relationships with previous versions and curators

Permissions and security are important components to the sharing process since contributors will wish to control who can access their uploaded data. AMDB provides mechanisms for creating user groups and assigning per-model permissions for these groups. This permits an uploaded model to be included in the database while being visible, downloadable, or curatable by only select groups. Contributors, therefore, can share their data with a certain level of control without the risk of their data becoming publicly available in an unrestricted form to all users.

Bibliographic information about the models is also stored, whereby contributors provide publication information and then link these publications to the models they describe. All these processes are actuated by the site’s web-based user interface, which simplifies the task of interacting with the database by encapsulating operations as interactions with web forms. Ensuring consistency, associating descriptive and bibliographic information with models, and making models available to collaborators is all handled internally by the AMDB software. The end result is a web-based database of models, maintained and shared automatically in low-bandwidth standardized forms.

The database focuses on storing geometric models representing anatomy and functional models representing the results from benchmark simulations or other non-anatomical spacial data sets. Data from participants in the electrophysiology benchmark study described in [13] conform to a common format, thus permitting the generation of comparison graphs and tables automatically. AMDB provides services for generating graphs plotting activation time across the myocardium volume, generating tables of activation times at corner nodes, and calculating L ² norm comparison values. Figure 2 is an example of this graphing service. The purpose of the benchmark study was to provide a comparison between various electrophysiology simulation platforms for the purposes of assessing accuracy. Producing graphs and other comparison data sets facilitates this objective through the simple properties of being easy to use and immediately available to study participants and other researchers looking to compare simulations in the future.

Fig. 2

Comparison graph example

The heartgen service is implemented as a SOAP ⁵ service which interfaces with the MATLAB executable. On a separate server from the one hosting the website itself, a Flask ⁶ Python-based web server provides the SOAP entry point and interface layer. The service code is responsible for converting the input data sent with the SOAP request into an input file and storing that on the server. Next, it calls the MATLAB heartgen program which performs the actual fitting process. Once this is completed an archive containing the results is sent back as the return value of the SOAP request.

The SOAP method accepts parameters for the generation process and the input model file encoded as a base-64 string, the encoding for which is the responsibility of the client. Upon completion it will return the archive containing results, also as a base-64 string. Figure 3 lists the outline of the server code in Python, with sections irrelevant to the discussion omitted. The body of the method heartgen implements the interface between the server and the MATLAB code, which is a simple process of decoding the file sent through the variable attach and calling a script which invokes heartgen. Implementing a server of this type to interface with a command line tool in a compact code base is a comparatively straightforward task to accomplish. The great benefit it brings is separating computational services from web servers and making them generic for other clients to access and so making tools available without the need for complicated installations by clients.

Fig. 3

Heartgen service implementation outline

2.1 Heartgen pipeline

The heartgen web service is implemented as a MATLAB application with support from the CMGui [4] tool and the Sheffield Image Registration Toolkit (ShIRT) [1, 2]. Users primarily access the application through a web form (illustrated in Fig. 4) on the AMDB site where they can set parameters and send data as part of a fitting operation. Once submitted and the fitting has been completed, users can either resubmit the binary image data or post the generated model onto AMDB for others to access.

Fig. 4

AMDB binary image submission form

The heartgen pipeline is illustrated in Fig. 5 which is initiated with the input binary segmentation data and user parameters. The parameters are used to generate a template mesh meeting the requested resolution and level of detail specifications. The template and initial input data are then fed into the registration operation, which produces a mesh warping field. When this field is applied to the template mesh, a deformed mesh is produced which closely approximates the initial anatomy. The result is a patient-specific ventricular model.

Fig. 5

Heartgen workflow

The data input for heartgen is a stack of binary images outlining the structure of the myocardial tissue. These data may represent left ventricular or biventricular structure; the user must specify through the form the anatomical type of data that are being uploaded to achieve a correct fitting. Users must also choose parameters specifying properties of the generated mesh: resolution in the apex, circumference, and radial dimensions, basis function (cubic Hermite or Lagrange), level of detail, alignment initialization option, and aperture angle for the septum base. If the alignment initialization option chosen calls for a manual input of rotation values, these must also be provided.

Figure 6 illustrates the use case of AMDB through the web form, from uploading data to posting the model on the site:

• 1. User sets parameters and uploads data through web page, initiating fitting operation

• 2. User is redirected to regeneration page (a) while the fitting operation is in progress. Eventually results are emailed to user (b).

• 3. Further fitting operations can be initiated from the regeneration page using the same data (a) if the emailed results are deemed to be not acceptable, the results of which are also emailed back to the user (b).

• 4. Once a satisfactory model has been generated, the result can be posted on AMDB as a new geometric model.

Fig. 6

Heartgen webform use case

Fitting a mesh to a series of images derived from patient data is not always a straightforward process for any arbitrary data set. For this reason users may need to iterate through a process of performing a fitting operation with certain parameters, checking the results, and then adjusting the parameters and then attempting another fitting. AMDB facilitates this process by sending results as emailed attachments which the user can analyse for correctness and then submit the uploaded data for another fitting operation without having to re-upload the data file. Once a satisfactory fitting has be achieved, the model data stored on the server can be used to immediately create a stored geometric model entry in the database.

3 Results

This section will briefly describe some indicative examples of the new data uploaded to the site since the publication of our previous study. The first set of models are those generated by contributors through their own imaging and meshing processes, and the second are those generated as part of simulation benchmark exercises (explained in detail in the "Appendix"). These latter models are termed “functional” models and represent data generated by physics simulations. As outlined above, these data are provided as numerical benchmarks to compare future simulations against. The final set includes model data generated by the heartgen tool.

3.1 Uploaded models

AMDB stores a number of cardiac models already described in related publications. The Auckland Heart [10] is a finite element representation of a canine heart with ventricular geometry and fibre organization. Three heart models [15] from the INRIA Asclepios group represent a mean canine heart at different resolutions, which were generated through the average of nine separate hearts acquired from MRI imaging. The Philips Research Europe whole heart model [5] represents the mean anatomy of 30 individuals composited together to produce a surface triangle mesh. A heart model [14] was derived from statistical inference on 100 living humans, which resulted in a tetrahedral mesh incorporating statistical measures of the fibre orientation and electrical conduction pathways.

In addition to these models, a significant range of new models has been uploaded through recent research efforts. Three patient-specific models of the human aorta produced by the Medical Physics Unit at the University of Sheffield represent a healthy aorta, a version with a Berlin Heart INCOR left ventricular assist device (LVAD) cannula included, and a third (Fig. 7a) suffering from aortic coarctation. The porcine vascular model in Fig. 7b was derived from a cryomicrotome process where the excised pig heart was perfused through the blood vessels with a fluorescent casting material, then immersed in a sodium solvent and thickening agent mixture before being frozen [17]. Two models have been uploaded to the database which represents the results of a electrophysiological simulation using the Eikonal equation with Fast Marching Method. The purpose of these models is to provide a benchmark data set, representing the activation times within a 20 × 7 × 3 mm volume of myocardium, which the results from future simulations can be compared against. Ninety-six models representing the diffusion of electricity of a volume of myocardium have been uploaded as part of a benchmark study of simulations using the Ten Tusscher 2006 [18] model (sample given in Fig. 7c). Study participants submitted results at various timesteps and mesh resolutions which were collected together and compared as part of the study [13] (see Sect. 6).

Fig. 7

Human aorta (a), Porcine Vascular Model (b), electrophysiology benchmark (c)

3.2 Generated models

The heartgen process has been developed and applied to produce a variety of patient-specific heart models. These resulting models describe the anatomy of different diseased conditions of the human heart, porcine models, and those involved in cardiac therapies. The broad range of models produced via this approach demonstrates the flexibility of the fitting process by being able to cope with such varying input data. Providing these models to researchers opens up a range of data on cardiac conditions and therapies for use in simulation and analysis.

The following briefly outlines the range of such models currently available: Fig. 8a illustrates one of two porcine models generated using a process similar to the one implemented for the heartgen service. Ex-vivo DT-MRI scans of two porcine subjects were processed to segment the myocardial anatomy and extract fibre orientation. Data were then used to create cubic Hermite biventricular meshes, using a variational fitting technique described in [9]. Two left ventricle geometries were generated from heart failure patients selected for Cardiac Resynchronization Therapy [8], as part of the euHeart project (Fig. 8b). In the given image, the white sections represent the generated mesh, while the red component is the isosurface at level 0.5 generated from the binary images. AMDB has a set of six cases of left ventricular meshes with a hole in the apex, created for the cannula of a LVAD. The anatomy was captured by CT images, and a robust model-based segmentation strategy [5] was used to identify the extents of the left ventricle. These meshes have been used for the optimization of the treatment of heart failure with LVAD [11, 12].

Fig. 8

Porcine Fibre Orientation Model (a), Cardiac Resynchronization Therapy Model (b)

4 Discussion

AMDB compares similarly to other databases of scientific data except that it includes services for the generation of models from uploaded data. The CellML Model Repository ⁷ stores mathematical cell models represented in a standard markup language. The JSim simulation system ⁸ project also maintains a database of mathematical models, in this case representing numeric models which may or may not be directly related to biological functions. The BioModels Database ⁹ stores computational models representing biological processes, cellular components, molecular function, and other processes for a variety of species. All of these databases present users and contributors with an interface to store and disseminate data with facilities for curation and cross-referencing. AMDB instead stores geometric models of anatomy and functional simulation rather than cellular or computational models and additionally provides services for the generation of data from uploaded results. This last key feature is not present in the above-mentioned web databases, as such AMDB in this way is unique in making a computational web service available in conjunction with a collaborative database.

Exchanging information between researchers and practitioners is a critical aspect of medical science. Without a simple, accessible mechanism for one party to make their results available to others the ability to collaborate is greatly reduced. AMDB provides such a mechanism to share model data which is well described by its originators and associated with the published literature involved in their creation. Additionally, complex software tools to generate models from image data are presented as web applications. Researchers, therefore, can produce and share their results without needing to download, install (and possibly compile), and then learn to use such tools. Furthermore, this approach also enables the use of this framework by non-technical users, especially clinicians.

The accomplishments so far with AMDB cover the presentation and sharing of data and begins to explore the analysis and creation of data online as part of a web application. Control over how data are shared is provided through a relatively coarse-grained approach based on permissions; however, future development may include a more in depth mechanism to provide contributors with the ability to restrict access or vizualization based on a wider set of criteria. This would address the concerns of participants with regard to how their data are used, manage attribution, and to address regulator concerns. How versions of a data set are curated together as a series of relation scientific results will also be addressed as part of future development.

AMDB thus is a link between data and clinically relevant results. For software to be useful in a clinical situation it must have access to data about the relevant physiology at hand as well as that of individual patients. AMDB serves as a source of data for these applications to use as part of the simulation and treatment process, as well as a starting point for the analysis of anatomical features of collected data sets. Ultimately, the goal is to provide a platform for the hosting of simulation codes as web applications in an integrated environment combining computation and data curation. This would allow researchers and practitioners to access the same tools in a format practical for both, while also hosting the data needed as input which can be easily fed into simulations of patient function.

The form of the data itself is of obvious importance to all users of AMDB. Currently, the CmGui format (colloquially referred to as Exformat) is the prevalent mode of data representation, always in the form of separate text files for node and element definitions. The advantage of this format is the flexbility in the data type definitions which can be used to specify almost all aspects of the data provided, leaving nothing to implicit understanding or convention. The disadvantage of this format is the lack of standards and adoption, and its planned obsolescence in favour of FieldML [3], which is a promising future option. Other formats may also be uploaded, but only VTK in certain formats is understood by the site’s underlying software tools.

A clear need for a more universal and standardized solution is present and will be the focus of future efforts with AMDB. Providing greater support for commonly used formats is preferable to the development of new formats; therefore, the analysis tasks of the site must be expanded to encompass these formats. No one data format is universal and standard for representing anatomical data, and so AMDB must be extended to store and convert many commonly used formats. The tools for mesh generation and analysis must also be extended to operate with these formats.

Using the database as a repository for benchmark information rather than a store for geometry will also be a focus of future work. The largest benchmark data set covers the electrophysiology simulations described in the "Appendix". Other data sets cover physics with a varying number of individual results. Future work with AMDB will focus on including more such benchmarks in the database through possible further large-scale studies.

5 Conclusion

This paper has summarized the on-going research initiatives enabled by the Anatomical Model Database. AMDB was initially set up to act as a store for cardiac models only. It has been extended to include hosting data for other model types, functional models representing simulation results, and includes a service for the creation of models. The set of functional models represents a source of benchmark information for electrophysiological simulations which researchers can use as comparison results for their own code. Additionally, AMDB provides analysis routines for comparing these results, with members within the data set and especially with new results uploaded by other research groups. Last, the heartgen web service provides a facility for creating ventricular heart models from uploaded imaging data, allowing the creation of patient-specific models suitable for simulation and analysis.

Appendix: Reaction diffusion benchmark using the ten Tusscher model

AMDB stores a total of 96 models as part of the simulation benchmark study undertaken in [13] which represent the results of the electrophysiology simulations as activation times over a 20 × 7 × 3 mm volume of myocardial tissue. These electrophysiological simulations used the Ten Tusscher 2006 [18] model to simulate electricity propagation over the volume, such that each node’s data represent activation time in milliseconds (the time at which the upstroke passed through 0 mV).

The study aimed to establish a benchmark physiology problem with a simple setup which can be reproduced easily by various research groups. To perform a benchmark using this simulation, a number of groups were asked to develop code to perform the simulation using the three spacings (0.5, 0.2, 0.1 mm) and three timestep (0.005, 0.01, 0.05 ms) setups. The results from these groups are then compared to demonstrate that the problem is coherent and consistent, and therefore the results are useful in testing the correctness of these simulation implementations.

Eleven groups were invited to perform the simulation and submit their results. This produces 99 data sets to upload to the site, excepting four instances where the simulations failed for 0.1 mm resolution and 0.05 ms time steps, and one which produced un-physiological results. The table given in Table 1 lists the participants, their institutions, the numerical method used and type of mesh or grid used.

Table 1 List of study participants

Table 2 gives the L ² norm of the difference in activation times between simulations with the highest temporal and spatial resolutions. These values represent the quantitative difference between results, which would be expected to produce similar values when comparing implementations using the same underlying method, either finite element or finite difference. However one result shown here is that in some cases, such as A and G, there is a similarity of results despite differing methods being used.

Table 2 L ² norm differences between simulations of highest temporal and spatial resolution

To generate this table as well as other figures, the AMDB website was expanded to include functionality for analysing and processing data stored as models. The section of the site dedicated to functional models allows users to plot the activation times for one or more EP benchmark models and produce a graph in SVG format like those presented here. A second analysis samples the values at all eight corners of selected result sets, as well as the center point. A third analysis performs the L ² norm calculations between selected models, which was used to generate the data for Table 2.