Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out

Biomarker_DB_0.2

VIEWS: 3 PAGES: 27

									Biomarker Database SDD                                           Rev 0.2




Biomarker Database Software Design Document

December 2011
Rev 0.2




Required Approvals:

 Author of this
                        Andrew Buckler
 Revision:

 System Engineer:       Andrew Buckler
                      Print Name                 Signature          Date




Document Revisions:
  Revision        Revised By       Reason for Update         Date
  0.1             Matt Ouellette   First Issue               November 2011
  0.1             Andrew Buckler   Added design detail       December 2011




BBMSC                                                                      1 of 27
Biomarker Database SDD                                                                                                            Rev 0.2




                                                      Table of Contents
1.      EXECUTIVE SUMMARY ................................................................................................ 3
   1.1. COMPONENT DESCRIPTION AND PURPOSE ............................................................................. 3
   1.2. SCOPE .................................................................................................................................... 3
   1.3. PLATFORM DETAILS .............................................................................................................. 5
   1.4. REFERENCED STANDARDS ..................................................................................................... 7
2.      DEFINITIONS .................................................................................................................... 8
3.      COMPONENT-LEVEL REQUIREMENTS ................................................................... 8
   3.1. FUNCTIONALITY FOR FIRST DEVELOPMENT ITERATION ......................................................... 8
   3.2. PERFORMANCE..................................................................................................................... 11
   3.3. QUALITY CONTROL ............................................................................................................. 12
   3.4. “SUPER USER” AND SERVICE SUPPORT ................................................................................ 12
   3.5. UPGRADE / TRANSITION ....................................................................................................... 12
   3.6. SECURITY ............................................................................................................................ 13
   3.7. REQUIREMENTS FOR SUBSEQUENT ITERATIONS ................................................................... 13
4.      PLATFORM SPECIFIC MODEL .................................................................................. 14
   4.1. OVERVIEW ........................................................................................................................... 14
   4.2. ASSUMPTIONS AND DEPENDENCIES ..................................................................................... 15
   4.3. COMPONENT INTERFACE ...................................................................................................... 15
     4.3.1. Interface Model ............................................................................................................ 16
     4.3.2. Operations Details for <Interface Name> .......................................................... 16
   4.4. MESSAGE INFORMATION MODEL ......................................................................................... 17
     4.4.1. Information Model........................................................................................................ 17
     4.4.2. Information Model Description .................................................................................... 19
   4.5. SERVICE INTERACTIONS ....................................................................................................... 19
     4.5.1. Actors ........................................................................................................................... 19
     4.5.2. Interaction Details........................................................................................................ 20
   4.6. IMPLEMENTATION CONSIDERATIONS ................................................................................... 21
     4.6.1. Security ......................................................................................................................... 21
     4.6.2. Auditing ........................................................................................................................ 23
     4.6.3. Privacy ......................................................................................................................... 23
     4.6.4. Error Handling............................................................................................................. 24
   4.7. DEPLOYMENT DETAILS ........................................................................................................ 25
   4.8. CONSTRAINTS ...................................................................................................................... 26
5.      REFERENCES .................................................................................................................. 26




BBMSC                                                                                                                                       2 of 27
       Biomarker Database SDD                                                                                          Rev 0.2




       1. Executive Summary
       1.1. Component Description and Purpose
       The Biomarker DB is ultimately intended to be an RDF-compliant triple store. It is
       created by the QI-Bench Specify app based on REST services to link to ontologies on
       BioPortal, including QIBO, and stores triples in a database based on using the QIBO to
       guide a question-answer paradigm for interacting with domain experts to create W3C-
       compliant SPARQL endpoints. This prototype has been created by starting from the
       early version of the AIM Template Builder so as to intentionally provide the opportunity
       to merge database schemas, as part of the specification for a quantitative imaging
       application includes a computable as well as user-accessible versions of the template
       under which actual measurements will be made, whether algorithmically or user-based.
       We will leverage the existing semantic annotations in caDSR for these data sources and
       APIs, while exploring touchpoints with domain ontologies (such as the BRIDG or LS-
       DAM at NCI, or OBO Foundry domain ontologies) through various mechanisms such as
       the NCI Thesaurus and the NCI Metathesaurus which contains 17 million relationships
       between concepts compiled from 76 different terminology sources enabling the data to
       be integrated with other linked data in the translational research community such as the
       30 billion triples currently in Bio2RDF, or the investigation/study/assay datasets
       available from EBI and NCBI conformant to ISA-TAB and MIBBI standards and
       annotated to OBO Foundry domain ontologies.

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




              QIBO                                     Reference Data Sets, Annotations, and storesanalysis
                                                                                               3. Batch
                                                                                                                        disparate
                                                                  Analysis Results             scripts
                                                                                             ontologies and offers
                                                             Source of clinical study
                                    Quantitative Imaging
                                                                      results                RESTful web services
                                   Specification Language


                                                                                             to access annotated
                                                                                             data [1]. We build on
                 UPICT Protocols, QIBA
                                                                                             top of these services
                  Profiles, entered with                                                     that work with any
                     Ruby on Rails web
                                 service                                                     ontology in NCBO’s
                                                                                             BioPortal [2], including
                                                                                                  4. Output
UPICT Protocols, QIBA                    QIBO-
Profiles, literature                                                                            Clinical and those
                                                                                             QIBO Body of Evidence linked
                                                                                                 BatchMake
papers and other
sources
                                                                          (red edges
                                                                           represent
                                                                                                (formatted to
                                                                                             through it.enable ontology
                                                                                                   Scripts      The
                                                                                                SDTM and/or other
                                                                        biostatistical
                                                                       generalizability)
                                                                                                standardizedis
                                                                                             catalog                 separately
                                                                                                              registrations

                                                                                             curated and updated by
             Figure 1: Semantic workflow supported by the Biomarker DB.
                                                                                             the administrators of
             BioPortal, decoupling knowledge engineering experts who curate the ontologies from
             domain experts who utilize the applications we create in a more user friendly fashion to
       BBMSC                                                                                                                3 of 27
Biomarker Database SDD                                                                           Rev 0.2



support the use of terms and expressions that draw from community efforts to distill
medical and technical knowledge. Phase II of this SBIR proposal will add statistical
robustness to the “initial annotations” using the W3C-recommended “N-ary” relations
(that generalize beyond binary “A relates to B” relations) to create statistically enriched
annotations that may be used to improve the generalizability of the propositions [3].
Establish methods for semantically labeling imaging biomarker data
Our approach will involve two main components: (1) an ontology covering the key
concepts necessary to specify quantitative imaging biomarkers and assay methods, and
(2) an application (Specify) that will guide the researcher to formulate a set of
statements which later is consumed by a query engine (see Aim 1b) in collecting the
reference datasets supporting his/her hypothesis. The ontology: We will extend the
Quantitative Imaging Biomarker ontology (QIBO) [see previous work] to link to existing
established ontologies [4] (Fig. 4). The Basic Formal Ontology (BFO) [5] 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 [6, 7]; and (2) export resulting EMF UML into a RDF/OWL
representation using TopBraid Composer, a powerful semantic modeling environment
[8]. See an example RDF/OWL representation for LSDAM Gene UML class (Fig 4).
                                              RDF Triple Store

                                                 CT       obtained_by
                                                                           CT
                                             Volumetry

                                  used_for           measure_of


                               Therapeutic                        Tumor
                                 Efficacy                         growth



                                                                                          Statistical Analysis
                                                                                           Results (Relation
                                                                                               strength)

                     Specify                                               Formulate       Annotation and
                                                                                           Image Markup,
                                                                                            Non-imaging
                                                                                            Clinical Data


                                                                                            Primary Data:
                                                                                          Images and other
                                                                                              Raw Data


              QIBO                                                                 Reference Data Sets

BBMSC                                                                                                       4 of 27
Biomarker Database SDD                                                                 Rev 0.2




Figure 1: Specify leverages QIBO to specify a hypothesis in the form of RDF triples stored in a
database (store). Formulate then uses these triples to invoke SPARQL queries against web
services (SPARQL end-points) for assembling reference data sets supporting the hypotheses.



1.3. Platform Details
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.
Description:
The Biomarker Database is made up of 4 tables which store the triple and the
supporting terms, ontologies and properties.


Schema:
Table name: bp_ontologies
id        :integer(4)       not null, primary key
name         :string(255)
description :string(255)
abbreviation :string(255)
versionid    :integer(4)
ontologyid :integer(4)
created_at :datetime
updated_at :datetime


Table name: bp_terms
id          :integer(4)       not null, primary key
name           :string(255)
bpid         :string(255)
bp_ontology_id :integer(4)
created_at      :datetime
updated_at      :datetime


Table name: bp_properties
id          :integer(4)       not null, primary key


BBMSC                                                                                        5 of 27
Biomarker Database SDD                                                              Rev 0.2



bp_ontology_id :integer(4)
name           :string(255)
bpid         :string(255)
domain         :integer(4)
range         :integer(4)
created_at      :datetime
updated_at       :datetime


Table name: bp_triples
id       :integer(4)      not null, primary key
domain      :integer(4)
property :string(255)
range      :integer(4)
created_at :datetime
updated_at :datetime



All tables are prefixed with "bp_" for Bioportal, this will likely change in future iterations,
but since the data for ontologies, terms and properties is directly related to Bioportal it
was appropriate to give them that scope. The bp_triples table stores a bp_term for the
domain and the range. The RAILS models that manage these tables automatically
handle the relationships between the different tables. This allows the system to easily
reference the appropriate Ontologies and Terms in the Bioportal system by referencing
the ontologyid property in BpOntology class and property bpid in the BpTerm class. So
when given a BpTriple class it is possible to reference the domain and range, properties
as follows.


Usage:
triple = BpTriple.find(:first)
domain_term = triple.domain
range_term = triple.range


bp_server = Bioportal(:apikey => "6d3a093c-f01e-4003-b616-adcc5889a7fb")
domain_ontology = bp_server.get_ontology(domain_term.bp_ontology.ontologyid)


BBMSC                                                                                     6 of 27
Biomarker Database SDD                                                           Rev 0.2



domain_term = domain_ontology.get_term(domain_term.bpid)
range_ontology = bp_server.get_ontology(range_term.bp_ontology.ontologyid)
range_term = domain_ontology.get_term(range_term.bpid)


# the triple can then be represented as follows
puts "#{domain_ontology.label}:#{domain_term.label} #{triple.property}
#{range_ontology.label}:#{range_ontology.label}"


Triple Creation:
Triples are created using the BioportalsController create_triple method. The parameters
required are the ontologyid, termid for the domain, propertyid and termid for the range.
The system currently only supports the creation of triples within the same ontology, this
is something that we hope to be able to support in the future, the ability to create triples
from different ontologies.

1.4. Referenced Standards
Provide references to the standards as well as technical standards that component is
using.
E.g.
Standards such as - HL7V3, BRIDG2.1, ISO 21090 Data types
Domain             Description
Standards
BRIDG v2.1
HL7v3
ISO 21090
…….
……..


Technology Standards such as SOAP 1.1, Http, Https, SAML
Technology         Description
Standards
SOAP 1.1           Simple Object Access Protocol ver 1.1 is used
                   to interact with the component
SAML v2.0          Simple Assertion Markup Language ver2.0 will
                   be used for security related data


BBMSC                                                                                  7 of 27
Biomarker Database SDD                                                           Rev 0.2




…….
……..


2. Definitions
        The following are terms commonly used that may of assistance to the reader.
        xxx                       Def xxx.




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.



BBMSC                                                                                 8 of 27
Biomarker Database SDD                                                                            Rev 0.2



View: Supported views and other GUI requirements. Note: use of figures for screen
shots is encouraged as necessary to show an essential feature, but not to show
unnecessary implementation detail.
Controller: Functional requirements on logical flow.
Requirements                              Origin   Model            View                  Controller
Activity: Consider concepts,              EA       State of         Views are defined     Contents of
relations, or properties                           Biomarker DB     to display            Biomarker DB may
                                                   at any given     Biomarker DB          be made available
                                                   time may be      contents.             to local or remote
                                                   displayed.                             viewers.
   Need a platform-independent            SUC
image metadata template editor to
enable the community to define
custom templates for research and
clinical reporting.
   There will be ultimately be a tie in   SUC
to eCRF.
   Relationship to external               SUC
knowledge sources (e.g.,
ontologies) needs to be understood
and links are made.
Activity: Curate new knowledge            EA       QIBO is static   Existing concepts     If a user chooses
representation                                     except that      and relations are     to fill in the blank,
                                                   requests may     displayed but         then an email is
                                                   be made to       also a blank that     generated to the
                                                   extend it.       user may choose       curator for their
                                                                    to fill in.           consideration.
  <curation takes place in Protégé,       SUC
not part of QI-Bench directly.>
Activity: Decide if new or existing       EA       Existing         Views for a listing   If a request is
biomarker                                          Biomarker DB     of existing           made to add, the
                                                   entries may be   entries, an edit      user’s certificate is
                                                   edited or new    panel, and an         checked to see if
                                                   ones added.      add panel for any     they are authorized
                                                                    given concept.        to do so.
   Means for extending Annotation         SUC
Tool templates so that new
experiments can be supported
without programming on the
application (workstation) side is
required.
   Once a template is created, any        SUC
workstation will simply select it to
enable Reference Data Set per the
template.
   Scientist identifies novel             SUC
measurement, observation,
processing step, or statistical
analysis method.
   Scientist defines new data             SUC
structures.


BBMSC                                                                                                     9 of 27
Biomarker Database SDD                                                                           Rev 0.2



Requirements                             Origin   Model               View                Controller
  Interaction between biology and        SUC
the intended imaging process are
sufficiently understood to discern
what is needed to mimic expected
behavior.
Activity: Specify clinical context       EA       QIBO                Views               See ontology
(either as first for new biomarker                elaborates          dynamically         traversal algorithm.
or as additional for existing                     concepts for        update for new or
biomarker)                                        clinical context,   modified
                                                  including links     instances of
                                                  to FMA,             concepts for
                                                  Snomed, and         clinical context
                                                  GO.                 using Bioportal
                                                                      services.
   Describe the patient population       SUC
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        SUC
“rationale” of the role of the
feature(s) assessed by the imaging
test in healthy and disease states is
documented.
   A statement of value to               SUC
stakeholders (patients,
manufacturers, biopharma, etc.),
expressed in the context of the
alternatives is understood (e.g., with
explicit reference to methods that
are presently used in lieu of the
biomarker).
   Consensus exists on whether the       SUC
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.




BBMSC                                                                                                  10 of 27
Biomarker Database SDD                                                                      Rev 0.2



Requirements                           Origin   Model            View                Controller
   The Profile is used to establish    SUC
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         EA       QIBO             Views               See ontology
(either as first for new biomarker              elaborates       dynamically         traversal algorithm.
or as additional for existing                   concepts for     update for new or
biomarker)                                      assay            modified
                                                methods,         instances of
                                                including link   concepts for
                                                to Radlex.       assay methods
                                                                 using Bioportal
                                                                 services.
   High-level descriptions of the      SUC
processing hardware and software,
highlighting potential weaknesses,
should be provided.
   Detailed descriptions of the        SUC
procedures to be used for image
acquisition, analysis and
interpretation of the quantitative
imaging biomarker as a clinical
metric should be included.
   Procedures to be used when          SUC
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       SUC
for validation and compliance
reports. Ensure consensus on the
XML schema is attained with all
QIBA participants.


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




BBMSC                                                                                             11 of 27
Biomarker Database SDD                                                                             Rev 0.2



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




BBMSC                                                                                                   12 of 27
Biomarker Database SDD                                                               Rev 0.2



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




BBMSC                                                                                     13 of 27
Biomarker Database SDD                                                      Rev 0.2




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.
E.g.
Domain Model
All COPPA services comply to a given implementation model of BRIDG, HL7V3, ISO
21090 data types


Domain Model        Description
NCI’s          The component specifications will be based on
Implementation NCI’s restricted implementation of ISO 21090
of ISO 21090   data types
Data types




…                   …


Technology Stack
Specify what technology stack is used to access the component. Only interface-specific
technologies should be described here.
Technology         Affects
Globus             GTK is used to develop this WSRF complaint
Toolkit 4.1        grid service
Tomcat    5.x      Tomcat server will be used to deploy this
                   service




…                  …




BBMSC                                                                            14 of 27
Biomarker Database SDD                                                       Rev 0.2




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
Component will be deployed              A new separate server needs to
in its individual container             be procured for each of the
                                        component installations
Component will deployed in              Institutional Network team
the DMZ                                 needs to ensure this is
                                        possible


…                                       …


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
caGrid Production        Component relies on caGrid Production
Environment              environment for advertisement and
                         discovery
Subject Registry         Uses the Subject Registry Service to
Service                  retrieve additional subject information




…                        …



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.

BBMSC                                                                              15 of 27
Biomarker Database SDD                                                          Rev 0.2




  4.3.1. Interface Model
This section is a placeholder for an overall description of the interfaces implemented.
Implemented Supported        Interface Description           Link
Interface No. Interface Name
AE-INF1         AEManagement Contains                        Provide the link to the
                             functionality to                WSDL or Java
                             manage the                      Interface Specification
                             lifecycle of an                 (eg. javadocs)
                             AE                              depending upon the
                                                             platform
AE-INF2         AEQuery            Contains                  Provide the link to the
                                   functionality to          WSDL or Java
                                   retrieve an AE            Interface Specification
                                                             (eg. javadocs)
                                                             depending upon the
                                                             platform




                …                                            …


Provide the UML diagrams describing the above mentioned interfaces.


  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.

4.3.2.1. <Operation Name>
Description          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             Describe the controls used to enforce the security
Controls             requirements for this operation
Inputs               Provide the syntactic detail of the input parameters (eg. Link

BBMSC                                                                                  16 of 27
Biomarker Database SDD                                                         Rev 0.2



                    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           List down all the possible exception conditions along with its
Conditions          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.
The following diagram is a works-in-progress. It is neither complete with respect to the
information model described in the Application Architecture Specification, nor are the
QISL and AIM Template aspects properly integrated. However, it is an accurate
depiction of the current database schema and establishes a baseline for subsequent
development:




BBMSC                                                                                17 of 27
Biomarker Database SDD   Rev 0.2




BBMSC                        18 of 27
Biomarker Database SDD                                                            Rev 0.2




    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
Object Name                       AdverseEvent
Description of the Object         Represents the Adverse Event
                                  occurring within the system
Link to the Object                Provide link to the XSD or the Java Interface
Specification                     Specifications
Attribute Name       Type         Description
Id                   String /     Stores the Id of the Adverse Event
                     Number /
                     II etc.




…                                 …




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


BBMSC                                                                                 19 of 27
Biomarker Database SDD                                                        Rev 0.2



                                to input Adverse Event Data
Subject                         Uses the Subject Registry Service
Registry                        to retrieve additional subject
Service                         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
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         Producer /    Data           Link             Description
Name          Consumer
Subject       Producer      Subject   Provide link to       AE Service
Registry                    Informati the XSD or            relies on
Service                     on        Java                  Subject Registry
v1.0                                  Specification         Service to
                                      defining the          retrieve
                                      data element          additional
                                      exchanged             subject
                                                            information
Scheduled Consumer          AE        Provide link to       AE Service
Calendar                    Informati the XSD or            supplies AE
Service                     on        Java                  information to
v1.0                                  Specification         the Treatment
                                      defining the          Plan service
                                      data element
                                      exchanged




…                                                           …




BBMSC                                                                              20 of 27
Biomarker Database SDD                                                       Rev 0.2




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           Yes/No
place to restrict access to only authenticated users or systems?

If Yes then provide the following in detail:
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                   Yes/No
(Authorization) to ensure that access to information is granted to
only the authorized users / systems?
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       Yes/No
from it?

If Yes then provide the following in detail:



BBMSC                                                                             21 of 27
Biomarker Database SDD                                                       Rev 0.2



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               Yes/No
privileged? And if yes, is it at risk from any external threats or
vulnerabilities?
If Yes then provide the following in detail:
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 /      Yes/No
regulatory compliance either at federal, state, local or institutional
level ?
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          Yes/No
such as SSL, Firewall protection etc.

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.




BBMSC                                                                             22 of 27
Biomarker Database SDD                                                            Rev 0.2




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


Operation         Auditing Details
Name
createAE
                                 Logged in User
                                 Time stamp of creation
                                 AE Identifier
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

BBMSC                                                                                  23 of 27
Biomarker Database SDD                                                           Rev 0.2




       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            Privacy        Security Control in           Access Requirement
Element         Regulation     Place
Subject         HIPAA          Component will use            User needs to be
                               caGrid based Grid             member of Study Co-
                               Grouper                       ordinator or Site
                               Authorization                 Co-ordinator group
                               controls to
                               restrict access




  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
BBMSC                                                                                 24 of 27
Biomarker Database SDD                                                             Rev 0.2



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                  AEException
Description of the Error           Represents the Exception object in
Object                             the AE Service
Link to the Object                 Provide link to the XSD or the Java Interface
Specification                      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                Impact
Details
Deployment                Provide details of the different deployment
Modes                     mode provided by this detail.
Performance               Provide specific measures of the
details                   component’s expected performance for each
                          component operation.
Scalability               Does this component need to support a
details                   particular number of requests? Are there
                          performance requirements for the component?

BBMSC                                                                                  25 of 27
Biomarker Database SDD                                                           Rev 0.2



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?




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.      BioPortal REST services. Available from:
http://www.bioontology.org/wiki/index.php/BioPortal_REST_services, accessed 25
November 2011.
2.      The National Center for Biomedical Ontology BioPortal. Available from:
http://bioportal.bioontology.org/, accessed 27 November 2011.
3.     Defining N-ary Relations on the Semantic Web, W3C Working Group Note 12
April 2006. Available from: http://www.w3.org/TR/swbp-n-aryRelations/, accessed 25
November 2011.
4.   Tirmizi, S.H., et al., Mapping between the OBO and OWL ontology languages. J
Biomed Semantics, 2011. 2 Suppl 1: p. S3.
5.    BFO Basic Formal Ontology. Available from: http://www.ifomis.org/bfo, accessed
27 November 2011.

BBMSC                                                                                26 of 27
Biomarker Database SDD                                                  Rev 0.2



6.      Eclipse Modeling Framework Project (EMF). Available from:
http://eclipse.org/modeling/emf/, accessed 27 November 2011.
7.      ECCF Transform Plugins for Eclipse. Available from:
https://ncisvn.nci.nih.gov/WebSVN/listing.php?repname=seminfrastruc&path=%2Ftrunk
%2Feccf%2Feclipse%2Fplugins%2Fgov.nih.nci.si.eccf.transform%2F&rev=280&peg=2
80, accessed 27 November 2011.
8.      TopBraid Composer. Available from:
http://www.topquadrant.com/products/TB_Composer.html, accessed 27 November
2011.




BBMSC                                                                        27 of 27

								
To top