Claudiu Farcas

iDASH: integrating data for analysis, anonymization, and sharing

iDASH (integrating data for analysis, anonymization, and sharing) is the newest National Center for Biomedical Computing funded by the NIH. It focuses on algorithms and tools for sharing data in a privacy-preserving manner. Foundational privacy technology research performed within iDASH is coupled with innovative engineering for collaborative tool development and data-sharing capabilities in a private Health Insurance Portability and Accountability Act (HIPAA)-certified cloud. Driving Biological Projects, which span different biological levels (from molecules to individuals to populations) and focus on various health conditions, help guide research and development within this Center. Furthermore, training and dissemination efforts connect the Center with its stakeholders and educate data owners and data consumers on how to share and use clinical and biological data. Through these various mechanisms, iDASH implements its goal of providing biomedical and behavioral researchers with access to data, software, and a high-performance computing environment, thus enabling them to generate and test new hypotheses.

Rich Services: The Integration Piece of the SOA Puzzle

One of the key challenges to successful systems-of- systems integration using Web services technologies is how to address crosscutting architectural concerns such as policy management, governance, and authentication, while still maintaining the lightweight implementation and deployment flavor that distinguishes Web services from earlier attempts at providing interoperable enterprise systems. To address this challenge, this article introduces the notion of a Rich Service, an extension of the standard service notion, based on an architectural pattern that allows hierarchical decomposition of system architecture according to separate concerns. Rich Services enable the capture of different system aspects and their interactions. By leveraging emerging Enterprise Service Bus technologies, Rich Services also enable a direct transition from a logical to a deployed service-oriented architecture (SOA). This results in immediate benefits not only in SOA design, implementation, deployment, and quality assurance, but also in the traceability of architectural requirements to an SOA implementation.

Addressing the Integration Challenge for Avionics and Automotive Systems—From Components to Rich Services

Automotive and avionics systems are complex, distributed, software-intensive systems-of-systems (SoS). Consequently, system integration is a central challenge in both domains. Important cross-cutting requirements aspects, such as security, authorization, and failure management, are best understood as properties of the interplay among sub-systems. Yet, traditional development processes address the integration challenge only late, at the level of implementation and deployment. Consequently, potentials for reuse within and across product lines are left unrealized. Furthermore, late integration leads to high calibration, configuration and redesign costs. Service-Oriented Architectures (SOAs) have emerged as a solution to the integration challenge. However, inappropriate application of SOA-principles results in a high degree of fragmentation and scattering of functionality-this leads to additional difficulties in requirements traceability and quality assurance. In this article, we give a comprehensive overview of these SOA-challenges, and present Rich Services as a hierarchical SOA blueprint and development process enabling SoS integration in a dependable way. Rich Services introduce services as hierarchical, partial interaction patterns; these interactions are then augmented with infrastructure elements to inject behaviors that address cross-cutting requirements aspects. Rich Services also seamlessly address the mapping from logical to deployment architectures. Using end-to-end failure management as an example, we illustrate the utility of Rich Services.

Cyberinfrastructure for the US Ocean Observatories Initiative: Enabling interactive observation in the ocean

The Ocean Observatories Initiative (OOI) is an environmental observatory covering a diversity of oceanic environments, ranging from the coastal to the deep ocean. Construction is planned to begin in mid-2010 with deployment phased over five years. The key integrating element of the OOI is a comprehensive cyberinfrastructure whose design is based on loosely coupled distributed services, and whose elements are expected to reside throughout the OOI observatories, from seafloor instruments to deep sea moorings to shore facilities to computing and archiving infrastructure. There are six main components to the design comprising the core capability container, consisting of four elements providing services for users and distributed resources and two infrastructural elements providing core services. The Sensing and Acquisition component provides capabilities to acquire data from and manage distributed seafloor instrument resources, including their interactions with the infrastructure power, communication and time distribution networks. The Data Management component provides capabilities to distribute and archive data, including cataloging, versioning, metadata management, and attribution and association services. The Analysis and Synthesis element provides a wide range of services to users, including control and archival of models, event detection, quality control services and collaboration capabilities to create virtual laboratories and classrooms. The Planning and Prosecution element gives the ability to plan, simulate and execute observation missions using taskable instruments, and turns the OOI into an interactive observatory. The remaining elements are the Common Operating Infrastructure that provides core services to manage distributed, shared resources in a policy-based framework. It includes capabilities for efficient and scalable communication, to manage identity and policy, manage the resource life cycle, and catalog/repository services for observatory resources. The Common Execution Infrastructure provides an elastic computing framework to initiate, manage and store processes that may range from initial operations on data at a shore station to the execution of a complex numerical model on the national computing infrastructure, and on compute clouds.

MAGI: a Node.js web service for fast microRNA-Seq analysis in a GPU infrastructure

Summary: MAGI is a web service for fast MicroRNA-Seq data analysis in a graphics processing unit (GPU) infrastructure. Using just a browser, users have access to results as web reports in just a few hours—>600% end-to-end performance improvement over state of the art. MAGI’s salient features are (i) transfer of large input files in native FASTA with Qualities (FASTQ) format through drag-and-drop operations, (ii) rapid prediction of microRNA target genes leveraging parallel computing with GPU devices, (iii) all-in-one analytics with novel feature extraction, statistical test for differential expression and diagnostic plot generation for quality control and (iv) interactive visualization and exploration of results in web reports that are readily available for publication. Availability and implementation: MAGI relies on the Node.js JavaScript framework, along with NVIDIA CUDA C, PHP: Hypertext Preprocessor (PHP), Perl and R. It is freely available at http://magi.ucsd.edu. Contact: j5kim@ucsd.edu Supplementary information: Supplementary data are available at Bioinformatics online.

The Treasure Map for Rich Services

Large systems-of-systems often service large numbers of stakeholders - more stakeholders often means more concerns, many of which are crosscutting. The rich services architecture is a type of service-oriented architecture (SOA) that allows hierarchical decomposition of a system architecture into separate concerns, thereby capturing different system aspects and their interactions, and accounting for crosscutting concerns concisely and sensibly. By leveraging emerging enterprise service bus technology, rich services enable a simple and direct deployment mapping to a system-of-systems network. This paper describes a development process that leverages rich services and is compatible with agile development methodologies. It encompasses use cases, requirements decomposition, role identification, and service definition to produce a rich services logical architecture that can then be mapped to a virtual network topology, and finally a physical network topology. The process decouples development stages to improve flexibility and productivity of complex projects, promising reduced cost and risk.

Serving ocean model data on the cloud

The NOAA-led Integrated Ocean Observing System (IOOS) and the NSF-funded Ocean Observatories Initiative Cyberinfrastructure Project (OOI-CI) are collaborating on a prototype data delivery system for numerical model output and other gridded data using cloud computing. The strategy is to take an existing distributed system for delivering gridded data and redeploy on the cloud, making modifications to the system that allow it to harness the scalability of the cloud as well as adding functionality that the scalability affords.

A System to Build Distributed Multivariate Models and Manage Disparate Data Sharing Policies: Implementation in the Scalable National Network for Effectiveness Research

Background Centralized and federated models for sharing data in research networks currently exist. To build multivariate data analysis for centralized networks, transfer of patient-level data to a central computation resource is necessary. The authors implemented distributed multivariate models for federated networks in which patient-level data is kept at each site and data exchange policies are managed in a study-centric manner. Objective The objective was to implement infrastructure that supports the functionality of some existing research networks (e.g., cohort discovery, workflow management, and estimation of multivariate analytic models on centralized data) while adding additional important new features, such as algorithms for distributed iterative multivariate models, a graphical interface for multivariate model specification, synchronous and asynchronous response to network queries, investigator-initiated studies, and study-based control of staff, protocols, and data sharing policies. Materials and Methods Based on the requirements gathered from statisticians, administrators, and investigators from multiple institutions, the authors developed infrastructure and tools to support multisite comparative effectiveness studies using web services for multivariate statistical estimation in the SCANNER federated network. Results The authors implemented massively parallel (map-reduce) computation methods and a new policy management system to enable each study initiated by network participants to define the ways in which data may be processed, managed, queried, and shared. The authors illustrated the use of these systems among institutions with highly different policies and operating under different state laws. Discussion and Conclusion Federated research networks need not limit distributed query functionality to count queries, cohort discovery, or independently estimated analytic models. Multivariate analyses can be efficiently and securely conducted without patient-level data transport, allowing institutions with strict local data storage requirements to participate in sophisticated analyses based on federated research networks.

iCONCUR: informed consent for clinical data and bio-sample use for research

Background: Implementation of patient preferences for use of electronic health records for research has been traditionally limited to identifiable data. Tiered e-consent for use of de-identified data has traditionally been deemed unnecessary or impractical for implementation in clinical settings. Methods: We developed a web-based tiered informed consent tool called informed consent for clinical data and bio-sample use for research (iCONCUR) that honors granular patient preferences for use of electronic health record data in research. We piloted this tool in 4 outpatient clinics of an academic medical center. Results: Of patients offered access to iCONCUR, 394 agreed to participate in this study, among whom 126 patients accessed the website to modify their records according to data category and data recipient. The majority consented to share most of their data and specimens with researchers. Willingness to share was greater among participants from an Human Immunodeficiency Virus (HIV) clinic than those from internal medicine clinics. The number of items declined was higher for for-profit institution recipients. Overall, participants were most willing to share demographics and body measurements and least willing to share family history and financial data. Participants indicated that having granular choices for data sharing was appropriate, and that they liked being informed about who was using their data for what purposes, as well as about outcomes of the research. Conclusion: This study suggests that a tiered electronic informed consent system is a workable solution that respects patient preferences, increases satisfaction, and does not significantly affect participation in research.

A Service-Oriented Blueprint for COTS Integration: the Hidden Part of the Iceberg

The use of commercial off-the-shelf (COTS) software can greatly reduce the development cost and effort for complex software systems. Reusing software can also improve the general quality of a system by leveraging already proven implementations. One of the limiting factors in the adoption of COTS software is the complexity of integrating it with the rest of the system under development. Often, requirements do not entirely match the functionalities available in COTS components, increasing the complexity of the glue software that needs to be written. In this paper, we present the blueprint of a service-oriented architecture that can guide the engineer both in specifying the functionalities of a complex software system and as a deployment architecture to seamlessly integrate COTS components implementing such functionalities. The COTS integration concern, typically a deployment issue, is addressed in the service architecture, and is treated as first-class citizen of the development process.