Quantitative Imaging Biomarker Ontology (QIBO) Software Design Document

splashburgerInternet and Web Development

Oct 22, 2013 (4 years and 17 days ago)

177 views

QIBO

SDD

Rev 0.3



BBMSC

1

of
24

Quantitative Imaging Biomarker Ontology (QIBO)

Software Design Document


Dec
ember

2011

Rev
0.3






Required Approvals:

Author of this
Revision
:

Andrew Buckler






System
Engineer:

Andrew Buckler






Print Name


Signature


Date



Document Revisions:

Revision

Revised By

Reason for Update

Date

0.
1

Andrew Buckler

First Issue

9
-
10
-
2011

0.
2

Tiffany Ting Liu

Address BioPortal and other
technical issues

11
-
14
-
2011

0.
3

Andrew Buckler

Added design detail

12
-
5
-
2011


























QIBO

SDD

Rev 0.3



BBMSC

2

of
24

Table of Contents

1.

EXECUTIVE SUMMARY

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

3

1.1.

C
OMPONENT
D
ESCRIPTION AND
P
URPOSE

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

3

1.2.

S
COPE

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

4

1.3.

P
LATFORM
D
ETAILS

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

4

1.4.

R
EFERENCED
S
TANDARDS

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

6

2.

DEFINITIONS

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

7

3.

COMPONENT
-
LEVEL REQUIREMENTS

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

8

3.1.

F
UNCTIONALITY FOR
F
IRST
D
EVELOPMENT
I
TERATION

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

8

3.2.

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

11

3.3.

Q
UALITY
C
ONTROL

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

11

3.4.

“S
UPER USER


AND
S
ERVICE
S
UPPORT

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

11

3.5.

U
PGRADE
/

T
RANSITION

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

12

3.6.

S
ECURITY

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

12

3.7.

R
EQUIREMENTS FOR
S
UBSEQUENT
I
TERATIONS

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

12

4.

PLATFORM SPECIFIC MO
DEL

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

13

4.1.

O
VERVIEW

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

13

4.2.

A
SSUMPTIONS AND
D
EPENDENCIES

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

13

4.3.

C
OMPONENT
I
NTERFACE

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

14

4.3.1. Interface Model

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

14

4.3.2.

Operations Details for <Interface Name>

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

14

4.4.

M
ESSAGE
I
NFORMATION
M
ODEL

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

15

4.4.1. Information Model
................................
................................
................................
........

15

4.4.2. Information Model
Description

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

15

4.5.

S
ERVICE
I
NTERACTIONS

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

16

4.5.1. Actors

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

16

4.5.2. Interaction Details
................................
................................
................................
........

16

4.6.

I
MPLEMENTATION
C
ONSIDERATIONS

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

17

4.6.1. Security

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

17

4.6.2. Audit
ing

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

19

4.6.3. Privacy

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

20

4.6.4. Error Handling

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

21

4.7.

D
EPLOYMENT
D
ETAILS

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

22

4.8.

C
ONSTRAINTS

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

23

5.

REFERENCES

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

23

QIBO

SDD

Rev 0.3



BBMSC

3

of
24

1.

Executive Summary

Imaging biomarkers are developed for use in the clinical care of patients and in the
conduct of clinical trials of therapy. In clinical practice, imaging biomarkers are intended
to (a) detect and characterize disease, before, during or after a course of th
erapy, and
(b) predict the course of disease, with or without therapy. In clinical research, imaging
biomarkers are intended to be used in defining endpoints of clinical trials. A precondition
for the adoption of the biomarker for use in either setting is
the demonstration of the
ability to standardize the biomarker across imaging devices and clinical centers and the
assessment of the biomarker’s safety and efficacy. Currently
qualitative imaging

biomarkers are extensively used by the medical community. Ena
bled by the major
improvements in clinical imaging, the possibility of developing
quantitative

biomarkers is
emerging. For this document “Biomarker” will be used to refer to the
measurement

derived from an imaging method, and “device” or “test” refers to t
he
hardware/software

used to generate the image and extract the measurement.

However, imaging biomarker data and knowledge are not standardized and thus integration and
multi
-
scale analysis of this type of data is limited.
Ontologies and linked data may b
e used to
specify putative imaging biomarkers and related aspects such as clinical context of use.
This specification is used to generate testable hypotheses and reference data sets for
both technical and clinical validation of the biomark
ers according to
the hypotheses
.

1.1.

Component

Description and Purpose

Building upon existing tools and content in NCBO‘s BioPortal, we create a system that
addresses some of these drawbacks.
The Quantitative Imaging Biomarker Ontology
(QIBO) represents and integrates heteroge
neous knowledge in the domain of imaging
biomarkers, for the goal of developing applications to enable the storage and retrieval of
desired quantitative imaging biomarker, to discover novel imaging biomarkers, and to
build
validation
frameworks for imaging

experiments. As of this writing, the QIBO
consists of 488 concepts spanning 9 upper classes, including Experimental Subject,
Biological Intervention, Imaging Agent, Imaging Instrument, Image Post
-
processing
Algorithm, Biological Target, Indicated Biology,

and Biomarker Application. QIBO may
be used to annotate imaging experiments with standardized terms in the ontology and
to generate hypotheses for novel imaging biomarker
-
disease associations.

Using QIBO, the
Specify

application is needed that interfaces to BioPortal as its
repository of ontologies; BioPortal encapsulates disparate ontologies and related
annotated data in one common interface available via REST Web service, and an
application is needed to build on top

of these services

that works 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 underlying representation and versi
oning of the ontologies, but accommodation for
the unique aspects of this application with respect to curation is needed. The output of
this is an RDF store

referred to as the
Biomarker D
B
.

QIBO

SDD

Rev 0.3



BBMSC

4

of
24

1.2.

Scope

The domain of the ontology encompasses imaging biomarkers

for both pre
-
clinical and
clinical applications, featuring molecular imaging due to its particular richness and
biological specificity.

A. Initial curation to collect terms

To gather terms, relationships, and properties of the terms in the imaging biomarker
ontology, At Stanford, we started with a literature review of the journal Molecular
Imaging and Biology. We sampled 22 articles published since 2006. In parallel one of us

(Buckler) distilled terms associated with 95 putative biomarkers in oncology indications
from approximately 43 articles in such journals as JNM, JMRI, Cell, Molecular Imaging
and Biology, and Transgenic Research; 47 putative biomarkers in cardiovascular
i
ndications from approximately 30 articles in such journals as JNM, Molecular Therapy,
Stroke, and Circulation; 52 putative biomarkers in neurology indications from
approximatley 25 journals such as Nuclear Medicine and Biology, NeuroImage, and
Nuclear Inst
ruments & Methods in Physics Research; 22 putative biomarkers in
musculoskeletal indications from approximately 6 articles in such journals as EJNM and
Molecular Imaging; 5 putative biomarkers in endocrinology indications from 3 articles in
such journals a
s PNAS and VIIS conference proceedings; and 4 putative biomarkers
from approximately 19 articles in pulmonary indications from approximately 19 articles
in such jounals as European Respiratory Journal, Proceedings of American Thoracic
Society, Medical Phys
ics, and Thoracic Imaging. We examined methods and results of
experiments reported in the papers, focusing on abstracting terms and relationships that
characterize and annotate an imaging biomarker. This approach allows us to examine
specific instances of
biomarkers and to be able to build the ontology from the bottom up.

B. Reusing other publiclly available ontologies

To build the imaging biomarker ontology , we reviewed a range of publicly available
ontologies, including MeSH (Medical Subject Headings)
[
1
]
, NCI thesaurus
[
2
]
, GO
[
3
]
,
FMA

[
4
]
, and BIRNLex (a controlled terminology for Biomedical Informatics Research
Network)
[
5
]

to adopt or adapt them wherever possible. For example, entities of
anatomical structure were imported from FMA, and entities of biological process were
extracted from GO, MeSH and NCI thesaurus.

1.3.

Platform D
etails

Provide the implementation platform selected for the
component

and also provide the
rationale behind choosing it. Examples of
Component

Implementation can be Java EJB
Service, Web Service, RESTful Service, Grid(caGrid) Service, etc.

We have built the Web Ontology Language (OWL)
-
based ontology using Protégé, a
widely used ontology editing tool
[
6
]
.
Protégé
version 3.4
supports two ontology
modeling paradigms: OWL and frames
, whereas Protégé version 4 supports only OWL
.
We chose to use Protégé version 3.4.4
in developing QIBO.
Desipte of many similarities
between the two languages, Protégé
-
OWL provides description logic reasoning
capability with high expressive power
[
7
]
. classes can be asserted directly in the ontolgy
in both OWL and frames,
describing necessary conditions.
Necessary and sufficient
QIBO

SDD

Rev 0.3



BBMSC

5

of
24

conditions can be only defined in OWL to specify new classes where an OWL classifier
can run to generate inferred hierarchy.

Inferred hierarchy is particularly suitable for
representing the hetergenous knowledge in imaging biomarkers and allows for defining
newly discovered biomarkers. OWL allows for powerful knowledge reasoning, and
thereby is suitable to convey complexity and

richness in imaging biomarker research.

Based on the curation, we first identified top
-
level concepts of the Imaging Biomarker
Ontology that capture major entities appearing in an imaging biomarker experiment.
We also created synonyms and definitions for

classes in the ontology. To ensure
consistency, is
-
a relationship (subsumption) is strictly conserved in every branch of the
ontology. Other relationships are defined as attributes, such as relationships between
the first level classes.

QIBO will be extended to relate and link to other established
ontologies such as
Foundational Medical Anatomy (FMA)

[
8
]
, Gene Ontology (GO)

[
9
]
, SNOMED

[
10
]

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

caTissue

[
12
]
, caArray

[
13
]
,
NBIA

[
14
]

and AIM UML models,
associated
common data elements
(
CDEs
)

and underlying NCIt and other
ontology concepts.

We use NCI
Thesaurus
(NCIt)
[
15
]

and
Metathesaurus with concepts
from
Biomedical Research Integrated Domain
G
roup

(
BRIDG
)

[
16
]

and
LS
-
DAM
models
and other standard
ized

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

[
17
]
.

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

Thus, we create SPARQL endpoints for
discoverable data s
ervices, using the semantic annotation based on the CDEs and the
underlying controlled terminologies
.

We

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

link to existing established ontologies

[
19
]

(Fig. 4)
.
The Basic Formal Ontology (BFO)
[
20
]

upper ontology will be leveraged to align different ontologies through a 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 b
roader knowledge
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

Architect XMI
for LSDAM (or BRIDG) to Eclipse Modeling Framework (EMF) UML format using a
Figure
1
. Current QIBO concepts are expanded
with those from other relevant models according
to links we have identified. (Example UML
representation shown behind the colors.)

QIBO

SDD

Rev 0.3



BBMSC

6

of
24

customized version of transform libraries developed as part of the NCI
-
CBIIT Semantic
Infrastructure projec
t
[
21
,
22
]
; and
(2)

export

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

See an example RDF/OWL representation for LSDAM Gene UML class
(Fig 4).

1.4.

Referenced Standards

In order to support these capabilities, the following strategy will be employed in the
development and/or use of i
nformation models and ontologies (Tables 1 and 2):

Ontologies:

Ontology

Available through

Extend
or just
use?

Dynamic
connection?

Example of use

Systematized
Nomenclature of
Medicine
--
Clinical
Terms (SNOMED
-
CT)

UMLS Metathesaurus,
NCBO BioPortal

Use

Dynamically
read at run
-
time

Grammar for
specifying clinical
context and
indications for use

RadLex (including
Playbook)

RSNA through
www.radlex.org
,or NCBO
Bioportal

Use

Dynamically
read at run
-
time

Grammar for
representing imaging
activities


Gene Ontology (GO)

GO Consortium,
www.geneontology.org

Use

Dynamically
read at run
-
time

Nouns for
representing genes
and gene products
associated with
mechanisms of action

International
vocabulary of
metrology
---

Basic
a
nd general concepts
and associated terms
(VIM)

International Bureau of
Weights and Measures
(
BIPM
)

Use

Updated on
release
schedule

How to represent
measurements and
measurement
uncertainty

Exploratory imaging
biomarkers

Paik Lab at Stanford

Extend

Dynamically
read at run
-
time

Grammar for
representing imaging
biomarkers

Table 1: Ontologies utilized in meeting the functionality


We have started developing tools to enable automatic annotation of imaging
experiments using QIBO and other ontology standa
rds. We have created QI
-
Bench,
open
-
source informatics
tooling used to characterize the performance of quantitative
medical imaging as needed to
specify and support experimental activities for the
statistical validation of quantitative imaging using the Qu
antitative Imaging Biomarker
Ontology (QIBO) and other resources

[
24
]
.
In particular,
as an initial development stage,
we have created a web
-
interface that allows users to access the terms in QIBO and to
link to terms in other ontologies. This
interface also allows users input novel biomarker
QIBO

SDD

Rev 0.3



BBMSC

7

of
24

instances annotated by terms in QIBO. The new biomarker instance will be reviewed. If
needed new terms that best annotate the novel biomarker will be added to QIBO.


While this is an ongoing effort in dev
eloping and implementing a feasible approach to
link these ontologies, we have considered
employed
an uppe
r ontology approach first
developed by basic Formal ontology (BFO)
[
25
]
.
BFO is an upper ontology that provides
a formal structure o
f upper level abstract classes that has been adapted by the Open
Biological and Biomedical Ontologies

(OBO) foundry, a large collaborative effort for the
goal of creating orthogonal and
interoperable
ontologies in biomedical research.
Upper
concepts in BFO are classified as continuant

(which further classified as independent
continuant and dependent conti
nant)

and occurrent

with respect to time.



As a practical matter, many (but not all) of these ontologies have been collected within
the NCI Thesaurus (NCIT). It may be that there is utility in utilizing this to subsume
included ontologies

as a design consideration.


Information models:

Information Model

Available
through

Extend
or just
use?

Dynamic
connection?

Example of use

Biomedical Research
Integrated Domain
Group (BRIDG)
(drawing in HL7
-
RIM
and SDTM)

caBIG

Use

Updated on
release
schedule

Data structures for clinical trial
steps and regulatory submissions
of heterogeneous data across
imaging and non
-
imaging
observations

Life Sciences Domain
Analysis Model (LS
-
DAM)

caBIG

Use

Updated on
release
schedule

Data structures for represent
ing
multi
-
scale assays and
associating them with
mechanisms of action that link
phenotype to genotype

Annotation and Image
Markup (AIM)

caBIG

Extend

Updated on
release
schedule

Data structures for imaging
phenotypes

Table 2: Information Models utilized
in meeting the functionality

2.

Definitions

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

Ontology

An explicit specification of a conceptualization

to represent

concepts
that exist in a knowledge domain and relationships that
hold among
them.

Entity

Formal explicit description of concepts in a domain of discourse; also
called classes

QIBO

SDD

Rev 0.3



BBMSC

8

of
24

Slot

Properties of each concept describing various features and attributes of
the concept; also called roles or
properties

Relation

Asserted
relationships among entities that are true universally
;
example relationships are is
-
a, has, part
-
of, etc., which are
represented by the ontological inherent hierarchy (is
-
a relation) or
slots (other relations)

Instance

Individuals of entities

Subsumption

Is
-
a relations defined by the hierarchy in the ontology


3.

Component
-
level Requirements

Note that, the normal process of requirements development does not guarantee that
adjacent requirements are directly related. In situations where requireme
nts 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 originated the
requirement.



Component


Identifies all Enterprise Use Case/project
components to which the
requirement applies.



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 requirement
s 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 cases, the
Component attribute will identify all co
mponents 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 application for which the
requirement was originally defined.

3.1.

Functionality

for First Devel
opment Iteration

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

QIBO

SDD

Rev 0.3



BBMSC

9

of
24

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

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


SUC




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


SUC

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.

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

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 Bioport
al
services.

See ontology
traversal algorithm.

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




QIBO

SDD

Rev 0.3



BBMSC

10

of
24

Requirements

Origin

Model

View

Controller

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

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




QIBO

SDD

Rev 0.3



BBMSC

11

of
24

Requirements

Origin

Model

View

Controller

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




Discover novel imaging biomarkers
using instances of ontology; e.g.
establishing biomarker
-
target
-
disease pairs and link common
target to identify novel biomarker
-
disease pairs.






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.

Requirements

Origin

Comment / TI

Design
Guideline

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








QIBO

SDD

Rev 0.3



BBMSC

12

of
24

Requirements

Origin

Comment / TI

Design
Guideline









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.
















3.7.

Requirements

for Subsequent Iterations

Defined in the SUC but not yet staged for implementation.

Requirements

Origin

Comment / TI

Design
Guideline













QIBO

SDD

Rev 0.3



BBMSC

13

of
24

4.

Platform Specific Model

4.1.

Overview

Provide Technical overview of the platform. This includes the Domain Model and
includes technology stack. This information can be a reference to a separate document
if a number of components comply with the same platform.

Bioportal is an
open repository o
f biomedical ontologies that provides access to
ontologies.
The first version of the ontology is now on bioportal at
http://bioportal.bioontology.org/ontologies/46341
.
Publishing the QIBO on
tology on
the
production instance of
bioportal involves a few simple steps: signing into bioportal and
uploading QIBO.
For subsequent version
s

of QIBO,
we will use the
Specify

git
repository that is already established.



Domain Model

Description

NCI’s
Implementation of
ISO 21090 Data
types

The
component

specifications will be based on NCI’s
restricted implementation of ISO 21090 data types

QI
-
Bench

Spanning Information Model


Technology Stack

Specify what technology stack is used to access the
component
. Only interface
-
specific
technologies should be described here.

Technology

Affects

Protégé 3.4.4

QIBO is curated in Protégé and represented in OWL

NCBO BioPortal

QIBO is uploaded to BioPortal and access by applications
including
Specify

using REST services as documented in
the Application Architecture Specification


4.2.

Assumptions and Dependencies

This section enumerates any assumptions made in this specification as well as any
dependencies.


Assumptions can include deployment environment

constraints such as network
connectivity, lack of firewalls etc.

Assumptions

Affects

Definitive version of QIBO is
Individuals wishing to extend the QIBO
QIBO

SDD

Rev 0.3



BBMSC

14

of
24

maintained in Git repo and updated
with reference to Jira issues fro the
“QIBO” component

獨ou汤⁵瑩汩ze⁥獴sb汩獨ed me捨an獩ms


Dependencies can include external components such as the caGrid Production
environment, other
component
s. This section can include both business as well as
technical dependencies

Dependency

Description

OBO Foundry
concepts


NCBO BioPortal
service capability



4.3.

Component

Interface

This section should provide details of the
component

interfaces implemented by this
specification. A UML model with details of the main entry point of the
component

should
be included. The content would depend on the technology binding used for this model.
For example for a
component

implemented as java API, this could be the UML model
showing the main java interfaces. For a web service this could show the service po
rt
type. For a web application implementation this should include screen shots. Details of
the major
component

interfaces should be presented as part of this section such as java
interface, WSDL portTypes.

4.3.1.

Interface Model

This section is a placeholder for
an overall description of the interfaces implemented.

Implemented
Interface No.

Supported
Interface
Name

Interface Description

Link


REST services
described fro
BioPOrtal


See Specify AAS


4.3.2.

Operations Details for
<Interface Name>

This section should describe in detail the operations for each of the interfaces within the
component
. Each operation should be listed separately and described.

NOTE:
This section should be repeated for each implemented interface.

QIBO

SDD

Rev 0.3



BBMSC

15

of
24

4.3.2.1.

<Operation Name>

Descript
ion

An overall description on what the operation does. An
activity diagram showing the details of the operation can be
optionally included.

Pre
-
Conditions

Specify any platform specific pre
-
conditions for invoking this
operation. (Eg. User needs to have a
X.509 Grid Proxy to
invoke this secured operation)

Security
Controls

Describe the controls used to enforce the security
requirements for this operation

Inputs

Provide the syntactic detail of the input parameters (eg. Link
to XSD in GME)

Outputs

Provide
the syntactic detail of the output parameters (eg.
Link to XSD in GME)

Post
-
Conditions

Provide details about the state of the system after this
operation is executed successfully. Also describe any state
changes for the data types in this operation

Exception
Conditions

List down all the possible exception conditions along with its
error code and error message

Notes

Include additional implementation details.


4.4.

Message Information Model

This section describes the information model of the messages sent

to the
component
.
This should match the semantic profile detailed above. It should include a UML model
showing the object model for the
component
. It should also include a detailed
description of the model elements in a tabular format. This section should

also include
artifacts such as an xml schema as required for the technology binding.

4.4.1.

Information Model

A UML diagram showing the
component

object model.

4.4.2.

Information Model Description

This section should include a detailed description of the
component

object model. This
object model is the external facing object model which the clients of the
component

will
use to interact with the
component
. This can include a tabular description of objects and
attributes of the
component

model. Any artifacts that imp
lementers of this
component

need to adhere such as an xml schema or java interfaces should be referred to here.

NOTE: the following table should be repeated for each entity which acts as an input or
output parameter within the Information Model. Note: Exc
eptions should be defined
separately in the Error Handling section below

QIBO

SDD

Rev 0.3



BBMSC

16

of
24

Object Name

AdverseEvent

Description of the Object

Represents the Adverse Event occurring within
the system

Link to the Object
Specification

Provide link to the XSD or the Java
Interface
Specifications

Attribute Name

Type

Description

Id

String /
Number / II
etc.

Stores the Id of the Adverse Event













4.5.

Service Interactions

This section describes the actors involved with the
component

and the dynamic
behavior of the
component
. It should include details of
component

behavior in all
significant service interactions.

An interaction diagram illustrating the interaction should also be included in this section.

4.5.1.

Actors

A description of the actors involved in
component

interactions.

Name

Type

Description

caEHR

System

System interacts with the
component

to input
Adverse Event Data

Subject
Registry
Service


Uses the Subject Registry Service to retrieve
additional subject information













4.5.2.

Interaction Details

Provide the interaction details between this
component

and other actors. Describe the
technology used for this interaction. Also provide the exact version of the
component

to
be used and the data specifications to adhere to for a particular interaction. Th
e number
QIBO

SDD

Rev 0.3



BBMSC

17

of
24

of consumers of the
component

can always increase in the future. However provide a
notional interaction with a consumer below to describe the specification of the

*Producers provided the data which this
component

needs.

*Consumers consume the data provided by this
component
.

Actor
Name

Producer /
Consumer

Data

Link

Description

Subject
Registry
Service
v1.0

Producer

Subject
Information

Provide link to
the XSD or
Java
Specification
defining the
data element
exchanged

AE
Service relies on
Subject Registry
Service to retrieve
additional subject
information

Scheduled
Calendar
Service
v1.0

Consumer

AE
Information

Provide link to
the XSD or
Java
Specification
defining the
data element
exchanged

AE Service supplies
AE informat
ion to the
Treatment Plan
service



















4.6.

Implementation Considerations

The following sections can optionally be used to specify any implementation specific
details for this
component
.

4.6.1.

Security

Provide technical specification on security requirements to access this
component
. This
includes authentication, authorization, encryption, and other LOA requirements.

Access Control

Does the
Component

require Access Control mechanism to be in
place to r
estrict access to only authenticated users or systems?

Yes/No

If Yes then provide the following in detail:

QIBO

SDD

Rev 0.3



BBMSC

18

of
24

1. Authentication Mechanism used to authenticate the user or external systems

2. Type of Credentials which are required to connect to the
component

3. The minimal LOA which the users/systems need to provide to access the
component

4. Does the
Component

allow anonymous access to its operations

Application (Service) Security [Access Policy]

Does the
Component

incorporate any security controls
(Author
ization) to ensure that access to information is granted to
only the authorized users / systems?

Yes/No

If Yes then provide the following in detail:

1. Explain the Authorization Mechanism used to secure the
component

(Grid
Grouper, CSM, Custom etc.)

2. List down in detail the Authorization Policy which is implemented to restrict
access to information and operations in the
component

to authorized users
only. If the
component

allows Anonymous access list down the operations
which allow Anonymous access
as part of the Authorization Policy. NOTE: If
the Authorization Policy is large, it can be provided as an appendix to this
document

Cryptography

Does the
Component

require encryption of data transmitted to and
from it?

Yes/No

If Yes then provide the
following in detail:

1. The Cryptographic algorithm / mechanisms used for encryption / decryption
of the information

Information Security and Risk Management

Is the information served by the
component

confidential or
privileged? And if yes, is it at risk from any external threats or
vulnerabilities?

Yes/No

If Yes then provide the following in detail:

QIBO

SDD

Rev 0.3



BBMSC

19

of
24

1. Policy against unauthorized access, use, disclosure, disruption, modification
or destruction of information served by the
component
.

2. The possible risks to the
component

and the ways to reduce or mitigate
these risks

Legal, Regulations, Compliance
and Investigations

Does the information served by the
component

fall under any legal /
regulatory compliance either at federal, state, local or institutional
level ?

Yes/No

If Yes then provide the following in detail:

1. List all the legal / regulatory compliance which the
component

has to cater
too

2. The security controls in place to ensure that the legal / regulatory compliance
is met

Telecommunications and Network Security

Does the
component

need any network or transport level security
such as SSL, Firewall protection etc.

Yes/No

If Yes then provide the following in detail:

1. Transport level security requirements such as SSL and how it has been
achieved in the
component

2. Network
requirements such as firewall configurations, DMZ configurations
etc.

4.6.2.

Auditing

Provide auditing requirements for the
component
. The level of auditing required, what
interactions need to be audited etc.


Operation
Name

Auditing Details

createAE



Logged in

User



Time stamp of creation



AE Identifier

QIBO

SDD

Rev 0.3



BBMSC

20

of
2
4

queryAE

None










Entity Name

Auditing Details

AdverseEvent

Following operations for this entity are audited



Creation



Updating



Deletion











Also provide information about the technology used
for auditing purposes and additional
details like how long the audit information should be available, how to access audit
information etc.

4.6.3.

Privacy

Dataset should be analyzed for various federal regulations. Specify if the
component

implements privacy policy (such as HIPPA, 21 CFR Part 11, PHI etc).


Based on each of these regulatory requirements:



Identify the data which requires privacy



Provide details of various controls which will be put in place to ensure this privacy



List down
the requirements which a user needs to fulfill to gain access to this
private data



Also mention about breach of privacy scenario and how it will be handled
(optional).

Data
Element

Privacy
Regulation

Security Control in
Place

Access Requirement

Subject

HI
PAA

Component

will use
caGrid based Grid
Grouper Authorization
controls to restrict access

User needs to be member
of Study Co
-
ordinator or
Site Co
-
ordinator group

QIBO

SDD

Rev 0.3



BBMSC

21

of
24

Data
Element

Privacy
Regulation

Security Control in
Place

Access Requirement













4.6.4.

Error Handling

Provide technical specification on how the errors will be raised by the
component

and
what information will be provided. Provide a technical model of the error conditions and
its specific meaning.

In this section, provide the technical specification on how

the errors will be raised by the
component

and what information will be provided. Provide a technical model of the error
conditions and its specific meaning.

NOTE: This section should only list the errors which are to be returned to the clients.
The
component

should provide an encapsulation boundary to all the internal errors and
return only the errors which are of use to the client application.

4.6.4.1.

Overview

Provide overview of the error handling and reporting mechanism for the specific
implementation. De
pending upon the technology used to implement the
component

specification, describe in detail the appropriate error reporting mechanism. E.g. In case
of web services it would be web service faults or in case of EJB interface they will be
Java Exceptions.

4.6.4.2.

E
rror Object Details

Provide technology specific details about eacht attribute and its data type contained
within the error object, which can be used to describe the error condition that occurred.
It is recommended that each error object contain a unique co
de which can be used to
identify the error condition programmatically. It should also be supported by a human
readable message which can be used for display purposes. Also an attribute describing
the criticality of the error can be present as well. Also an

attribute describing the
criticality of the error (FATAL, MAJOR, MINOR, etc.) can be present as well.



In case of an EJB Interface these attributes become exception of the exception
object as class attributes.



In case of a WebService interface these attrib
utes can be using the Error Code,
String and Message fields of a SOAP Fault. Additional information like severity
etc. can be represented in form of a Structured XML which can be included in the
message part of the SOAPFault.


Error Object Name

AEException

QIBO

SDD

Rev 0.3



BBMSC

22

of
24

Description of the Error
Object

Represents the Exception object in the AE
Service

Link to the Object
Specification

Provide link to the XSD or the Java Interface
Specifications

Attribute Name

Type

Description

Code

CD

Provides the Error Code

Message

ST

Provides the Error Message

Severity

CD

Provides the type of error (eg. FATAL, MAJOR,
MINOR etc.)





4.7.

Deployment Details

The following sections can optionally be used to specify any deployment specific details
for this
component
.

Deployment
Details

Impact

Deployment Modes

Provide details of the different deployment mode provided
by this detail.

Performance
details

Provide specific measures of the
component
’s expected
performance for each
component

operation.

Scalability details

Does this
component

need to support a particular number
of requests? Are there performance requirements for the
component
?

Discovery

How can clients call this
component
? For example if this is
an application it would be installed on their computers,
downloaded
from a public web site etc.

Uptime

Provide the details of the uptime provided by this
implementation of the
component
.

Failover

Does this
component

need to provide hot failover? If yes,
then how should it be handled at
component

/ database
levels etc?







QIBO

SDD

Rev 0.3



BBMSC

23

of
24


4.8.

Constraints

This section should include any additional constraints on the
component

that have not
been covered in the previous sections.

Constraints

Impact








5.

References


1.

Lowe, H.J. and G.O. Barnett,
Understanding and

using the medical subject
headings (MeSH) vocabulary to perform literature searches.

JAMA : the journal
of the American Medical Association, 1994.
271
(14): p. 1103
-
8.

2.

Thesaurus, N.,
https://cabig.nci.nih.gov/tools/NCI_Thesaurus.

2011.

3.

Ashburner, M.,

et al.,
Gene ontology: tool for the unification of biology. The Gene
Ontology Consortium.

Nature genetics, 2000.
25
(1): p. 25
-
9.

4.

Rosse, C. and J.L. Mejino, Jr.,
A reference ontology for biomedical informatics:
the Foundational Model of Anatomy.

Journal

of biomedical informatics, 2003.
36
(6): p. 478
-
500.

5.

Bug, W.J., et al.,
The NIFSTD and BIRNLex vocabularies: building
comprehensive ontologies for neuroscience.

Neuroinformatics, 2008.
6
(3): p.
175
-
94.

6.

Rubin, D.L., N.F. Noy, and M.A. Musen,
Protege:
a tool 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.

7.

Wang, H., Rector, A., Drummond, N., Horridge M. et
al.,
Frames and OWL Side
by Side.

th International Prot g Conference, tanford, California, , .

8.

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

9.

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

10.

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

11.

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

QIBO

SDD

Rev 0.3



BBMSC

24

of
24

12.

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

13.

caArray
-

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

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

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

20.

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

21.

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

22.

ECCF Transform Plugins for Eclipse
. Available from:
https://ncisvn.nci.nih.gov/WebSVN/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.

23.

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

24.

Bench, Q., (
www.qi
-
bench.org)
.

25.

Grenon, P., B. Smith, and L. Goldberg,
Biodynamic ontology: applying BFO in
the biomedical domain.

Stud Health Technol Inform, 2004.
102
: p. 20
-
38.