Biomedical Engineering Reference
In-Depth Information
3.
ca GWAS
Data mart for Genome Wide Association Studies [20].
4.
CTODS
Clinical Trials Object Database, a system for providing dei-
dentifi ed data from clinical trials [21].
5.
National Biomedical Imaging Archive ( NBIA )
Repository for Digital
Imaging and Communication in Medicine (DICOM) images [22].
6.
caIntegrator 2
A tool for setting up custom caBIG-compatible Web
portals for integrative research [23].
7.
geWorkbench
caGrid-enabled tools for performing genomic analy-
sis [24] .
8.
caB2B
a caGrid-enabled tool for performing in silico experiments by
leveraging caBIG - compatible data repositories and analytical tools [25] .
The CCTS [26] provides interoperable software to support clinical trials and
consists of the following applications:
1.
C 3 PR
caBIG Clinical Participant Repository, a patient registration
tool [27] .
2.
PSC
Patient Study Calendar, a tool for scheduling patients on clinical
trials [28] .
3.
ca BIG Clinical Connector
Software to assist in the integration with a
clinical data management system. Currently C3D and OpenClinica are
supported [29] .
4.
ca BIG Adverse Event Reporting System ( ca AERS )
A tool for manag-
ing and reporting adverse events during clinical trials [30].
5.
ca BIG Lab Viewer
Laboratory results viewer that integrates with the
rest of the clinical trials suite [31].
6.
ca BIG Integration Hub (formerly caXchange)
An open - source, enter-
prise service bus to enable seamless integration of CCTS components
with each other and existing systems at hospitals and research cen-
ters [32] .
As with all caBIG software, the LSD and CCTS provide semantically anno-
tated interfaces to enable interoperability with other systems.
In the fi rst generation of caBIG systems, the services provided to the SOA
tended to be large and complicated. Indeed, it was not uncommon to have a
single API specifi cation (implemented as described above in multiple tech-
nologies such as Java, Web Service, and Grid Service) that provided access to
all of the data and resources that were made available by that system. While
this greatly facilitated integration compared to a more traditional system, it
became clear that a different level of granularity would make it simpler to
support service marshaling and other integration activities. In addition, the
model of one system producing one service tended to introduce undesirable
variation in the way that particular classes of data were represented. For
Search WWH ::
Custom Search