“Specify” Architecture Specification - QI-Bench

attentionclewInternet και Εφαρμογές Web

2 Φεβ 2013 (πριν από 4 χρόνια και 6 μήνες)

291 εμφανίσεις

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

1

of
14


QI
-
Bench “Specify”

Architecture Specification


June 2011

Rev
0.1






Required Approvals:

Author of this
Revision
:

Andrew J. Buckler






System Engineer:

Andrew J. Buckler






Print Name


Signature


Date


Document Revisions:

Revision

Revised By

Reason for Update

Date

0.1

AJ Buckler

Initial version

June 2011



































QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

2

of
14

Table of Contents

1.

EXECUTIVE SUMMARY

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

3

1.1.

P
URPOSE AND
S
COPE

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

3

1.2.

T
ERMS
U
SED IN
T
HIS
D
OCUMENT

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

3

2.

STRUCTURE OF THE APP
LICATION

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

4

2.1.

D
ATASTORES

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

6

2.1.1. Quantit
ative Imaging Biomarker Ontology (QIBO)

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

6

2.1.2. Linked Ontologies

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

6

2.1.3. Biomarker DB

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

6

2.2.

A
CTIV
ITIES

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

6

2.3.

O
NTOLOGY
T
RAVERSAL
A
LGORITHM

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

7

2.4.

A
SSUMPTIONS

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

8

2.5.

D
EPENDE
NCIES

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

8

3.

SYSTEM
-
LEVEL REQUIREMENTS

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

8

3.1.

F
UNCTIONALITY FOR
F
IRST
D
EVELOPMENT
I
TERATION

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

9

3.2.

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

11

3.3.

Q
UALITY

C
ONTROL

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

12

3.4.

“S
UPER USER


AND
S
ERVICE
S
UPPORT

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

12

3.5.

U
PGRADE
/

T
RANSITION

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

12

3.6.

S
ECURITY

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

13

3.7.

R
EQUIREME
NTS FOR
S
UBSEQUENT
I
TERATIONS

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

13

4.

DEPLOYMENT MODEL(S)

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

13

5.

IMPLEMENTATION CONSI
DERATIONS AND RECOMM
ENDATIONS FOR
TECHNICAL REALIZATIO
N

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

14

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

3

of
14

1.

Executive Summary

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

1.1.

Purpose and Scope

Specifically, the “
Specify”

app is developed to allow users to:




Specify context for use and assay methods.



Use consensus terms in doing so.

From a technology point of view,
Specify

refers to the part of the project most

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


This representation is used downstream.


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

Most literally,
Specify

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

instance of the functionali
ty for more sophisticated users.

1.2.

Terms Used in This Document

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

AAS


Application Architecture Specif
ication

ASD


Application Scope Description

BAM


Business Architecture Model

BRIDG

Biomedical Research Integrated Domain Group

caBIG


Cancer Biomedical Informatics Grid

caDSR

Cancer Data Standards Registry and Repository

CAT


Composite Architecture Team

CBIIT


Center for Biomedical Informatics and Information Technology

CFSS


Conceptual Functional Service Specification

CIM


Computational Independent Model

DAM


Domain Analysis Model

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

4

of
14

EAS


Enterprise Architecture Specification

ECCF


Enterprise Conformance a
nd Compliance Framework

EOS


End of Support

ERB


Enterprise Review Board

EUC


Enterprise
Use
-
case

IMS


Issue Management System (Jira)

KC


Knowledge Center

NCI


National Cancer Institute

NIH


National Institutes of Health

PIM


Platform Independent Model

PSM


Platform Specific Model

PMO


Project Management Office

PMP


Project Management Plan

QA


Quality Assurance

QSR


FDA’s Quality System Regulation

SAIF


Service Aware Interoperability Framework

SD
D


Software Design
Document

SIG


Service Implementation Guide

SUC


System Level Use
-
case

SME


Subject Matter Expert

SOA


Service

Oriented Architecture

SOW


Statement of Work

UML


Unified Modeling Language

UMLS


Unified Medical Language System

VCDE


Vocabularies & Common Data Elements

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

2.

Structure of the Application



Describe the application in macro and its overall organization



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

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

5

of
14



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



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

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

model:


QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

6

of
14

Specify

is defined as an implementation of the following behavioral model:


2.1.

Datastores

2.1.1.

Quantitative Imaging Biomarker Ontology (QIBO)

knowledge representation for quantitative imaging biomarker concepts and relations

(see vvv.doc)

2.1.2.

Linked Ontologies

existing onto
logies like FMA, Snomed, Radlex, GO, …

2.1.3.

Biomarker DB

linked concept instances that represent biomarkers

2.2.

Activities

Activity

Model

View

Controller

consider concepts,
relations, or properties

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

Views
are defined to
display Biomarker DB
contents.

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

curate new knowledge
representation

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

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

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

decide if new or existing
biomarker

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

Rev 0.1



BBMSC

7

of
14

Activity

Model

View

Controller

edited or new o
nes
added.

panel, and an add panel
for any given concept.

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

specify clinical context
(either as first for

new
biomarker or as
additional for existing
biomarker)

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

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

See ontology traversal
algorithm.

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

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

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

See ontology traversal
algorithm.

2.3.

Ontology Traversal Algorithm

<from an email chain… clean up in later versions of spec as it matures>

I am working with collaborators at Stanford (as per copy) on a

project using Ruby on Rails.


We hope to
interface to BioPortal for access to FMA, GO, Snomed, and Radlex. We call these “linked ontologies” in
the sense that they are accessed via a “master” ontology called the Quantitative Imaging Biomarker
Ontology whe
re most of the value is in the relations, though the is
-
a hierarchy is also important.


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

1.

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

2.

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

3.

For each such Relation:

a.

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

b.

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

c.

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

d.

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

i.

Store a “triple” with the

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

e.

Else, for the selected term in the QIBO we recurse starting again at step 1 above (which
has the effect of navigating the ontology using the relatio
ns identified in it to enumerate a
sequence of terms for disparate concepts but through the links, and for each term
allowing as deep or shallow into the respective is
-
a hierarchies as desired by the user).


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


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


This algorithm would build a dynamic display


and a database to match it


according to the structure
identified by following the relations.

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

8

of
14

2.4.

Assumptions

In this section please addr
ess the following questions:



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



Are there any key assumptions that are being made?

2.5.

Dependencies

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

Description

Doc Title

Doc
Version

<business friendly description>

<document title>

<document
version>

3.

System
-
level Requirements

Note that, the normal process of

requirements development does not guarantee that
adjacent requirements are directly related. In situations where requirements are tightly
related or where requirements are to be considered in the context of an upper level
requirement, explicit parent
-
chi
ld 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 proj
ect or Enterprise Use Case that originated the
requirement.



Comment / TI


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



Design Guideline


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

Requirements may, and often do, apply to multiple components. In such 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 program for which the
requirement was originally defined. Often this i
s SUC (System Use Case) but it may be
different.

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

9

of
14

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: us
e of figures for screen
shots is encouraged as necessary to show an essential feature, but not to show
unnecessary implementation detail.

Controller
: Functional requirements on logical flow.

Requirements

Origin

Model

View

Controller

Activity: Consider
concepts,
relations, or properties

EA

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

Views are defined
to display
Biomarker DB
contents.

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

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


SUC




There will be ultimately be a tie in
to eCRF.

SUC




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


SUC




Activity: Curate new knowledge
representation

EA

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

Existing concepts
and relations are
displayed but
also a blank that
user may

choose
to fill in.

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

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


SUC




Activity: Decide if new or existing
biomarker

EA

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

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

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

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


SUC




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

SUC




QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

10

of
14

Requirements

Origin

Model

View

Controller

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


SUC




Scientist defines new data
structures.

SUC




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


SUC




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

EA

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

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

See ontology
traversal algorithm.

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


SUC




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

SUC




A statement of value to
stakeholders (patients,
manufacturers, biopharma, etc.),
expressed in the context of the
alternatives is understood (e.g.,
with
explicit reference to methods that
are presently used in lieu of the
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 measur
ed;
controls; scoring procedures,
including the values that will be
used (e.g., pos vs. neg; 1+, 2+ 3+);
interpretation; etc.

SUC




QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

11

of
14

Requirements

Origin

Model

View

Controller

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.


SUC




Activity: S
pecify 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
processing hardware and software,
highlighting potential weaknesses,
should be provided.


SUC




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

SUC




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


SUC




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

SUC




3.2.

Performance

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

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

12

of
14

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.




















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
































QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

13

of
14

Requirements

Origin

Comment / TI

Design
Guideline





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





































4.

Deployment Model(s)



Relevant and representative examples of deployment scenarios

QI
-
Bench “Specify” AAS

Rev 0.1



BBMSC

14

of
14

5.

Implementation Considerations and
Recommendations for Technical Realization



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



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