"Specify" Architecture Specification - QI-Bench

goldbashedΤεχνίτη Νοημοσύνη και Ρομποτική

15 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

234 εμφανίσεις

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

1

of
28


QI
-
Bench
Specify

Architecture Specification


June 2012

Rev
0.5






Required Approvals:

Author of this
Revision
:

Andrew J. Buckler






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

0.3

AJ
Buckler

Additional design detail

December 2011

0.4

AJ Buckler

To close iteration 1

June 22, 2012

0.5

AJ Buckler

Prep for iteration 2

June 22, 2012



















QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

2

of
28

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

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

7

2.

STRUCTURE OF THE APP
LICATION

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

8

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

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

1
7

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
U
PER 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

REALIZATION

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

26

6.

REFERENCES

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

27

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

3

of
28

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
precise semantic

specification
uncomplicated for

diverse group
s

of experts that are not skilled
proficient

in knowledge engineering

tools
.

The key is to bring a level of rigor
to the
problem space in such a way as to facilitate cross
-
disciplinary teams to function without
requiring individuals to be experts in the representation of knowledge, inferencing
mechanisms, or computer engineering associated with grid computing or datab
ase
query design.
We 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
infrastructures suc
h as caGrid and data integration approaches supported by these
infrastructures such as caB2B/caIntegrator of 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 acco
rding 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 Dat
a 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
.
Determining the
biological relevance of a quantitative imaging read
-
ou
t is a difficult problem
.
For
example, having direct tumor volumetry data in the lung and the pancreas, do these
results extend to the liver?
First
,

it is important to establish to what extent an
intermediate
marker

is in the causal pathway

to a
true

clini
cal
endpoint.

Second, given
the combinatorial complexity that arises with
multiple

contexts for use
, multiple imaging
protocols, etc.
, a logical and mathematical framework is needed to establish how extant
study data may be used to establish performance in

clinical
contexts that
were not
explicitly part of the original studies. E
xisting
tools

rarely

if ever

relate the logical world
of ontology with the biostatistical analyses that characterize
diagnostic or prognostic
performance.

E
xisting tools do not permit the extrapolation of statistical validation
results
to semantically related situations
. Despite decades of using statistical validation
approaches, there is no methodology to formally represent the generaliza
bility of a
validati
on study.
We provide
this

capability in a manner
that

is accessible to
varying levels of collaborative models, from individual companies or institutions
to larger consortia or public
-
private partnerships to fully open public access.

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

4

of
28

1.1.

Purpose and Scope

Speci
fy

is developed to allow users to:




Specify context for use and assay methods.



Use consensus terms in doing so.

We develop a semantic framework that will enable domain experts to provide
semantically bountiful specifications (without struggling with unfamiliar knowledge
engineering techniques) and to formulate natural language
-
like queries based on them
to discover
and collect reference data sets supporting testable hypotheses (Fig. 3).
BioPortal
catalogs and
stores

disparate
ontologies and
offers
REST
ful

w
eb service
s
to access annotated
data
[
1
]
. We build on

top of these services

that work

with any

ontology in NCBO’s
BioPortal
[
2
]
,
including
QIBO

and those linked
through it
. The
ontology
catalog

is
separately curated and
updated by the
administrators

of BioPortal, decoupling knowledge engineering experts who curate the
ontologies from domain experts who utilize the applications we create in a more user
friendly fashion to
support the use of terms and expressions that draw from community
efforts to dis
till medical and technical knowledge.

Phase II of this SBIR proposal will add
statistical robustness to the “initial annotations” using the W3C
-
recommended “N
-
ary”
relations (that generalize beyond binary “A relates to B” relations) to create statistically

enriched annotations that may be used to improve the generalizability of the
propositions
[
3
]
.


Figure 1: Overall semantic workflow supported by QI
-
Bench

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.5



BBMSC

5

of
28

Establish methods for semantically labeling imaging biomarker data

QIBO will be extended to relate and link to other established ontologies such

as
Foundational Medical Anatomy (FMA)

[
4
]
, Gene Ontology (GO)

[
5
]
, SNOMED

[
6
]

and R
ad
L
ex
[
7
]
. It also
incorporates

caTissue

[
8
]
, caArray

[
9
]
, NBIA

[
10
]

and
AIM UML model
s, associated
common
data elements (
CDEs
)

and underlying
NCIt and other ontology concepts.

We
use NCI Thesaurus
(NCIt)
[
11
]

and
Metathesaurus with concepts
from
Biomedical Research Integrated Domain
Group

(
BRIDG
)

[
12
]

and
LS
-
DAM
models
and other standard
ized

domain
ontologies such as from
t
he Open
Biological and Biomedical Ontologies
(
OBO
) Foundry

[
13
]
.

We incorporate
no
n
-
imaging data such as clinical
outcomes by mapping to concepts from
the Patient Outcome Data Service
(PODS)
[
14
]
.

Thus, we create SPARQL endpoints for discoverable data services, using
the

semantic annotation based on the CDEs and the underlying controlled
terminologies
.

Our approach will involve
two main

component
s: (1)
an ontology covering the
key concepts necessary
to
specify quantitative
imaging biomarkers and
assay methods
, and (2) an
application
(
Specify
)

that
will guide the researcher to
formulate a
set of
statements which later is
consumed by a query
engine (see Ai
m 1b) in
collecting the reference
datasets supporting
his/her hypothesis.
The
ontology
:
We

will extend
the Quantitative Imaging
Biomarker ontology
(QIBO) [see previous
work]
to

link to existing established ontologies

[
15
]

(Fig. 2
)
.
The Basic Formal Ontology
(BFO)
[
16
]

upper ontology will be leveraged to align different ontologies through a
Figure
2
. Current QIBO concepts are expanded
with those from other relevant models according
to links we have identified. (Example UML
representation shown behind the colors.)


Figure
4
: Example classes (as boxes) and relationships (as arrows)
from ontologies

targeted by this application. The direction of arrows is
from a service input to an output object. These relations align with RDF
triples generated by
Specify

as described in Aim 1a.

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

6

of
28

shared abstract level.
Furthermore
,

the necessary portions
of
the
current BRIDG and
LSDAM conceptual UML models wil
l be converted to ontology models in OWL
.

Use of
OWL will facilitate harmonization of different knowledge representations, namely UML
and OWL, into one form and furthermore allow us to leverage its broader k
nowledge
representation capability.

The UML to OWL conversion will be done either manually or
automatically depending on how much of the model needs to be converted. Automated
conversion
would

done
in two

steps
:

(1) convert current Sparx Enterprise Archite
ct XMI
for LSDAM (or BRIDG) to Eclipse Modeling Framework (EMF) UML format using a
customized version of transform libraries developed as part of the NCI
-
CBIIT Semantic
Infrastructure projec
t
[
17
,
18
]
; and
(2)

export

resulting EMF UML into a RDF/OWL
representation using TopBraid Composer
, a powerful semantic modeling environment
[
19
]
.


Figure
1
:

Specify

leverages QIBO to specify a hypothesis in the form of RDF triples stored in a
data
base (store). Formulate then
uses these triples to invoke SPARQL queries against web
services (SPARQL

end
-
points) for assembling reference data sets supporting the hypotheses.


The
application
:
Specify

will be web
-
based and help a researcher to traverse the QIBO
concepts according to their relationships (Fig. 5) and create statements represented as
RDF t
riples and stored in an RDF store. An example set of statements using QIBO will
look like
: “Find all images where:
Image

is from
Patient

AND
Patient

has age >60 AND
Patient

has
Disease

where
Disease

has value Lung Cancer AND
Patient

has
Smoking
Status

wher
e
Smoking Status

has value True.” This
translates to “
Find me all images
that are from a patient
older than 60, diagnosed with lung cancer and is a smoker
”. The
specify application leveraging QIBO will translate the above statement to a set of RDF
triples to be stored in a RDF triple store. Each set of RDF triples will be
stored as a

profile.


Formulate
Statistical Analysis
Results (Relation
strength)
Annotation and
Image Markup,
Non
-
imaging
Clinical Data
Primary Data:
Images and other
Raw Data
Reference Data Sets
QIBO
Specify
RDF Triple
Store
CT
Volumetry
CT
obtained_by
Tumor
growth
m
easure_of
Therapeutic
Efficacy
used_for
QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

7

of
28

Specify

is
packaged in two forms: 1) as a web
-
service linking t
o the databases on the
project 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


Ap
plication 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


Co
mposite Architecture Team

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 Conformance and Compliance Framework

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

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

8

of
28

SD
D


Software Design
Document

SIG


Service Implementation Guide

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

Whe
n 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
overall 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 ne
eded, with a
concise descript
ion of each



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 queryin
g 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 termin
ologies
(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 Quer
ying Language (DCQL).

While 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
QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

9

of
28

serve as starting points that has applicable aspects and serve as points

of departure.
Besides these 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 So
ftware Development Kit (SDK)
.

Related

Work: Quantita
tive Imaging Biomarker Ontology (QIBO).

Biomedical
studies generate rich and diverse types of imaging data, spanning from high
-
resolution
microsc
opy
images
to
fluores
cence
imagin
g to
nanopa
rticle
-
based

imagin
g.
The
rich
informa
tion in
imagin
g
extend
s far
b
eyond
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 fields of imaging
physics,
probe chemistry,
molecular
biology, quantitation techniques
, and more
.
To provide a
means for these descriptions, we have built an ontology
[
20
]

a hierarchical framework
that represents concepts

in a specific domain

as well as relationships between concepts
[
21
]
.
This

ontological structure is an ideal f
ramework 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 d
ata and knowledge from different sources
.
(Note that
RadLex
is related but focuses on radiologist interpretations instead

[
22
]
).
We
have built
QIBO using We
b Ontology Language (OWL) in

Protégé
-
OWL
, a

commonly
used ontology
authoring

tool
[
23
-
25
]
. 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 defined 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 complex
ity
and richness

in imaging biomarker research.

QIBO

integrates knowledge in different

Figure
2
. Left

Panel
:
Quantitative Imaging Biomarker Ontology (QIBO)
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.5



BBMSC

10

of
28

fields represented by
several
upper classes, including
:

Imaging Subject, Biological
Intervention, Imaging Agent, Biological Target, Imaging Technique, Imaging Device,
Po
st
-
processing Algorithm, Indicated Biology, Quantitative Imaging Biomarker, and
Biomarker Use
[
20
]
.

Context
.
The purpose of
QI
-
Bench

is to aggregate evidence relevant to the process

of
characterizing and optimizing

imaging biomarkers.
W
e a
re 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 an
alyze 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
deploy

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.





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 imaging applications in standard terms, but it was not linked to
ontologies. The second prototype utilizes REST services to link to ontologies on
BioPorta
l, including QIBO, and creates stores triples in a database based on using the
QIBO to guide a question
-
answer paradigm for interacting with domain experts to create
an early version of what this proposal would turn into W3C
-
compliant SPARQL
endpoints. Th
is prototype has been created by starting from the early version of the
AIM Template Builder so as to intentionally 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.5



BBMSC

11

of
28

The b
ehavioral model is understood in the context of the following logical
information

model:


QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

12

of
28

Specify

is defined as an implementation of the following behavioral model:


2.1.

Datastores

2.1.1.

Quantitative Imaging Biomarker Ontology (QIBO)

knowledge representation for q
uantitative 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
consi
deration.

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 certificat
e
QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

13

of
28

Activity

Model

View

Controller

edited or new ones
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 dynamica
lly
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 instances 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, t
he 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 down 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 t
he pick list from that
ontology (including the ability to select from among the children as
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 w
ent to select it).

e.

Else, for the selected term in the QIBO we recurse starting again at step 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.5



BBMSC

14

of
28

but through t
he links, and for each term allowing as deep or shallow into
the respective is
-
a hierarchies 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 i
n the domain (at step 2); the set of terms in
the domain for this relation (at step 3a); and 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 identified 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 ontol
ogies 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/bioportals/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 B
ioportal. Currently this list is hard coded. In a future release this
list will 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 t
o the database is simply for speed, requesting the ontology list from Bioportal
takes several seconds.

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

15

of
28

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. Usi
ng the "+" link to
the left of a term a list of child terms will appear below 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 co
nsist of the Properties and a URL to
the XML representation of the term on Bioportal, 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.

Create 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
propert
y. The "+" signs can be used to navigate the hierarchy as before until the correct
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 interface 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 triple
s 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 algor
ithm for navigating the hierarchy is accomplished using
get_terms

method in the 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. The
n 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 th
e 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.5



BBMSC

16

of
28


pu
ts root_term.label


root_term.get_children.each do |child1|


puts "
\
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


Imagi
ng Agent


Caged_Fluorescent_Dye_Label


Photoswitchable fluorescent protein


Small Molecule


Nucleotide


Amino Acid


Monosaccharide


Small Molecule


Chemical


Chemically Synthe
tic Molecule


Antibody mimetic


Vitamin

….

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

17

of
28

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

text 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 inf
ormation and regions
-
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 objec
ts 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 h
as two main objectives.
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 applying

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 que
stions:



Upon what services 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 on 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.5



BBMSC

18

of
28

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 us
ed:



Origin


Identifies the project or Enterprise Use Case that originated 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 taken 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 case
s, the
Component attribute will identify all components where the requirement 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 origin
ally defined. Often this is SUC (System Use Case) but it may be
different.

3.1.

Functionality

for
Second

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 encouraged 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.5



BBMSC

19

of
28

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 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.

<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 do 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.5



BBMSC

20

of
28

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 process to be run on
data sequestered by a trusted
broker that is requested by
commercial entities that wi
sh to
obtain a certificate of compliance
(formal) or simply an assessment of
proficiency as measured with
respect to the Profile.


SUC




Activity: Specify 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.5



BBMSC

21

of
28

Requirements

Origin

Model

View

Controller

High
-
level descriptions of the
processin
g 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.5



BBMSC

22

of
28

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.5



BBMSC

23

of
28

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 a
nd server information to
make navigating and working with the BioPortal services easier. After setting up a
connection 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 needed 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.5



BBMSC

24

of
28

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 of all the latest versions of ontologies stored in Bioportal


terms/concepts

-

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

example url: http://rest.b
ioontology.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.bioontology.org/wiki/index.php/BioPortal_REST_services#Property_Services

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

Returns a set of available properties for a given ontology, it is not poss
ible 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 the 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 property. 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 th
e API key can be retrieved from
the account page.


Example Bioportal Library Usage:

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

25

of
28

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 => "6d3a093c
-
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 a
ccess 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 Biop
ortal, 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} (#{ont
ology.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 retrieved using the
get_terms
and
get_term
methods.


Ex
ample 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.5



BBMSC

26

of
28


# 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 associated properties for a term
in th
e 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 domain 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.range}"

end


5.

Implementation Consideration
s 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.5



BBMSC

27

of
28



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


6.

References


1.

BioPortal REST services
. Available from:
http://www.bioontology.org/wiki/index.php/BioPortal_REST_services
, accessed
25 November 2011.

2.

The National Center for Biomedical Ontology BioPortal
. Available from:
http://bioportal.bioontology.org/
, acc
essed 27 November 2011.

3.

Defining N
-
ary Relations on the Semantic Web, W3C Working Group Note 12
April 2006
. Available from:
http://www.w3.org/TR/swbp
-
n
-
aryRelations/
, accessed
25 November 2011.

4
.

The Foundational Model of Anatomy ontology (FMA)
. Available from:
http://sig.biostr.washington.edu/projects/fm/AboutFM.html
, accessed 27
November 2011.

5.

The Gene Ontology project
. Available from:
http://www.geneontology.org/
,
accessed 27 November 2011.

6.

SNOMED Clinical Terms® (SNOMED CT®)
. Available from:
htt
p://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html
, accessed 27
November 2011.

7.

RSNA RadLex
. Available from:
http://www.rsna.org/informatics/radlex.cfm
,
accessed 27 November 2011.

8.

caTis
sue Suite
. Available from: https://cabig.nci.nih.gov/tools/catissuesuite,
accessed 27 November 2011.

9.

caArray
-

Array Data Management System
. Available from:
https://cabig.nci.nih.gov/tools/caArray, accessed 27 November 2011.

10.

National Biomedical
Imaging Archive
. 2011; Available from:
https://cabig.nci.nih.gov/tools/NCIA, accessed 27 November 2011.

11.

NCI Thesaurus (NCIt)
. Available from:
http://ncit.nci.nih.gov/ncitbrowser/
,
accessed 27 Novembe
r 2011.

12.

The Biomedical Research Integrated Domain Group (BRIDG) Model
. Available
from:
http://www.bridgmodel.org/
, accessed 27 November 2011.

13.

The Open Biological and Biomedical Ontologies
. Available from:
http://www.obofoundry.org/
, accessed 27 November 2011.

14.

Patient Outcomes Service (PODS)
. Available from:
https://wiki.nci.nih.gov/display/caEHR/Patient+Outcomes+Service, accessed 27
November 2011.

15.

Tirmizi,
S.H., et al.,
Mapping between the OBO and OWL ontology languages.

J
Biomed Semantics, 2011.
2 Suppl 1
: p. S3.

16.

BFO Basic Formal Ontology
. Available from:
http://www.ifomis.org/bfo
, accessed
27 November 2011.

QI
-
Bench
Specify

AAS

Rev 0.5



BBMSC

28

of
28

17.

Eclipse Modeling Framework Project (EMF)
. Available from:
http://eclipse.org/modeling/emf/
, accessed 27 November 2011.

18.

ECCF Transform Plugins for Eclipse
. Available from:
https://ncisvn.nci.nih.gov/WebS
VN/listing.php?repname=seminfrastruc&path=%2
Ftrunk%2Feccf%2Feclipse%2Fplugins%2Fgov.nih.nci.si.eccf.transform%2F&rev
=280&peg=280, accessed 27 November 2011.

19.

TopBraid Composer
. Available from:
http://www.topquadrant.com/products/TB_Composer.html
, accessed 27
November 2011.

20.

Liu, T., et al.,
The Imaging Biomarker Ontology: Ontology
-
based Support for
Imaging Biomarker Research
, in
Society for Imaging Informatics in Medicine
2011 Annual

Meeting
2011.

21.

Noy, N.F. and D.L. McGuinness,
A Guide to Creating Your First Ontology.

Stanford Knowledge Systems Laboratory technical report KSL
-
01
-
05 and
Stanford Medical Informatics technical report SMI
-
2001
-
0880, 2001.

22.

Rubin, D.L.,
Creating and
curating a terminology for radiology: ontology modeling
and analysis.

Journal of digital imaging : the official journal of the Society for
Computer Applications in Radiology, 2008.
21
(4): p. 355
-
62.

23.

Rubin, D.L., N.F. Noy, and M.A. Musen,
Protege: a too
l for managing and using
terminology in radiology applications.

Journal of digital imaging : the official
journal of the Society for Computer Applications in Radiology, 2007.
20 Suppl 1
:
p. 34
-
46.

24.

Musen, M.A.,
Domain ontologies in software engineering:

use of Protege with the
EON architecture.

Methods of information in medicine, 1998.
37
(4
-
5): p. 540
-
50.

25.

Musen, M.A., et al.,
PROTEGE
-
II: computer support for development of
intelligent systems from libraries of components.

Medinfo. MEDINFO, 1995.
8 Pt

1
: p. 766
-
70.