Specify_AAS_0.2x - QI-Bench

bawltherapistΛογισμικό & κατασκευή λογ/κού

13 Δεκ 2013 (πριν από 3 χρόνια και 7 μήνες)

287 εμφανίσεις

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

1

of
27


QI
-
Bench “Specify”

Architecture Specification


November

2011

Rev
0.2






Required Approvals:

Author of this
Revision
:

Andrew J. Buckler

and Matt Ouellette






System Engineer:

Andrew J. Buckler






Print Name


Signature


Date


Document Revisions:

Revision

Revised By

Reason for Update

Date

0.1

AJ Buckler

Initial version

June 2011

0.2

AJ Buckler
/ Matt
Ouellette

Further developed concept

and
added detail from 2
nd

prototype

November 2011































QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

2

of
27

Table of Contents

1.

EXECUTIVE SUMMARY

................................
................................
................................

3

1.1.

P
URPOSE AND
S
COPE

................................
................................
................................
.............

4

1.2.

T
ERMS
U
SED IN
T
HIS
D
OCUMENT

................................
................................
..........................

6

2.

STRUCTURE OF THE APP
LICATION

................................
................................
.........

7

2.1.

D
ATASTORES

................................
................................
................................
.......................

12

2.1.1. Quantitative Imaging Biomarker Ontology (QIBO)

................................
....................

12

2.1.2. Linked Ontologies

................................
................................
................................
........

12

2.1.
3. Biomarker DB

................................
................................
................................
..............

12

2.2.

A
CTIVITIES

................................
................................
................................
..........................

12

2.2.1. Question
-
Answer Paradigm for Engaging Domain Experts (QISL tab)
......................

13

2.2.2. AIM Template Builder tabs

................................
................................
..........................

17

2.3.

A
SSUMPTIONS

................................
................................
................................
......................

17

2.4.

D
EPENDENCIES

................................
................................
................................
....................

17

3.

SYSTEM
-
LEVEL REQUIREMENTS

................................
................................
...........

18

3.1.

F
UNCTIONALITY FOR
F
IRST
D
EVELOPMENT
I
TERATION

................................
.......................

18

3.2.

P
ERFORMANCE
................................
................................
................................
.....................

21

3.3.

Q
UALITY
C
ONTROL

................................
................................
................................
.............

21

3.4.

“S
UPER USER


AND
S
ERVICE
S
UPPORT

................................
................................
................

21

3.5.

U
PGRADE
/

T
RANSITION

................................
................................
................................
.......

22

3.6.

S
ECURITY

................................
................................
................................
............................

22

3.7.

R
EQUIREMENTS FOR
S
UBSEQUENT
I
TERATIONS

................................
................................
...

23

4.

DEPLOYMENT MODEL(S)

................................
................................
...........................

23

4.1.

B
IOPORTAL
I
NTEGRATION
L
IBRARY

................................
................................
....................

23

5.

IMPLEMENTATION CONSI
DERATIONS AND RECOMM
ENDATIONS FOR
TECHNICAL REALIZATIO
N

................................
................................
................................
.

26

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

3

of
27

1.

Executive Summary

The purpose of the QI
-
Bench project is to aggregate evidence relevant to the process of
implementing imaging biomarkers to allow sufficient quality and quantity of data are
generated to support the responsible use of these new tools in clinical settings. T
he
efficiencies that follow from using this approach could translate into defined processes
that can be sustained to develop and refine imaging diagnostic and monitoring tools for
the healthcare marketplace to enable sustained progress in improving healthc
are
outcomes.

There are four innovative aspects of the proposed work:
We make formal
specification accessible to diverse group
s

of experts that are not skilled or
interested in knowledge engineering.

Algorithm to elicit formal specifications from
non
-
eng
ineering experts without background or interest in formal knowledge
representation suitable for creating SPARQL endpoints to establish context for rigorous
hypothesis testing, find reference data, etc. The key is to bring level of rigor to the
problem spac
e in such a way as to facilitate cross
-
disciplinary teams to function without
requiring individuals to be experts at the representation of knowledge, inferencing
mechanisms, or computer engineering associated with grid computing or database
query design.
W
e map both medical as well as technical domain expertise into
representations well suited to emerging capabilities of the semantic web.

The
proposed project captures functionality improved from the currently available data
integration mechanisms such as in

caGrid and caBIG. It
explores how a linked data
interface can be created from an object
-
oriented data interface based on a UML model,
annotated with CDEs according to the ISO
-
11179 metadata registry metamodel
standard. The experience could illuminate best

practices for combining a semantic web
approach on the data interface layer with a model
-
driven approach for software
development, especially since Common Data Elements are widely used to annotate
Case Report Form (CRF) templates for clinical research
.
We

address the problem of
efficient use of resources to assess limits of generalizability.

The canonical
example of statistical validation is when sufficient statistical power either proving or
disproving a hypothesis is met, usually stated along with a char
acterization of variability
under defined scenarios. Determining the biological relevance of a quantitative imaging
read
-
out is a difficult problem. First it is important to establish to what extent a read
-
out
is an intermediate end
-
point capable of being
measured prior to a definitive endpoint
that is causally rather than coincidentally related. Second, given the combinatorial
complexity that arises with a multiplicity of contexts for use coupled with the cost in time
and resource to experimentally interr
ogate the space fully, a logical and mathematical
framework is needed to establish how extant study data may be used to establish
performance in contexts that have not been explicitly tested
. E
xisting capabilities only
rarely relate the logical world of ontology development with the biostatistical analyses
that characterize performance.
E
xisting tools do not permit the extrapolation of
statistical validation results along arbitrary ontology hie
rarchies. Despite decades of
using statistical validation approaches, there is no methodology to formally represent
the generalizability of a validation activity.

Mix of biological and statistical inference: use
of “strength” on otherwise binary relations,

merge of two fields each of which is
QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

4

of
27

necessary to assess limits of generalizability using an economic use of resources.
We
provide the capability in a manner which is accessible to varying levels of
collaborative models, from individual companies or insti
tutions to larger
consortia or public
-
private partnerships to fully open public access.

Doing it open
source allows……………………

1.1.

Purpose and Scope

Specifically, the “
Specify”

app is developed to allow users to:




Specify context for use and assay methods.



Use c
onsensus terms in doing so.

From a technology point of view,
Specify

refers to the part of the project most closely
associated with Stanford, comprising the Protégé, BioPortal
, and Ruby
-
on
-
Rails
application that build the internal representation to specify quantitative imaging
biomarkers and assay methods.


This representation is used downstream.


Our ideas
associated with the
“Profile Editor” live here
(which itself derives
fr
om the name for
QIBA profiles but which
has generalized
beyond that now).

We will leverage the
existing semantic
annotations in caDSR
for these data sources
and APIs, while
exploring touchpoints
with domain ontologies
(such as the BRIDG or
LS
-
DAM at NCI, o
r OBO Foundry domain ontologies) through various mechanisms such
as the NCI Thesaurus and the NCI Metathesaurus which contains 17 million
relationships between concepts compiled from 76 different terminology sources
enabling the data to be integrated with
other linked data in the translational research
community such as the 30 billion triples currently in Bio2RDF, or the
investigation/study/assay datasets available from EBI and NCBI conformant to ISA
-
TAB
and MIBBI standards and annotated to OBO Foundry doma
in ontologies.

Building
on

NCBO‘s BioPortal, we create a system that addresses the

indicated
drawbacks. BioPortal encapsulates disparate ontologies and related annotated data in
one common interface available via REST Web service,
and we build an application
on
top of these services

that work

with any ontology in BioPortal


including QIBO

and
those linked through it
. The ontology library is separately curated and updated by the
administrators of BioPortal, decoupling us from the un
derlying representation and

Figure
1
: Semantic workflow supported by the work.

Quantitative Imaging
Specification Language
Batch Analysis
Service
Reference Data Set
Manager
UPICT Protocols, QIBA
Profiles, literature
papers and other
sources
QIBO
-
BatchMake
Scripts
Reference Data Sets, Annotations, and
Analysis Results
(red edges
represent
biostatistical
generalizability)
Source of clinical study
results
Clinical Body of Evidence
(formatted to enable
SDTM and/or other
standardized registrations
4. Output
3. Batch analysis
scripts
UPICT Protocols, QIBA
Profiles, entered with
Ruby on Rails web
service
QIBO
QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

5

of
27

versioning of the ontologies
.The application meets Aim 1, and the output of this is an
RDF store.

Likewise,
the
Formulate

application is built to utilize the RDF store for the formulation of
testable hypotheses and data querie
s as well as to execute such queries to form
reference data sets. This application may be viewed as an extension of current
capabilities of caB2B and caIntegrator, however taking a different approach to close the
gaps described ab
ove.

The text below needs

to be written better but it embeds the concepts:

…using terms and expressions that draw from community efforts to distill medical and
technical knowledge and that represents these specifications in such a way as to enable
the logical inference of testable

hypotheses and which provides a basis for powerful
queries to collect reference data sets. Formalize means by which existing Quantitative
Imaging Biomarker ontology (QIBO) will be extended to relate and link to other
established ontologies such as Foundat
ional Medical Anatomy (FMA), Gene Ontology
(GO), SNOMED and RADLEX.

Convert the existing triple store produced by QI
-
Bench to a W3C compatible RDF store.
Map publicly accessible data sources residing in a relational database, to a linked data
interface usi
ng semantic annotation based on BRIDG and LSDAM ontologies and other
standard domain ontologies. Various approaches such as D2R, object (Hibernate) to
SPARQL, or CQL to SPARQL will be considered.


The approach will be implemented in
software with accompany
ing documentation.

Create publicly accessible, free and open
source web applications to build and use specifications for quantitative imaging
biomarkers:

Extend existing application specify.qi
-
bench.org to build backend database
using RDB/RDF SPARQL, inclu
ding integration of AIM Template Builder and
question/answer paradigm utilizing the relations of the Quantitative Imaging Biomarker
Ontology and linked ontologies on BioPortal.


Such application to be deployable either
as a web service or as a local instan
ce of the functionality for more sophisticated users.

Review of BRIDG and LSDAM conceptual UML models. Determine an approach to
convert these UML models into an OWL ontology, with appropri
ate class and property
axioms, in a technical proposal.
Review of cu
rrent
caTissue, caArray, NBIA and AIM
UML models,

associated CDEs and underlying NCI
t and other ontology concepts. As
necessary, explore use of NCI Thesaurus and Metathesaurus to create touchpoints
with
concepts from BRIDG and LSDAM ontologies and other s
tandard domain ontologies
such as from OBO Foundry.

Software application to build backend database using RDB/RDF SPARQL, including
integration of AIM Template Builder and question/answer paradigm utilizing the relations
of the Quantitative Imaging Biomarke
r Ontology and linked ontologies on BioPortal.
Such application
to be deployable either as a web service or as a local instance of the
functionality for more sophisticated users
.

Utilizing existing NCBO services as linked by the Quantitative Biomarker Ont
ology (ref
linked sister paper), we support the following novel use case. Using a Web
-
tool written
using Rails, the user uploads associations to textual descriptions <NEED TO LAY THIS
OUT BETTER> (Step 0). For example, a user can submit a UPICT PROTOCOL… Q
IBA
QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

6

of
27

PROFILE… PAPER FROM LITERTURE… COOPERATIVE GROUP PROTOCOL….
We invoke the NCBO Annotator service to process these textual descriptions and
assign ontology terms to the element identifiers [
6
,
7
].

The task is to create SPARQL endpoints for a subset of the caGrid
and caBIG
data
services, using the semantic annotation based on the CDEs
and the underlying
controlled terminologies, and to
use the
se endpoints to demonstrate the ability to
discover and meaningfully integrate discovered data in the context of addressing
relevant, data
-
dependent questions posed by users, questions that could n
ot be
answered without the discovery and analysis of the endpoint
-
accessible

data. The
subset of the
data services chosen for this task would depend on the level of resources,
the
ir expertise and interests,
the usefulness and impact of the underlying data
,

and the
needs of the use case
.
Candidates as described in the use case previously, include
caArray, caTissue, NBIA, AIM and PODS services.

The UML model with the
current
CDE annotation to NCI Thesaurus concepts
will be leveraged as fully as possible, whil
e
exploring touchpoints
to the caBIG Domain Analysis Models (e.g. BRIDG, LS
-
DAM) or
to other community standard domain reference ontologies
, through the NCI Thesaurus
and the NCI Metathesaurus, as well as other concept mapping resources such as the
NCBO Bi
oPortal
. The goal is to maximize the utility and impact of linking this data to
other RDF data to generate translational scientific discoveries.

Most literally,
Specify

would be packaged in two forms: 1) as a web
-
service linking to
the databases on the pro
ject server dev.bbmsc.com; and 2) as a local installation/

instance of the functionali
ty for more sophisticated users.

1.2.

Terms Used in This Document

The following are terms commonly used that may of assistance to the reader.

AAS


Application Architecture
Specification

ASD


Application Scope Description

BAM


Business Architecture Model

BRIDG

Biomedical Research Integrated Domain Group

caBIG


Cancer Biomedical Informatics Grid

caDSR

Cancer Data Standards Registry and Repository

CAT


Composite Architecture Te
am

CBIIT


Center for Biomedical Informatics and Information Technology

CFSS


Conceptual Functional Service Specification

CIM


Computational Independent Model

DAM


Domain Analysis Model

EAS


Enterprise Architecture Specification

ECCF


Enterprise Conformanc
e and Compliance Framework

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

7

of
27

EOS


End of Support

ERB


Enterprise Review Board

EUC


Enterprise
Use
-
case

IMS


Issue Management System (Jira)

KC


Knowledge Center

NCI


National Cancer Institute

NIH


National Institutes of Health

PIM


Platform Independent Model

PSM


Platform Specific Model

PMO


Project Management Office

PMP


Project Management Plan

QA


Quality Assurance

QSR


FDA’s Quality System Regulation

SAIF


Service Aware Interoperability Framework

SD
D


Software Design
Document

SIG


Service Implementation Gui
de

SUC


System Level Use
-
case

SME


Subject Matter Expert

SOA


Service

Oriented Architecture

SOW


Statement of Work

UML


Unified Modeling Language

UMLS


Unified Medical Language System

VCDE


Vocabularies & Common Data Elements

When using the template,
extend with specific terms related to the particular EUC being
documented.

2.

Structure of the Application



Describe the application in macro and its overall organization



Include an executive summary of the overall application workflow (e.g., a concise
overal
l description of the responsibilities of this application, and the roles (if any)
that it plays in interaction patterns such as client
-
server, service
-
to
-
service, etc.)



Enumeration of the behavioral interfaces that are known to be needed, with a
concise
descript
ion of each

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

8

of
27



Consider representation formalism and the intended audience, not necessarily
rigorously expressing the content in UML


Related

Work:
caBIG.
The
Cancer Biomedical Informatics Grid (caBIG)

supports
sharing and querying of cancer research
data enabled by semantic annotation and
secured access control. Data shared spans the translational spectrum from
-
omics to
tissue biospecimens to images to clinical research to patient outcome. The federated
data
and analytical
service infrastructure (
caGrid
) is based on the Globus Toolkit from
the Argonne National Laboratory. Each data service exposes an object
-
oriented
interface based on a UML model, with attributes annotated to controlled terminologies
(primarily the
NCI Thesaurus
) by Common Data Elements (CDEs) from the
Cancer
Data Standards Registry and Repository (caDSR)

which is based on an
NCI
implementation of the ISO
-
11179 metadata registry metamodel
. The NCI
-
developed
object
-
oriented querying languages for the data service interfaces include the caGrid
Querying Language (CQL) and the Distributed caGrid Querying Language (DCQL).

Whi
le caGrid provides a secured and semantically enabled framework for data sharing
and querying, data integration is on the logical level by matching caDSR CDEs. Three
specific development areas of caBIG serve as prior work for this purpose. The
Annotation
and Image Markup (AIM) project, in particular the AIM Template Builder, the
caB2B (cancer “Bench to Bedside”) application, and the “caIntegrator” applications
serve as starting points that has applicable aspects and serve as points of departure.
Besides th
ese applications and caGrid on which they are based, additional data are
also accessible through individual Java, SOAP and REST
-
based APIs, for example
APIs generated by the
caCORE Software Development Kit (S
DK)
.


Figure
2
. Left

Panel
:
Quantitative Imaging Biomarker Ontology (QIBO)
QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

9

of
27

Relate
d

Work:
Quantitative Imaging Biomarker Ontology (QIBO).

Biomedical studies generate rich
and diverse types of imaging data, spanning from high
-
resolution microscopy images to
fluorescence imaging to nanoparticle
-
based

imaging.
The rich information in imagin
g
extends far beyond the numerical values of the pixels

it involves describing

imaging
biomarkers that are indicators of the underlying biology

of interest
. Fully specifying an
imaging biomarker involves a series of heterogeneous concepts that span the fie
lds of
imaging physics, probe chemistry,
molecular
biology, quantitation techniques
, and
more
.
To provide a means for these descriptions, we have built an ontology
[
1
]

a
hierarchical framework that represents concepts

in a specific domain

as

well as
relationships between concepts
[
2
]
.
This

ontological structure is an ideal framewo
rk for
integration of hete
rogeneous and complex knowledge about imaging
.

B
y formally
defining concepts and synonyms of concepts in
the imaging domain
,
QIBO

facilitates
elimination of terminology variation and ambiguity, and thus can be used to link data
an
d knowledge from different sources
. (Note that
RadLex
is related but focuses on
radiologist interpretations instead

[
3
]
).
We have built
QIBO using Web
Ontology
Language (OWL) in

Protégé
-
OWL
, a

commonly
used ontology
authoring

tool
[
4
-
6
]
.
Protégé
-
OWL provides description logic reasoning capability with high
ly

expressive
power.
Not

only classes can be asserted
explicitly

in the ontology, but necessary and
sufficient conditions can be defi
ned to specify new classes, where
an automated

classifier can run to generate
an
inferred hierarchy. OWL allows for powerful knowledge
reasoning, and thereby is suitable to convey complexity and richness

in imaging
biomarker research.

QIBO

integrates knowl
edge in different fields represented by
several
upper classes, including
:

Imaging Subject, Biological Intervention, Imaging
Agent, Biological Target, Imaging Technique, Imaging Device, Post
-
processing
Algorithm, Indicated Biology, Quantitative Imaging Biom
arker, and Biomarker Use
[
1
]
.

Context
.
The purpose of
QI
-
Bench

is to aggregate evidence relevant to the process

of
characterizing and optimizing

imaging biomarkers.
W
e are developing resources that
enable many parties to better exploit available data, and a neutral broker resource that
could provide developers and regulators with unbiased and objective data
demonstrating performance.
QI
-
Bench
provide
s

the cap
ability to

analyze massive data
sets rather than the smaller numbers that are typically analyzed in literature reports.
And to do so according to analytical methods that are accepted broadly rather than
being idiosyncratic to individual studies.
The vision is to
dep
loy the software, both as
web
-
accessible resource
s

for collaborative community effort

or as
instances that
may
be used within individual organizations for their own purposes.


developed in Protégé
-
OWL
. Right

Panel
: A
complete
view of the IS_A
hierarchy of the 490 classes in QIBO.

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

10

of
27




Figure
3
.
Left panel: Access to QI
-
Bench, which is composed of five applications, is supported at
www.qi
-
bench.org
. The first two


Specify

and
Formulate



are tightly linked and result in specified reference data
sets being c
ollected
.

Downstream applications include
Execute
,
Analyze
, and
Package
. Middle panel: The
current prototype of
Specify

includes a question
-
answer paradigm driven capability using BioPortal to create
a triple store. Right panel: The
Specify

prototype also incorporates the Aim Template Builder.

Two early prototypes of the
Specify

application

have been produced. The first utilized
a .XSLT based schema to describe a structured template for data entry from domain
experts to describe imagin
g applications in standard terms, but it was not linked to
ontologies. The second prototype utilizes REST services to link to ontologies on
BioPortal, including QIBO, and creates stores triples in a database based on using the
QIBO to guide a question
-
ans
wer paradigm for interacting with domain experts to create
an early version of what this proposal would turn into W3C
-
compliant SPARQL
endpoints. This prototype has been created by starting from the early version of the
AIM Template Builder so as to inten
tionally provide the opportunity to merge database
schemas, as part of the specification for a quantitative imaging application includes a
computable as well as user
-
accessible versions of the template under which actual
measurements will be made, whether

algorithmically or user
-
based. The Likewise, an
early prototype for the second application
Formulate

has been written, using CQL on
caGRID.


QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

11

of
27

The behavioral model is understood in the context of the following logical
information

model:


QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

12

of
27

Specify

is defin
ed as an implementation of the following behavioral model:


2.1.

Datastores

2.1.1.

Quantitative Imaging Biomarker Ontology (QIBO)

knowledge representation for quantitative imaging biomarker concepts and relations

(see vvv.doc)

2.1.2.

Linked Ontologies

existing ontologies
like FMA, Snomed, Radlex, GO, …

2.1.3.

Biomarker DB

linked concept instances that represent biomarkers

2.2.

Activities

Activity

Model

View

Controller

consider concepts,
relations, or properties

State of Biomarker
DB at any given time
may be displayed.

Views are
defined to
display Biomarker DB
contents.

Contents of Biomarker
DB may be made
available to local or
remote viewers.

curate new knowledge
representation

QIBO is static except
that requests may be
made to extend it.

Existing concepts and
relations are
displayed
but also a blank that user
may choose to fill in.

If a user chooses to fill in
the blank, then an email
is generated to the
curator for their
consideration.

decide if new or existing
biomarker

Existing Biomarker
DB entries may be
Views for a listing of
existing entries, an edit
If a request is made to
add, the user’s certificate
QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

13

of
27

Activity

Model

View

Controller

edited or new o
nes
added.

panel, and an add panel
for any given concept.

is checked to see if they
are authorized to do so.

specify clinical context
(either as first for

new
biomarker or as
additional for existing
biomarker)

QIBO elaborates
concepts for clinical
context, including
links to FMA,
Snomed, and GO.

Views dynamically
update for new or
modified instances of
concepts for clinical
context using Bioportal
services.

See ontology traversal
algorithm.

specify assay method
(either as first for new
biomarker or as
additional for existing
biomarker)

QIBO elaborates
concepts for assay
methods, including
link to Radlex.

Views dynamically
update for new or
modified instance
s of
concepts for assay
methods using Bioportal
services.

See ontology traversal
algorithm.

2.2.1.

Question
-
Answer Paradigm for Engaging Domain Experts
(QISL tab)

The use case we are working to implement in Rails, expressed as pseudo
-
code, is as
follows:

1.

We
start a term from the Quantitative Imaging Biomarker Ontology, which is
stored in BioPortal.

2.

Perform a query to determine its relations, or stated differently, the relations
having this term in their Domain.

3.

For each such Relation:

a.

Perform a query to
determine what terms are in the Range of the given
Relation.

b.

Prompt the user to select from among the terms (by providing them a pick
list).

c.

If the selected term has children in the is
-
a hierarchy, we allow the user
either to stop at the term or traverse d
own the is
-
a hierarchy at their
discretion.

d.

If the term is identified as being searchable in another ontology (i.e.,
instead of being fleshed out in QIBO), provide the pick list from that
ontology (including the ability to select from among the children a
s
desired).

i.

Store a “triple” with the

term of step 1, the relation at step 3, and
the selected term of this step (regardless of how deep in the is
-
a
hierarchy they went to select it).

e.

Else, for the selected term in the QIBO we recurse starting again at st
ep 1
above (which has the effect of navigating the ontology using the relations
identified in it to enumerate a sequence of terms for disparate concepts
QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

14

of
27

but through the links, and for each term allowing as deep or shallow into
the respective is
-
a hierarchi
es as desired by the user).

Thus
, we don’t desire a full hierarchy when we make the query, rather we just need the
“short list” of relations for which this term is in the domain (at step 2); the set of terms in
the domain for this relation (at step 3a); a
nd the set of terms (only) one
-
level deeper in
the is
-
a hierarchy (at step 3c).


We wish to pull this data dynamically from the ontology at run
-
time.


This algorithm would build a dynamic display


and a database to match it


according
to the structure id
entified by following the relations.

2.2.1.1.

Implementation

The QISL tab is an extension of the AIM Template Builder. The intent of the QISL tab is
to provide access to ontologies that are defined in Bioportal, navigate the hierarchy of
those ontologies and create

Triples.


The Files:

app/controllers/bioportals_controller

app/views/bioportals/_definition.erb

app/views/bioportals/_definition_terms.erb

app/views/bioportals/_get_ontology.erb

app/views/bioportals/_get_term_details.erb

app/views/bioportals/_get_terms.erb

app/views/bioportals/_get_triples.erb

app/views/bioportals/create_triple.js.erb

app/views/bioportals/delete_triple.js.erb

app/views/bioportals/get_ontology.js.erb

app/views/bioportals/get_term_details.js.erb

app/views/bi
oportals/get_terms.js.erb

app/views/bioportals/show.erb


Features & Usage:

Select an ontology

-

The first step is to select an ontology from the full set of
Ontologies stored on Bioportal. Currently this list is hard coded. In a future release this
list wi
ll be stored and managed in the database, and a script can be executed to get the
latest versions of ontologies from Bioportal. The purpose for hard coding and eventually
moving to the database is simply for speed, requesting the ontology list from Bioport
al
takes several seconds.

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

15

of
27

Navigate the Ontology Hierarchy

-

When an ontology is selected from the drop down
list the root terms for that ontology appear in the rightmost pane. Using the "+" link to
the left of a term a list of child terms will appear belo
w and to the right of the current
term, thus creating a tree structure. By clicking on a term in the hierarchy the right pane
is replaced with the term details, which currently consist of the Properties and a URL to
the XML representation of the term on Bi
oportal, which is mainly there for debugging
and reference purposes. In the future we may provide additional details on the term like
description, comments and the non relational or green properties, once they are
available through the Bioportal service.

C
reate a triple

-

With a term selected in the right pane, a list of properties is displayed
and the associated Range for that property is show below and to the right of the
property. The "+" signs can be used to navigate the hierarchy as before until the co
rrect
Term is found in the range to create the triple. Once the Term is found the "(+)" button
can be used to create and store a triple in the database. All stored triples appear in the
left most pane on the screen. This interface is a proof of concept for

generating triples.
We plan to make adjustments to the UI to make it more intuitive and functional as the
project progresses. For instance begin able to access and set additional static
properties for triples as well as improving the overall drill down in
terface to make the
most of the screen.

Managing Triples

-

The left pane is used to manage the Triple store in the database.
Currently the only functionality is to view the triples for the selected ontology and to
remove triples from the store by clicking
the "(
-
)" buttons. Eventually this will support
setting additional properties for a given triple as well as improved navigation from a
triple.

Navigation Algorithm:

The tree algorithm for navigating the hierarchy is accomplished using
get_terms

method in t
he BioportalsController for QISL. Given a term id the system will use the
Bioportal integration library to access this details on the term as well as the children of
the term. Then is builds an HTML list object <ul><li></li>…</ul> to represent the
children

in the list. If a child term has children it will add a "+" link that can be used to
drill further into the children of that term. Here is some basic pseudo code that would
drill through 3 layers of the hierarchy. This is illustrated using a 3 level deep
loop, the
true algorithm uses the recursive get_terms method to be able to navigate an infinite
number of levels.

Example hierarchy 3 levels deep:

# establish a connection with the server

server = Bioportal(:apikey => "6d3a093c
-
f01e
-
4003
-
b616
-
adcc5889a7fb"
)

# retrieve the latest version of the QIBO ontology

ontology = server.get_ontology(46348)

# traverse the root terms of the ontology

ontology.get_terms.each do |root_term|

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

16

of
27


puts root_term.label


root_term.get_children.each do |child1|


put
s "
\
t" + child1.label


child1.get_children.each do |child2|


puts "
\
t
\
t" + child2.label


child2.get_children.each do |child3|


puts "
\
t
\
t
\
t" + child3.label


end


end


end

end


# results:

Imaging Agent


Photoactivatable Imaging Agent


Caged_Fluorescent_Dye_Label


Photoswitchable fluorescent protein


Imaging Agent


Caged_Fluorescent_Dye_Label


Photoswitchable fluorescent protei
n


Small Molecule


Nucleotide


Amino Acid


Monosaccharide


Small Molecule


Chemical


Chemically Synthetic Molecule


Antibody mimetic


Vitamin

….

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

17

of
27

2.2.2.

AIM Template Builder

tabs

Medical knowledge contained within an imaging report is stored in
an
unstructured text
format and separated from graphical drawings, typically in a proprietary format on an
imaging system. Extracting valuable medical information from
unstructured

tex
t and
combining
it
with drawings from those sources are both time consuming and
cumbersome to filter and search.

The caBIG® Annotation and Image Markup (AIM)

information model

is used to express
and capture image annotation and markup information relevant to images. An
annotation can
contain

explanatory or descriptive information

that was
generated by
humans or machines that directly relates to the content of a referenced image

or
images. It describes information regarding the meaning of pixel information in images.
An image markup
includes

the graphical symbols or textual descriptions associated with
an image. Markups can be used to

visually

depict textual information and regio
ns
-
of
-
interest (graphical drawing)
next to,

or more typically
on top of
, an image. Information
from annotations and markups are used to populate

an

AIM instance via the AIM
software library for the purpose of generating AIM DICOM SR objects and AIM native
XML documents.

The

AIM template XML schema allows an expert to create an XML document containing
controlled questions and answers based on known vocabularies such as SNOMED CT,
RadLex, LOINC,
and

user
-
defined terminologies.

This project has two main object
ives.
The first
is to enhance
the
AIM 3.0 XML template
schema to
include

other elements in AIM 3.0 that
were

not
included

by the first AIM 3.0
XML template schema. The second
objective

is to improve the existing AIM Template
Manager

web application
by appl
ying

the new XML template schema,
addressing
feedback from users of the
AIM Template Manager
demonstration application
,

and
implementing
new requirements

for the application
.

2.3.

Assumptions

In this section please address the following questions:



Upon what se
rvices does this specification depend (underpinning infrastructure,
other HL7 services, etc)



Are there any key assumptions that are being made?

2.4.

Dependencies

List of capabilities (aka responsibilities or actions) that the application’s workflow
depends o
n and description on what it does in business terms.

Description

Doc Title

Doc
Version

<business friendly description>

<document title>

<document
version>

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

18

of
27

3.

System
-
level Requirements

Note that, the normal process of requirements development does not
guarantee that
adjacent requirements are directly related. In situations where requirements are tightly
related or where requirements are to be considered in the context of an upper level
requirement, explicit parent
-
child relationships have been created.

These can be
identified by the requirement numbering


child requirements have numbers of the form
XX.Y indicating the Y
th

child of requirement XX.

The following list of attributes is used:



Origin


Identifies the project or Enterprise Use Case that ori
ginated the
requirement.



Comment / TI


Additional information regarding the requirement. This may
include information as to how the requirement may be tested (i.e. the test
indication).



Design Guideline


Used to identify requirements that are to be tak
en as
guidance or are otherwise not testable. In such cases the phrase “Not a testable
requirement” will appear.

Requirements may, and often do, apply to multiple components. In such cases, the
Component attribute will identify all components where the r
equirement applies
(including components that do not apply to this Enterprise Use Case).

The Origin of a requirement is intended to identify the program for which the
requirement was originally defined. Often this is SUC (System Use Case) but it may be
di
fferent.

3.1.

Functionality

for First Development Iteration

Model
:
Requirements placed on input, output, or significant intermediate data used by
the application.

View
: Supported views and other GUI requirements. Note: use of figures for screen
shots is encoura
ged as necessary to show an essential feature, but not to show
unnecessary implementation detail.

Controller
: Functional requirements on logical flow.

Requirements

Origin

Model

View

Controller

Activity: Consider concepts,
relations, or properties

EA

State

of
Biomarker DB
at any given
time may be
displayed.

Views are defined
to display
Biomarker DB
contents.

Contents of
Biomarker DB may
be made available
to local or remote
viewers.

Need a platform
-
independent
image metadata template editor to
enable the community to define
custom templates for research and
clinical reporting.


SUC




QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

19

of
27

Requirements

Origin

Model

View

Controller

There will be ultimately be a tie in
to eCRF.

SUC




Relationship to external
knowledge sources
(e.g.,
ontologies) needs to be understood
and links are made.


SUC




Activity: Curate new knowledge
representation

EA

QIBO is static
except that
requests may
be made to
extend it.

Existing concepts
and relations are
displayed but
also a blank that
user m
ay choose
to fill in.

If a user chooses
to fill in the blank,
then an email is
generated to the
curator for their
consideration.

<curation takes place in Protégé,
not part of QI
-
Bench directly.>


SUC




Activity: Decide if new or existing
biomarker

EA

Existing
Biomarker DB
entries may be
edited or new
ones added.

Views for a listing
of existing
entries, an edit
panel, and an
add panel for any
given concept.

If a request is
made to add, the
user’s certificate is
checked to see if
they are authorized
to d
o so.

Means for extending Annotation
Tool templates so that new
experiments can be supported
without programming on the
application (workstation) side is
required.


SUC




Once a template is created, any
workstation will simply select it to
enable
Reference Data Set per the
template.

SUC




Scientist identifies novel
measurement, observation,
processing step, or statistical
analysis method.


SUC




Scientist defines new data
structures.

SUC




Interaction between biology and
the intended imaging
process are
sufficiently understood to discern
what is needed to mimic expected
behavior.


SUC




Activity: Specify clinical context
(either as first for new biomarker
or as additional for existing
biomarker)

EA

QIBO
elaborates
concepts for
clinical
context,
including links
to FMA,
Snomed, and
GO.

Views
dynamically
update for new or
modified
instances of
concepts for
clinical context
using Bioportal
services.

See ontology
traversal algorithm.

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

20

of
27

Requirements

Origin

Model

View

Controller

Describe the patient population
characteristics, which
determine
how general the study is, and
therefore the importance of the
result. The study design should
include how to capture the data to
back up claims about the patient
population characteristics.


SUC




A mechanistic understanding or
“rationale” of
the role of the
feature(s) assessed by the imaging
test in healthy and disease states is
documented.

SUC




A statement of value to
stakeholders (patients,
manufacturers, biopharma, etc.),
expressed in the context of the
alternatives is understood (e.g.,
with
explicit reference to methods that
are presently used in lieu of the
biomarker).


SUC




Consensus exists on whether the
test is quantitative, semi
-
quantitative, or qualitative
(descriptive); what platform will be
used; what is to be measured;
controls; scoring procedures,
including the values that will be
used (e.g., pos vs. neg; 1+, 2+ 3+);
interpretation; etc.

SUC




The Profile is used to establish
targeted levels of performance with
means for formal data selection that
allows a batch proce
ss to be run on
data sequestered by a trusted
broker that is requested by
commercial entities that wish to
obtain a certificate of compliance
(formal) or simply an assessment of
proficiency as measured with
respect to the Profile.


SUC




Activity: Specif
y assay method
(either as first for new biomarker
or as additional for existing
biomarker)

EA

QIBO
elaborates
concepts for
assay
methods,
including link
to Radlex.

Views
dynamically
update for new or
modified
instances of
concepts for
assay methods
using
Bioportal
services.

See ontology
traversal algorithm.

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

21

of
27

Requirements

Origin

Model

View

Controller

High
-
level descriptions of the
processing hardware and software,
highlighting potential weaknesses,
should be provided.


SUC




Detailed descriptions of the
procedures to be used for image
acquisition
, analysis and
interpretation of the quantitative
imaging biomarker as a clinical
metric should be included.

SUC




Procedures to be used when
results are not interpretable or are
discrepant from other known test
results must be described; this is
especially important for imaging
tests used for eligibility or
assignment to treatment arms.


SUC




Develop a standardized schema
for validation and compliance
reports. Ensure consensus on the
XML schema is attained with all
QIBA participants.

SUC




3.2.

Performance

Non
-
functional requirements, such as how fast a capability needs to run.

Requirements

Origin

Comment / TI

Design
Guideline

User interface display and update time needs to feel quick.

AAS

Implication is that can’t
load whole ontologies
but
rather work
incrementally.


3.3.

Quality Control

Support for internal and/or external quality control.

Requirements

Origin

Comment / TI

Design
Guideline













3.4.


“Super user” and Service Support

Additional capabilities needed by privileged users.

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

22

of
27

Requirements

Origin

Comment / TI

Design
Guideline

Need a way to assess irregularites in QIBO and/or Biomarker
DB instances and to rectify them.




















3.5.

Upgrade / Transition

Requirements to support legacy and/or prior versions.

Requirements

Origin

Comment / TI

Design
Guideline

Need to devise a means for orderly update as QIBO concepts
come and go




































3.6.

Security

Applicable security compliance requirements.

Requirements

Origin

Comment / TI

Design
Guideline

User certificate needs to distinguish between view
-
only,
authorized to create Biomarker DB instances, authorized to
edit existing instances, and to curate QIBO.
































QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

23

of
27

Requirements

Origin

Comment / TI

Design
Guideline





3.7.

Requirements

for Subsequent Iterations

Defined in the SUC but not yet staged for implementation.

Requirements

Origin

Comment / TI

Design
Guideline





































4.

Deployment Model(s)



Relevant and representative examples of deployment scenarios


4.1.

Bioportal
Integration Library


Description:

Bioportal is a wrapper class for the NCBO Bioportal REST service documented here:
http://www.bioontology.org/wiki/index.php/BioPortal_REST_services
. The main class
Bioportal is a simple front end that keeps some basic state and server information to
make navigating and working with the BioPortal services easier. After setting up a
conne
ction with their server by passing an API key the user can then perform functions
like pulling a list of ontologies, get details on a specific ontology, navigate the terms of
that ontology, and get properties for that ontology. Further development is neede
d in
accessing both the green and blue properties as the Bioportal service adds support for
them. Also there are some caching issues which need to be addressed so the same
content is not requested repeatedly.


Files:

lib/bioportal.rb

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

24

of
27

lib/bioportal/ontology
.rb

lib/bioportal/property.rb

lib/bioportal/term.rb


Bioportal REST services used:

ontologies

-

http://www.bioontology.org/wiki
/index.php/BioPortal_REST_services#List_all_the_latest
_version_of_ontologies

example url:
http://rest.bioontology.org/bioportal/ontologies?apikey=YourAPIKey

returns a list o
f all the latest versions of ontologies stored in Bioportal


terms/concepts

-

http://www.bioontolo
gy.org/wiki/index.php/BioPortal_REST_services#Get_term.2C_incl
uding_its_properties.2C_subclasses.2C_and_superclasses

example url: http://rest.bioontology.org/bioportal/concepts/44103?conceptid=O80
-
O84.9&apikey=YourAPIKey

Returns details on a specific term
or concept in the ontology, providing access to
properties, superclass, subclass and other information about that term.


properties

-

http://www.bioont
ology.org/wiki/index.php/BioPortal_REST_services#Property_Services

example url:
http://rest.bioontology.org/bioportal/ontologies/properties/38801?apikey=You
rAPIKey

Returns a set of available properties for a given ontology, it is not possible to get a
simple list of properties associated with a given term.


Using Bioportal Library:

Create server connection

-

The first thing to do is create an instance of th
e Bioportal
class and specify the server and API key to use. By default the server will be
"
http://rest.bioontology.org/bioportal
" but can be overridden with a stage URL by
specifying the :base_url prop
erty. You can also enable debugging which will show all
Bioportal URL requests by setting the :show_url property to true. In order to use
Bioportal an API key must be retrieved by creating an account in Bioportal website here
http://bioportal.bioontology.org/login
. Once logged in the API key can be retrieved from
the account page.


Example Bioportal Library Usage:

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

25

of
27

require 'bioportal'

bp = Bioportal(:apikey => "6d3a093c
-
f01e
-
4003
-
b616
-
adcc5889a7fb")

bp.show_urls = true

bp.base_url = "
http://stagerest.bioontology.org/bioportal
"


# alternatively you can define all properties for the Bioportal connection in one call:

bp = Bioportal(:apikey => "6d
3a093c
-
f01e
-
4003
-
b616
-
adcc5889a7fb", :show_urls =>
true, :base_url => "
http://stagerest.bioontology.org/bioportal
")


Retrieve ontologies

-

Once a Bioportal connection has been established there are

helper functions that help provide access to the ontology information stored in Bioportal.
Namely the
get_ontologies

and
get_ontology

methods. There is also a generic
get_page

method that will return raw XML data from Bioportal.
get_page

is the main
method that handles the requests with Bioportal, all other classes use this method to
extract their data.


Example Usage:

# get a list of all ontologies and print their labels and associated version id

ontologies = bp.get_ontologies

ontologyes
.each do |ontology|


puts "#{ontology.label} (#{ontology.id})"

end


# get a single ontology based on the version id

qibo_ontology = bp.get_ontology(46348)


Getting Ontology Terms

-

From an ontology a list of terms associated with that
ontology can be r
etrieved using the
get_terms
and
get_term
methods.


Example Usage:

# get the root terms for an ontology

qibo_ontology.get_terms.each do |term|


puts "#{term.label} (#{term.id})"

end

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

26

of
27


# get a specific term in an ontology

volume = qibo_ontology.get_term
("volume")


Navigate Term Hierarchy

-

Navigating the hierarchy of an ontology can be done using
the "get_children" method. This is a quick way to access the "SubClass" hierarchy for a
given term.


Example Usage:

# get a list of all children for all root
therms and display

qibo_ontology.get_terms.each do |term|


puts "#{term.label} (#{term.id})"


term.get_children.each do |child|


puts "
\
t#{child.label} (#{child.id})"


end

end


Getting Term Properties

-

It is also possible to get the a
ssociated properties for a term
in the ontology using the
get_properties

method. The method will use the Bioportal
property services method to get all available properties for an ontology and then narrow
down the available properties to the ones with the d
omain of the term that is selected.


# Get a list of properties for a given term.

volume = qibo_ontology.get_term("volume")

properties = volume.get_properties

properties.each do |property|


puts "#{property.label} (#property.id) range = #{property.rang
e}"

end


5.

Implementation Considerations and
Recommendations for Technical Realization



Identification of topics requiring elaboration in candidate solutions. This may be
application
-
specific, deployment related, or non
-
functional

QI
-
Bench “Specify” AAS

Rev 0.2



BBMSC

27

of
27



This specification in the
real world (e.g., relationships to existing infrastructure,
other deployed services, dependencies, etc.)