QIBO SDD
Rev 0.5
Quantitative Imaging Biomarker Ontology (QIBO)
Software Design Document
June 2012
Rev 0.5
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
11-14-2011
technical issues
0.3
Andrew Buckler
Added design detail
0.4
Andrew Buckler
Prepared for Iteration 1 Testing
6-28-2012
phase
0.5
Andrew Buckler
Prepared for Iteration 2 Design
BBMSC
12-5-2011
6-28-2012
1 of 24
QIBO SDD
Rev 0.5
Table of Contents
1.
EXECUTIVE SUMMARY ................................................................................................ 3
1.1. COMPONENT DESCRIPTION AND PURPOSE ............................................................................. 3
1.2. SCOPE .................................................................................................................................... 4
1.3. PLATFORM DETAILS .............................................................................................................. 4
1.4. REFERENCED STANDARDS ..................................................................................................... 6
2.
DEFINITIONS .................................................................................................................... 7
3.
COMPONENT-LEVEL REQUIREMENTS ................................................................... 8
3.1. FUNCTIONALITY FOR FIRST DEVELOPMENT ITERATION ......................................................... 8
3.2. PERFORMANCE..................................................................................................................... 11
3.3. QUALITY CONTROL ............................................................................................................. 11
3.4. “SUPER USER” AND SERVICE SUPPORT ................................................................................ 11
3.5. UPGRADE / TRANSITION ....................................................................................................... 12
3.6. SECURITY ............................................................................................................................ 12
3.7. REQUIREMENTS FOR SUBSEQUENT ITERATIONS ................................................................... 12
4.
PLATFORM SPECIFIC MODEL .................................................................................. 13
4.1. OVERVIEW ........................................................................................................................... 13
4.2. ASSUMPTIONS AND DEPENDENCIES ..................................................................................... 13
4.3. COMPONENT INTERFACE ...................................................................................................... 14
4.3.1. Interface Model ............................................................................................................ 14
4.3.2. Operations Details for <Interface Name> .................................................................. 14
4.4. MESSAGE INFORMATION MODEL ......................................................................................... 15
4.4.1. Information Model........................................................................................................ 15
4.4.2. Information Model Description .................................................................................... 15
4.5. SERVICE INTERACTIONS ....................................................................................................... 16
4.5.1. Actors ........................................................................................................................... 16
4.5.2. Interaction Details........................................................................................................ 16
4.6. IMPLEMENTATION CONSIDERATIONS ................................................................................... 17
4.6.1. Security ......................................................................................................................... 17
4.6.2. Auditing ........................................................................................................................ 19
4.6.3. Privacy ......................................................................................................................... 20
4.6.4. Error Handling............................................................................................................. 21
4.7. DEPLOYMENT DETAILS ........................................................................................................ 22
4.8. CONSTRAINTS ...................................................................................................................... 23
5.
REFERENCES .................................................................................................................. 23
BBMSC
2 of 24
QIBO SDD
Rev 0.5
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 therapy, 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. Enabled 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 the 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 be 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 biomarkers 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 heterogeneous 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 versioning 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 DB.
BBMSC
3 of 24
QIBO SDD
Rev 0.5
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
indications 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 Instruments & 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 as 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 Physics, 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 Details
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
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
BBMSC
4 of 24
QIBO SDD
Rev 0.5
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 RadLex [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
Group (BRIDG) [16] and LS-DAM
models and other standardized domain
ontologies such as from the Open
Figure 1. Current QIBO concepts are expanded
Biological and Biomedical Ontologies
with those from other relevant models according
(OBO) Foundry [17]. We incorporate
to links we have identified. (Example UML
non-imaging data such as clinical
representation shown behind the colors.)
outcomes by mapping to concepts from
the Patient Outcome Data Service (PODS) [18]. Thus, we create SPARQL endpoints for
discoverable data services, 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 will 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 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
customized version of transform libraries developed as part of the NCI-CBIIT Semantic
Infrastructure project [21, 22]; and (2) export resulting EMF UML into a RDF/OWL
BBMSC
5 of 24
QIBO SDD
Rev 0.5
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 information 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 runtime
Grammar for
specifying clinical
context and
indications for use
RadLex (including
Playbook)
RSNA through
www.radlex.org,or NCBO
Bioportal
Use
Dynamically
read at runtime
Grammar for
representing imaging
activities
Gene Ontology (GO)
GO Consortium,
www.geneontology.org
Use
Dynamically
read at runtime
Nouns for
representing genes
and gene products
associated with
mechanisms of action
International
vocabulary of
metrology --- Basic
and 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 runtime
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 standards. 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 Quantitative 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
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.
BBMSC
6 of 24
QIBO SDD
Rev 0.5
While this is an ongoing effort in developing and implementing a feasible approach to
link these ontologies, we have considered employed an upper ontology approach first
developed by basic Formal ontology (BFO) [25]. BFO is an upper ontology that provides
a formal structure of 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 continant) 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 (LSDAM)
caBIG
Use
Updated on
release
schedule
Data structures for representing
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
Slot
Properties of each concept describing various features and attributes of
the concept; also called roles or properties
BBMSC
7 of 24
QIBO SDD
Rev 0.5
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 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 Yth 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 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 cases, 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 application for which the
requirement was originally defined.
3.1. Functionality for First Development Iteration
Model: Requirements placed on input, output, or significant intermediate data used by
the application.
View: Supported views and other GUI requirements. Note: use of figures for screen
shots is encouraged as necessary to show an essential feature, but not to show
unnecessary implementation detail.
Controller: Functional requirements on logical flow.
BBMSC
8 of 24
QIBO SDD
Rev 0.5
Requirements
Origin
Model
View
Controller
Relationship to external knowledge
sources (e.g., ontologies) needs to
be understood and links are made.
<curation takes place in Protégé,
not part of QI-Bench directly.>
SUC
SUC
QIBO is static
except that
requests may
be made to
extend it.
Activity: Decide if new or existing
biomarker
EA
Existing
Biomarker DB
entries may be
edited or new
ones added.
Existing concepts
and relations are
displayed but also
a blank that user
may choose to fill
in.
Views for a listing
of existing
entries, an edit
panel, and an add
panel for any
given concept.
If a user chooses
to fill in the blank,
then an email is
generated to the
curator for their
consideration.
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.
Scientist defines new data
structures.
Interaction between biology and the
intended imaging process are
sufficiently understood to discern
what is needed to mimic expected
behavior.
Activity: Specify clinical context
(either as first for new biomarker
or as additional for existing
biomarker)
SUC
Views
dynamically
update for new or
modified
instances of
concepts for
clinical context
using Bioportal
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.
A mechanistic understanding or
“rationale” of the role of the
feature(s) assessed by the imaging
test in healthy and disease states is
documented.
BBMSC
SUC
SUC
EA
QIBO
elaborates
concepts for
clinical context,
including links
to FMA,
Snomed, and
GO.
SUC
SUC
9 of 24
QIBO SDD
Rev 0.5
Requirements
Origin
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).
Consensus exists on whether the
test is quantitative, semiquantitative, 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.
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 wish to
obtain a certificate of compliance
(formal) or simply an assessment of
proficiency as measured with
respect to the Profile.
Activity: Specify assay method
(either as first for new biomarker
or as additional for existing
biomarker)
SUC
High-level descriptions of the
processing hardware and software,
highlighting potential weaknesses,
should be provided.
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.
BBMSC
Model
View
Controller
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.
SUC
SUC
EA
SUC
SUC
10 of 24
QIBO SDD
Rev 0.5
Requirements
Origin
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.
Develop a standardized schema for
validation and compliance reports.
Ensure consensus on the XML
schema is attained with all QIBA
participants.
Discover novel imaging biomarkers
using instances of ontology; e.g.
establishing biomarker-targetdisease pairs and link common
target to identify novel biomarkerdisease pairs.
SUC
Model
View
Controller
SUC
3.2. Performance
Non-functional requirements, such as how fast a capability needs to run.
Requirements
Origin
Comment / TI
User interface display and update time needs to feel quick.
AAS
Implication is that can’t
load whole ontologies
but rather work
incrementally.
Design
Guideline
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.
BBMSC
11 of 24
QIBO SDD
Rev 0.5
Requirements
Origin
Comment / TI
Design
Guideline
3.5. Upgrade / Transition
Requirements to support legacy and/or prior versions.
Requirements
Origin
Comment / TI
Design
Guideline
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
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
BBMSC
Origin
Comment / TI
Design
Guideline
12 of 24
QIBO SDD
Rev 0.5
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 of 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 ontology on the
production instance of bioportal involves a few simple steps: signing into bioportal and
uploading QIBO. For subsequent versions 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
BBMSC
13 of 24
QIBO SDD
Rev 0.5
maintained in Git repo and updated
with reference to Jira issues fro the
“QIBO” component
should utilize established mechansims
Dependencies can include external components such as the caGrid Production
environment, other components. 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 port
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 Supported
Interface No. Interface
Name
REST services
described fro
BioPOrtal
Interface Description
Link
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.
BBMSC
14 of 24
QIBO SDD
Rev 0.5
4.3.2.1. <Operation Name>
An overall description on what the operation does. An
Description
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 implementers 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: Exceptions should be defined
separately in the Error Handling section below
BBMSC
15 of 24
QIBO SDD
Rev 0.5
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
caEHR
Type
System
Description
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. The number
BBMSC
16 of 24
QIBO SDD
Rev 0.5
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 information 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 restrict access to only authenticated users or systems?
Yes/No
If Yes then provide the following in detail:
BBMSC
17 of 24
QIBO SDD
Rev 0.5
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
(Authorization) 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:
BBMSC
18 of 24
QIBO SDD
Rev 0.5
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
createAE
BBMSC
Auditing Details

Logged in User

Time stamp of creation

AE Identifier
19 of 24
QIBO SDD
Rev 0.5
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
HIPAA
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
BBMSC
20 of 24
QIBO SDD
Data
Element
Rev 0.5
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. Depending 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. Error 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 code 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 attributes 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
BBMSC
AEException
21 of 24
QIBO SDD
Rev 0.5
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?
BBMSC
22 of 24
QIBO SDD
Rev 0.5
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
BBMSC
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.
Thesaurus, N., https://cabig.nci.nih.gov/tools/NCI_Thesaurus. 2011.
Ashburner, M., et al., Gene ontology: tool for the unification of biology. The Gene
Ontology Consortium. Nature genetics, 2000. 25(1): p. 25-9.
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.
Bug, W.J., et al., The NIFSTD and BIRNLex vocabularies: building
comprehensive ontologies for neuroscience. Neuroinformatics, 2008. 6(3): p.
175-94.
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.
Wang, H., Rector, A., Drummond, N., Horridge M. et al., Frames and OWL Side
by Side. 9th International Protégé Conference, Stanford, California, USA, 2006.
The Foundational Model of Anatomy ontology (FMA). Available from:
http://sig.biostr.washington.edu/projects/fm/AboutFM.html, accessed 27
November 2011.
The Gene Ontology project. Available from: http://www.geneontology.org/,
accessed 27 November 2011.
SNOMED Clinical Terms® (SNOMED CT®). Available from:
http://www.nlm.nih.gov/research/umls/Snomed/snomed_main.html, accessed 27
November 2011.
RSNA RadLex. Available from: http://www.rsna.org/informatics/radlex.cfm,
accessed 27 November 2011.
23 of 24
QIBO SDD
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
BBMSC
Rev 0.5
caTissue Suite. Available from: https://cabig.nci.nih.gov/tools/catissuesuite,
accessed 27 November 2011.
caArray - Array Data Management System. Available from:
https://cabig.nci.nih.gov/tools/caArray, accessed 27 November 2011.
National Biomedical Imaging Archive. 2011; Available from:
https://cabig.nci.nih.gov/tools/NCIA, accessed 27 November 2011.
NCI Thesaurus (NCIt). Available from: http://ncit.nci.nih.gov/ncitbrowser/,
accessed 27 November 2011.
The Biomedical Research Integrated Domain Group (BRIDG) Model. Available
from: http://www.bridgmodel.org/, accessed 27 November 2011.
The Open Biological and Biomedical Ontologies. Available from:
http://www.obofoundry.org/, accessed 27 November 2011.
Patient Outcomes Service (PODS). Available from:
https://wiki.nci.nih.gov/display/caEHR/Patient+Outcomes+Service, accessed 27
November 2011.
Tirmizi, S.H., et al., Mapping between the OBO and OWL ontology languages. J
Biomed Semantics, 2011. 2 Suppl 1: p. S3.
BFO Basic Formal Ontology. Available from: http://www.ifomis.org/bfo, accessed
27 November 2011.
Eclipse Modeling Framework Project (EMF). Available from:
http://eclipse.org/modeling/emf/, accessed 27 November 2011.
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.
TopBraid Composer. Available from:
http://www.topquadrant.com/products/TB_Composer.html, accessed 27
November 2011.
Bench, Q., (www.qi-bench.org).
Grenon, P., B. Smith, and L. Goldberg, Biodynamic ontology: applying BFO in
the biomedical domain. Stud Health Technol Inform, 2004. 102: p. 20-38.
24 of 24